In this post, we will focus on Microsoft Traffic within Global Secure Access (GSA).

Previously, I wrote a post about Tenant Restriction.

2024.07.07 - [Microsoft 365/Entra] - Microsoft Entra ID. Set up tenant restrictions v2 by GSA (English)

Since both the article and the video required updates, and several new features have recently been added, I decided to rewrite this guide as the 2026 edition.

GSA functionality is broadly divided into three profiles:

• Microsoft Traffic
• Internet Access
• Private Access

Among them, Microsoft Traffic is designed to manage Microsoft service traffic. One of its core capabilities is Tenant Restriction, which helps prevent data leakage through personal accounts or unauthorized external tenants.

Even by using only Microsoft Traffic, organizations can block personal accounts and control access paths to external tenants at the network layer.

The following Microsoft documents were referenced during this configuration:

Global Secure Access and Universal Tenant Restrictions - Global Secure Access | Microsoft Learn

Configure Tenant Restrictions - Microsoft Entra ID - Microsoft Entra External ID | Microsoft Learn

Youtube: https://youtu.be/4FzfVHB-rdM

Step 1. Activate GSA

Entra Admin Center -> Global Secure Access -> Activate

Create a group that will be assigned to the policy.

Global Secure Access -> Connect -> Traffic forwarding -> Microsoft traffic profile -> Enable

User and group assignments -> View

Assigned -> Select items

Add user/group

Assign the target group.

Step 2. Enable Tenant Restriction

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

Edit tenant restriction defaults

Create Policy

A Policy ID will be generated.

Configure the Block settings.

Global Secure Access -> Settings -> Session management -> Universal Tenant Restriction -> Enable

Step 3. Install the Client and Verify Policy Application

Connect -> Client download -> Download Client

Proceed with the installation.

Verify the GSA installation status.

Confirm that the client is successfully connected.

Verify that access to external tenants is blocked.

Step 4. Allow Specific External Tenants

If you need to allow access to a specific external tenant:

External Identities -> Cross-tenant access settings -> Organizational settings -> Add organization

Search by Domain or Tenant ID and add the organization.

Select the Tenant restriction option.

Configure the Allow settings.

In future posts, I may also cover additional topics such as client deployment, Internet Access, and Private Access features in more detail.

In this post, I’m going to walk through Device Onboarding.

Youtube: https://youtu.be/vQQRM6gqMzo

If you have worked with Microsoft Defender for Endpoint, commonly known as MDE, even a little bit, you have probably heard the term “onboarding” many times. MDE has been around for quite a while, and in the field, it is often described simply as MDE = EDR.

However, the reason I’m covering onboarding in this post is not only because of MDE.

The more important purpose is to organize device onboarding as a foundation for understanding Endpoint DLP.

Endpoint DLP is a feature in Microsoft Purview. However, for it to work on actual endpoints, the device must be onboarded based on Microsoft Defender for Endpoint. Therefore, to properly understand Endpoint DLP, we first need to understand the MDE onboarding structure.

1. Understanding Onboarding

1) Why does Endpoint DLP require device onboarding?

If you look at the Microsoft Learn documentation for Endpoint DLP, it states from the beginning that device onboarding is required.

To understand why, we first need to briefly look at the overall concept of Microsoft Defender.

In the Microsoft 365 E5 security area, Defender mainly protects the following areas:

• Email
• Cloud apps
• Devices
• Identity

The core concept of Defender XDR, as I understand it, is as follows.

A structure that collects signals from multiple security areas, gathers logs, analyzes correlations between those logs, and then responds.

In other words, Defender XDR is not simply a collection of individual security products. It can be understood as a system that brings signals from multiple areas together, analyzes them as one flow, and supports response.

2) The difference between cloud resources and devices

Areas such as email, cloud apps, and Entra ID Protection are already resources that exist in the cloud.

For example, Exchange Online, SharePoint Online, and Microsoft Entra ID run inside the Microsoft 365 cloud. Therefore, logs and signals can be collected through service-to-service integration without installing a separate client.

Devices, however, are different.

Operating systems such as Windows 11 clients or Windows Server are not cloud resources. They are endpoints that exist in the actual user environment. To collect security signals from these devices, you need a process that connects the device to Microsoft Defender for Endpoint.

This process is called device onboarding.

The structure of Defender for Identity has also changed significantly over time, and it can also be understood as a model where the related environment is onboarded first, and then signals are collected.

To summarize, the core of Defender is as follows:

1. Collect signals.
2. Gather logs.
3. Analyze correlations across multiple logs.
4. Detect and respond.

Endpoint DLP is also a Purview feature, but it needs device-side signals because it must detect and control activities such as file usage, copying, uploads, and app usage on the endpoint.

Therefore, to understand Endpoint DLP, we first need to understand MDE onboarding.

3) The relationship between MDE onboarding and Endpoint DLP

Microsoft Defender for Endpoint and Endpoint DLP may appear to belong to different portals and management areas, but from an endpoint perspective, they are very closely connected.

In practice, it is easier to understand them as follows.

• MDE collects endpoint security signals and works as EDR.
• Endpoint DLP detects and controls data leakage activities on endpoints.
• Both features require device onboarding in order to work on endpoints.
• Endpoint DLP can be understood as operating on top of MDE onboarding.

In other words, before configuring Endpoint DLP, the device must first be onboarded to Defender for Endpoint.

In this post, I will start by explaining the basic process of onboarding devices.

4) Major types of onboarding methods

If you look at the MDE onboarding documentation, it includes steps such as preparing for deployment, assigning roles, and checking the environment.

In practice, the first thing you need to check is what type of environment you currently have.

