In this post, we will walk through how to configure a Shared PC (Shared Device) using Microsoft Intune.

Shared PCs are commonly used in environments such as:

• Meeting rooms
• Training centers
• Lobby kiosks
• Factory floor terminals

Because multiple users access the same device, credential management and data persistence prevention are critical.

For example:

• User A finishes work but forgets to sign out.
• User B logs in next and unintentionally gains access to User A’s session or data.

This scenario can create serious risks from a privacy and compliance perspective.

To mitigate this risk, Intune provides the Shared multi-user device policy, which allows you to automatically delete user profiles when users sign out.

Official documentation:
Shared or multi-user Windows device settings in Microsoft Intune - Microsoft Intune | Microsoft Learn

Youtube: https://youtu.be/GNIXtqwN6Ck

Step 1. Enroll the Device into Intune

Before deploying policies, the device must first be enrolled in Intune.

Even if the device is intended for shared usage, enrollment should be performed using an administrator or master account.

After enrollment:

1. Create a Security Group for policy deployment
2. Add the shared PC to the group

Only after completing these steps can the policy be successfully assigned.

Step 2. Create a Shared Multi-User Device Policy

Navigation Path

Intune Admin Center > Devices > Windows > Manage Devices > Configuration > Create > New Policy

Select the following options:

• Platform: Windows 10 and later
• Profile Type: Templates
• Template: Shared multi-user device

Then assign a policy name.

Policy Configuration Example

Below is an example configuration:

Key Design Intent of This Configuration

1️⃣ Immediate Profile Deletion Upon Sign-out

When a user signs out, their profile is immediately deleted.

→ Prevents residual data from remaining on the shared device.

Note: The contents of the Downloads folder are also removed after sign-out.

2️⃣ Local Storage Restriction

By disabling local storage, files are not permanently stored on the shared device.

3️⃣ Sign-in Required After Sleep

• Device enters sleep after inactivity
• User must sign in again when waking the device

→ Prevents session hijacking

4️⃣ When Entra ID Sign-in Is Allowed

If users sign in with their M365 (Entra ID) account:

• OneDrive integration is available
• Personal environment is maintained during the session
• Profile is deleted after sign-out

This enables temporary personalization while maintaining shared-device security.

Assigning the Policy

Assign the policy to the device group and create it.

Once applied:

• Users can sign in using Guest or Domain accounts

• A new profile is created each time a user signs in

• Only the Downloads folder is accessible in File Explorer

• Data inside Downloads is removed after sign-out

Considerations When Using Guest Accounts

Guest accounts do not require a password by default.

If a user leaves without signing out:

• The next user may access the active session
• Previous user activity may be visible

This can create a security vulnerability.

Advantages of Allowing Entra ID Sign-in

When Domain (Entra ID) sign-in is enabled:

• Re-authentication is required after screen lock
• Session protection is enhanced
• Overall security posture improves

Depending on the enterprise environment, Entra ID-based sign-in is generally recommended.

Additional Mitigation for Guest-Based Environments

If operating primarily with Guest accounts, consider implementing:

• Automatic forced sign-out after a defined idle time
• Screen lock enforcement
• Additional session protection policies

This can be achieved through PowerShell scripts or Intune remediation scripts.

Previously, I covered how to export a Power BI M Query from Microsoft Sentinel and connect it to Power BI Desktop.

2025.08.24 - [Microsoft 365] - Microsoft 365 Log Management (2): Connecting MDI Logs to Sentinel and Power BI

While doing a self-study to compare Endpoint DLP logs against Microsoft Defender for Endpoint (MDE) logs, I ran into a practical issue: in Power BI, reorganizing column order can be surprisingly annoying when you just want to quickly compare a few fields side by side.

After digging in, I found a very handy trick:

✅ You can take the M Query exported from Sentinel/Log Analytics and paste it directly into Excel Power Query—and it works.

If you do analysis primarily in Excel (filters, quick comparisons, pivot tables), this approach is super practical.

So here’s the clean workflow:

“M Query export → Excel connection → analysis”

Youtube: https://youtu.be/iuyK1sINfzw

TL;DR

• In Sentinel / Log Analytics, export your query using Export to Power BI (as an M query).
• In Excel, open Power Query (Blank Query) and paste the M Query into the Advanced Editor.
• Authenticate using Organizational account, then Close & Load to load it into a worksheet table.
• From then on, just hit Refresh to update logs—no more re-running the same query in the portal.

Step 1) Export the M Query from Sentinel / Log Analytics