Typical environments can be categorized as follows.

In this post, I will explain the process based on two major flows.

When I explain this in practice, I usually call the flow where devices are registered and managed through Intune Intune onboarding, and the Group Policy-based onboarding flow MDE onboarding.

I will use the same terminology in this post.

5) Basic test environment

The basic environment used in this post is as follows.

• Active Directory is configured.
• AD objects are synchronized to Microsoft Entra ID through Entra ID Connect.
• Devices can be configured as Hybrid Joined devices.
• Intune is configured from scratch in a new test tenant.
• Intune onboarding and MDE onboarding will be performed afterward.

For reference:

Just because a device object is synchronized to Entra ID does not mean that the device is registered in Intune.

Entra ID Connect simply synchronizes objects. It can register a device object in Entra ID, but that does not mean the device is managed by Intune or that security signals are being collected.

Therefore, the following two concepts should be clearly separated.

In real-world environments, there are cases where the device appears in Entra ID but does not appear in Intune.

In this case, the device has not yet completed Intune MDM enrollment.

2. Intune Enrollment

First, we configure the basic settings for Intune enrollment in the Microsoft Entra admin center.

2.1. Enabling Microsoft Intune

In the Entra admin center, go to the following location.

Microsoft Entra admin center
→ Mobility
→ Microsoft Intune

Here, configure the MDM user scope.

In this test environment, I configure it as follows.

MDM user scope: All

This setting defines which users are allowed to enroll devices through MDM.

In a production environment, you can limit this to a specific user group.

However, since the purpose of this post is to explain the onboarding concept, I will proceed with All.

After changing the setting, click Save.

Now Intune is ready to enroll devices.

2.2. Automatically enrolling AD Joined devices into Intune

To enroll Active Directory joined devices into Intune, you can use Group Policy.

A simple way to explain it is:

We are applying a policy to AD-joined Windows devices that says, “You also need to register with Intune.”

In this example, assume that the following OU exists in Active Directory.

Also assume that an AD-joined PC is registered inside this OU.

Now we will create a GPO so that this device is automatically enrolled into Intune.

2.3. Creating the GPO and configuring automatic MDM enrollment

Open Group Policy Management on the Domain Controller and create a new GPO on the target OU.

In the GPO editor, go to the following path.

Computer Configuration
→ Policies
→ Administrative Templates
→ Windows Components
→ MDM

Open the following setting.

Enable automatic MDM enrollment using default Azure AD credentials

Change the setting as follows.

Enabled
Credential Type: User Credential

2.4. Applying the policy and verifying enrollment

When the policy is applied successfully, you can verify the registration status in Windows Settings.

Settings
→ Accounts
→ Access work or school

If the device is registered successfully, you will see information indicating that the device is managed by your company or organization.

You can also verify it using the following command.

dsregcmd /status

In the output, you can check the following information.

Managed by Intune

2.5. Checking the enrollment behavior through Task Scheduler

If device enrollment does not proceed correctly, you can check Task Scheduler.

In Windows, tasks related to MDM enrollment run through scheduled tasks.

The location is as follows.

Task Scheduler
→ Microsoft
→ Windows
→ EnterpriseMgmt

In this location, you can check triggers and tasks related to device enrollment.

Therefore, if Intune enrollment does not work as expected, this area can help you identify the cause.

2.6. Checking the enrollment status in Entra ID and Intune

Once MDM enrollment is completed through GPO, the registration status may appear first in the Entra admin center.

After some time, the device will also appear in the Intune admin center.

The registration status may be reflected in Entra ID first, while Intune may take a little longer.

Therefore, if the device does not appear in Intune immediately after registration, it does not necessarily mean that the process failed.

You should check again after some time.

2.7. Entra ID Joined device enrollment method

Now let’s assume an environment without Active Directory.

In an environment without AD, you can register a device through Entra ID Join.

You can perform Entra ID Join during the initial Windows setup, or if the PC is already being used as a workgroup device, you can connect it directly from Windows Settings.

The path is as follows.

Settings
→ Accounts
→ Access work or school
→ Connect

Select the following option.

Join this device to Microsoft Entra ID

In the past, this was called Azure AD Join, but the current name is Microsoft Entra ID Join.

After entering the user account and completing the process, the device can be joined to Entra ID and enrolled into Intune as well.

3. Defender portal provisioning

3.1. Microsoft Defender portal provisioning

To configure Defender, go to the Microsoft Defender portal.

Microsoft Defender portal
→ System
→ Settings

After a short while, provisioning proceeds as shown below.

In a new test tenant, the Defender XDR workspace may not yet be provisioned.

In this case, you need to provision the Defender environment first.

Provisioning is required only once, and it may take some time to complete.

You can understand this as preparing the Defender backend workspace, which is separate from the Entra ID or Intune admin center.

3.2. Enabling Microsoft Intune connection

Once Defender XDR provisioning is complete, you need to connect Intune with Microsoft Defender for Endpoint.

This step is commonly referred to as Intune connection.

In other words, up to this point, we registered devices into Intune. From now on, we configure the service-to-service connection between Intune and Defender for Endpoint.

In the Microsoft Defender portal, go to the following path.

Microsoft Defender portal
→ Settings
→ Endpoints
→ General
→ Advanced features

Find the following item.

Microsoft Intune connection

Change the value to On and save it.

Microsoft Intune connection: On

When this setting is enabled, Intune and Defender for Endpoint are connected. After that, Intune can automatically retrieve Defender for Endpoint onboarding packages or deploy EDR policies.

3.3. Checking the connection status in the Intune admin center

After enabling Microsoft Intune connection in the Defender portal, check the connection status in the Intune admin center.

The path is as follows.

Microsoft Intune admin center
→ Endpoint security
→ Setup
→ Microsoft Defender for Endpoint

Once the connection is complete, you can configure which platforms should be integrated with Microsoft Defender for Endpoint in the Intune admin center.

The path is as follows.

Microsoft Intune admin center
→ Endpoint security
→ Microsoft Defender for Endpoint

Enable the Defender for Endpoint connection for the supported platforms.

For example, if you are targeting Windows devices, enable the following item.

Connect Windows devices to Microsoft Defender for Endpoint: On

This connection setting is for the integration between Defender and Intune. It should be distinguished from EDR onboarding policy deployment, which actually makes Windows devices send signals to Defender for Endpoint.

3.4. Deploying the EDR onboarding policy

Now we need to onboard actual Windows devices to Microsoft Defender for Endpoint.

To create an EDR onboarding policy in Intune, go to the following path.

Microsoft Intune admin center
→ Endpoint security
→ Endpoint detection and response

Create a new policy.

Create Policy

When creating the policy, select the platform and profile as follows.

Platform: Windows
Profile: Endpoint detection and response

Specify the policy name.

In Configuration settings, select the Microsoft Defender for Endpoint client configuration package type.

If the connection between Intune and Defender for Endpoint has been completed successfully, you can use the following option.

Microsoft Defender for Endpoint client configuration package type:
Auto from connector

Auto from connector means Intune automatically retrieves the latest onboarding package from Defender for Endpoint.

Specify the target group for onboarding.

Therefore, you do not need to separately download and upload the onboarding package from the Defender portal.

3.5. What Auto from connector means

Auto from connector is the recommended option when Intune and Defender for Endpoint are properly connected.

The advantages of this method are as follows.

• Intune automatically retrieves the latest onboarding package from Defender for Endpoint.
• No manual package download is required.
• The latest onboarding configuration can be used when creating the EDR policy.
• The policy can be deployed to Intune-managed devices.

On the other hand, if Intune and Defender for Endpoint are not connected,

or if you are working in a special environment, you can use a manual onboarding package.

In the manual method, you download the onboarding package from the Microsoft Defender portal and manually enter it into the Intune policy.

However, for a typical Intune-based deployment, using Auto from connector is simpler.

3.6. Checking the onboarding status

You can check the onboarding status as shown below.

4. MDE Onboarding

4.1. What MDE onboarding means

From this point on, we will move into what I distinguish as MDE onboarding.

The Intune registration described earlier was the process of making a device an Intune-managed device.

By contrast, what I mean by MDE onboarding here is a method where the device is not enrolled into Intune. Instead, the Microsoft Defender for Endpoint onboarding package is deployed through Group Policy, and the device is connected directly to Defender for Endpoint.

Because devices onboarded in this way are not MDM-enrolled into Intune, their management state should be understood as Managed by MDE, not Managed by Intune.

4.2. Why is Group Policy-based MDE onboarding needed?

Not every environment can immediately use Intune.

Some organizations still operate based on Active Directory, and due to various special circumstances, it may be difficult to deploy Intune enrollment policies.

The environments that may require MDE onboarding are as follows.

• Devices are AD Joined.
• Intune MDM enrollment has not been applied, or cannot be applied.
• The existing GPO-based management structure is still maintained.
• You want to onboard devices to Defender for Endpoint first and quickly.
• Servers or some business network devices are difficult to enroll into Intune.

In this case, even without configuring Intune first, you can deploy the Microsoft Defender for Endpoint onboarding package through Group Policy.

This is what I refer to as MDE onboarding.

The flow is as follows.

AD Joined Device
→ Group Policy
→ Run MDE Onboarding Script
→ Connect to Microsoft Defender for Endpoint service
→ Device appears in the Defender portal
→ Security settings can be managed in the Managed by MDE state

4.3. Downloading the Group Policy onboarding package from the Defender portal

First, download the onboarding package from the Microsoft Defender portal.

The path is as follows.

Microsoft Defender portal
→ Settings
→ Endpoints
→ Device management
→ Onboarding

Select the operating system.

Operating system: Windows 10 and Windows 11

If you are targeting servers, select the relevant Windows Server operating system.

Select the deployment method as follows.

Deployment method: Group Policy

Then download the onboarding package.

Download onboarding package

After extracting the package, you can find the following file.

WindowsDefenderATPOnboardingScript.cmd

This script is used to onboard the actual device to Microsoft Defender for Endpoint.

4.4. Preparing a shared path for the onboarding script

For the client to run the script through Group Policy, the target device must be able to access a shared path.

For example, you can create the following shared folder on a file server.

\\fileserver.contoso.com\MDEOnboarding

Copy the onboarding script to the shared folder.

\\fileserver.contoso.com\MDEOnboarding\WindowsDefenderATPOnboardingScript.cmd

The important point here is that the target computer accounts must be able to access this path.

For testing purposes, I configured Everyone with read permission.

In a production environment, you can configure permissions more strictly according to your security policy.

The key point is that the client device must be able to run the script through GPO.

4.5. Creating a Scheduled Task in Group Policy

Now create a new GPO in Group Policy Management Console.

Edit the GPO and go to the following path.

Computer Configuration
→ Preferences
→ Control Panel Settings
→ Scheduled Tasks

Create a new task.

New
→ Immediate Task (At least Windows 7)

This method runs the task immediately on the target device when the GPO is applied.

4.6. General settings for the Scheduled Task

In the General tab of the Scheduled Task, configure the following.

Change User or Group

Alternatively, enter SYSTEM in the UI and click Check Names. It should be resolved as follows.