In the Azure Portal, navigate to either:

• Microsoft Sentinel > Logs

• Log Analytics Workspace > Logs

Write or select the query for the table > Setting Time range > Share > Export to Power BI (as an M query)

Step 2) Connect to Log Analytics Using M Query in Excel

2-1) Create a Blank Query

In Excel:

• Data > Get Data > From Other Sources > Blank Query

2-2) Paste the M Query into Advanced Editor

In the Power Query Editor:

Open Advanced Editor

Paste the entire M Query you downloaded in Step 1 as-is

A typical exported M Query includes things like:

• The target table
• The query time range

✅ Pro tip: If you need to connect multiple tables, just duplicate the query and update only the table name and time span section. It’s the fastest way to scale your workbook.

2-3) Configure Credentials (Authentication)

On first connection, you may see Edit Credentials.

Organizational account → sign in → Connect

2-4) Load to Excel and Refresh Anytime

Before loading:

• Rename the query to something meaningful
• Then choose Close & Load to load into an Excel worksheet table

• Use filters, sorting, pivots, conditional formatting, side-by-side comparisons… all the Excel stuff that’s great for fast investigation.

And the best part:

✅ Refresh updates the dataset without re-running the whole process in the portal.

Step 3) Bonus: Analyze Logs with Copilot (Excel + OneDrive/SharePoint)

After loading logs into Excel:

1. Save the workbook to OneDrive or SharePoint
2. Ask Copilot to analyze the data

If Copilot recognizes your tables (for example, MDE-related tables), it can quickly do things like:

• Summaries
• Trend analysis
• Outlier/anomaly detection
• Quick insights and narrative explanations

Wrap-up

Using M Query Export from Sentinel/Log Analytics isn’t just for Power BI—you can connect it directly to Excel and build a refreshable log analysis workbook.

If your workflow is centered on:

• Fast comparison
• Column reordering
• Filtering
• Pivot-based analysis

…then Excel can be the more efficient tool. And once the dataset is in OneDrive/SharePoint, Copilot becomes an extra boost for rapid investigation.

M365 Log Management (4): Building a Windows Update Dashboard from Update History (Intune + Log Analytics + Power BI)

Recently, I’ve been getting more and more interested in visualizing operational logs and device records in a Power BI dashboard. In the Microsoft ecosystem, one of the biggest advantages is that the reporting and data pipelines are designed by the same vendor that built the platform, which often makes the integration more efficient than many third‑party approaches.

At first, I considered pulling everything with PowerShell, but I found that Intune policies + Log Analytics can load the relevant Windows Update signals with far less friction—and then you can build a dashboard on top of them quickly.

This post walks through how to create a Windows Update dashboard using Windows Update for Business reports, Azure Log Analytics, and a Power BI template.

Youtube: https://youtu.be/ToqAFJpoh_g

What You’ll Need (Requirements)

To build the dashboard described here, you’ll need:

• An Azure subscription
• A Log Analytics workspace
• Devices enrolled and managed with Microsoft Intune
• Power BI Desktop (to open the template and customize the report)

Reference Materials (Official/Community)

These were the key resources used while implementing the solution:

• Windows Update for Business reports overview - Windows Update for Business reports | Microsoft Learn
• Tailor Windows Update for Business reports with Power BI | Windows IT Pro Blog
• Configure devices using Microsoft Intune - Windows Update for Business reports | Microsoft Learn

High-Level Flow (How the Data Gets to Your Dashboard)

At a high level, the process looks like this:

1. Intune policy enables required diagnostic/telemetry settings on devices
2. Windows Update for Business reports is enabled and connected to your Log Analytics workspace
3. Devices upload update status signals → stored in Log Analytics tables (e.g., tables prefixed with UC*)
4. A Power BI template queries the Log Analytics workspace and visualizes update health

Step 1) Configure Intune Devices for Windows Update for Business Reports

This step ensures that devices can send the required diagnostic data (including device name, if needed for reporting clarity). I followed the Microsoft Learn guidance and created a configuration policy using the Settings catalog. 1.%20Windows%20Update%20%EA%B8%B0%EB%A1%9D%EC%9D%84%20%ED%86%B5%ED%95%9C%20%EB%8C%80%EC%8B%9C%EB%B3%B4%EB%93%9C%20%EB%A7%8C%EB%93%A4%EA%B8%B0.loop)

1. Create a Configuration Profile

In Intune admin center:

Devices → Windows

Configuration → Policies → New policy

Platform: Windows 10 and later | Profile type: Settings catalog