NT AUTHORITY\SYSTEM

Configure the options as follows.

Run whether user is logged on or not
Run with highest privileges

The reason for using these settings is that the onboarding script must run with system privileges, not user privileges.

Add a new action in the Actions tab.

Actions
→ New

In Action, enter the path as follows.

For Program/script, enter the UNC path of the onboarding script.

\\fileserver.contoso.com\MDEOnboarding\WindowsDefenderATPOnboardingScript.cmd

It is better to use a UNC path here rather than a local path.

4.7. Checking the MDE onboarding status on the client

To check the onboarding status on the client, you can check the registry and the service status.

First, check whether the Sense service exists and is running.

Get-Service Sense

If it is running correctly, you should see a status similar to the following.

Status   Name    DisplayName
------   ----    -----------
Running  Sense   Windows Defender Advanced Threat Protection Service

You can also check the onboarding status in the registry.

reg query "HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status"

For example, the following value can help you determine the onboarding status.

OnboardingState

In general, if the OnboardingState value is 1, the device can be considered onboarded.

Once onboarding is completed, check whether the device appears in the Microsoft Defender portal.

The path is as follows.

Microsoft Defender portal
→ Assets
→ Devices

A successfully onboarded device appears in the Devices list.

However, the device may not appear immediately.

In general, the following process may take some time.

GPO application
→ Scheduled Task execution
→ Onboarding script execution
→ Sense service initialization
→ Initial security signal transmission
→ Device appears in the Defender portal

Therefore, even if the device does not appear immediately after onboarding, check again after some time.

4.8. Integration

MDE-onboarded devices can receive some Endpoint Security policies through Microsoft Defender for Endpoint Security settings management, even if they are not MDM-enrolled into Intune, by using the Integration setting.

This method is useful in the following environments.

• Server devices
• Existing AD Joined devices that are difficult to enroll into Intune
• Environments operated mainly with GPO
• Environments where you want to onboard to Defender for Endpoint first and quickly
• Intermediate stages before transitioning to Intune MDM management

To apply Integration, you need to check the Enforcement Scope in the Defender portal.

The path is as follows.

Microsoft Defender portal
→ Settings
→ Endpoints
→ Configuration management
→ Enforcement scope

Here, you specify the scope of devices to which Microsoft Defender for Endpoint can apply security settings.

You can set the scope to all devices, or limit it to devices with specific tags.

In a production environment, rather than targeting all devices from the beginning, it is better to limit the scope using a test tag first.

You can check the applied devices in the Intune admin center.

Microsoft Intune admin center
→ Devices
→ All devices

To summarize:

Intune Onboarding
= A method where the device is enrolled into Intune and managed as Managed by Intune

MDE Onboarding
= A method where the device is onboarded to Defender for Endpoint through Group Policy and managed as Managed by MDE

Therefore, when explaining Endpoint DLP or Defender for Endpoint in an existing AD-based environment, it is more natural to first explain that devices can be connected to Defender for Endpoint through Group Policy-based MDE onboarding, and then security settings can be managed in the Managed by MDE state.

The next post and video will cover the detailed settings of Endpoint DLP or MDE.

Before We Start

Third-party device control and DLP solutions often provide features to block program execution.

These days, asking an AI about how each feature works usually gives you a decent understanding of the underlying logic.

When I looked into this, the three native Windows options most commonly recommended were:

• IFEO (Image File Execution Options)
• AppLocker
• WDAC (Windows Defender Application Control)

Among these, WDAC has been rebranded as App Control for Business and is now used under that name.

In this post, I'll walk through how to deploy an App Control for Business policy through Intune.

Youtube: https://youtu.be/aY4hwoPoWR0

1. What Is App Control for Business (WDAC)?

App Control for Business is still commonly referred to as WDAC in the field. It's frequently compared with AppLocker. Here's how they differ:

App Control for Business vs. AppLocker

Item App Control for Business (WDAC) AppLocker

Key Difference

While AppLocker operates as a user-mode policy, WDAC supports kernel-level enforcement based on Code Integrity. That's the most significant distinction.

2. Creating a Policy

WDAC requires you to create policies in XML format. Microsoft provides a dedicated tool for this.

Installing the App Control Policy Wizard

You can download the Microsoft App Control Wizard

and use the Policy Creator to build XML-based policies.

Operationally, the workflow is: deploy a Base Policy → supplement it with Supplemental Policies.

Note that Supplemental Policies can only add Allow rules — they cannot lift blocks defined in the Base Policy, nor can they add new deny rules.

Operational Structure

The typical flow is:

Deploy Base Policy
↓ Add exceptions via Supplemental Policy

Notes on Supplemental Policies

• Can add Allow rules
• Cannot remove existing Block rules
• Cannot add new Deny rules

In other words, all blocking (Deny) must be designed at the Base Policy level.

This post does not cover Supplemental Policy deployment.

2.1 The Three Base Templates

The wizard provides three templates out of the box:

Template Allowed scope Security Flexibility

Think of these three as a spectrum — stricter on the left (DefaultWindows), more flexible on the right (SignedAndReputable). Pick the balance that fits your organization's security requirements and operational flexibility.

Strict
DefaultWindows
↓ AllowMicrosoft
↓ SignedAndReputable
Flexible

3. Testing Default Windows Mode

Applying Default Windows Mode

Select Default Windows Mode in the wizard.

Disabling Audit Mode

To verify actual enforcement behavior, disable Audit Mode.

Proceed with Next.

Generating the Policy

Complete the wizard to generate the XML.

4. Deploying the Policy

Intune Admin Center

Navigate to Endpoint Security → App Control for Business.

After creating a policy:

• Name the policy

• Upload the XML

• Assign targets and create the policy

Verifying Policy Application

Check the applied policy files at:

C:\Windows\System32\CodeIntegrity\CIPolicies\Active

You can compare the folder contents before and after application.

Testing

Try launching Chrome.

Result: Blocked.

Checking Policies via PowerShell

CiTool.exe -lp

You can also verify the applied policies using this PowerShell command.

5. Designing a Real-World Policy

In practice, most enterprise environments start with AllowMicrosoft or SignedAndReputable as the Base Policy, then layer in Allow rules for LOB applications and Deny rules for risky binaries as needed.

DefaultWindows is theoretically the most secure, but the exception-management overhead is usually too high for general office environments. It tends to be reserved for regulated industries or fixed-function devices.

5.1 Designing an AllowMicrosoft Policy

Template Creation

Select Allow Microsoft Mode.

Confirming Chrome Is Blocked

Out of the box, Chrome execution is blocked.

Checking the Event Log

You can review enforcement events at:

Applications and Services Logs → Microsoft → Windows → CodeIntegrity → Operational

The log will show that chrome.exe failed to meet the conditions required by the applied Policy ID and was therefore blocked.

For whitelist operation, I chose not to modify the template itself — instead, I added only the necessary exception paths. Below is an example of how I configured those exceptions.

Adding Whitelisted Path Exceptions

Use Add Custom.

Rather than creating rules path-by-path, I registered the main exception paths using wildcards (*) for broader coverage. This dramatically reduces maintenance overhead — you don't need to update the policy every time a subfolder or new file is added.

That said, overly permissive wildcards can become bypass points for malware, so it's essential to limit wildcards to the narrowest scope actually needed.

Once the Allow rules are complete, deploy the policy.

Result

Chrome now launches successfully.

Any files outside the allowed paths are still blocked. For example, running a Chrome installer from the desktop will be blocked. This effectively prevents users from installing arbitrary applications. If needed, you can add paths like Downloads to the Allow rules to permit installation.

You can confirm in the event log that execution was blocked by policy.

What This Achieves

This structure delivers:

• Prevention of arbitrary application installation
• Execution limited to approved paths only

5.2 Designing a SignedAndReputable Policy

Finally, let's look at Signed and Reputable Mode.

Template Selection

Select Signed and Reputable Mode.

Confirming Policy Application

Check the applied policy files and review the event log.

Testing Chrome Execution

Chrome runs successfully — allowed based on ISG reputation.

6. ISG (Intelligent Security Graph)

ISG is a reputation-based allow mechanism that leverages Microsoft's global security signals to determine whether an application can be trusted.

For organizations with no prior experience running whitelist-based policies, starting with this template is usually the most realistic option.

Most IT environments operate on the principle of "allow broadly by default, block only specific problematic applications" — and the SignedAndReputable mode fits this pattern best.

7. SignedAndReputable Operational Design Flow

Step 1

Deploy the SignedAndReputable Base Policy.

Step 2

Enable Managed Installer — this automatically trusts applications deployed via Intune.

Step 3

Add Allow rules for key execution paths.

Step 4

Add Deny rules for specific risky applications (for example, WinRAR).

Result

• Chrome → Allowed
• WinRAR → Denied

Important

Deny rules take precedence over Allow rules.

Monitoring via Advanced Hunting

If your devices are onboarded, you can monitor enforcement events through Advanced Hunting:

DeviceEvents
| where ActionType in ("AppControlCodeIntegrityPolicyAudited",
                       "AppControlCodeIntegrityPolicyBlocked")
| summarize
    AuditCount = countif(ActionType endswith "Audited"),
    BlockCount = countif(ActionType endswith "Blocked"),
    LastSeen = max(Timestamp)
    by DeviceName, FileName, FolderPath
| sort by AuditCount + BlockCount desc

Final Thoughts

In my opinion, the most practical starting point is the combination:

SignedAndReputable + Allow rules for key execution paths + Deny rules for specific risky applications

This strikes the best balance between security and operational feasibility for most enterprise environments.

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.

Many IT engineers and managers are unaware that if your Hyper-V host server is running Windows Server Datacenter Edition, you can use AVMA (Automatic Virtual Machine Activation) keys to automatically activate guest VMs. Leveraging this feature simplifies the activation process and makes management much easier.

In this post, I’ll walk you through how AVMA works, how to use it, and some practical tips for automating Windows Server VM activation on Hyper-V.

Youtube: https://youtu.be/deyWNdW6S-U

What is AVMA?

AVMA (Automatic Virtual Machine Activation) allows you to activate Windows Server virtual machines running on a Datacenter edition Hyper-V host without needing to enter a product key for each VM. This is especially useful for environments where you frequently deploy or redeploy VMs.

Reference:
Automatic Virtual Machine Activation in Windows Server | Microsoft Learn

• Guest VM: The version of Windows Server you can activate depends on the host OS version.

Supported Host and Guest Combinations

For example, if your host is Windows Server 2025, you can activate guest VMs from 2012 R2 up to 2025 using AVMA keys.

AVMA Keys for Each Windows Server Version

You can find the official AVMA keys in Microsoft’s documentation. Here are some examples:

How to Use AVMA Keys During Installation

When installing Windows Server as a VM on your Hyper-V Datacenter host, you can enter the AVMA key during setup:

Choose a licensing method:
Select “Use a product key” and enter the AVMA key for your OS version.

Select the image:
The installer will recognize the OS version that matches the AVMA key.

Post-Installation Activation

After installation, you might notice that Windows is not yet activated. Here’s how to proceed:

Check Activation Status:
Go to Start > Settings > System > Activation. If not activated, you may see an error (e.g., 0xC004F012).

Activate via Command Line:
Open PowerShell or Command Prompt as Administrator and run:

This will trigger activation using the AVMA key.

Verify Activation:
The activation state should now show as “Active”.

Activating an Already Installed VM

If you’ve already installed the OS without entering a key, you can still activate:

Go to System Settings:
Start > System > About > Product key and activation.

Change Product Key:
Enter the appropriate AVMA key and proceed with activation.

Next

Activate

Pro Tip: Using Sysprep

After completing activation, running Sysprep is highly recommended for managing test environments efficiently. This avoids repetitive product key entry and ensures your template VMs are ready for rapid deployment.

Conclusion

AVMA is a powerful feature for anyone managing Windows Server VMs on Hyper-V Datacenter hosts. It streamlines activation, reduces manual work, and helps maintain compliance. Make sure to use the correct AVMA key for your guest OS version, and enjoy hassle-free VM deployments!

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. 

While organizing Intune policies, I discovered the existence of the Intune Data Warehouse and realized that it’s possible to build BI dashboards using Power BI.

Searching on YouTube, I found that connection methods have been available for quite some time.

My goal is to visualize every area of M365, so I decided to take on the challenge right away.

Youtube:  M365. Creating an Intune Dashboard

1. Import Data

There are two main ways to connect Intune Data Warehouse to Power BI.

Method 1. OData Feed

In Power BI, select Get data > OData feed

Feed URL Input

Enter your organizational account and click Connect

All available tables will be listed – check all and click Load

Data Loading

Import complete

Method 2. Connector

In Power BI, select Get Data > More

Online Services > Intune Data Warehouse

Specify Period

Select tables and click Load (the following steps are the same)

The Connector brings in more tables, but the meaningful data is similar
OData Feed allows for custom queries via Advanced Query
The Connector allows you to specify the period

This post will proceed using the Connector method.

2. Download Power BI Template

Most Intune dashboard resources are based on the following template:

PowerBiDashboards/Intune Dashboard.pbix at main · JayRHa/PowerBiDashboards · GitHub

Dashboard Example

Transform data > Data source settings to check the Connector-based connection.

Refresh

you may encounter an error like below:

The template creator’s blog suggested checking the technical documentation below and changing the locale, but even after changing it, the issue was not resolved. Therefore, I proceeded by copying the template instead.

Supported languages and countries/regions for Power BI

https://learn.microsoft.com/en-us/power-bi/fundamentals/supported-languages-countries-regions

In your BI file connected to your data, add pages with the same names as the template at the bottom.

Copy and paste the three pages as shown below.

3. Add Objects and Set Relationships

Since the structure may not match, you might encounter some errors.

Adjust the structure to match.

This error occurs because the Text Filter object is missing.

Go to More visuals > From AppSource.

Search for and add the Text Filter.

After refreshing or switching pages, you’ll see the issue is resolved.

Errors on the Devices page occur because table relationships do not match the template.

Model View menu to check the differences in Relationships count.

First import data, BI automatically sets relationships.

Since each environment is different, table relationships may vary. Use the following approach as a reference, and match the relationships to the template as needed.

Go to Manage relationships.

Some relationships in the template are missing in your BI.

Match Structure

After do it. Save

Sometimes, relationships are not automatically created because there’s no data on one side.

Inactive/Active reversed, fix them as well.

Errors on the Devices page will be resolved.

There are no errors on the ConfigProfiles page as well.

4. Conclusion

By leveraging Power BI, you can intuitively manage Intune devices.

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.

Previous Post: 2025.08.10 - [Microsoft 365] - Microsoft 365 Log Management (1): Getting Started with Sentinel

In the previous post, we explored how to enable Microsoft Sentinel and start collecting Microsoft 365 logs.
This time, we’ll focus on integrating Microsoft Defender for Identity (MDI) logs into Sentinel and preparing them for Power BI visualization.

Youtube: Microsoft 365 Log Management (2): Connecting MDI Logs to Sentinel and Power BI

Step 1. Verify MDI Activation

Navigation Path: System → Settings → Identities

Check Sensor Activation:
With the latest MDI v3, activation is much simpler—if your Domain Controller is already onboarded to Microsoft

Defender for Endpoint (MDE), MDI can be enabled without additional steps.

(A separate post will cover the new version once it’s officially released.)

Verify Signals:
Go to Advanced Hunting and confirm that IdentityLogonEvents are being recorded.

→ If signals appear here, you can confirm that Sentinel is also receiving MDI logs.

Connector Setup:
Navigate to Microsoft Defender XDR → Open connector page.

→ Enable Microsoft Defender for Identity and save.

After a short delay, you should be able to query MDI logs in Sentinel.

Step 2. Register an Enterprise App for Sentinel Log Export

Currently, Advanced Hunting and Sentinel have limitations when running large queries.
Our ultimate goal is to visualize data in Power BI, so we’ll first store logs as CSV files in SharePoint.

To achieve this, we’ll use the Log Analytics API, which requires Enterprise App registration.

Registration Steps

1. Go to Entra Admin Center → App registrations → New registration

2. Name the app → Register

3. Navigate to API permissions → Add a permission

4. Select APIs my organization uses → Log Analytics API

5. Check Data.Read → Add permissions

6. Click Grant admin consent

7. Go to Certificates & secrets → New client secret → Add

8. Copy the generated Value and store it securely

9. In Log Analytics Workspaces → Access control (IAM), click Add role assignment

10. Assign Log Analytics Reader role

11. Grant the role to the newly created app

Step 3. Export Logs to CSV

Tenant ID & Client ID