Create the profile and give it a name (example used: AllowDeviceNameInDiagnosticData)

2. Add Required Settings

In the Settings catalog, search and add the following:

• Allow Telemetry
  • Category: System
  • Value: Basic
• Configure Telemetry Opt In Settings UX
  • Value: Disabled
• Configure Telemetry Opt In Change Notification
  • Value: Disabled
• Allow device name to be sent in Windows diagnostic data
  • Value: Allowed

3. Assign and Monitor the Policy

• Assign the profile to the target users/devices

• Complete Review + create

• Monitor the deployment status in Intune to confirm devices are checking in successfully 

Step 2) Enable Windows Update for Business Reports and Connect Log Analytics

Once devices are ready, you need to enable Windows Update for Business reports and link it to your Azure subscription and Log Analytics workspace. 

1. Open the Built-In Workbook in Azure

In Azure Portal:

• Go to Monitor

• Select Workbooks > Choose Windows Update for Business reports

• Click Get started 

2. Configure Enrollment (Subscription + Workspace)

• Select your Azure subscription & Log Analytics workspace > Save settings

During this flow, you can see that configuration is handled through Microsoft Graph (the UI surfaces the Graph endpoint being called). 

3. Wait for Data to Populate

The UI mentions it may take up to 24 hours, but in my case it took 48+ hours before data appeared.

4. Confirm Data in Log Analytics

In Log Analytics, the data lands in tables that start with UC (for example, multiple UC* tables will appear once ingestion begins). 

5. Understand Collection / Upload Frequency

Microsoft documentation also lists data types and upload frequency/latency. Practically speaking, you should expect some tables/events to arrive on different cadences (some daily, some per update event, and with latency that can span hours to a day or more). 

Step 3) Tailor the Reports with Power BI

Once data is available in Log Analytics, the easiest path to a polished dashboard is to use the official Power BI template published for Windows Update for Business reports. 

1. Download the Power BI Template

From the Tech Community / Windows IT Pro blog post, download the Power BI template referenced in the guide.

Tailor Windows Update for Business reports with Power BI | Windows IT Pro Blog

2. Copy the Workspace ID

In Azure Portal:

• Open Log Analytics workspaces

• Copy the Workspace ID

3. Open the Template and Load Data

• Open the Power BI template file
• When prompted, paste the Workspace ID

• Click Load 

4. Authenticate

When Power BI prompts for access to the Log Analytics endpoint:

• Choose Organizational account

• Click Connect 

5. View Your Windows Update Dashboard

After authentication completes and data is loaded, the dashboard visuals populate and you can begin customizing pages, KPIs, filters, and device group views. 

Wrap-Up

With just Intune, Log Analytics, and the Power BI template, you can build a practical Windows Update dashboard without writing custom scripts or maintaining a separate data pipeline. The key is getting device diagnostics configured correctly, enabling WUfB reports, and allowing enough time for ingestion to stabilize. 

In the previous post, I covered the flow of managing logs from MDI → Sentinel → Log Analytics API → PowerShell → CSV → BI.

Previous Post:

2025.08.24 - [Microsoft 365] - Microsoft 365 Log Management (2): Connecting MDI Logs to Sentinel and Power BI

While exporting logs using PowerShell, I started to wonder:
As we move toward a more serverless cloud environment, managing logs via scheduled PowerShell scripts means I still need to operate a VM, which increases management overhead.

If you’re only considering cost, scheduling PowerShell scripts on a VM and exporting to SharePoint or OneDrive can be cheaper.
However, from a long-term perspective, I believe it’s time to move away from running scheduled PowerShell scripts on VMs and adopt a serverless approach.

Also, visualizing and managing logs with BI tools can provide valuable insights.
With this in mind, I anticipate that connecting to Microsoft Fabric or similar platforms will eventually become necessary.

In this post, I’ll cover how to export logs to Azure Data Lake Storage (ADLS) Gen2 and connect them to BI.

Youtube : Microsoft 365 Log Management (3): How to connect Sentinel logs to Azure Data Lake Storage Gen 2

Step 1. Create an ADLS Gen2 Storage Account

1. Go to Azure Portal → Search for Storage Accounts

2. Create a Storage Account
In Preferred storage type, select Azure Blob Storage or Azure Data Lake Storage Gen2.

3. Hierarchical Namespace - Check Enable hierarchical namespace.

Data Lake Storage Gen2 is suitable for big data analytics and other data analysis scenarios.

4. Complete the creation and verify the storage account

Step 2. Create an Export Rule

1. Go to Log Analytics Workspace → Settings → Data Export → Create export rule

2. Name your rule

3. Select the tables to export

4. Set the destination to the storage account you created

5. Go to Data storage → Containers to check the exported tables

6. Navigate through subfolders to see that exports occur every 5 minutes

Step 3. Connect to Power BI

1. In Power BI Desktop, go to Get data → More

2. Select Azure → Azure Data Lake Storage Gen2

3. You’ll be prompted to enter a URL

4. Find the DFS URL using Azure Storage Explorer

Go to Storage Account → Storage browser → Download and install Azure Storage Explorer

Connect, navigate to the folder path, and open Properties

Copy the DFS URL

5. Paste the URL into Power BI

6. Enter your credentials (Account Key)

You can find the Account Key under Security + networking → Access keys

7. Connect and then Combine & Transform Data

Unlike saving to SharePoint, where you need to create queries manually, the native connector support makes this process much simpler.

Conclusion

By following these steps, you can export Microsoft 365 logs to Azure Data Lake Storage Gen2 and easily visualize them in Power BI.
If you’re considering a serverless environment and BI integration, this approach offers a more efficient and scalable way to manage your logs in the long run.

▶ Watch on YouTube: Microsoft 365 Log Management (1): Getting Started with Sentinel

Why Log Management Matters in Microsoft 365

One of the biggest challenges I faced while managing Microsoft 365 was log management.
Initially, message trace and audit logs were enough. But as I started incorporating security solutions like Microsoft Defender, the amount of data skyrocketed.

How We Used to Do It

Previously, I relied on PowerShell scripts to extract logs, store them in a separate repository, and later manage them via SQL Server for analysis.
While this worked, it had several drawbacks:

• Required a dedicated VM for log collection
• Credential management was cumbersome and posed security risks
• Didn’t align well with the SaaS-first approach
• Frequent schema changes and new log types increased maintenance overhead

In short, the process became increasingly labor-intensive.

Why I Chose Microsoft Sentinel

To solve these issues, I turned to Microsoft Sentinel.
Although Sentinel is primarily a SIEM solution, my initial goal is centralized log management. Here’s why Sentinel stood out:

• Native integration with Microsoft 365
• Automated log collection and schema updates
• Easy integration with Defender, Entra, Intune, and more

The Role of AI

Thanks to AI, the barrier to entry for these technologies has dropped significantly.
With Copilot, I can leverage the data stored in Sentinel more intelligently.
Once logs are ingested into Sentinel, it’s like having a database ready for advanced analytics—and AI can answer questions based on that data.

This marks the beginning of a shift from manual log management to a more automated and intelligent approach.

What is Microsoft Sentinel?

Microsoft Sentinel is a cloud-native SIEM (Security Information and Event Management) solution that collects and analyzes security logs and events from multiple sources.
It supports threat detection, automated response, and security operations efficiency.

Learn more: What is Microsoft Sentinel? | Microsoft Learn

Microsoft 365 Log Collection Architecture

Here’s the architecture I’m planning for Microsoft 365 → Sentinel:

• Signals from various Microsoft 365 services are sent to Sentinel via built-in connectors
• However, not all logs are supported by default
• Unsupported logs require API calls or custom connectors

Note: In this post, we’ll focus on enabling Sentinel. Detailed configurations for each service will be covered in future posts.

Steps to Enable Microsoft Sentinel

1. Access Azure Portal
https://portal.azure.com → Search for Sentinel

2. Create a Sentinel Resource

- Create a new resource group

- Create a Log Analytics Workspace

It is just Log Analytics workspace.

Move to Sentinel → Create

- Add Microsoft Sentinel to the workspace

Adding Microsoft Sentinel

3. Add Microsoft 365 Data Connectors
- Go to Content Hub

Currently, Sentinel is being integrated with the Defender page.
If you go to Defender (Security.microsoft.com) and click on Microsoft Sentinel, you can confirm that it is being provisioned.

If you refresh in the Content hub within Sentinel on Azure, you will see the available Content that can be added as shown below.

For a simple connection test, search for Microsoft Entra ID and proceed with the installation.

Data Connectors → Microsoft Entra ID → Open connector page

Select the logs to import and apply changes.

4. Verify Log Collection
- Wait for logs to populate

- Use KQL mode to query and validate data ingestion

What’s Next?

In the next post, I’ll cover enabling specific Microsoft 365 logs and, if needed, the E5 onboarding process.