Workspace ID

Client Secret

Once these values are ready, you can use a PowerShell script to call the Log Analytics API and export logs in chunks.

I created the following script to call the Log Analytics API using AI.

You’ll need the following details for the script:

# === Authentication (Service Principal) ===
$TenantId = "<TENANT_ID>"
$ClientId = "<CLIENT_ID>"
$Secret   = "<CLIENT_SECRET>"  

# === Workspace ===
$WorkspaceId = "<WORKSPACE_ID>"

# === Extraction target / Period / Output ===
$Table        = "IdentityLogonEvents"
$StartUtc     = [datetime]"2025-08-12T00:00:00Z"
$EndUtc       = [datetime]::UtcNow
$ChunkHours   = 6  
$OutDir       = "F:\sentinel\IdentityLogonEvents"
$FilePrefix   = "IdentityLogonEvents"
$SkipExisting = $true

# === Interval / Retry / Timeout ===
$MinIntervalSeconds = 30 
$HttpTimeoutSeconds = 300
$MaxRetries         = 5
$BaseDelaySeconds   = 5

<# ======================= Utilities ======================= #>

# Create folder
New-Item -ItemType Directory -Force -Path $OutDir | Out-Null

# Token cache
$Script:TokenInfo = $null

function Get-LogAnalyticsToken {
    if ($Script:TokenInfo -and $Script:TokenInfo.ExpiresOn -gt (Get-Date).ToUniversalTime().AddMinutes(5)) {
        return $Script:TokenInfo.AccessToken
    }

    $body = @{
        client_id     = $ClientId
        client_secret = $Secret
        grant_type    = "client_credentials"
        scope         = "https://api.loganalytics.io/.default"
    }

    $tokenResponse = Invoke-RestMethod -Method Post `
        -Uri "https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token" `
        -Body $body `
        -TimeoutSec $HttpTimeoutSeconds

    $Script:TokenInfo = [pscustomobject]@{
        AccessToken = $tokenResponse.access_token
        ExpiresOn   = (Get-Date).ToUniversalTime().AddSeconds([int]$tokenResponse.expires_in)
    }
    return $Script:TokenInfo.AccessToken
}

function Invoke-LAQuery {
    param(
        [Parameter(Mandatory=$true)] [string] $Kql,
        [Parameter(Mandatory=$true)] [string] $WorkspaceId
    )

    $attempt = 0
    while ($true) {
        $attempt++
        $token = Get-LogAnalyticsToken
        $headers = @{ Authorization = "Bearer $token" }
        $body    = @{ query = $Kql } | ConvertTo-Json

        try {
            return Invoke-RestMethod -Method Post `
                -Uri "https://api.loganalytics.azure.com/v1/workspaces/$WorkspaceId/query" `
                -Headers $headers -ContentType "application/json" `
                -Body $body -TimeoutSec $HttpTimeoutSeconds
        }
        catch {
            $status = $_.Exception.Response.StatusCode.value__
            $resp   = $null
            try { $resp = [System.IO.StreamReader]::new($_.Exception.Response.GetResponseStream()).ReadToEnd() } catch {}

            # 401: Refresh token
            if ($status -eq 401 -and $attempt -le $MaxRetries) {
                $Script:TokenInfo = $null
                Start-Sleep -Seconds ($BaseDelaySeconds * [math]::Pow(2, $attempt - 1))
                continue
            }

            # 429 or 5xx
            if (($status -eq 429 -or $status -ge 500) -and $attempt -le $MaxRetries) {
                $retryAfter = 0
                try { $retryAfter = [int]$_.Exception.Response.Headers["Retry-After"] } catch {}
                if ($retryAfter -le 0) {
                    $retryAfter = [int]($BaseDelaySeconds * [math]::Pow(2, $attempt - 1))
                }
                Write-Warning "Query throttled/failed (status $status). Retry in $retryAfter sec. Attempt $attempt/$MaxRetries"
                Start-Sleep -Seconds $retryAfter
                continue
            }

            throw "Log Analytics query failed (status $status): $resp"
        }
    }
}

function Convert-RowsToObjects {
    param(
        [Parameter(Mandatory=$true)] $ResultTable
    )
    $cols = $ResultTable.columns.name
    $rows = $ResultTable.rows | ForEach-Object {
        $o = [ordered]@{}
        for ($i=0; $i -lt $cols.Count; $i++) { $o[$cols[$i]] = $_[$i] }
        [pscustomobject]$o
    }

    foreach ($row in $rows) {
        foreach ($p in $row.PSObject.Properties) {
            $v = $p.Value
            if ($v -is [System.Collections.IDictionary] -or
                $v -is [System.Array] -or
                $v -is [PSCustomObject]) {
                $row.($p.Name) = ($v | ConvertTo-Json -Compress -Depth 50)
            }
        }
    }
    return $rows
}

function Wait-ForRateLimit($startedAt, [int]$minSeconds) {
    $elapsed = [int]((Get-Date).ToUniversalTime() - $startedAt).TotalSeconds
    $remain  = $minSeconds - $elapsed
    if ($remain -gt 0) { Start-Sleep -Seconds $remain }
}

<# ======================= Query Loop ======================= #>