Tip: If you’re planning to integrate Sentinel with Microsoft 365, start small—enable core connectors first, then expand gradually.

Previous post

2024.09.16 - [Microsoft 365/Graph & IIS] - Microsoft Graph & IIS. (4) Display Mailbox using the Mail.read permission

Continuing from the previous post, this time we will implement the functionality to compose and send emails using the Mail.Send permission of the Graph API.

We'll continue using the project created in the previous post.

https://youtu.be/KReqV8EPVh0

The process pattern is somewhat established at this point:

Step 1: Add Mail.Send permission

Step 2: Create a ViewModel for sending emails

Step 3: Create a View for composing and sending emails

Step 4: Add the Action Method for sending emails

Step 1. Add Mail.Send permission

Appsettings.json

Add Mail.Send permission.

Step 2. Create a View Model for Sending Emails

Create the EmailSendViewModel to hold the data needed for sending emails. This model will include fields like recipient address, email subject, and email body.

Create the EmailSendViewModel class

public class EmailSendViewModel
{
        public string To { get; set; } = string.Empty;
        public string Subject { get; set; } = string.Empty;
        public string Body { get; set; } = string.Empty;
}

Step 3. Create a View for Sending Emails

Create a view (SendEmail.cshtml) in the Views/Home directory, where users can compose and send emails. This view will use the EmailSendViewModel as its model.

Create SendEmail.cshtml

Modify the content as shown below.

@model Identity.Models.EmailSendViewModel

<h2>Send Email</h2>

<form asp-action="SendEmail">
    <div class="form-group">
        <label>To</label>
        <input asp-for="To" class="form-control" />
    </div>
    <div class="form-group">
        <label>Subject</label>
        <input asp-for="Subject" class="form-control" />
    </div>
    <div class="form-group">
        <label>Body</label>
        <textarea asp-for="Body" class="form-control"></textarea>
    </div>
    <button type="submit" class="btn btn-primary">Send</button>
</form>

Step 4. Add Action Method for Sending Emails

Add the SendEmail action method to the HomeController. This method accepts EmailSendViewModel as a parameter and sends an email using the Microsoft Graph API.

Modify HomeController.cs.

Add the following content.

// GET action method to display the email sending form
[HttpGet]
public IActionResult SendEmail()
{
    return View(new EmailSendViewModel()); // Pass an empty model to the view
}

// Sendemail
[HttpPost]
[AuthorizeForScopes(ScopeKeySection = "MicrosoftGraph:Scopes")]
public async Task<IActionResult> SendEmail(EmailSendViewModel model)
{
    var message = new Message
    {
        Subject = model.Subject,
        Body = new ItemBody
        {
            ContentType = BodyType.Text,
            Content = model.Body
        },
        ToRecipients = new List<Recipient>()
        {
            new Recipient
            {
                EmailAddress = new EmailAddress
                {
                    Address = model.To
                }
            }
        }
    };

    await _graphServiceClient.Me.SendMail(message, null).Request().PostAsync();

    return RedirectToAction("Index");
}

Navigate to the Home/sendemail URL.

Send a test email

The test email has been received.

Previous Post:

2024.09.16 - [Microsoft 365/Graph & IIS] - Microsoft Graph & IIS. (3) Creating a sample login page using the Microsoft Identity Platform

Continuing from the previous post, this time we will use the Mail.Read permission in the Graph API to retrieve mail folders, subject lines, and content, and publish them on IIS.

We will continue using the project created in the previous post.

https://youtu.be/tOCCgRloYOo

Step 1. Testing Mail.Read Permission

We will test the Mail.Read permission by retrieving only the subject lines of the user's emails on a specific page.

Add the Mail.Read permission to the existing Appsettings.json -> Save the file.

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "Domain": "M365x31504705.onmicrosoft.com",
    "TenantId": "a0c898ca-2445-4e74-ab4b-afd7916549a6",
    "ClientId": "726cf3c0-8faa-4b91-a3dc-4ec4723a411b",
    "CallbackPath": "/signin-oidc"
  },
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*",
  "MicrosoftGraph": {
    "BaseUrl": "https://graph.microsoft.com/v1.0",
    "Scopes": "user.read mail.read" //Add Mail.read
  }
}

Modify the HomeController.cs file

Add the //Email Titles section to the existing code as shown below.

using Identity.Models;
using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;
using System.Diagnostics;
using Microsoft.Graph;
using Microsoft.Identity.Web;

namespace Identity.Controllers
{
    [Authorize]
    public class HomeController : Controller
    {
        private readonly GraphServiceClient _graphServiceClient;
        private readonly ILogger<HomeController> _logger;

        public HomeController(ILogger<HomeController> logger, GraphServiceClient graphServiceClient)
        {
            _logger = logger;
            _graphServiceClient = graphServiceClient;
        }

        [AuthorizeForScopes(ScopeKeySection = "MicrosoftGraph:Scopes")]
        public async Task<IActionResult> Index()
        {
            var user = await _graphServiceClient.Me.Request().GetAsync();
            ViewData["GraphApiResult"] = user.DisplayName;
            return View();
        }

        // Email Titles
        [AuthorizeForScopes(ScopeKeySection = "MicrosoftGraph:Scopes")]
        public async Task<IActionResult> EmailTitles()
        {
            var messages = await _graphServiceClient.Me.Messages
                .Request()
                .Select(m => new { m.Subject })
                .GetAsync();

            var titles = messages.Select(m => m.Subject).ToList();
            return View(titles);
        }

        public IActionResult Privacy()
        {
            return View();
        }

        [AllowAnonymous]
        [ResponseCache(Duration = 0, Location = ResponseCacheLocation.None, NoStore = true)]
        public IActionResult Error()
        {
            return View(new ErrorViewModel { RequestId = Activity.Current?.Id ?? HttpContext.TraceIdentifier });
        }
    }
}

Create the View.

Views -> Home -> Add -> View

Razor View -> Empty -> Add

EmailTitles.cshtml -> Add

It will be generated as shown below.

Modify the content as follows.

@model List<string>

<h2>Email Titles</h2>
<ul>
@foreach (var title in Model)
{
    <li>@title</li>
}
</ul>

Start Debuging -> Log in -> Verify permissions and click Accept.

When you navigate to the Home/emailtitles URL, it will be displayed as shown below.

When compared with OWA (Outlook Web App), you can see that only the email subjects have been retrieved.

This time, let's create a page that retrieves and displays emails in the following structure: Folder -> Subject -> Body.

Step2. Action Method

Action Methods in the controller handle HTTP requests and retrieve data by calling the Microsoft Graph API. We will implement Action Methods such as MailFolders, EmailTitles, and EmailDetails to fetch the list of mail folders, the list of emails in a specific folder, and the detailed content of an email, respectively.

Modify the HomeController.cs file

Remove the existing Email Titles code.

Insert the code for Mail Folders, Titles, and Details respectively.

//MailFolders
public async Task<IActionResult> MailFolders()
{
    var mailFolders = await _graphServiceClient.Me.MailFolders
        .Request()
        .GetAsync();

    return View(mailFolders.CurrentPage.Select(f => new MailFolderViewModel { Id = f.Id, DisplayName = f.DisplayName }).ToList());
}

//EmailTitles
public async Task<IActionResult> EmailTitles(string folderId)
{
    var messages = await _graphServiceClient.Me.MailFolders[folderId].Messages
        .Request()
        .Select(m => new { m.Subject, m.Id })
        .GetAsync();

    var titles = messages.CurrentPage.Select(m => new EmailViewModel { Id = m.Id, Subject = m.Subject }).ToList();
    return View(titles);
}

//EmailDetails
public async Task<IActionResult> EmailDetails(string messageId)
{
    var message = await _graphServiceClient.Me.Messages[messageId]
        .Request()
        .Select(m => new { m.Subject, m.Body })
        .GetAsync();

    var model = new EmailDetailsViewModel
    {
        Subject = message.Subject,
        BodyContent = message.Body.Content
    };

    return View(model);
}

Step3. View model

A View Model is a model used to pass data to the View and is used to define the data retrieved from the Action Method. For example, the EmailViewModel includes the email's ID and subject. This allows the data needed in the view to be structured and managed efficiently.

Right-Click on the Models folder -> Add -> Class

MailFolderViewModel.cs -> Add

It will be generated as shown below.

Modify it as shown below.

namespace Identity.Models
{
    public class MailFolderViewModel
    {
        public string Id { get; set; }
        public string DisplayName { get; set; }
    }
}

Similarly, go to Models -> Add -> Class.

EmailViewModel.cs -> Next

Modify it as shown below -> Save.

namespace Identity.Models
{
    public class EmailViewModel
    {
        public string Id { get; set; }
        public string Subject { get; set; }
    }
}

Add EmailDetailsViewModel.cs in the same way.

Modify it as shown below -> Save.

public class EmailDetailsViewModel
{
    public string Subject { get; set; }
    public string BodyContent { get; set; }
}