$cursor = $StartUtc
while ($cursor -lt $EndUtc) {
    $iterStart = [datetime]::UtcNow

    $chunkStart = $cursor
    $chunkEnd   = $cursor.AddHours($ChunkHours)
    $cursor     = $chunkEnd

    $stamp   = $chunkStart.ToString("yyyyMMddHHmm")
    $outFile = Join-Path $OutDir ("{0}{1}.csv" -f $FilePrefix, $stamp)
    if ($SkipExisting -and (Test-Path $outFile)) {
        Write-Host "Skip: $outFile"
        Wait-ForRateLimit $iterStart $MinIntervalSeconds
        continue
    }

    $startIso = $chunkStart.ToString("yyyy-MM-ddTHH:mm:ssZ")
    $endIso   = $chunkEnd.ToString("yyyy-MM-ddTHH:mm:ssZ")

    $kql = @"
$Table
| where TimeGenerated >= datetime('$startIso')
| where TimeGenerated <  datetime('$endIso')
| order by TimeGenerated asc
"@

    Write-Host ("Query {0}Z ~ {1}Z" -f $chunkStart.ToString("s"), $chunkEnd.ToString("s"))

    try {
        $r = Invoke-LAQuery -Kql $kql -WorkspaceId $WorkspaceId

        if (-not $r.tables -or $r.tables.Count -eq 0 -or -not $r.tables[0]) {
            Write-Host "  -> No result table."
        } else {
            $rows = Convert-RowsToObjects -ResultTable $r.tables[0]
            if ($rows -and $rows.Count -gt 0) {
                $rows | Export-Csv -Path $outFile -NoTypeInformation -Encoding UTF8
                Write-Host ("  -> {0} rows -> {1}" -f $rows.Count, $outFile)

                if ($rows.Count -ge 450000) {
                    Add-Content -Path (Join-Path $OutDir "_oversized.txt") -Value "$startIso~$endIso,$($rows.Count)"
                    Write-Warning "Result very large ($($rows.Count) rows). Consider reducing chunk size for this period."
                }
            } else {
                Write-Host "  -> No rows."
            }
        }
    }
    catch {
        Write-Warning "Error range: $startIso ~ $endIso"
        Write-Warning "Error: $($_.Exception.Message)"
        Add-Content -Path (Join-Path $OutDir "_failed.txt") -Value "$startIso~$endIso"
    }

    Wait-ForRateLimit $iterStart $MinIntervalSeconds
}

Write-Host "Done. Output dir: $OutDir"

Tip: Adjust ChunkHours and MinIntervalSeconds to avoid hitting API throttling limits.

When everything is configured correctly, the export process will look like this:

Step 4. Connect Power BI (Load CSV from SharePoint)

The Sentinel Data Lake feature is currently available in preview, but it appears that Power BI integration is not yet supported.
For now, we’ll store the data in SharePoint Online, which is a cost-effective option, and then aggregate it in Power BI.

Upload CSV to SharePoint

Power BI Desktop  Get Data  Blank query

Advanced Editior

Paste the query below. (This was created with the help of AI.)

let
    // ========== ① User Settings ==========
    SiteUrl         = "https://clim823.sharepoint.com/sites/Sentinel",
    LibraryName     = "Shared Documents",      
    TargetFolder    = "IdentityLogonEvents",     
    FileNamePrefix  = "IdentityLogonEvents",     
    KeepLastNMonths = 6,

    // ========== ② File → Table Conversion Function ==========
    ParseCsv = (fileContent as binary) as table =>
        let
            csv = Csv.Document(
                    fileContent,
                    [Delimiter = ",", Columns = null, Encoding = 65001, QuoteStyle = QuoteStyle.Csv]
                  ),
            promoted = Table.PromoteHeaders(csv, [PromoteAllScalars = true])
        in
            promoted,

    // ========== ③ Navigate to Target Folder ==========
    Source      = SharePoint.Contents(SiteUrl, [ApiVersion = 15]),
    Library     = Source{[Name=LibraryName]}[Content],
    Folder      = Library{[Name=TargetFolder]}[Content],   // DeviceLogonEvents 

    // ========== ④ Filter Files ==========
    FilteredByName = Table.SelectRows(Folder, each Text.StartsWith([Name], FileNamePrefix)),
    FilteredByExt  = Table.SelectRows(FilteredByName, each Text.Lower([Extension]) = ".csv"),

    // ========== ⑤ Load Files → Convert to Tables ==========
    AddedData   = Table.AddColumn(FilteredByExt, "Data", each ParseCsv([Content]), type table),
    TablesList  = List.RemoveNulls(List.Transform(AddedData[Data], each try _ otherwise null)),

    // ========== ⑥ Align Schema & Merge ==========
    AllCols        = if List.Count(TablesList) = 0 
                     then {} 
                     else List.Distinct(List.Combine(List.Transform(TablesList, each Table.ColumnNames(_)))),
    AlignedTables  = List.Transform(TablesList, each Table.ReorderColumns(_, AllCols, MissingField.UseNull)),
    Appended       = if List.Count(AlignedTables) = 0 
                     then #table(AllCols, {}) 
                     else Table.Combine(AlignedTables),

    // ========== ⑦ Filter by Last N Months ==========
    WithTimestampTyped = if List.Contains(Table.ColumnNames(Appended), "Timestamp")
                         then Table.TransformColumnTypes(Appended, {{"Timestamp", type datetime}})
                         else Appended,

    FilteredByDate =
        if List.Contains(Table.ColumnNames(WithTimestampTyped), "Timestamp")
        then Table.SelectRows(WithTimestampTyped, each [Timestamp] >= Date.AddMonths(DateTime.LocalNow(), -KeepLastNMonths))
        else WithTimestampTyped
in
    FilteredByDate

Close & Apply

Using this data, you can build dashboards that provide valuable insights into identity-related activities, as shown below.

Why This Matters

By connecting MDI logs to Sentinel and then visualizing them in Power BI, you can:

• Detect suspicious identity activities faster
• Correlate identity signals with other security data
• Build interactive dashboards for security insights