Step 4. View

Finally, the View constructs the user interface and displays the data received from the View Model. Create corresponding view files for each action in the Views/Home directory.

Views/Home Folder -> Add -> New Item

MailFolders.cshtml -> Add

Modify as shown below and save.

@model IEnumerable<Identity.Models.MailFolderViewModel>

<h2>Mail Folders</h2>
<ul>
    @foreach (var folder in Model)
    {
        <li><a href="@Url.Action("EmailTitles", "Home", new { folderId = folder.Id })">@folder.DisplayName</a></li>
    }
</ul>

Modify the previously created Emailtitles.cshtml file.

@model IEnumerable<Identity.Models.MailFolderViewModel>

<h2>Mail Folders</h2>
<ul>
    @foreach (var folder in Model)
    {
        <li><a href="@Url.Action("EmailTitles", "Home", new { folderId = folder.Id })">@folder.DisplayName</a></li>
    }
</ul>

Modify the previously created Emailtitles.cshtml file.

Modify it as shown below and save.

@model IEnumerable<Identity.Models.EmailViewModel>

<h2>Emails</h2>
<ul>
    @foreach (var email in Model)
    {
        <li><a href="@Url.Action("EmailDetails", "Home", new { messageId = email.Id })">@email.Subject</a></li>
    }
</ul>

Create EmailDetails.cshtml in the same manner as the previously created files.

EmailDetails.cshtml -> Add

@model Identity.Models.EmailDetailsViewModel

<h2>@Model.Subject</h2>
<div>
    @Html.Raw(Model.BodyContent)
</div>

Start Debugging

Access the path /home/mailfolders.

The list of folders is displayed. Click on Inbox.

You can now see the list of emails in the Inbox. Click on the email subject to view more details.

The email body is displayed.

Proceed with the Publish and IIS deployment process as in the previous post. Verify the functionality as shown below.

Last Post

2024.09.16 - [Microsoft 365/Graph & IIS] - Microsoft Graph & IIS. (2) Publishing an ASP.NET Sample Page to IIS

In this post, we will create a login page in IIS using an M365 (Entra ID) sample login page.

https://youtu.be/hb7ZDVwJWEE

Launch Visual Studio -> Create a new project

ASP.NET Core Web App (Model-View-Controller)

Specify the Project name-> Next

Authentication type -> Microsoft identity platform -> Create

Next

Sign in -> Microsoft

Log in with the administrator account.

Create new

A browser window pops up. Log in with the administrator account.

Authentication complete.

Specify the Display name. -> Register

Confirm that the creation is successful.-> Next

Add Microsoft Graph permissions -> Next

Save the Client secret value in a notepad.-> Next

Finish

Close

Close

Service is registered, and verify that Secrets.json (Local) has been created.

Double-click on the Appsettings.json file.

The information for the created app is displayed.

The same information is confirmed in Entra ID.

Start Debugging

After accessing localhost, you're redirected directly to the login page -> Log in with the administrator account.

Upon first access, the permissions are displayed as shown below -> Click Accept. -> Accept

Display the logged-in account information.

When you sign out, the following message is displayed.

When you log in with a different account, it displays the information of that account.

Build -> Identity

Web Server (IIS) -> Next

Web Deploy Package -> Next

Specify the location to export the package -> Set the Site Name -> Click Finish.

Close

Publish

Once completed, copy the package file to the IIS Server.

As done in the previous post, after extracting the files, copy the essential folders and files, such as wwwroot, to the root directory as shown below.

Launch IIS Manager

Righ-Click on Sites -> Add Website

Specify the settings as shown below.

When testing on localhost, an Error 500 occurs as shown below. The cause is that the ClientSecret value is not included during publishing, which leads to this issue.

Open the Appsettings.json file using Notepad.

Add the previously saved Secret Value in the following format -> Save the file:

IISRESET

Confirm the login process.

Proceed with testing by accessing the published URL.

A Redirect URI error has occurred.

Entra ID Admin center -> Applications -> App registration -> Authentication -> Add the following to Redirect URIs as shown below.

Confirm the login process.\

Previous Post

2024.09.16 - [Microsoft 365/Graph & IIS] - Microsoft Graph & IIS. (1) Setting up the basic testing environment.

In this post, we will cover the process of publishing an ASP.NET Sample Page to IIS. Since most Microsoft solutions are based on ASP.NET, I thought this would be a necessary step before testing Graph.

https://youtu.be/6z7HdW6IoCI

Launch Visual Studio.

File -> New -> Project

ASP.NET Core Web App (Model-View-Controller) -> Next

Next

Verify that the Framework is set to .NET 8.0 -> Click "Create" (You will need to install the Runtime and SDK version 8.0 on IIS to match this setting.)

Solution Explorer -> Controllers -> Add -> Controller

MVC Controller - Empty -> Add

Name the controller as HelloWorldController. -> Add

Right-Click on Views -> Add -> New Folder

Name it HelloWorld.

Right-click on HelloWorld.-> Add -> New Item

If the following options appear, select Show All Templates.

Razor View - Empty -> Confirm the name as Index.cshtml. -> Add

Verify that it has been created under the HelloWorld folder.

다음과 같이 입력합니다.

ViewData["Title"] = "Index";

<h2>Index</h2>
<p>Hello from the HelloWorld view!</p>

Debug -> Start Debugging

If any messages related to SSL certificates appear, click "Yes" for all of them.

Yes

Yes

Yes

The sample page is now accessible in Edge.

When you access /HelloWorld, it is displayed as follows:

Now, let's proceed with creating the sample page as a site in IIS.

Build -> Publish [Project Name]

Web Server (IIS) -> Next

Web Deploy Package -> Next

Specify the location. -> Site name 지정 -> Finish

Click Publish.

It will be generated as shown below. Now, copy the files to the IIS server.

After copying, extract the files.

After extracting, move the files to a subfolder as shown below -> Copy the folder and files to the root directory (C:\Sample).

Copy completed.

Launch IIS Manager.

Sites -> Add Website

Proceed with the creation process as shown below. (For the certificate, specify the one that was previously created.)

Confirm that the creation is successful.

Application Pools -> Double-click on **Sample**.

.NET CLR version -> Change the setting to **No Managed Code**.

IISRESET

Access localhost to verify the setup.

Once DNS registration and certificate binding are completed, test the published URL.

I will discuss Tenant restriction settings.

The primary purpose of Conditional Access is to prevent company accounts from being accessed on personal devices. However, Conditional Access cannot prevent other company accounts from being accessed on company devices.

Of course, if a company device can access Naver Mail and Google Drive, it means the company is not very concerned about data leakage, and you may disregard this post.

To use M365, you need to open MS-related URLs such as office.com. Tenant Restriction is a concept used to prevent access with other company or personal accounts (such as outlook.com) during this time.

Youtube (English)

https://youtu.be/z-sVlZoz3y8

Technical article

Configure tenant restrictions - Microsoft Entra ID - Microsoft Entra External ID | Microsoft Learn

There are three main methods:

1. GSA
2. Company Proxy Equipment
3. GPO

The method using GSA requires a prior understanding of GSA.

I will cover that part separately later.

In this post, I will apply tenant restrictions using the third option, GPO.

Step 1: Configure default tenant restrictions v2

Entra Admin Center > Cross-tenant access settings > cross-tenant access settings > Default settings

Edit tenant restrictions defaults

Create Policy

The Policy ID is generated as shown below. Make sure to copy each value and keep them.

To set up a blocking policy for external accounts, configure it as shown below (default settings).

To block all external apps, configure the settings as shown below.

Step 2: Enable tenant restrictions on Windows managed devices (preview)

In the technical documentation, there are guidelines as shown below.

Tenant restrictions V2 on Windows is a partial solution that protects the authentication and data planes for some scenarios. It works on managed Windows devices and does not protect .NET stack, Chrome, or Firefox. The Windows solution provides a temporary solution until general availability of Universal tenant restrictions in Microsoft Entra Global Secure Access (preview).

-> Although the content is difficult to understand, it can be interpreted as indicating that the feature will be provided in a different way in the future. Currently, it is in the preview stage.

Download the ADMX files for the latest Windows GPO policies.

Download Administrative Templates (.admx) for Windows 11 2023 Update (23H2) from Official Microsoft Download Center

Once installed, the policy files will be saved to the following location.

Depending on the method of policy deployment in AD, copy the PolicyDefinitions folder to the appropriate location with only the necessary languages. (This part of the policy is related to AD, so we will not cover it here.)

Run gpmc.msc on the Domain Controller (DC).

Create a policy in the Organizational Unit (OU) that you will use for testing. Right-click and select "Edit".

Computer Configuration > Administrative Templates > Windows Components > Tenant Restrictions

Configure the settings as shown below.

Attempt to log in with a personal account on Edge.

Verify that access is blocked as shown below.

You can also see that access is blocked when attempting to log in with another tenant account.