👋 Introduction ​

When hiring contractors and granting them access to sensitive resources, such as internal data, SaaS platforms or administrative portals, it is critical to enforce security controls at the application layer, because direct management of the device is not possible. Implementing Microsoft Edge for Business alongside Mobile Application Management (MAM) is an effective way to safeguard your organisation's data accessed through browsers on Windows.

Microsoft has announced the launch of a Public Preview (March 2026) feature that will allow browser-based protection policies to be applied to the work profile of Edge for Business, even when the device is not managed directly. This approach ensures data boundaries are maintained while respecting the ownership of devices belonging to other organisations.

⚙️ Configuration ​

Mobile Threat Defense (MTD) ​

The Microsoft Intune MTD connector links Intune with third-party vendors to provide cross-platform threat intelligence. For unmanaged devices, MAM can use these connectors to assess device health without an agent present on the machine.

The connector will only gather data from MAM-enrolled users. To stop transmission, users can sign out of the protected app or the admin can remove the MTD connector from Intune.

The data sent through the connector includes:

• User, app and device identifiers
• Last update timestamp
• A predefined health state
  • Secured: Zero-tolerance for threats
  • Low: Allows only low-level threats
  • Medium: Allows low or medium level threats
  • High: Allows all threat levels (should only be used for test purposes)

Configure the MTD Connector

1. Open the Intune admin portal -> Tenant administration -> Connectors and tokens -> Mobile Threat Defense and click ➕ Create.
2. Now select Windows Security Center in the Select the Mobile Threat Defense connector to setup field and click Create.

App Configuration policy ​

This will set up the behaviour of the Edge work profile and how we want the app to interact with the user. Following you will find my best practices:

1. Open the Intune admin portal -> Apps -> Manage apps -> Configuration and click ➕ Create -> Managed Apps.
2. Enter a Name, Description and click Select public apps.
3. Now select Microsoft Edge with the Windows platform, click Select and Next.

4. Now add the following settings from the Settings catalog.

5. Click Next 2 times, add your contractor group to Assignments and then click Create.

App Protection policy ​

This will set up the behaviour of the Edge work profile and how we want the user to interact with the data. Following you will find my best practices:

1. Open the Intune admin portal -> Apps -> Manage apps -> Protection and click ➕ Create -> Windows.
2. Enter a Name and Description for the policy, then click Next.
3. Now select Microsoft Edge and click Next.

4. Select which Data Protection settings you want to apply to the app, then click Next.

   Leak control

   If you set the Allow cut, copy, and paste policy, to anything different than All destinations and sources, the following controls are set by default:

   • Blocks Screenshots
   • Blocks Developer Tools

   

5. Lastly you can select App conditions and Device conditions.

6. Click Next, add your contractor group to Assignments and then click Create to finish the policy.

Conditional Access policy ​

This will set up the access control that forces the contractors to use the app protection policy we set up.

1. Open the Intune admin portal -> Devices -> Manage devices -> Conditional access -> Policies and click ➕ New Policy.
2. Enter the Name for your policy.
3. Under Users or Agents select your contractor user group.
4. Under Target resources select Microsoft Admin Portals and Office 365. (You can also select any other browser-based resource you want to protect.)

5. Under Conditions -> Device platforms select Windows.

6. Under Conditions -> Client apps select Browser.

7. Under Grant select Grant access and Require app protection policy.

8. Lastly set the policy to On and click Create.

⭐ Usage scenarios ​

MAM enrollment ​

To use the new work profile feature you only need to have the previously created polcies assigned to the contractor group on the organizations side.

On the user side, the contractor needs to activate a setting from their side to get the new experience.

1. Open Microsoft Edge and open edge://flags.

2. Enable the following flags and restart the browser.

   • #edge-allow-mam-on-mdm - (This setting is needed when the contractor's device is already enrolled with his own organizations MDM.)
   

3. After Edge restarted, open your resource of choice (here portal.office.com) and sign in.

4. In the sign in process the system will ask you to log in to a separate Edge work profile. This happens so the profile can be managed by the MAM policy.

5. Clicking Switch Edge profile triggers a pop-up to select and confirm your preferred account. Here you click Sign in to sync data and log in to the Edge work profile.

6. In the sign in flow you will be asked if you want to sign in to all apps or only this app.

Important

You need to select Yes, because the Edge work profile can not be managed otherwise and this feature will not work.

info

If you have not disabled the Disable MDM enrollment when adding work or school account on Windows setting

your contractor will also get the question if he wants to enroll his device, which he should answer with No.

7. After that, you will get a success message and the MAM policies will apply.

8. In the Screenshot below you see that the app protection policies we configured do now apply to the office resource.

What can the organization see of the contractors device?

• Windows registers the device in Entra ID, where it will be listed with minimal information.

• The device will not be listed in the Intune or Defender portal

To find information about the contractors sessions you can:

• use the sign in logs and the conditional access policy
• or use the special App protection status and App configuration status reports in Intune (Intune -> Apps -> Monitor)

Downloads to OneDrive ​

To additionally force downloads to be saved in OneDrive for Business, you can make the following settings:

1. First you need to go to Intune, to the App Protection policy we just created and make sure Send org data to is set to No destinations.

2. After that we need to create an Edge policy. To do that, open the M365 admin portal -> Settings -> Microsoft Edge select the Configuration policies tab and click ➕ Create policy.

3. Enter the Name and Description for your policy, and make sure to select Windows 10+ as Platform and Cloud as Policy type, before clicking Next.

4. Click Next in the Settings and Extensions section, until you come to the Customization Settings.

INFO

If you do not see the Customization Settingssection, you create the policy completly without settings in it and assign it to the contractor group. After that, when you open the policy again, you will see the Customization Settings section, select it and make the needed settings.

4. In the Customization Settings tab, navigate to Security Settings and enable the Protected Downloads setting.

After you set this up, files downloaded in Edge by your contractors are redirected to the Microsoft Edge Downloads folder in OneDrive for Business, which is tenant-managed and enforces organizational compliance.

Watermarking ​

You can also force watermarking in the protected Browser session for your contractors. With that, you can make sure that you even got visual leak control.

To set this up, you can follow the same steps as described in the Downloads to OneDrive section, but instead of enabling Protected Downloads you need to enable Enable watermarking protection.

You ca see the effect in the screenshot below.

(I adjusted the Screenshots contrast a bit, so the watermarking is better visible in the screenshot)

💡 Conclusion ​

Managing external contractors and third-party vendors presents a significant security challenge, you need to grant them access to sensitive resources while maintaining strict data protection boundaries. Implementing MAM (Mobile Application Management) with Microsoft Edge for Business solves this elegantly by enforcing security controls at the application profile layer rather than requiring device enrollment. This approach allows you to protect your organization's data and resources without the friction of device management, without exposing your resources to unmanaged devices or providing the contractor with a separate device. By combining app-level policies and conditional access, you create a secure work profile that sits isolated on the contractor's device, ensuring organizational compliance while respecting device ownership and maintaining a seamless user experience.

Preview Limitations

• Users can't access data protected by Conditional Access policies when using devices managed by another tenant with the same Conditional Access settings active.
• To enroll MAM policies on an externally managed device, it mustn't have any Endpoint DLP policies applied at the device level.

References

• Microsoft Intune Blog - Protect browser-based work on agency-managed Windows PCs
• Microsoft Learn - Secure Your Corporate Data in Intune with Microsoft Edge for Business -Microsoft Learn - Cross-tenant support using Intune MAM
• Microsoft Learn - Known limitations

👋 Introduction ​

Microsoft Defender for Identity (MDI) (formerly Azure Advanced Threat Protection / Azure ATP) is a cloud-based security solution that helps you protect and monitor identities across your organization. It brings together identity data within the Microsoft Defender portal from both on-premises and cloud identities. It helps you by bringing together your identity signals with all the other security signals you get and shows you a full picture of these threats. In addition it extends the automated attack disruption features of Microsoft Defender to your on-premises identities.

Licenses ​

Defender for Identity is already included in a lot of M365 plans, but also available as a standalone license.

• Enterprise Mobility + Security E5 (EMS E5/A5)
• Microsoft 365 E5 (Microsoft E5/A5/G5)
• Microsoft 365 E5/A5/G5/F5* Security
• Microsoft 365 F5 Security + Compliance*
• Standalone Defender for Identity license

How does it work? ​

Outside the Cloud, Defender for Identity works by utilizing a sensor on your AD DS (Domain Services / Domain Controller), AD FS (Federation Service) and AD CS (Certificate Service) Servers. The sensor monitors for threats, analyzes network traffic and collects event logs. It sends this data to the cloud service, which combines and displays the findings together with the other security signals in the Microsoft Defender portal.

Over the past years, Microsoft has integrated Defender for Identity into the unified Microsoft Defender XDR portal. This provides a central location for viewing security alerts and incidents, making it easier to respond across different areas. This is because attackers do not operate within boundaries, whether these be identity-based, device-based or otherwise.

Also there are two versions of the Defender for Identity sensor (2.x & 3.x) at the moment because of the efforts from Microsoft to make the onboarding, offboarding and operation easier by integrating it into the Defender for Endpoint and Operating System from Windows Server 2019 onwards. That also means that the new sensor uses the same connectivity as Defender for Endpoint and you don't have to open additional ports on your firewalls. But the new sensor is still in Development at the moment (February 2026) and does not fully support all features of the previous version yet.

3rd Party Integrations ​

You can use a third-party identity or Privileged Access Management (PAM) provider with Microsoft Defender for Identity.

You have the option to integrate Okta using the built-in integration. Microsoft provides comprehensive documentation, including a step-by-step guide on how to configure the integration (see How Microsoft Defender for Identity protects your Okta accounts).

If you use a third-party PAM solution, Microsoft also offers built-in integrations with several providers like CyberArk, BeyondTrust and Delinea. Documentation on supported PAM providers is available directly in the Microsoft Defender portal -> Investigation & response -> Partner catalog -> Technology partners, where you can find detailed information and direct links. You can also access this information here: Integrate Defender for Identity with PAM services.

Sizing ​

MDI sensors require a minimum amount of resources to run properly. If the server doesn't have the required resources, domain controller performance shouldn't be affected, but the Defender for Identity sensor might not work as expected.

You can use the MDI sizing tool to check if you got the required resources. Download it here.

1. Copy the tool to your domain controller and run it.

2. The tool will run and check if your server is supported based on the Busy Packets/Second value. This is calculated based on the 15 busiest minutes over a 24-hour period. While the tool runs, it creates and updates an XMLS report. As soon as you are ready, stop the tool with CTRL + C and open the report to check the results.

A few common results are:

Migrate ATA -> MDI ​

If your identity security still utilizes the local Advanced Threat Analytics (ATA) solution, moving from ATA to MDI modernizes your security with advanced analytics and automated remediations.

Unlike ATA, MDI uses Event Tracing for Windows (ETW) to provide more in-depth detection functionality, correlating threats with all the other security signals in the Defender security stack.

So it is highly recommended to switch to this modern, more secure and up to date security solution.

If you need guidance on how to Migrate, Microsoft provides migration information here.

💿 Installation ​

Getting started ​

To get started with Defender for Identity you first need to have a license activated in your tenant. Otherwise the Identity sections will not be visible in the Defender portal.

If you have a license and navigate to your Defender portal, the Identity section takes a moment to appear.

After the Identity section is visible and you navigate to Settings -> Identity, the Defender for Identity Workspace will get prepared.

Which Sensor version is right for me?

The new sensor (v3 / unified sensor) is integrated directly into Windows Server with Defender for Endpoint, eliminating separate installation steps, addtional port openings and a separate update channel, using the standard Windows update cycle. Version v3 is recommended when onboarding new domain controllers, but there is no need to update existing MDI environments.

Here you find a comparison table between the two sensor versions:

Feature	Classic Sensor (v2)	New Sensor (v3)
Installation	Separate download & installation	Built-in to Windows Server
OS Support	Windows Server 2012 R2 and later (2012 R2 functionality is limited due to the OS.)	Windows Server 2019 and later
Network Ports	Requires additional ports to be opened for communication with the cloud service (look here)	Uses the same ports as Defender for Endpoint, no additional ports needed
Update Method	Separate update channel	Standard Windows Update cycle
Name Resolution	Local protocols (NetBIOS, WINS)	Cloud-based NNR via Defender data
Management	Standalone agent management	Unified with Defender for Endpoint (MDE)
AD permissions	Requires account with read acces to the whole directory to get full functionallity	Uses Local System identity

Be aware that if you got the 2.x sensor alreaddy installed, you won`t be able to deploy the 3.x sensor on the same server, without removing the old one first.

And here is a decision tree to help you decide which sensor version to use:

Current limitations of sensor v3:

• Server needs Defender for Endpoint deployed
• Doesn't support VPN integration
• Doesn't support ExpressRoute

Microsoft is activly working on closing the gaps between the two sensors, providing a migration functionality and support for running v3 without Defender for Endpoint in the future.

Sensor 2.x Installation ​

After your Workspace is prepared, you can start installing MDI sensors.

1. Under General -> Sensors you click Add sensor and get the question about which sensor version you want to install.

2. If you click Continue with the classic sensor you can download the 2.x installer and get the Access Key you need during installation.

3. When starting the installer you select your language and click Next.

4. Next you get the option of which type of installation you can perform. On a Domain Controller (as in the screenshot), a standalone MDI server or a AD FS / AD CS / Entra Connect server.

5. After clicking Next, you select the installation path, enter the Access key shown to you in the portal and click Install.

6. After the Installation completes you can find the Sensor in the Sensors list in the portal.

Sensor 3.x Installation ​

1. To install the new sensor, you go to the Defender Portal -> System -> Settings -> Identities and select the Activation blade. Here you will see all the server with defender for endpoint in your environment that are eligible for the new sensor.
2. Select the server and click + Activate to start the activation process.

3. Confirm the activation by clicking Activate in the pop-up.

4. After that, the portal will confirm the successful activation.

5. The new sensor can then be found in the sensor list.

⚙️ Configuration ​

You should set up a few recommended settings for MDI now:

Audit settings ​

To configure the audit settings required for MDI to detect suspicious activity, you can use PowerShell, Group Policy, or if you are deploying the new sensor (v3.x), leverage the Automatic Windows auditing configuration feature.

The following audits are required to set up either way for Domain controllers:

• Directory services advanced auditing
• NTLM auditing
• Domain object auditing

1. The automatic option

   The automatic option applies the same settings you would configure manually, with the added benefit of checking every 24 hours for any configuration drift and automatically correcting it. You can set it up in the Defender portal -> System -> Settings -> Identities, select Advanced features and turn Automatic Windows auditing configuration on.

   WARNING

   Currently this is still in preview as of February 2026, but works perfectly in my experience.

2. The PowerShell option

   To use the powershell option you first need to install the MDI powershell module on your server.

   powershell

   Install-Module -Name DefenderForIdentity

   Then you can use the following command to generate a report of all the settings and their configuration commands. These also need to be run.

   powershell

   New-MDIConfigurationReport -Path "C:\Reports" -Mode "Domain" -Identity "DOMAIN\AdminAccount" -OpenHtmlReport

3. The Group Policy option

   To configure MDI via group policy, set up a new policy on your server by starting Group Policy Management and navigating to:

   Computer Configuration -> Policies -> Windows Settings -> Security Settings

   Configure the settings as described in the Microsoft documentation: Configure Windows event auditing.

Configure RPC auditing ​

Microsoft introduced a new RPC (Remote Procedure Call) Health alert for the new sensor (v3.x). This will monitor the RPC configuration on your MDI devices and should improve the detection accuracy and security coverage. For this you need to apply a tag to your sensor 3.x devices, which will enforce the configuration automatically.

1. To configure the tag, open the Defender Portal -> System -> Settings -> Microsoft Defender XDR -> Asset Rule Management and click ➕ Create a new rule.
2. Enter a Rule name, Description and click Next.

3. Create rules to target the servers with the v3 sensor and click Next.

4. Add the tag Unified Sensor RPC Audit and click Next.

5. On the last page of the wizard you do not only see a summary of the settings you just created, but also the amount of devices that will be affected. If everything looks good, click Submit to create the rule.

6. The new rule will then be visible in the list together with its last run time and status.

7. If you display the 'Tags' column in the device overview under Assets -> Devices, you will also be able find the newly applied tag there.

Power settings ​

No matter which sensor version you are using, set the Power options on the server to High Performance to ensure the best performance. You can do that either in the Control Panel of the server directly or via your policy of choice (Group Policy, Azure Arc etc.).

Time synchronization ​

All servers and domain controllers with an MDI sensor should have system times that are within five minutes of each other to make sure the sensors work properly.

To set that up you need to create a Group Policy and link that to your MDI Servers.

1. Open the Group Policy Editor for your Domain and create a new Group Policy Object.
2. Go to Computer Configuration -> Administrative Templates -> System -> Windows Time Service -> Time Providers and set all settings to Enabled with standard settings.

3. Next got to Computer Configuration -> Preferences -> Control Panel Settings -> Services and create a new Service. Set the Service up as shown in the Screenshot below.

4. Now close the Policy editor and link the GPO to the OU where your MDI Server's are.

Network Name Resolution (NNR) ​

As a core component of MDI, NNR maps raw network data and IP addresses to specific devices. This correlation allows for more precise event attribution and more effective threat investigation.

MDI sensor v3.x uses the Defender device inventory for name resolution, requiring no additional configuration or port openings.

MDI sensor v2.x uses network traffic and TCP fingerprinting to map IP addresses to device objects by correlating computer names with Active Directory. For this, the sensor uses a few methods:

Primary methods:

• NTLM over RPC (TCP Port 135)
• NetBIOS (UDP port 137)
• RDP (TCP port 3389) - only the first packet of Client hello

Secondary method:

• Queries the DNS server using reverse DNS lookup of the IP address (UDP 53)

Manage Sensor settings ​

1. To manage your individual sensors you can go to the Defender portal -> System -> Settings -> Identities and click on the sensor of your choosing.
2. This will trigger the opening of a details pane on the right side with more information about the sensor and its status.
3. On the bottom of the pane select Manage sensor to open another pane where you can configure sensor details.
4. You can optionally enter a Description to provide more information about the sensor, but you must ensure that the Domain controller field is filled in and that, in the case of a v2 sensor, at least one of the Network adapters is selected.

sensor v2.x	sensor v3.x

Directory services accounts (DSA) ​

You can set up a read only directory service account for your MDI sensor to connect to the domain controller. Even so the MDI service and updater will use a local account regardless, there are scenarios where a DSA can be nessecary.

• Sensors installed on AD FS or AD CS servers.
• Accessing the DeletedObjects container to gather information on deleted users and computers.
• Domain and trust mapping.
• Querying another domains over LDAP when activity from someone out of this other domain is detected.

1. To add a DSA, you go to the Defender portal -> System -> Settings -> Identities and navigate to Directory services accounts.
2. Here you click ➕ Add credentials and enter your account details into the flyout that appears on the right side.

Manage action accounts ​

You can set up a separate management account in the case you do not want to utilize the sensors local system account for MDI response actions (e.g. Attack disruption in the AD). But be aware, that only the v2.x sensor supports separate management accounts. If you enable this gMSA account on a Server with a v3.x sensor, response actions will not work. If possible, use the default MDI Local System Account for response actions across the board.

1. To add your individual management account you go to the Defender portal -> System -> Settings -> Identities and navigate to Management action accounts.
2. Here you set the option to Manually configure your management accounts and enter your account details into the flyout that appears on the right side.

VPN ​

Microsoft Defender for Identity integrates with VPN solutions by ingesting RADIUS events (RFC 2866). These events include details such as source IP addresses and connection locations.

Supported VPN vendors are:

• Microsoft
• F5
• Check Point
• Cisco ASA

1. To integrate your VPN you go to the Defender portal -> System -> Settings -> Identities and navigate to VPN.
2. Here you set the option to Enable RADIUS accounting and enter the shared secret you need to configure beforehand in your VPN solution.

Adjust alerts thresholds ​

Some Microsoft Defender for Identity (MDI) alerts use a learning period to understand what normal activity looks like in your environment. After that, they can better detect suspicious behavior. Each alert also includes built-in logic, such as thresholds and activity filtering, to reduce false positives. If you set lower thresholds, you'll get more alerts, but if you set higher thresholds, you'll get less noise. You just have to let the system learn and then experiment with the settings a bit, to find the best balance with the least amount of false positives for your environment. If you enable Recommended test mode, or set the threshold to Medium or Low, you'll get immediate alerts even if the learning period isn't finished.

1. To adjust the alert thresholds you go to the Defender portal -> System -> Settings -> Identities and navigate to Adjust alert thresholds.
2. Here you can enable the Recommended test mode or set the thresholds you want.

Entity tags ​

In Microsoft Defender for Identity, Entity tags are labels that you assign to specific identities, such as users, devices or groups, to indicate a higher level of security relevance. These tags provide context about an entity’s sensitivity or role, helping Defender for Identity to prioritise, detect and respond to threats more effectively.

The following accounts, devices and groups are tagged sensitive by default:

• Administrators
• Power Users
• Account Operators
• Server Operators
• Print Operators
• Backup Operators
• Replicators
• Network Configuration Operators
• Incoming Forest Trust Builders
• Domain Admins
• Domain Controllers
• Group Policy Creator Owners
• Read-only Domain Controllers
• Enterprise Read-only Domain Controllers
• Schema Admins
• Enterprise Admins
• Microsoft Exchange Servers
• Certificate Authority Server
• DHCP Server
• DNS Server
• Microsoft Exchange Server

You can additionally configure three types of Entity tag manually: Sensitive, Honeytoken and Exchange server.

1. To start creating Entity tags go to the Defender portal -> System -> Settings -> Identities and navigate to one of the 3 tag pages Sensitive, Honeytoken or Exchange server.
2. Here you can start tagging users, devices or groups, depending on the tag.

Sensitive: This tag identifies high-value or sensitive assets that have not yet been tagged and which, if compromised, would pose a significant security risk.

Honeytoken: Honeytokens are deliberately planted fake accounts or digital assets designed to lure attackers and reveal unauthorized activity. To use this, you just create a account in an obvoius position with deliberatly bad security. When marked as honeytoken, the account will get tight monitoring, so when an attacker uses the account you instantly know about it.

Exchange Server: You can use this tag for devices that host additional Exchange services.

Actions and exclusions ​

MDI enables you to exclude specific IP addresses, devices, domains or users from detection. For instance, an authorised security scanner might trigger a DNS alerts. By creating an exclusion, you can ensure that MDI ignores these known sources, thereby reducing false positives. However, it is better to use alerts than exclusions, because exclusions are unconditional, whereas alerts can be tuned and reviewed more specifically.

There are 2 types of exclusions: Global excluded entities and Exclusions by detection rule.
The first option simply excludes your IP addresses, devices, domains or users as you select them. The second option lets you select a threat detection rule and exclude your entities directly from a specific rule. Use this method to create clearer exclusions. This will ensure that your entities are not vulnerable to other threats.

1. To configure an exclusion, you go to the Defender portal -> System -> Settings -> Identities and navigate to Global excluded entities or Exclusions by detection rule.
2. Under Global excluded entities, simply click ➕ Add to exclude an entity across the board. Alternatively, use Exclusions by detection rule to apply exclusions to specific rules. Click any rule to view its details or add an entity.

Notifications ​

You can configure notifications for health and security alerts in MDI and let them be send via email or directly to your Syslog server.

1. To configure a notification, you go to the Defender portal -> System -> Settings -> Identities and navigate to Health issues notifications or Syslog notifications.
2. Under Health issues notifications, simply click ➕ Add to add one or more E-Mail adresses where all notifications will go to. Or use Syslog notifications to set up your syslog service and collect notifiactions that way.

⌨️ Admin experience ​

After setting up MDI you can get started defending your users 👮 and for that you got a few options.

Identities blade ​

Dashboard

First, MDI unlocked a new section in in your Defender portal called Identities and opening that, your first blade is the Dashboard. This page shows you information about the overall identity makeup of your environment.

At the top you will first find the Identity overview shield.

This will give you a quick overview of your user numbers in hybrid, cloud, and on-premises. You can also drill down by clicking onto the different user categories.

Directly underneath the overview, you find the Top insights divided into Users identified in a risky lateral movement path & Dormant Active Directory users who should be removed from sensitive groups.

The first shows sensitive accounts with risky lateral movement paths. The second lists accounts that are unused for over 180 days.

These are important clues for identifying potential attack paths and for you to investigate.

Underneath the top insights you find ITDR deployment health on the left.

This is just an overview of the MDI services you deployed and if they are healthy.

Right next to the ITDR deployment health you find the Identity Secure score and the Highly privileged identities list.

The first represents your organization's security posture in regards to identity. It is one part of the overall Microsoft secure score and gives you a good idea about how your security posture is evolving.

The second lists your sensitive accounts, with the option to drill down further.

Further down on the page you will find a few more widgets that will fill when your environment matures and indicents happen.

Service accounts

This page shows you a list of all your on-premises service accounts and their status. In additionan, you get a shortcut to your secure OAuth apps, but for that to function, you need an activated Defender for cloud Apps.

Health issues

On this page, you get a list of your Global health issues and Sensor health issues. You do not need to close these issues here. They will get closed automatically, when the problem is gone.

In the example in my screenshot, MDI detects that the sensor seem to be offline (because the server is off). This will vanish as soon as I turn the server back on and the sensor checks back in.

Tools

In the tools section you will find a few links to helpfull stuff.

• Microsoft Documentation
• Sizing Tool
• Readiness Script
• PowerShell module

Assets blade ​

Identities

MDI also unlocked a new section in in your Assets blade, called Identities. This page shows you a list of your Identities or a list of your Cloud application account.

You can get infos about all your identities, regardless of whether there are real users or services and the option to drill down into all of it.

Users

If you drill down into a user, you will find a few interesting pages.

On the main page you find information about incidents, alerts, used devices, AD settings and other information from on-prem and the cloud.

One cool feature is that MDI correlates accounts and shows you information not only about the account you are looking at, but also about all the other accounts that MDI thinks the user uses. This should help with identifying attack paths and elevations. You can also manually link accounts belonging to a specific user.

Of course, you will also see a correlated list of all the groups that this user and all his accounts belong to.

In the other tabs, you will find Security recommendations, Attack paths and, completely new as of February 2026, a list of the Conditional Access Policies to which the user must adhere.

Recommendations ​

In addition to the recommendations on the User page, MDI provides further recommendations to help you improve the security posture of your environment.

Sensor recommendations

When you open the Defender portal -> System -> Settings -> Identities and click on an unhealthy sensor, you will get a flyout on the right side with information / recommendations about the sensor problems and what you can do about it.

Exposure management

When you open the Defender portal -> Exposure management -> Recommendations and select Identities, you will get your Identities secure score, a comparison to other orgs and Recommendations to improve your score and with that, your security posture.

To show you, how such a recommendation workflow can work, we go through it with the recommended workflow to validate your sensor deployments.

1. Go to one of your domain controllers that runs MDI and run the following PowerShell command. This will missconfigure an AD setting on purpose.

   powershell

   Set-ADObject -Identity ((Get-ADDomain).distinguishedname) -Replace @{"ms-DS-MachineAccountQuota"="10"}

2. Then reopen the Exposure Management Recommendations and select the Resolve Unsecure Domain Configuration option.

3. After a short period of time, this issue should show you the status To address.

3. Opening the recommendation, you will first see a Description of it and on the second page, you will see your next steps for resolving the problem.

4. Even better, on the next page, Exposed entities, you will find the domain controller whose settings you changed. Click on it to get exact information about what is wrong with it.

5. The last two pages tell you about Related initiatives and Related metrics. These show the impact that fixing this issue will have on your secure score and security initiatives that you may want to follow.

6. Next, go back to your domain controller and run the following PowerShell command to restore the setting to its previous state.

   powershell

   Set-ADObject -Identity ((Get-ADDomain).distinguishedname) -Replace @{"ms-DS-MachineAccountQuota"="0"}

7. When you now go back to the same Resolve Unsecure Domain Configuration recommendation, you will see that the previously cited issue has been resolved.

Remediation actions ​

MDI enables you to take immediate action on compromised accounts. These response actions can be performed directly from the user page, the user side panel, the advanced hunting page or in the action center.

Security alerts ​

MDI security alerts provide information about suspicious activities detected, along with the accounts and computers involved. The Identity alerts page in Defender XDR provides a unified, cross-domain security view by correlating MDI signals with data from the other security products available.

The alerts are categorised and arrive in 2 different formats in the Defender portal. Both originate from the MDI sensor, but classic alerts are not yet migrated to the unified defender portal (A Microsoft initiative to unify security signals into a single pane of glass).

You can find a full list of all classic alerts here and of the new XDR alerts here.

1. To get a look at the current alerts open the Defender portal -> Investigation & response -> Incidents & alerts and select Alerts.

   (Microsoft screenshot, got no Alerts 🤷)

2. When you open one of the alerts you get the information you need to investigate, classify and remediate the problem.

Identity Security Initiative ​

Security metrics measure exposure risk across different initiatives by grouping related asset recommendations. Microsoft will provide a list of security initiatives that you can use to measure your security posture and progress.

1. To look at these initiatives, you go to the Defender portal -> Exposure management and select Initiatives.

2. There is also a specialised Identity Security page to help you progress to a more robust identity security posture.

3. When you click Open initiative page, you will see an overview of your current status, as well as tabs for the security metrics included in this initiative, Security recommendations and your historical progress.

Identity's security posture assessments ​

MDI features continuous monitoring of on-premises and cloud environments to identify weak spots and delivers accurate assessment reports to support a proactive, ongoing security cycle. This is realized through the security scores and differend categories Microsoft provides.

Following, I listed the information Microsoft provides for the different available categories:

• Hybrid security posture assessments
• Identity infrastructure security posture assessments
• Certificates security posture assessments
• Group policy security posture assessments
• Accounts security posture assessments
• Cloud identities security posture assessments

Advanced hunting ​

There are also options for using the information gathered by MDI in your advanced hunting queries.

To demonstrate this, we will once again use the recommended actions to validate your sensor deployments.

In the Defender portal's Advanced hunting page, u can use the following KQL queries to check that MDI sends data as expected.

IdentityInfo 
| where AccountDomain contains "domain" // insert domain

This query shows identy info with a specific domain.

IdentityQueryEvents 
| where DeviceName contains "DC_FQDN" // insert domain controller FQDN

This query shows identity query events (e.g. queries performed against AD objects) which involved a device with a specific FQDN.

IdentityDirectoryEvents
| where TargetDeviceName contains "DC_FQDN" // insert domain controller FQDN

This query shows identity directory events (e.g. password changes, UPN changes or system events like PowerShell activity) which involved a device with a specific FQDN.

If you tried these queries and you found them returning information, then you can be sure that the sensor functions correctly.

Reports ​

Instead of advanced hunting you can also utilize a few prepared Reports.

When opening the Defender portal you will find the Reports page directly on the left side. In here you got an Identities section with a few reports.

Sample Report:

💡 Conclusion ​

To wrap things up, Microsoft Defender for Identity is another importand part of the Microsoft security stack. As part of the Microsoft Defender XDR ecosystem, it provides deep visibility into what’s happening with your identities and help you get the difficult edges between on-premises and cloud environments secured.

We’ve covered what Defender for Identity is, how it works, how to deploy it, how to configure it to align with best practices and how to use it.

Microsoft also provides a Checklist, with the most important things to keep a look out for:

Defender for Identity should be a no-brainer for many organizations, because it is included in the M365 E5 and EMS E5 add-on licenses and is quickly deployed and configured. And for everyone else:

• If you are hybrid, extending your security to the local environment is really important and not needing a separate tool should be much easier and cheaper.
• If you are cloud-only, identity security is one of your most important security aspects, so it should be a big part of your posture management as well.

So no matter which environmental structure you run at the moment or where your identities live, as long as you are using M365 security, MDI is worth a deliberation.

References

• Microsoft Defender for Identity documentation
• Advanced Threat Analytics (ATA) to Microsoft Defender for Identity
• Activate the Defender for Identity sensor v3.x on a domain controller
• Network Name Resolution (NNR) in Microsoft Defender for Identity
• Directory Service Accounts for Microsoft Defender for Identity
• Configure Microsoft Defender for Identity action accounts
• Defender for Identity VPN integration
• Adjust alert thresholds
• Manage related identities and accounts in Microsoft Defender for Identity
• Remediation actions
• Security alerts in Microsoft Defender for Identity
• Identity Security Initiative
• Microsoft Defender for Identity's security posture assessments
• Best practices checklist
• Troubleshooting Microsoft Defender for Identity known issues

👋 Introduction ​

The Problem:

Giving workers local administrator rights on their devices is a common requirement in many organizations. However, managing and securing these local administrator accounts can be challenging.

LAPS (Local Administrator Password Solution) is a tool designed for this purpose, but it is intended for administrators, not end users. As a result, it is effectively unusable for end users. At present, it is not possible to restrict which LAPS passwords a user with the appropriate Entra permissions can read, without creating admin units. But this is not a viable solution in this case, as it would require creating a unit per device, which would quickly exceed Entra’s administrative unit limits. As a result, any user who has read access can view the LAPS passwords for all devices.

This is not great. If you do not want to grant end users access to the Entra portal and allowing them to read all LAPS passwords, this is a non-starter.

My approach:

If you want to take advantage of the built-in LAPS functionality, do not want to use Endpoint Privilege Management (EPM) or do not have the required license, another approach is needed. To address this, I cooked up an automation that allows users to request their LAPS password without accessing the Entra portal and without granting them any permissions to read LAPS passwords themselves.

To do that we need the following components:

• a custom role for accessing LAPS passwords
• an Azure Automation Account to run custom PowerShell code
• an enduser with an exchange mailbox

⚙️ Configuration ​

Resource Group ​

To get started we first create a resource group to group our new stuff together.

1. Open the Azure admin Portal -> Resource groups and click + Create.
2. Enter your Name and select your Subscription and Region.
3. Then Review + create the group.

Automation Account ​

Next we create the Automation Account we need.

1. Open the Azure admin Portal -> Automation Accounts and click + Create.
2. Enter your Subscription, the Resource group we created, a name and the same Region as the Ressource Group.

3. Click Next, make sure to select System assigned in the advanced tab under Managed Identities and click Next again.
4. In the Networking tab you can select how you want to connect to the automation account. In our example Public access is ok, but you maybe want to consider a Private Endpoint depending on your Azure Network infrastructure.
5. Now you can click Review + Create and Create again.

Runtime Environment ​

Now we start configuring the Automation Account by creating a Runtime Environment.

1. For that we open the Azure admin Portal -> Automation Accounts again and open the previously created Automation Account.
2. Now select Process Automation -> Runtime Environments and click ➕ Create.

3. Enter a Name and select the following attributes:
   • Language: PowerShell
   • Runtime Version: 7.4

4. Click Next and select the following Packages with ➕ Add from gallery:
   • Microsoft.Graph.Authentication
   • Microsoft.Graph.DirectoryManagement
   • Microsoft.Graph.Mail
   • Microsoft.Graph.Users

5. Now Click Next and Create and wait for the Runtime Environment to be ready.

Runbook ​

Next, we will create a runbook to add our script and run it autonomously.

1. For that we open the Azure admin Portal -> Automation Accounts again and open the previously created Automation Account.
2. Now select Process Automation -> Runbooks and click ➕ Create.

INFO

There are 2 Toturial Runbooks automatically created for you and you can just delete them if you like. They will then also vanish from the Resource Group.

• AzureAutomationTutorialWithIdentity
• AzureAutomationTutorialWithIdentityGraphical

3. On the Basics page select the following attributes:
   • Runbook: Create new
   • Name: Whatever you like
   • Runbook type: PowerShell
   • Runtime Environment: Click Select from existing and select the previously created runtime environment.

4. Now you can click Review + Create and Create again.
5. Next you will get dumped directly into the Editor. Here you can paste the script below in and click Save and Publish.

<#
.AUTHOR
	Michael Frank

.Dates & Version
	- Created: 22.09.2025
	- Lastupdated: 18.01.2026
	- Version: 1.0

.SYNOPSIS
	Get LAPS Passwords for all devices owned by a user and send them via email.

.Component
	The following PowerShell 7.4 modules must be installed:
    - Microsoft.Graph.Authentication
    - Microsoft.Graph.DirectoryManagement
    - Microsoft.Graph.Mail
    - Microsoft.Graph.Users

.Graph Permissions
    - Device.Read.All
    - Mail.ReadWrite
    - User.Read.All
    - DeviceLocalCredential.Read.All
    - Mail.Send

.DESCRIPTION
	This script connects to the Microsoft Graph API using the managed identity context.
	It retrieves all devices owned by a specified user in Entra ID and fetches their LAPS passwords.
  The passwords are sent to the user's registered email address, so they never leave the server.
  Ultimately, the sent mail is deleted, meaning the user only has to worry about the mail in their inbox and not a folder full of passwords in their sent items.
#>

Param(
[String]$EntraUserID
)

$Pass = @()

# Log in with the managed identity

Connect-MgGraph -Identity -NoWelcome

# Getting the devices of the passed user

$Devices = Get-MgUserOwnedDevice -userid $EntraUserID

# Getting the LAPS Passwords

foreach ($Device in $Devices) {

    $device = get-mgdevice -deviceid $Device.id | Select-Object displayname
    $Pass += Get-LapsAADPassword -DeviceIds $device.displayname -IncludePasswords -AsPlainText -ErrorAction SilentlyContinue

}

$user = Get-mguser -userid $EntraUserID

# Mail gets created and send

$params = @{
	subject = "LAPS"
	body = @{
		contentType = "HTML"
		content = "$($Pass)"
	}
	toRecipients = @(
		@{
			emailAddress = @{
				address = $user.mail
			}
		}
	)
}


$mail = New-MgUserMessage -UserId $EntraUserID -BodyParameter $params

Send-MgUserMessage -UserId $EntraUserID -MessageId $mail.id

# Script needs to sleep for a few seconds so the mail can get send and delivered
Start-Sleep -Seconds 5

# Get the send mail ID
$mails = $mails = get-MgUserMessage -UserId $EntraUserID -Filter "Subject eq 'LAPS'" | select Id

# Delete the send LAPS mail
remove-MgUserMessage -UserId $EntraUserID -MessageId $mails.id[0]

6. Confirm the publishing at the end.

Roles ​

After creating the runbook, we need to set up the access to the LAPS passwords for the runbook.

1. For that we first open the Entra admin center -> Roles & admins and click ➕ New custom role.
2. Enter the Name, a good Description about what the role does and select Start from scratch.

3. Click Next and select the following permissions to read the LAPS passwords, the users and the devices of the users.
   • microsoft.directory/deviceLocalCredentials/password/read
   • microsoft.directory/devices/registeredOwners/read
   • microsoft.directory/users/identities/read
4. Then click Nextagain and Create.

5. Next click on the newly created role and you will get to the Assignments page for the role. Click ➕ New assignment, search for the name of the previously created automation account, select it and click Add.

IMPORTANT

You can not select the service principal from the list of users without searching, because service principals will not get listed by deafult. This is so that you will not be overwhelmed with Service Principals when selecting a user or group.

Enterprise App ​

Once the custom role is created and assigned, you must also assign the appropriate Graph API permissions to the automation account. This step ensures that the Managed Identity, which acts as the security principal for the PowerShell execution, possesses the necessary authorization to interact with Microsoft Graph.

Because these permissions cannot be assigned via the Portal UI, you must use PowerShell to grant them:

# Makes sure that the Entra PowerShell Module is installed and importet
$module = Get-InstalledModule -Name Microsoft.Entra
if (!$module){
  Install-Module -Name Microsoft.Entra -Repository PSGallery -Scope CurrentUser -Force -AllowClobber
}

Import-module Microsoft.Entra

# Connect to Graph
Connect-Entra -Scopes 'Application.ReadWrite.All'

# Define the required permissions
$permissions = @('Device.Read.All','Mail.ReadWrite','User.Read.All','DeviceLocalCredential.Read.All','Mail.Send')

# Get the IDs for your Service Principal and MS Graph
# IMPORTANT! Change the AppName (aa-getLAPS) here to the Name you used!
$clientServicePrincipal = Get-EntraServicePrincipal -Filter "displayName eq 'aa-getLAPS'" 
$resourceServicePrincipal = Get-EntraServicePrincipal -Filter "displayName eq 'Microsoft Graph'"

# Iterates through the permissions and sets them up
foreach($permission in $permissions){
  $appRole = $resourceServicePrincipal.AppRoles | Where-Object { $_.Value -eq $permission }
  $appRoleAssignment = New-EntraServicePrincipalAppRoleAssignment -ObjectId $clientServicePrincipal.Id -PrincipalId $clientServicePrincipal.Id -Id $appRole.Id -ResourceId $resourceServicePrincipal.Id
  $appRoleAssignment | Format-List Id, AppRoleId, CreatedDateTime, PrincipalDisplayName, PrincipalId, PrincipalType, ResourceDisplayName
}

Now that we set up the permissions, you can check them in the portal:

1. Open the Entra admin center -> Enterprise apps, set the Application type to All Applications and search for the name of your previously created automation account.

2. Open the app and select Security -> Permissions.

Here you can now see the Graph API permissions we set up.

Before	After

Enduser permission ​

The enduser also needs permissions to trigger the runbook, for which we need a group.

1. You can create one by opening the Entra admin center -> Groups and click New group.
2. Enter your Name, Description and select your users and the group owner.
3. Click Create to create the group.

Now that we got a group, we give it permission to start the runbook. We can use a built-in role or create a custom role for least privilege.

1. To get started, you open the Azure admin Portal -> Automation Accounts and select the previously created Automation Account.
2. To create a custom role you select Access control (IAM) -> Roles search for the Automation Job Operator, click on the 3 dots on the right and select Clone.

3. Next you enter a Name, Description and click Next.

4. In the Permissions tab you remove all permissions except the following 2:
   • Microsoft.Automation/automationAccounts/jobs/read
   • Microsoft.Automation/automationAccounts/jobs/write
5. In addition, add the following with ➕ Add permissions:
   • Microsoft.Automation/automationAccounts/runbooks/read
6. Then you can click Review + Create and Create again, because the Assignable scopes will automatically be set to the current Automation Account.

Now we need to assign the custom or build-in role:

1. Back in the Automation Account, you select Access control (IAM) again, click ➕ Add and Add role assignment.

2. Now select either the previously created custom role or the built-in Automation Job Operator role and click Next.

3. Here select the Group we created earlier, add it with ➕ Select members, click Review ➕ assign and then Review ➕ assign again.

👤 User Experience ​

Now that everything is set up, the enduser can request their LAPS password without any privileged access. For that you can use the following PowerShell script, integrate that into one of your self-service portals, use power automate or Logic Apps.

INFO

If you want your users to just execute something simple, I packed the script into an .exe with a simple GUI that you can deploy via Intune (Download). But be aware that I used the resource names seen in this article for the exe.

To execute the script the user does not need any license or other permissions except to be a member of the group we created earlier. But be aware that the user needs a mailbox to be able to receive the LAPS password via mail.

# Install and/or Import the required modules
$required = 'Az.Accounts','Az.Automation'

foreach ($name in $required) {
  if (-not (Get-Module -ListAvailable -Name $name)) {
    Write-Host "Installing module $name..."
    Install-Module -Name $name -Scope CurrentUser -Force -AllowClobber -ErrorAction Stop
  }
  Import-Module $name -ErrorAction Stop
}

# Connect to Azure
connect-azAccount

# Get the current user's UPN and Entra User ID
$upn = (Get-AzContext).Account.Id
$userid = Get-AzAdUser -UserPrincipalName $upn

# Start the Automation Runbook with the Entra User ID as parameter
$param = @{
  Name                  = "ru-getLAPS"
  AutomationAccountName = "aa-getLAPS"
  ResourceGroupName     = "rg-getLAPS"
  Parameters            = @{ EntraUserID = $userid.id }
}
Start-AzAutomationRunbook @param

# Disconnect from Azure
disconnect-azAccount

A few moments later the user will receive an email with their LAPS passwords in their inbox.

The admin can also inspect the job execution in the Azure Portal under the Automation Account or in the Runbook. The actual email content / LAPS passwords will not be visible in the job output in the runbook jobs tab, so a person without the proper permissions will not be able to access them.

💡 Conclusion ​

This approach provides a simple, auditable way to deliver LAPS passwords to end users without granting them broad access. By using an Automation Account with a managed identity and scoped Graph permissions, you centralize sensitive operations while minimizing privileged access.

With this self-service setup, you can enrich your environment even if you already use an Endpoint Privilege Management (EPM) solution, as it provides a quick and easy way to give admin access to a users whole device. So no matter if you plan to use it with admins or endusers, this provides a flexible, least-privilege self-service solution to a problem as old as client-server setups itself.

Winget DSC (Desired State Configuration) ​

👋 Introduction ​

Desired State Configuration (DSC) is a feature that automatically keeps IT infrastructure in a defined, consistent desired state It provides drift control by ensuring that systems automatically conform to this defined state, maintaining consistency and correcting any deviations.

DSC can do stuff like keeping your applications up to date, ensuring services are running, applying configuration settings and managing files. These tasks help maintain consistency, security, and functionality across user devices with minimal manual intervention.

There are different versions and different implementations of DSC. Winget uses Powershell DSC 3.0 for the configure and Microsoft DSC 3.0 the new dscv3 command. These two implementations have different capabilities and purposes.

configure - Is build on top of Powershell DSC 3.0 and is used to configure your machine.

dscv3 - Is build on top of Microsoft DSC 3.0 and supports at the moment exporting the configuration of the current device, including Windows Settings, packages from configured WinGet sources and package settings from DSC v3 enabled packages.

🚀 Start using WinGet & DSC ​

Winget configure ​

What can be configured?

1. Configuration Settings
   • Windows Explorer
   • Dark Mode
   • Taskbar
2. Software Installation
   • Winget
   • MS Store
   • Software Configurations
3. Powershell Scripts
   • Whatever you can think of

How to create a WinGet DSC configuration file

1. Create a text file and save it with a .dsc.yaml extension.
2. Open the file in a text editor and add content in the following format:
   1. Schema: Defines the structure and properties required to configure a resource.
   2. Properties: Defines the properties of a resource.
   3. Assertions: Sets the conditions that must be met for a configuration to apply.
   4. Resources: Defines the resources that are being configured.
   5. Configuration Version: Sets the version of the configuration.

Example Code:

yaml

# yaml-language-server: $schema=https://aka.ms/configuration-dsc-schema/0.2

properties:
  assertions:
    - resource: Microsoft.Windows.Developer/OsVersion
      directives:
        description: Verify min OS version requirement Windows 11 Version 23H2
        allowPrerelease: true
      settings:
        MinVersion: '10.0.22631'
  resources:
    - resource: Microsoft.WindowsSandbox.DSC/WindowsSandbox
      directives:
        description: Create Windows Sandbox
        allowPrerelease: true
      settings:
        Ensure: Present # Ensure the resource is present
        LogonCommand: >
          # Define a command to run when the sandbox is started
  configurationVersion: 0.2.0

How to apply a configuration file

Open a PowerShell window and use the following code to apply the configuration file:

winget configure [filename].dsc.yaml

Example of the Microsoft Sandbox WinGet DSC configuration file executing:

# yaml-language-server: $schema=https://aka.ms/configuration-dsc-schema/0.2

properties:
  ########################################################################
  # Windows assertion Section: Defines the conditions that must be met for a configuration to apply
  ########################################################################
  assertions:
    - resource: Microsoft.Windows.Developer/OsVersion
      directives:
        description: Verify min OS version requirement Windows 11 Version 24H2
        allowPrerelease: true
      settings:
        MinVersion: '10.0.26200'
  ########################################################################
  # Windows resources Section: Defines the resources that are being configured
  ########################################################################
  resources:
  ########################################################################
  # Windows Settings: Enable Dark Mode
  ########################################################################
  - resource: Microsoft.Windows.Developer/EnableDarkMode
    directives:
      description: Enable dark mode
      allowPrerelease: true
    settings:
      Ensure: present # [Present, Absent]
      # Use caution when setting `RestartExplorer: true` as this will force explorer to close.
      RestartExplorer: true # Required to apply changes
  ########################################################################
  # Windows Feature: Hyper-V (Code is correct, but there is a bug with the DSC resource which produces the error "Class not registered")
  # https://github.com/microsoft/winget-cli/issues/4264
  ########################################################################
  - resource: PSDscResources/WindowsOptionalFeature
    directives:
      description: Enable Hyper-V
    settings:
      Ensure: present # [Present, Absent]
      Name: Microsoft-Hyper-V-All
  ########################################################################
  # Winget: Install VS-Code & YAML extension
  ########################################################################
  - resource: Microsoft.WinGet.DSC/WinGetPackage
    id: install-vs-code
    directives:
      description: Install Microsoft Visual Studio Code
      allowPrerelease: true
    settings:
      id: Microsoft.VisualStudioCode
      source: winget
      Ensure: Present
  - resource: Microsoft.VSCode.Dsc/VSCodeExtension
    id: install_vscode-yaml
    dependsOn:
      - install-vs-code
    directives:
      description: Install YAML extension for VSCode
      allowPrerelease: true
    settings:
      Name: redhat.vscode-yaml
      Exist: true
  ########################################################################
  # Powershell: Install PowerShell Modules
  ########################################################################
  - resource: PowerShellModule/PSModuleResource
    id: install-microsoft.graph
    directives:
      description: Install MS Graph module
      allowPrerelease: true
    settings:
      Module_Name: microsoft.graph
      Ensure: Present
  ########################################################################
  # MSStore: Install Microsoft Company Portal with Winget
  ########################################################################
  - resource: Microsoft.WinGet.DSC/WinGetPackage
    directives:
      description: Installing Microsoft Company Portal
      allowPrerelease: true
      securityContext: current
    settings:
      id: "9WZDNCRFJ3PZ"
      source: msstore
    id: 9WZDNCRFJ3PZ
  ########################################################################
  # Powershell Script: Check Autostart for OneDrive
  ########################################################################
  - resource: PSDscResources/Script
    id: OneDrive-Autostart
    directives:
      description: Autostart OneDrive
      allowPrerelease: true
    settings:
      GetScript: |
        # Your custom PowerShell code to check app configuration
      TestScript: |
        If( (Get-Item HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run).property -contains "OneDrive" ){ return $TRUE } else{ return $FALSE }
      SetScript: |
        # PowerShell script commands to install VSCode extensions
        New-ItemProperty -Path "HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" -Name "OneDrive" -Value "C:\Program Files\Microsoft OneDrive\OneDrive.exe -background"  
  ########################################################################
  # Configuration Version: Defines the version of the configuration
  ########################################################################
  configurationVersion: 0.2.0

Next to outright starting the configuration, you can also show, list, test, validate and export configurations.

winget configure show [filename].dsc.yaml

Winget dscv3 ​

What can be exported?

• package: The Packages of the local device
• source: The Sources of the local device
• user-settings-file: The User Settings File of the local device
• admin-settings: The Admin Settings of the local device

How to export stuff?

Open a PowerShell window and with following code you can export the packages, sources, user-settings-file and admin-settings of the current device and there manifests and schemas.

winget dscv3 package --export
winget dscv3 package --schema
winget dscv3 package --manifest

winget dscv3 source --export
winget dscv3 source --schema
winget dscv3 source --manifest

winget dscv3 user-settings-file --export
winget dscv3 user-settings-file --schema
winget dscv3 user-settings-file --manifest

winget dscv3 admin-settings --export
winget dscv3 admin-settings --schema
winget dscv3 admin-settings --manifest

💡 Conclusion ​

Desired State Configuration (DSC) provides a powerful, declarative foundation for defining and maintaining system state, ensuring environments remain consistent, auditable and free from configuration drift. By automating setup and enforcement, DSC reduces manual overhead and makes configuration management both scalable and reliable.

Winget DSC builds on this foundation by unifying package management and configuration into a single, scriptable workflow. With commands like configure for applying and enforcing settings and dscv3 for exporting current states, it enables reproducible, version-controlled setups that simplify provisioning and auditing across devices. When integrated with tools such as Intune or CI/CD pipelines, Winget DSC helps teams deliver consistent, ready-to-use systems faster and with greater confidence.

Resources

• Powershell DSC 3.0 - Microsoft Learn
• WinGet Configuration - Microsoft Learn
• Microsoft Desired State Configuration overview - Microsoft Learn
• DSC Community Repository - GitHub
• DSC - PowerShell Gallery
• DSC Community - Homepage
• DevHome Sample Configurations for Specific DSC Resource - Github

🧑‍🔧 Customize the Windows 11 Taskbar ​

Customising the Windows 11 Taskbar allows you to personalise the user experience by pinning frequently used applications and removing unnecessary shortcuts. This section provides instructions on creating a Taskbar configuration XML file and testing it in a controlled environment. To make things easier and avoid having to create a complicated XML file, I've created a script that gives you a handy list of your apps to select and then creates the XML file for you.

Creating the Taskbar settings XML ​

1. Configure the taskbar with Microsoft Intune or GPO by automatically creating the XML file using the script I created from the PSGallery.

Install-Script -Name New-TaskbarCustomizationXML

Or you Download the script directly from my Github.

2. As soon as you Start the Script with the command below, a Windows Explorer Dialog opens and you can select a Folder to save your Script.

New-TaskbarCustomizationXML

3. Next, the script opens a list of your current taskbar shortcuts. Select the shortcuts you want to add to the XML file.

4. The script opens a list of all your installed packages (programs). Select the ones you want to add to the XML file.

5. NEW Nov 2025 Next you will be asked if you want any of the Pins not to come back, if the user unpins them.

6. Pressing OK will create a new folder called TaskBar_XML in the folder you selected. You can then find your new XML file in this folder.

XML file example from Microsoft:

<?xml version="1.0" encoding="utf-8"?>
<LayoutModificationTemplate
    xmlns="http://schemas.microsoft.com/Start/2014/LayoutModification"
    xmlns:defaultlayout="http://schemas.microsoft.com/Start/2014/FullDefaultLayout"
    xmlns:start="http://schemas.microsoft.com/Start/2014/StartLayout"
    xmlns:taskbar="http://schemas.microsoft.com/Start/2014/TaskbarLayout"
    Version="1">
  <CustomTaskbarLayoutCollection>
    <defaultlayout:TaskbarLayout>
      <taskbar:TaskbarPinList>
        <!-- your pins list goes here -->
    </defaultlayout:TaskbarLayout>
 </CustomTaskbarLayoutCollection>
</LayoutModificationTemplate>

Test Taskbar XML ​

To test the XML file quickly and set up Start Pins, follow these instructions:

1. Start the Windows Sandbox, any other VM or your own PC. If you're using a Virtual Machine, copy the XML file onto it.

2. Open the local Group Policy Editor (gpedit.msc) and go to Computer Configuration -> Administrative Templates -> Start Menu and Taskbar.
   
3. Next open Start Layout, select Enabled and enter the path of the XML file.
4. Finally click OK.

5. Now open a command prompt or powershell window and enter the following command.

gpupdate /force

6. When the command is completed, open the Taskmanager, scroll down to the Windows Explorer and select Restart.

Taskbar before:

Taskbar after:

Deploy Taskbar XML ​

When deploying the Start Menu XML, please note that there is a slight oddity in Intune.
It is not possible to import the file directly; instead, the XML text must be copied and pasted into the text box.

Conclusion ​

By following the steps above, you can easily test and validate your Taskbar XML configuration in a controlled environment like Windows Sandbox or a virtual machine. This ensures that your customizations work as intended before deploying them to production systems.

🧑‍🔧 Customize the Windows 11 Start layout ​

You can customise the Windows 11 Start layout to make it consistent and user-friendly by pinning essential apps and organising the Start menu. This section provides guidance on creating the JSON file and deploying it.

Creating the Start Menu Layout JSON ​

1. Microsoft provides a CMDlet to help you create the Start Menu JSON.

2. Open a Powershell Windows and use the code below:

Export-StartLayout -Path "C:\temp\LayoutModification.json"

JSON file example from Microsoft:

{
  "pinnedList": [
      { "desktopAppLink": "%ALLUSERSPROFILE%\\Microsoft\\Windows\\Start Menu\\Programs\\Microsoft Edge.lnk" },
      { "packagedAppId": "windows.immersivecontrolpanel_cw5n1h2txyewy!microsoft.windows.immersivecontrolpanel" },
      { "desktopAppLink": "%APPDATA%\\Microsoft\\Windows\\Start Menu\\Programs\\File Explorer.lnk" },
      { "desktopAppLink": "%APPDATA%\\Microsoft\\Windows\\Start Menu\\Programs\\Windows PowerShell\\Windows PowerShell.lnk" },
      { "packagedAppId": "Microsoft.WindowsTerminal_8wekyb3d8bbwe!App" },
      { "packagedAppId": "Microsoft.Paint_8wekyb3d8bbwe!App" },
      { "packagedAppId": "Microsoft.Windows.Photos_8wekyb3d8bbwe!App" },
      { "packagedAppId": "MicrosoftCorporationII.QuickAssist_8wekyb3d8bbwe!App" },
      { "packagedAppId": "Microsoft.MicrosoftStickyNotes_8wekyb3d8bbwe!App" },
      { "packagedAppId": "Microsoft.SecHealthUI_8wekyb3d8bbwe!SecHealthUI" },
      { "packagedAppId": "Microsoft.OutlookForWindows_8wekyb3d8bbwe!Microsoft.OutlookforWindows"}
  ]
}

Layout Modification Options

Deploy Menu Layout JSON ​

You'll find the setting for deploying the Start Menu Customisation in the Settings Catalog in Intune.
When you're deploying the Start Menu JSON, you can import the file into Intune.

Start Menu before:

Start Menu after (The user can`t remove the Start Menu items):

Conclusion ​

If you follow the steps above, you can easily customise the Start Menu using the JSON file, making sure that users have a consistent experience.

Windows 365 Configuration ​

👋 Introduction ​

Windows 365 is Microsoft’s cloud-based Desktop-as-a-Service (DaaS) offering. It provides fully managed virtual PCs hosted in the cloud, which users can access from any device with an internet connection.

To learn more about what a Cloud PC or Windows 365 is or how it compares to other DaaS solutions, look at this article.

In the following guide I will go trough the configuration, provisioning and user experience of Windows 365.

To use Windows 365 Business, you only need to buy the license and assign it to a user in the M365 Admin Center -> Billing -> Licenses. You can not manage it and therefore no configuration of the Cloud PC itself is needed.

📥 Provisioning ​

Windows 365 Enterprise, Frontline, Reserve and Link are managed through the Intune admin center.

If you got no licenses in your tenant, you can not start with the configuration.

1. To start provisioning Licenses you first need to buy some or start a trial. You can do that by going to the Microsoft 365 admin center and select Marketplace or if this is not shown in your side panel you open Billing and select Purchase services. There you can just search for the Windows 365 product you want and get it as a purchase or trial.

2. Now that you got the license you can start with the provisioning. For that you open Billing and select Licenses.

3. Click on the Windows 365 License in your list and select + Assign license either in the Users or Groups tab and assign it to the identity you want to access the Cloud PC with.

⚙️ Configuration ​

Prerequisites:

• Access to the Intune admin portal
• Entra roles: Global Administrator, Intune Administrator or Windows 365 Administrator

To set up Windows 365, there are four configuration areas where you can define settings:

• Provisioning policies: Control how the Cloud PC is created and set up.
• Custom images: Create and use a custom Windows image from an Azure Image Gallery for new Cloud PCs.
• Azure network connection: Connect an Azure virtual network (VNet) for Cloud PC networking.
• Settings: Manage user-related settings for Cloud PCs.

In addition you should set up a device group to better assign your policies.

1. First you open the Intune admin portal -> Devices -> Device onboarding -> Windows 365, where you can see the Overview of the current Windows 365 status and get started.

2. If you select the All Cloud PCs or All Cloud Apps tabs, you will get a list of all the current Cloud PCs and Remote Apps and there status.

Provisioning policies ​

1. To create a provisioning policy you select the Provisioning policy tab and click Create.
2. On the first page you enter the policy name, description and select the Cloud PC experience and type you need.
   • Experience
     • Full Desktop
     • Remote App
   • Type
     • Enterprise
     • Frontline
     • Reserve (So new it is not on the screenshot.)
3. Next you select the Join type details.
   • Join type
     • Entra Join
     • Hybrid Entra Join
   • Network
     • Microsoft hosted network
     • Azure network connection
   • Entra single sign-on

Network connection

If you select Microsoft hosted network Microsoft will take care of the needed Network architecture. Additionally since December 2025 you can utilize a 3 tiered region level.

• Geography level (Level 1): Selects all regions in the whole Geography.
• Region group level (Level 2): Selects a specipic supgroup of that Geography, for data boundary requirements for example.
• Region level (Level 3): Selects a specific region.

The Cloud PCs will then get provisioned only in the selected regions and you can also select your own custom selection of regions out of a Geography. You can also set your Region selection to auto. That means Microsoft automatically spreads your devices through the Geography dependend on the best availability. So that also means, if there is an outage in a Region your Cloud PCs will get automatically set up in another region, without you needing to do anything and new regions will automatically get utilized.

If you select Azure network connection Cloud PCs will use a prior set up Vnet from your Azure supscription that you connected through the Azure network connection tab. With this you got the complete control over the network infrastructure and can connect Cloud PCs to your existing environment, without going through the internet. This is mandatory for Hybrid Entra joined Cloud PCs.

If you select Frontline as License type you can additionally select if you want to utilize Dedicated or Shared mode.

INFO

Be aware that selecting Access only apps which run on a Cloud PC always means you run Windows 365 Frontline in Shared mode.

4. Then you click Next and select the Image type on the next page. You can select from a few Microsoft provided gallery images or use a Custom image you set up in the Custom image tab.

5. Now click Next again and you get to the Configuration tab. Here you can set the following:
   • The Language the Cloud PC will use.
   • A possible custom device naming template.
   • If you want to use Autopilot device preperation. (This makes it easy to get the device directly set up the way you need it. With scripts and apps, ready for the user to log in.)
   • If you want to utilize Windows Autopatch to automate Windows updates on your Cloud PCs.

Experience Sync

If you create a profile for a Windows 365 Frontline Cloud PC in shared mode, you can addtionally select the new Experience Sync option. This new Feature (November 2025) will act as a quasi FsLogix(What is FsLogix?) for your Cloud PCs. With this the Windows personalization, user settings, application settings and application data will be saved between sessions. This provides a better user experience, despite Frontline shared mode resetting the Cloud PC after logoff.

You can activate it in the Configuration settings and set the amount of storage you want to give each user for that.

6. After the configuration you click Next again, enter your Scope tags, set the Assignment to the device group you created and then Review + create it.

Custom images ​

1. To add a custom image to Windows 365 you go to the Intune admin portal -> Devices -> Device onboarding -> Windows 365, where you can open the Custom images tab.

2. When you then click Add, a flyout window opens where you can select the following:
   • An image name.
   • The version of your image (So you can see which image is used here and used in which Cloud PC. This gives you a better understanding of your image lifecycle.)
   • The subscription where your image gallery is located.
   • The source image you want to use.

3. After that you just add the image.

Azure network connection ​

To add a custom network connection to your Cloud PC, you need to meet a few requirements.

Requirements for Entra joined Cloud PCs:

• Azure Virtual Network: Must be in the same region as the Windows 365 desktops.
• Network Bandwidth: Make sure the network has enough bandwidth for your needs.
• Subnet and IP Address Space: A subnet in the VNet with enough available IP addresses.

Additional requirements for Entra hybrid joined Cloud PCs:

• DNS Resolution: The VNet must be able to resolve AD DNS records.
• Domain Controller Access: The VNet must have network connectivity to a domain controller.

1. To add a custom network connection to Windows 365 you go to the Intune admin portal -> Devices -> Device onboarding -> Windows 365 and open the Azure network connection tab.
2. Here you can use + Create to add a network for Entra join or Entra hybrid join.

3. For an Entra join network you just enter a name and then select the VNet and Subnet from your existing subscriptions. For Entra hybrid join, you also need to add your domain info one tab later (The domain user needs to have the apropriate permissions to add devices).

4. After that you click Next, enter scope tags if needed and then create the connection.

5. This will now trigger a connection check that can take a few minutes to complete, to check if your connection is legit.

6. After the fact you can click on the Status and look at the checks that where performed. In the case of a failure, you can also find the problem in here.

Settings ​

1. To add settings to your Cloud PC you go to the Intune admin portal -> Devices -> Device onboarding -> Windows 365 and open the Settings tab, where you can create Cloud PC configurations or User settings.

Cloud PC configuration

In the Cloud PC configurations you can turn on Copilot + PC AI features.

1. Just add the Name and Description in the first tab, click Next and then in the Configuration settings tab, you enable the AI-enable features setting.
2. After that click Next again, enter Scope tags you need, create the assignment to a group of users and then Review + create the settings policy.

You will be able to verify if it worked in the Overview of your Cloud PC.

User settings

In the User settings you set up the behavior of the users that sign-in to your Cloud PCs.

1. First enter the name of your settings policy and then, you can set the following settings:
   • Enable local admin: Elevated user to local admin on the Cloud PC.
   • Enable users to reset their Cloud PCs: Enables a reset option in the Windows App, that lets the user reset / wipe and reprovision the Cloud PC (delets all user data and apps).
   • Allow user to initiate restore service: Allows the user to restore the Cloud PC to any available backup.
   • Frequency of restore-point service: Sets the time gap between restore points (4, 6, 12, 16 or 24 hours).
   • Cross region disaster recovery configuration: Lets you protect Cloud PCs during regional outages (needs an additional license). You can select: None, Disaster Recovery Plus or Cross Region Disaster Recovery (Learn more here).

2. After that click Next, create the assignment to a group of users and then Review + create the user settings.

Windows App settings

The Windows App settings are a Preview feature where you can set the behaviour of the Windows App or Windows web portal for your users (Learn more here).

1. Like with the other settings you can enter a Name first and then on the second tab set the following settings:
   • Enable users to reset their Cloud PCs: Enabling this shows the option for users to reprovision their Cloud PC.
   • Allow users to initiate a Restore: Enabling this shows the option for users to initiate restores of their Cloud PC.

Windows 365 Boot ​

Windows 365 Boot allows users to bypass the need to sign in to their physical device, enabling them to sign in directly to their Windows 365 Cloud PC after boot.

1. You can start the guided setup directly from the Overview page in the Intune admin portal -> Devices -> Device onboarding -> Windows 365, where you find it at the bottom under Windows 365 Guides -> Windows 365 Boot.

2. The first page explains what Windows 365 Boot is and what will be configured in this profile. You just click Next to continue.

3. After that you come to the Basics tab, where you can set the following options:
   • Device name template
   • Name
   • Description
   • Shared PC mode / Dedicated PC mode

And you get the Information about the ressources this guided setup will create for you. Now click Next to continue.

4. In the Endpoint updates tab you set up the update behavior of the physical device, you use to access the Cloud PC. After that click Next to continue.

5. In the Settings tab you can set up the following options:
   • VPN profile
   • Wi-Fi profile
   • OS language
   • Security baseline (This is for the physical device, not the Cloud PC)
   • Connection Timeout
   • Personalization (Shared PC mode only)
     • Company name
     • Company logo URL
     • Lock screen Image URL

Dedicated mode	Shared PC mode

6. If you then click Next you will come to the Assignments tab, where you can first choose a deivce group to assign the profile to and then decide if users (also which users) should still be able to access the local device or only the cloud PC. To learn more about restricting access to the local device look here.

7. When you now click Next again you come to the Review + create tab, where you will be informed again which ressources the guided setup will create.

• Windows 365 App
• Windows 365 Boot Enrollment Status Page Profile
• Windows 365 Boot Autopilot Profile
• Windows 365 Boot Device Configuration Policy
• Windows 365 Boot Windows Update Policy

Other Settings ​

There are a few other things you can set up or need to know regarding the configuration of Windows 365.

RBAC

First regarding automatic configurations.

If you connect Images or Network connections to your Windows 365 environment, the system will automatically set up the apropriate RBAC role asignments in your Azure ressources to give Windows 365 the permission it needs. But these Role assignment will not be removed automatically, if you delete the Image or Network connection again.

Configuration Settings

Secondly there are a lot of configurations you can set up to customize the Cloud PC experience even more. You can use the same controls you used for RDP connections in the past.

The following example demonstrates how to enable USB redirection. This allows the use of USB devices such as FIDO security keys.

1. To create a configuration you go to the Intune admin portal -> Devices -> Configuration, where you click create + Create -> + New Policy to create a new configuration.
2. Select Windows 10 and Lateras Platform and Settings catalog as Profile type and then click Create.
3. Enter a Name and Description for your profile and then click Next to continue.
4. If you now click on + Add settings you can search for the Do not allow supported Plug and Play device redirection setting, activate it and set it to Disabled.

5. Click Next again, enter Scope tags if needed, click Nextagain, set the Assignments to the Windows 365 device group you created at the start and then Review + create the settings profile.

Next we need to create the setting to allow redirection on the local device, that connects to the Cloud PC. You can create that manually in your local Group Policy Editor to test or also through Intune.

1. To create the setting through Intune follow the same steps as before and search for the setting Allow RDP redirection of other supported RemoteFX USB devices from this computer and set it to Enabled. To create the setting manually open the Group Policy Editor (just search for group policy in Windows) on your local device and navigate to Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Connection Client -> RemoteFX USB Device Redirection and set the setting there.

Once both settings have taken effect and you have connected to your Windows 365 machine, an additional symbol will appear in the connection bar, allowing you to activate or deactivate individual USB devices.

🗄️ Windows 365 Reserve ​

Windows 365 Reserve lets organizations give employees up to 10 days of Cloud PC access per year with an annual license. Cloud PCs are set up only when needed, what is cheaper and simpler then keeping physical loaner devices around and ship them through the lands.

There are a few important things to understand about Windows 365 Reserve licensing, as these will impact whether it is a good fit for your needs.

First, Windows 365 Reserve licenses must be purchased through Microsoft Sales and can not be gotten directly through the Microsoft Admin Center. The licenses apply at the tenant level and are not assigned in the Microsoft 365 admin center. Instead, they are applied when you create provisioning policies in Intune and assign those policies to a user group.

To cover users with Windows 365 Reserve, each user must already have the required base licenses, either standalone or as part of a bundle:

• Windows 11 Enterprise or Windows 10 Enterprise
• Microsoft Intune
• Microsoft Entra ID P1

The cost for Windows 365 Reserve is 20 $ per user per year (November 2025).

A few important additional points:

• Microsoft recommends purchasing one Windows 365 Reserve license for every user you want to cover
• Reserve licenses cannot be shared or pooled across users
• After a Windows 365 Reserve license is assigned through a provisioning policy, the user’s Cloud PC can be provisioned only after a seven-day waiting period.

So what that all means in practice is the following:

1. You contact you Microsoft sales rep and buy the needed amount of Windows 365 Reserve licenses.
2. These will then be provisioned to your tenant and visible in the Microsoft 365 admin center.
3. Now you create a user group with the users that you want to cover (should be the amount of licenses you bought).
4. Then you create a provisoning policy for Windows 365 in Intune and select Reserve as License type.
5. In the Assignment tab of the provisioning policy you select the user group you created.
6. When you then click on the provisioning policy, you will see all the users in the Cloud PC users tab.
7. You now wait 7 days.
8. After you can go back to the provisioning policy, click on the user and then click Provision.
9. Now the Reserve Cloud PC will be ready in now time for the user.

• If you want to learn more about Windows 365 Reserve click here.
• If you want learn more about the licensing click here.

⭐ User Experience ​

To access your Cloud PC there are multiple options. Following you find an Access Matrix where you find which access method is available for which license type and then a Feature Matrix where you find which features are available on which client.

1. The best option for accessing your Cloud PC on Windows is to use the Windows App and if you're not using Windows, you can also access it via the Browser at https://windows.cloud.microsoft/.
2. Here you will find your assigned and provisioned Cloud PCs after sing in.
3. Clicking the three dots on the right of your Cloud PC card allows you to perform various actions, such as restarting or restoring the Cloud PC, or accessing the settings.

4. For accessing, you just click Connect.

INFO

The first sign-in can run a little longer then normal.

📑 Reporting ​

To get a handle on the status of your Windows 365 devices, there are lots of options to look at.

IMPORTANT

This reporting is only available for Windows 365 Enterprise, Windows 365 Frontline or Windows 365 Reserve licenses. Windows 365 Business is not managed through Intune and therefore has not these specific reporting options.

Windows 365 tab

• Firstly, to get an Overview about your current W365 devices and W365 cloud apps, you can look at the Overview, All Cloud PCs and All Cloud Apps pages in the Intune admin portal -> Devices -> Device onboarding -> Windows 365.

• On the same Overview page you find the Connection Quality Report. This report gives a great overview regarding connection speeds, bandwidth, gateway locations and more.

• On the Overview page you also find the Resource Performance report, which is a shortcut to the Endpoint analytics Resource Performance report. This report gives you a comparision view, how your devices are doing in the ressource department. To see only the Cloud PCs you can set up a Device scope.

Device section

• You can find the most basic overview directly in the Intune admin portal under the Device Overview.

• Or you can find a report on Cloud PC device actions (Restarts, Wipes and so on) under the Monitor section.

Reports section

• In depth Windows 365 reports can be found in the Intune admin portal -> Reports under the Cloud PC overview. As well as the report on Connection quality, you will find many other useful reports, such as an overview of the status of your new Windows 365 Reserve licences or an overview of your AI-enabled (Copilot + PC) Cloud PCs.

• The first report I want to highlight is the Cloud PC utilization report, which gives you a great overview on how high the utilization of your Cloud PCs actually is. This will give you a better idea of whether you have the right number of Cloud PCs and whether you have enough of them.

• The second report to highlight is the Cloud PC recommendations report, which gives you even more information about your Cloud PC sizing and also provides recommendations on how to optimize the usage.

Individual device section

• Next you can get a lot of Windows 365 specific information directly from the individual device page in Intune. Like that it is in fact a Cloud PC, which size it has and if it is AI-enabled.

• Next to that you find 2 special tabs in a Windows 365 device page. The first is the Performance tab, where you can find detailed reports about the connectivity status, the connection quality and the connections your users made.

• The first of these performance reports is listed under Connectivity status, but if you open the report you will find a Connectivity history with timestamps and statuses of connection activities.

• The second performance report is listed under Connection quality. Here you find really detailed information about all the connections that where made in regards to there latency, speed and more.

• The third and last performance report is listed under Time connected and this is what it shows (even so the report is named Session Performance).

• Now at last, the second special tab is the Restore points tab, where you can find all the restore points that are available for this Cloud PC, with the possebility to restore.

🕵️ Digital forensics ​

Digital forensics is the systematic process of identifying, preserving, analyzing, and presenting digital evidence to investigate incidents such as cybercrime, fraud or data breaches.

As part of managing your devices, you may sometimes need to submit a device for digital forensics. Windows 365 makes this possible by allowing you to place a Cloud PC under review.

When a Cloud PC is placed under review, Windows 365 securely saves a snapshot of the Cloud PC to your Storage account. Once the snapshot is transferred, it fully belongs to you and is not managed by Microsoft anymore.

---

1. To do that, you just go to the Intune admin portal -> Devices -> Windows and open the Cloud PC you want to place under review.
2. Now you click on ... at the top right and then on Place Cloud PC under review.

3. That will open a flyout on the right side, where you can select a Storage account from your Subscription.

💡 Conclusion ​

Windows 365 offers a flexible and modern approach to desktop-as-a-service, whether you're looking to support a small team or an entire enterprise. It is not a catch-all solution, but ideal for supporting specific scenarios like temporary staff, contractors or remote workers without risking data leaving your environment or compromising security. In addition it provides great resilience without the need to manage your own worldwide infrastructure.

The key to a successful Windows 365 deployment is starting with a clear understanding of your requirements. Consider which type best fits your use case, Business for simplicity, Enterprise for full control, Frontline for frontline staff or Reserve to guarantee access.

Remember that Windows 365 is continuously evolving with new features like Experience Sync or AI-enabled capabilities. Stay informed about updates and regularly review your deployment through the available reports to ensure you're getting the most value from your investment.

References

• Windows 365 Experience Sync
• RDP USB Redirection
• Enhance Microsoft Hosted Network Cloud PC Resiliency with Multi-Region Selection
• User Experience Sync for Windows 365 Frontline in shared mode
• What is Windows 365 Boot?
• Compare Windows App features across platforms and devices

]]>

☁️ What is a Cloud PC? ​

A Cloud PC is a virtual computer hosted in the cloud. It allows users to access their desktop environment and applications from any device with an internet connection. Because the computing resources are managed remotely, organizations can adjust capacity as needed, which supports flexibility and scalability. This approach is particularly useful for remote work, as it enables consistent access to files and applications from anywhere.

Examples of Cloud PC services:

• Microsoft Windows 365
• Microsoft Azure Virtual Desktop
• Amazon WorkSpaces
• Google Cloud's Virtual Desktops

🧑‍💻 What is windows 365? ​

Windows 365 is Microsoft’s cloud-based Desktop-as-a-Service (DaaS) offering. It provides fully managed virtual PCs hosted in the cloud, which users can access from any device with an internet connection.

Use cases

• Security: You can keep your data on your own network, stay secure and compliant, reduce risk and still support remote work.
• Disaster Recovery: Quickly set up a secure work environment in case of compromise.
• Bring-yor-own-Device: Enable a secure and consistent environment without a physical devices.
• Short-Term Staff / Contractors: Provide secure and compliant access for temporary staff while reducing onboarding and offboarding effort.
• Performance spikes: Reduce the need for big, rarely used, local capacity and give demanding workloads the power they need without impacting the rest of your environment.
• Shared Devices: Frontline and frontline-shared licenses offer a cost-effective way to provide frontline and shift workers with their own desktop environment, eliminating the compliance and credential hassle associated with shared accounts.
• Mergers & Acquisitions: Spin-up capacity and give access to new useres quickly, without loosing security or compliance.

Windows 365 Plans

• Windows 365 Business: For businesses with up to 300 users, this is a fully Microsoft-managed Cloud PC solution with no management options.
• Windows 365 Enterprise: Microsoft-managed Cloud PC solution with management options through Intune.
• Windows 365 Government: Microsoft-managed Cloud PC solution for the US government with specific security and compliance requirements.
• Windows 365 Frontline: This license offers two options: dedicated desktop access for up to three users (one at a time per license) or a shared mode providing non-persistent machines to an unlimited number of users, also one at a time.
• Windows 365 Reserve: Microsoft-managed Cloud PC solution used as supstitude for an unavailable device or short-term access up to 10 days per user per year.

When it comes to providing dedicated Cloud PCs, most businesses need to decide between Windows 365 Business and Windows 365 Enterprise. Below you find a feature matrix comparing these two plans:

Windows 365 GPU-enabled

Microsoft also provides a Windows 365 Enterprise plan for GPU-enabled Cloud PCs with basic graphics acceleration or a dedicatid GPU.

👩‍💻 What is Azure Virtual Desktop (AVD)? ​

Azure Virtual Desktop is around for many many years at this point. It is a computer virtualization solution (Virtual Desktop Infrastructure (VDI)) in the Microsoft Azure Cloud. It offers all the known and loved features that your local VDI solutions provides and maybe a bit more, just in the cloud. Dedicated virtual desktops, multi-session desktops, non persistant desktops or remote apps is all possible with a maximum of control.

🆚 Windows 365 vs Azure Virtual Desktop ​

Windows 365 and AVD are both cloud-based virtual desktop solutions but serve different needs.

• Windows 365 (Cloud PC) delivers a fully managed Cloud PC for a simple and consistent Windows experience with minimal deployment effort.
• AVD (Cloud VDI) offers a flexible VDI platform supporting complex scenarios with multi-session capabilities and advanced configuration options.

Responsibility matrix:

✅ = Microsoft
➖ = You, if you want to manage it

Win365 Pros & Cons ​

Pros:

• Simplicity: Easy to deploy, manage and support.
• Consistency: Provides a consistent Windows experience across devices.
• Predictable pricing: Subscription-based pricing makes costs predictable and forecasting easier.
• Accessibility: Accessible from any device with an internet connection.
• Microsoft 365 integration: Directly integrated with Microsoft 365, Entra ID and Intune.

Cons:

• Customization: Limited control over host pools, networking architecture and advanced customization compared to AVD.
• Costs: More expensive at scale because of its subscription-based nature, compared to the consumption-based model of AVD.
• Scalability: No flexible consumption based provisioning of machines to help with usage spikes.

AVD Pros & Cons ​

Pros:

• Flexibility: Highly customizable, supporting a wide range of configurations and multi-session deployments.
• Scalability: Easily scalable, allowing businesses to adjust resources based on demand.
• Integration: Deep integration with other Azure services.
• Costs: More cost-effective for large-scale or variable deployments.

Cons:

• Complexity: Requires highly skilled IT staff to set up and manage effectivly.
• Security: Harder to secure then fully managed Windows 365 devices.
• Cost Predictability: Costs can be difficult to predict upfront due to variable usage.
• Management: More hands-on management required compared to Windows 365.

💡 Conclusion ​

In conclusion, Windows 365 offers a straightforward and reliable way to deliver a full Windows experience from the cloud, with minimal setup and ongoing management. It is the best solution for specific problems, such as providing contractors with secure access without the need to send out physical devices. Rather than using one or the other, combining AVD and Win365 is the most effective way of providing a complete cloud desktop environment that is prepared for most scenarios, cost-effective and secure.

Lastly Microsoft has released a purpose build cheap machine to access cloud Desktops directly, without the need to manage a local OS. Windows 365 Link is the first Cloud PC hardware device that lets users sign-in directly to their Cloud PC through the Windows 365 service.

References

• Windows 365 Configuration
• Windows 365 plans and pricing
• Azure Virtual Desktop documentation

👋 Introduction ​

Windows Backup for Organizations is a business-class feature that makes it easier to refresh and upgrade devices. It makes sure that users have the same experience with their Windows settings and Store apps. It does this by securely synchronising settings every 8 days and offering a seamless restore process during OOBE (Out-Of-Box Experience). This feature is designed to help you transition to a cloud-first device approach.

• Reduce migration overhead: Streamline Windows 10 to Windows 11 transitions
• Minimize user disruption: Minimize downtime during device changes
• Strengthen resilience: Confidently reset devices with backup & recovery
• Reduce IT efforts: Users restores preferred settings independently

Requirements

• Backup
  • Windows 10 22H2
  • Windows 11 22H2 and later
  • Must be Microsoft Entra joined or Microsoft Entra hybrid joined
• Restore
  • Windows 11 22H2 and later
  • The user needs at least one backup
  • If Autopilot is used, it needs to use user-driven mode
  • Microsoft Entra joined

🔧 Configuration ​

Restore Configuration

1. Sign in to the Intune admin center -> Devices -> Enrollment and select Windows Backup and Restore.

2. Now, a side panel opens on the right. Select On under Show restore page and then select Save.

Backup Configuration

1. Sign in to the Intune admin center -> Devices -> Configuration and select + Create -> + New Policy.
2. Now select Windows 10 and later as platform and Settings catalog as profile type and click Create.
3. Next you enter your Name and Description for the profile and click Next.
4. Now you click on Add settings, select Administrative Templates\Windows Components\Sync your settings\Enable Windows Backup and set it to Enabled.

5. On the next page, add scope tags if needed. On the page after that, assign the profile to your desired groups. Lastly go tho the Review + create page and click Create.

Reporting

To view reporting on device restores, sign in to the Intune admin center, navigate to Devices, select the device that used the restore option during OOBE and you will be able to see the restore status in the Enrollment section.

👤 User Experience ​

Backup Process

After an administrator configures the backup policy, Windows automatically backs up user settings, preferences, and installed Microsoft Store apps every eight days through a scheduled task. The user does not need to do anything and will not take notice of the backup happening.

You can see the backup status in the Windows Settings app under Accounts -> Windows backup.

Users can also initiate a manual backup by opening the Windows Backup app and following the prompts.

Restore process

During OOBE, the restore process follows these steps:

1. Sign in with your Microsoft Entra ID account (the same work or school account used during backup).
2. The restore page appears after sign-in.

3. Select a device to restore settings from (you will see a screenshot of the backed up desktop) or choose to configure the device as new (To configure as new, you need to select More options first.).

4. Select Continue to restore backed-up user settings and Microsoft Store apps.
5. Complete the remaining OOBE process as normal.
6. Once you reach the desktop, your previously backed-up settings and apps are automatically restored.

💡 Conclusion ​

Windows Backup for Organizations lets you keep user settings and store apps backed up in the cloud, which makes it easier to refresh and restore devices. It is the perfect companion to OneDrive, with the first one holding settings and the second one the data. With this combination you can offer a painless cloud-first device replacement experience. With this, you could even argue that resetting a device remotely is so painless, that it's much quicker and easier than any troubleshooting IT can do, especially for remote users.

Try it out with a few people, tell end users about the new backup screen and then roll it out bit by bit. It's basically risk-free and the only thing that changes for the user is that they get their settings back when they get a new PC.

👋 Introduction ​

Windows Server in-place Upgrade is a process designed to help you upgrade your existing Windows Server 2012 R2, 2016, 2019 or 2022 to Windows Server 2025 without the need for a complete reinstallation. This guide provides step-by-step instructions to ensure a smooth and successful upgrade, minimizing downtime and preserving your server settings and data.

Current service end Windows Server:

⬆️ Upgrade ​

Example: Windows Server 2012 R2 -> Windows Server 2025

1. Start the setup from a DVD or mounted ISO file.
2. If you select Change how Setup downloads updates, you can select to not download and install updates during the upgrade process in the next window.

3. Now you can select the edition you want to upgrade to.

4. Now the system checks if the upgrade can be performed and then you also need to accept the license terms.

5. After that you can choose to keep files, settings and apps or not. Next the system will check for updates if selected at the start.

6. Finally, after when the setup checked everything, you can start the upgrade process by clicking on Install.

7. Then the installation process runs and the server will restart a few times.

8. If you didn`t keep your settings, you select your languages again and set a password.

9. Then you are ready to log in again. After the login you need to select the diagnostics settings and all is set.

💡 Conclusion ​

In-place upgrades are a great way to upgrade non-critical servers where a rollback is not that difficult and you can save a lot of time. For critical servers like Domain Controllers or database servers, a clean installation is nearly always the better option.

In-place Pro's

• Server continuity: The upgrade maintains your server's settings, identity, IP address, hostname and domain membership.
• Automatic migration: Applications and configurations migrate automatically, reducing manual efforts.

In-place Con's

• Baggage: The upgrade retains old registry entries, clutter, drivers and more from the previous OS which all can impact the system later down the line.
• No replacement: No automatic process will replace your do dilligence in testing the server, the applications and checking functionality.

References

• Perform an in-place upgrade of Windows Server
• Windows Server major versions by servicing option
• Upgrade domain controllers to a newer version of Windows Server

Additional capabilities of the Intune Suite ​

The Intune Suite offers several advanced capabilities beyond its core functionality, which I will give an overview of in the following article. These include support for specialty devices, firmware over-the-air updates, and Microsoft Tunnel for Mobile Application Management (MAM). Together, these features help organizations manage a wider range of devices, ensure up-to-date firmware, and provide secure access for mobile apps without requiring full device enrollment.

🚇 Microsoft Tunnel for Mobile Application Management ​

Introduction ​

Microsoft Tunnel for MAM lets users securely access company data on their personal devices, no device enrollment required. With support for modern authentication, single sign-on, and Conditional Access, it keeps work secure without giving IT access to the whole device. It’s a smart way for companies to boost security while still respecting user privacy and keeping things simple.

Architecture ​

Microsoft Tunnel is a VPN gateway for Intune that runs on a Linux container and lets you securely access on-prem resources using modern authentication and Conditional Access.

Configuration ​

Tunnel for MAM uses the Microsoft Tunnel Gateway and has therefore the same requirements you can find here.
Once Microsoft Tunnel is up and running, you’ll just need to add two app configuration policies and an app protection policy to get Tunnel for MAM working.

Microsoft Tunnel configuration

To start the Configuration you need to open the Intune admin center → Tenant administration → Microsoft Tunnel Gateway
Here you can create the nessecary settings for Server configurations, Sites and Servers.

The following steps are required to create a Microsoft Tunnel:

1. Create a Server configuration
2. Create a Site configuration
3. Install Microsoft Tunnel with a script on your Linux Server

App configuration and protection policies

The next step is to create the App configuration and protection policies so that we can extend the Microsoft Tunnel Gateway to MAM Apps (not enrolled devices).

1. Open the Intune admin center → Apps
2. Here you find the Configuration and Protection blades where you can create the coresponding policies.

You can find a Step-by-Step Guide to create the Android policies and iOS policies on the Microsoft Learn Page.

• Android - App configuration for Defender
• Android - App configuration for Edge
• Android - App protection for Edge
• iOS - App configuration for LOB apps (Tunnel for MAM SDK)
• iOS - App configuration for Edge
• iOS - App protection

References ​

• Microsoft Learn - Microsoft Tunnel for Mobile Application Management
• Youtube - Microsoft Intune Tunnel for Mobile Application Management

☁️ Firmware over-the-air update ​

Introduction ​

Zebra LifeGuard Over-the-Air (LG OTA) Integration with Microsoft Intune is a feature that allows organizations to manage firmware updates for Zebra Android devices directly through the Intune. This integration helps with single pane of glass management and simplifies hands-free, automated deployment of updates.

How to set it up? ​

• Step 1: Set up Zebra Connector
• Step 2: Enroll Devices with Zebra LG OTA Service
• Step 3: Create and Assign Deployments
• Step 4: View and Manage Deployments

References ​

• Zebra LifeGuard Over-the-Air Integration with Microsoft Intune - Microsoft Learn
• Zebra's LifeGuard for Android™ Product Video - YouTube
• Zebra Documentation

📺 Support for specialty devices ​

Introduction ​

Intune Suite’s Support for Specialty Devices makes it easier to manage and secure things like AR/VR headsets, large smart screens, and certain meeting room devices.

IT administrators can use this support to ensure that these devices are secure and compliant with organisational policies. Features include device provisioning, certificate and Wi-Fi management, Conditional Access, device compliance, app lifecycle management and remote actions.

How does it work? ​

You can enrol the following devices using the Company Portal App or via web enrolment:

• AR / VR headsets
• large smart-screen devices
• select conference room meeting devices (additional teams room pro licences are required usually)

References ​

• Managing specialty devices with Microsoft Intune - Microsoft Learn
• Microsoft Management of Specialty Devices - YouTube

Enterprise Application Management ​

👋 Introduction ​

Enterprise Application Management (EAM) makes it super simple to deploy and keep your Win32 apps up to date using the Enterprise App Catalog. Instead of manually packaging and updating apps yourself, you get access to a catalog of popular Microsoft and third-party apps that are already prepped and maintained by Microsoft. No more worrying about packaging, testing, or chasing updates.

Everything is managed right from Intune, so you can deploy and update apps from one place. It saves your IT team a ton of time and helps to keep your apps on the latest versions. Plus, Microsoft keeps adding new features and more apps to make things even easier.

Features:

• App management: Quickly find and add apps from the Intune Portal without manual packaging needed.
• Latest apps: New app versions are added automatically, and you can track updates in the catalog report.

When you add an app from the Enterprise App Catalog, Intune prefills the the follwing installation details for you:

• install/uninstall commands
• install time and restart behavior
• uninstall and error behavior
• detection rules and requirements

✅ Prerequisites ​

• 64-bit versions of Windows
• Endpoints need to reach *.manage.microsoft.com
• Intune suite license, Enterprise Application Management standalone license or Microsoft 365 E5 license

📱 Adding an app with EAM ​

1. Open the Intune admin center → Apps → Windows and then click Create.
2. Select the 'App type' Enterprise App Catalog app and click Select.

3. In the 'App information' select Search the Enterprise App Catalog and then search for your app and click Next.

4. In the Configuration tap you will now get a list of the available Versions. Select the one you want and click Select.

5. Now you will get back to the Intune App Configuration screen you know, but with all details prepopulated for the app you selected.

6. You just need to add the assignment and you are done.

📲 Updating an app with EAM ​

When you open an app created with EAM, you can update it directly using the Update button. If the app is already on the latest version, an info banner will notify you.

Clicking the Update button starts a new app creation process, automatically populating the details for the newer version, just like when you first created the app. Only this time the 'Supersedence' section is filled in as well, with information about the older version of the app.

If you select the Enterprise App Catalog with updates button on the Overview page, you will find a report with all the EAM apps that can be updated. You can initiate the update process directly through the report, via the ... on the right side.

💡 Conclusion ​

Enterprise Application Management takes the hassle out of app deployment and updates, letting you focus on what matters most. With the Enterprise App Catalog, you get a growing list of ready-to-go apps, all managed right from Intune. As Microsoft keeps adding new features and apps, managing software across your organization just keeps getting easier. It’s a real time-saver for IT teams and helps keep everyone up to date—no more chasing down the latest versions!

👋 Introduction ​

The Microsoft Intune Suite is a set off 8 add-on capabilities that build on top of the current Intune ecosystem to enhance and complete the already vast feature set. You can purchase the Intune Suite as a bundle license on top of Intune itself or as separate licenses for each capability. In addition, some Microsoft 365 plans also include Intune Suite features.

📜 Features ​

💸 Is it worth it? ​

Whether the Intune Suite is worth the investment depends on your organization's needs. If you require advanced device management, streamlined app deployment, enhanced security, and remote support capabilities, the suite offers significant value by consolidating these features into a single platform. For organizations already using Microsoft 365 and got the licenses, the suite is a no brainer since it is now included in the main M365 plans (E3 and E5).

However, if you don't need these features, or if you already have alternative solutions in place and you do not use M365 Enterprise licenses, the additional cost in licenses may not be justified, but it could be well worth checking out and comparing costs with your current solution.

Microsoft Cloud PKI ​

👋 Introduction ​

Public Key Infrastructure (PKI) is a framework that uses digital certificates to authenticate identities and secure communications between devices and services. PKI can be used for protecting access for example to VPN, Wi-Fi, email, web access or devices, but a traditional PKI can be complex and resource-intensive, often requiringing a whole on-premise environment.

Microsoft Cloud PKI, part of the Intune Suite, delivers a fully cloud-based solution that automates certificate issuance, renewal, and revocation. By eliminating the need for on-premises infrastructure, Cloud PKI simplifies certificate lifecycle management across all supported platforms, making it easier for organizations to secure their environments at scale. This article provides an overview of Microsoft Cloud PKI, its core functionality, and its architecture.

Cloud PKI Features

✅ Prerequisites ​

• Supported platforms: Android, iOS/iPadOS, macOS, Windows (devices must be Intune-enrolled and support SCEP certificate profiles)
• Licensing: Microsoft Intune Suite license, Microsoft Cloud PKI standalone add-on license or Microsoft 365 E5 license
• Permissions: Assigned Intune role permissions
  • Read certificate authorities (CAs)
  • Create root or issuing CAs
  • Revoke issued leaf certificates (requires read CA permission)

🌊 Architecture & Flow ​

Microsoft Cloud PKI issues certificates using SCEP with it's cloud-based CA and registration authority.

Preperations in Intune (B1, B2 & B3):

• Create Cloud PKI root and issuing CAs.
• Assign trusted certificate profiles for both CAs.
• Assign platform-specific SCEP certificate profiles.

Arcitecture flow:

A1. Device checks in and receives certificate/SCEP profiles.
A2. Device generates a private key and CSR, sends to SCEP service.
A3. SCEP service validates the request.
A4. Registration authority requests issuing CA to sign the CSR.
A5. Device receives the signed certificate.

📃 Certificate fundamentals ​

Certification authority types ​

A certification authority (CA) performs the following tasks:

• Verifies the identity of a certificate requestor
• Issues certificates to requestors
• Manages certificate revocation

Microsoft Cloud PKI supports these types of certificate authorities:

• Root CA
• Issuing CA

Root certification authority

A root certification authority (CA) sits at the very top of your PKI setup, think of it as the main source of trust for everything below it. Its certificate is self-signed, meaning it basically vouches for itself (the issuer and subject are the same). You trust a root CA by adding its certificate to your trusted root store. From there, the root CA can hand out certificates to other CAs or even directly to users, devices, or services, signing each one with its private key to prove they're legit.

Issuing certification authority

An issuing CA is a subordinate certification authority that operates below a root CA in the hierarchy. It can:

• Issue certificates to other subordinate CAs within the hierarchy.
• Issue end-entity (leaf) certificates to servers, services, clients, or devices.

Issuing CAs can be positioned at any tier in the CA hierarchy except the root level.

Chaining ​

Chaining determines the optimal trust path for verifying a certificate. Each OS or service uses a certificate chain engine to compute and validate this path.

The chain building process involves:

• Certificate discovery: The process of finding and retrieving the issuing CA certificate for a leaf certificate, ensuring the chain leads up to a trusted root CA.
• Certificate validation: Building possible chains and checking each certificate for validity (name, time, signature, revocation, and other constraints).
• Selecting the best chain: Returning the highest quality trust path.

When verifying a certificate, the chain engine searches the certificate store for intermediate and root candidates. Multiple intermediates may be needed to complete the chain. The engine matches certificates using the subject key identifier (SKI) and authority key identifier (AKI), repeating the process until it finds a self-signed root certificate.

Chain validation process

Windows validates certificate chains using three methods:

• Exact match: Uses issuer’s subject, serial number, and KeyID from the AKI extension.
• Key match: Uses only the KeyID from AKI to find a parent with a matching SKI.
• Name match: If AKI is missing, matches the issuer’s subject name to the parent’s subject.

If SKI and AKI are missing, Windows uses name matching and if duplicates exist, selects the newest certificate. If the parent certificate isn't found locally, Windows tries to retrieve it using URLs from the authority information access field.

Each certificate in the chain is checked for formatting, validity, revocation and that the chain ends in a trusted root.
The chain is valid only if all checks pass.

Name matching chain validation example:

Chain of trust

For certificate-based authentication to work, both your devices and services (like Wi-Fi, VPN, or web apps) need to trust the full CA chain. Just make sure the root CA certificate is installed everywhere. If a device is missing the issuing CA cert, it can usually grab it automatically using the AIA (Authority Information Access) info in the certificate.

Certificate-based authentication

The certificate-based authentication process and handshake work as follows:

1. Your device starts talking to the service it wants to connect to.
2. The service replies that it wants to establish a secure connection using TLS/SSL and the SSL handshake begins.
3. The service asks your device to show a client authentication certificate.
4. Your device hands over its certificate so it can prove who it is.

🧑‍🔧 Configurating Cloud PKI ​

Microsoft Cloud PKI supports two deployment options:

• Cloud root CA: Set up a private, cloud-based two-tier PKI in your Intune tenant, with a root CA and one or more issuing CAs that deliver certificates to managed devices via SCEP. All CAs remain tenant-private.

• Bring your own CA (BYOCA): Use your existing private CA (e.g., ADCS) as the trust anchor by creating a cloud-based issuing CA in Intune. Intune sends a CSR (Certificate Signing Request) for your private CA to sign, establishing the trust chain.

Microsoft Cloud PKI objects are created and managed in the Microsoft Intune admin center. From there, you can:

• Set up and manage Cloud PKI
• Create and assign certificate profiles to devices
• Monitor issued certificates

Configure Cloud CA ​

1. Sign in to the Microsoft Intune admin center and navigate to Tenant administration → Cloud PKI and select Create.

2. On the first page provide a Name and a Description.
3. On the Configuration settings page you configure the CA settings.

CA type: Root CA	CA type: Issuing CA
Validity period: 5, 10, 15, 20 or 25 years	Root CA source: Intune or BYOCA Validity period: 2, 4, 6, 8 or 10 years (The validity must not exceed the root CA's)
Extended Key Usages purposes: Sever auth Client auth Code signing Email protection IPSEC end system IPSEC tunnel IPSEC user Time stamping OCSP signing Smartcard logon MAC adress Custom Type Name Object Identifier	Extended Key Usages purposes: Select the intended purpose of the CA from those selected in the Root CA settings.
Subject attributes: Common name (CN) Optional: Organization (O) Country (C) (must be a two-character code) State/province (ST) Locality (L)	Subject attributes: Common name (CN) Optional: Organization (O) Country (C) (must be a two-character code) State/province (ST) Locality (L)
Encryption, select the key size and algorithm: RSA-2048 and SHA-256 RSA-3072 and SHA-384 RSA-4096 and SHA-512	The Encryption is set by the root CA.

4. Select Next and on the next to pages you can add Scope tags and create the CA.

Create Certificate Profiles ​

Microsoft Cloud PKI includes a built-in SCEP service that handles certificate requests for devices automatically.

To start issuing certificates, you’ll need to create trusted cert profiles for both your root and issuing CAs. These profiles build trust with the Cloud PKI registration authority that uses SCEP. Then you need for every platform (Windows, Android, iOS/iPadOS, macOS) that’ll get SCEP certs a separate profiles.

Create a trusted Certificate Profile for the root and issuing CA

First you need to download the public keys from your Cloud PKI.

1. Open the Microsoft Intune admin center and navigate to Tenant administration → Cloud PKI.

2. Now select your root CA and issuing CA's and download the certificates.

Now we need to install the downloaded root and issuing CA certificates on the clients.

1. Open the Microsoft Intune admin center and navigate to Devices → Configuration.
2. Next you need to click Create and select New Policy.
3. After that you choose your Platform and select Profile type: Templates

4. Here we choose Trusted certificate and click Create.
5. In the next screen you can set the Name and Description.
6. After that you upload first the root certificate and in a second trusted certificate profile the issuing certificate.
7. You need to select the appropriate Destination store for the certificate.

8. Next choose an assignment, applicability rules and create the profiles.

Create SCEP certificate profile

Just like you set up trusted cert profiles, you’ll need to create a SCEP cert profile for each OS you want to support. This lets devices grab client auth certificates from the issuing CA, which they’ll use for things like connecting to Wi-Fi or VPN.

First you need to copy the SCEP URI from your Cloud PKI.

1. Open the Microsoft Intune admin center and navigate to Tenant administration → Cloud PKI.
2. Now select your issuing CA and copy the SCEP URI in the Properties.

Next you create the SCEP certificate Profile.

1. Open the Microsoft Intune admin center and navigate to Devices → Configuration.
2. Next you need to click Create and select New Policy.
3. After that you choose your Platform and select Profile type: Templates

4. Here we choose SCEP certificate and click Create.
5. In the next screen you can set the Name and Description.
6. Now under Configuration settings you can paste the copied SCEP URI into the SCEP Server URLs field. Keep the {{CloudPKIFQDN}} placeholder as is, Intune will fill in the right FQDN when it sends the profile to devices. It’ll be something under *.manage.microsoft.com. You can find more infos about Network Endpoints for Microsoft Intune here.
7. After that you can configure the remaining settings:
   • Certificate type: User or Device
   • Subject name format: Ensure all variables used are present on the user or device object in Microsoft Entra ID.
   • Certificate validity period: The amount of time remaining before the certificate expires in days, month or years.
   • Key storage provider (KSP): Select where you want to store the certificate key (TPM KSP, Windows Hello for Business or Software KSP).
   • Key usage: Specify the cryptographic action that is required to exchange the certificate's public key (Digital Signature, Key encipherment).
   • Key size (bits): Select the key length (1024, 2048 or 4096).
   • Hash algorithm: Use a hash algorithm type with the certificate (SHA-1 or SHA-2).
   • Root Certificate: Select the root CA that this chain of trust should use.
   • Extended key usage: Select the EKU you specified in the issuing certificate. If you choose an EKU that isn't on the issuing CA, the SCEP profile will fail and no certificate will be issued.
   • Renewal threshold: The device can ask for a renewal as soon as this percentage of the time is left.

4. Lastly you assign the profile to your targets and then Create it.

🔍 Monitoring ​

View issued certificates

To view issued certificates, go to Devices → Monitor, and then select Certificates.

Monitor Cloud PKI issuing CA

Monitor certificate deployments from issuing CA's to your Intune devices. When opening the CA you find a dashboard displaying the following:

• Active certificates
• Expired certificates
• Revoked certificates
• Total issued certificates

Select View all certificates to see all issued certificates. The Reports are normally updated in 24 hours.

You can also manually revoke an issued leaf certificate from this dashboard.

1. Select View all certificates.
2. Choose the certificate and click Revoke.

View SCEP certificate profile report

Go to Devices → Configuration and select the SCEP profile, and then select Certificates.

Audit logs

In the admin center, go to Tenant Administration → Audit Logs.

You can current list of the available logs here.

View Certificates on the Client

Open the local certificate store (certmgr.msc) on your device and navigate to Trusted Root Certificate Authorities → Certificates to view the installed Root Certificates.

Open the local certificate store (certmgr.msc) on your device and navigate to Intermediate Certificate Authorities → Certificates to view the installed Intermediate Certificates.

💡 Conclusion ​

In short, Intune Cloud PKI makes it a lot easier to manage certificates without the hassle of on-prem infrastructure. It’s a modern, cloud-based solution that integrates seamlessly with Intune, helping you securely authenticate devices and users while keeping things scalable and simple. Whether you're rolling out certificates for Wi-Fi, VPN or app access, Cloud PKI takes care of the heavy lifting, so you can focus more on managing endpoints and less on managing cert servers.

So in my opinion, if you use certificates and have your devices intune managed, Cloud PKI is the killer feature of the Intune Suite. It replaces so much manual work and local infrastructure, that it is well worth the price in my opinion.

You can find kown issues and limitations here.

Remote Help ​

👋 Introduction ​

Remote Help is a Microsoft cloud-based remote support tool designed for IT teams. It enables support staff (helpers) to securely connect to users’ devices (sharers) using organizational accounts via Microsoft Entra ID, ensuring secure and authenticated sessions.

With Remote Help, you can leverage Intune’s role-based access control (RBAC) to define exactly who can provide support and what level of access they have. This gives organizations granular control over remote assistance, helping maintain security and compliance throughout the support process.

Features

• Support for unenrolled devices: You can enable assistance for users on devices not enrolled in Intune.
• Organization sign-in: To prevent impersonations, both the helper and the person receiving support use Microsoft Entra accounts to verify their identity.
• Compliance warnings: If a device doesn’t meet your organization’s compliance policies, helpers will see a warning before connecting.
• Role-based access control (RBAC): Admins can fine-tune who can provide assistance, the permissions they have on the remote device, and whether users can simply view or take full control.
• Monitor sessions: View real-time and historical reports in the Intune admin center, including who helped whom, which device was involved, session duration, and audit logs.

✅ Prerequisites ​

General prerequisites ​

License

• Remote Help add on license, Intune Suite license or M365 E3 / E5 license for all helpers and sharers

Supported platforms

• Windows 10/11
• Windows 10/11 on ARM64 devices
• Windows 365
• Android
• Android Enterprise dedicated devices (Samsung and Zebra devices)
• macOS
• iOS/iPadOS (works with supported browsers)
• Azure Virtual Desktop
• Linux (not officially supported but works with supported browsers)
• Browser
  • Safari
  • Chrome
  • Edge
  • Firefox

Platform prerequisites ​

Remote Help on Windows

• Supports enrolled and unenrolled devices.
• Sharer's device must be Intune-enrolled (to remotely start a session).
• Remote Help uses port 443 (HTTPS) to connect to https://remotehelp.microsoft.com via RDP, secured with TLS 1.2.
  (See Microsoft docs for the full list of required network endpoints.)

Remote Help on macOS

No special prerequisites are required.

Remote Help Web App

• Single-Sign-On

Remote Help on Android

• Samsung devices (Android Enterprise Dedicated)
• Zebra devices (Android Enterprise Dedicated)

📊 Data and 🔒 privacy ​

Microsoft logs minimal session data to monitor Remote Help health, this includes:

• Session times: When a session starts and ends (retained for 30 days).
• Session details: Includes the identities of the helper and sharer, and the device involved (retained for 30 days).
• Errors: Issues like disconnections are logged on the sharer's device in Event Viewer.
• Features used: Actions performed during the session, such as view-only mode or elevation requests (retained for 30 days).

Remote Help logs session details locally in Windows Event Logs for both helper and sharer.
Microsoft cannot access session content or see actions or keystrokes.

Both the helper and sharer see these details from each other's organizational profiles:

• Profile picture (if you have one)
• Company name
• Verified domain
• First and last name
• Job title

🧑‍🔧 Configuration ​

Tenant Config ​

To configure Remote Help in your tenant (for any supported platform), follow these steps:

Turn on Remote Help

1. Sign in to the Microsoft Intune admin center and head to Tenant administration → Remote Help.
2. Select the Settings tab.
   1. Enable Remote Help
   2. Choose whether to allow users to receive help on unenrolled devices, then set this option to Allowed if desired.
   3. Choose whether to allow helpers and sharers to chat with each other during a session, then set this option to No if desired.

Set up permissions for Remote Help

Remote Help uses Intune’s role-based access controls (RBAC) to decide who can help and what they’re allowed to do.

The Help Desk Operator Role gives you all permissions for a remote help session.

Here are the main permissions you can configure for Remote Help sessions:

	Category: Remote Help app Elevation View screen Unattended control Take full control
	Category: Remote tasks Offer remote assistance

The default Help Desk Operator role comes pre-configured with all necessary Remote Help permissions enabled. You can assign this role as-is, or create custom roles to tailor permissions for different support scenarios. For more details on configuring RBAC, see Role-based access control.

Assign users to roles

To grant helpers the necessary permissions, assign them to the appropriate role:

1. Sign in to the Microsoft Intune admin center and navigate to Tenant administration → Roles and select a role.
2. Now open Assignments, then click Assign to create a new role assignment.
3. On the Basics page, enter a name and description and click Next.
4. On the Admin Groups page, select your helper group and click Next.
5. Now enter a Scope tag if you want and then create the Assignment.

App deployment ​

You can either deploy the App through Intune or install it directly on the target machines.

To install it manuall you can download the latest version of Remote Help directly from Microsoft or your can install it with Winget.

Winget install Microsoft.RemoteHelp

To deploy the app through Intune, you have two main options:

• Download and package: Download the installer, package it as an INTUNEWIN file, and deploy it as a Win32 app via Intune.
• Universal App deployment (no packaging): Use my Universal App deployment method to install the app directly with Winget, without the need for packaging.

If you choose the INTUNEWIN method, use the following information for deployment:

# Install command
remotehelpinstaller.exe /quiet acceptTerms=1 enableAutoUpdates=1

# Uninstall command
remotehelpinstaller.exe /uninstall /quiet acceptTerms=1

WebApp

Sharer: https://aka.ms/rh	Remote Helper: https://aka.ms/rhh

Macos

If you have a MacOS Client you can download the latest version of Remote Help directly from Microsoft.

iOS

To use Remote Help on iOS, install the Intune App or access the Web App using a supported browser.

Android

To use Remote Help on Android Enterprise devices, install the Intune App or access the Web App using a supported browser.

Additionally, ensure that screen capture is allowed in your Android device policies.

For Zebra devices: Configure Zebra OEMConfig as described in the Microsoft documentation.

Conditional Access ​

To control Remote Help with conditional access you need to create a Service Principal using the Remote Assistance Service AppId.

New-MgServicePrincipal -AppId "1dee7b72-b80d-4e56-933d-8b6b04f9a3e2"

⌨️ Usage ​

To start a remote session you can either start the app yourself and exchange a security code with the enduser or you can start a session directly trough Intune. Then the security code is already taken care of by Intune.

If you want to start a remote session right from Intune, just open the Intune Admin portal, head to Devices, pick the device you want to help, and hit New remote assistance session.

A flyout will appear, and a notification is sent to the end user. When the user clicks the toast notification, Remote Help launches automatically and waits for you to initiate the session, no code exchange required. If the end user has already started Remote Help, the flyout updates to show a green checkmark next to Launch Remote Help. You can then proceed directly to step 4.

To start a remote session without Intune, use the following instructions.

1. The user first need to sign in to the Remote Help Client or has SSO active.

2. Next the helper clicks the Get security code button and then has 10 Minutes time to give this code to a sharer (Enuser that needs help).
3. The sharer takes the security code from the helper and puts it into the appropriate box in the Remote Help Client.

Helper view	Sharer view

4. Now the sharer sees a waiting screen while the Helper is choosing if he wants to Take full control or View screen.

Helper view	Sharer view

5. Once the helper has selected their desired action, the sharer receives a pop-up window displaying the helper’s account details and the requested action (view screen or take control). The sharer can then choose to allow or decline the connection.

Information

If you do not have the required RBAC permissions in Intune to act as a helper, a notification window will appear informing you that you lack the necessary permissions to provide remote assistance.

6. The sharer now just sees a simple bar at the top where he can stop the session with X or start a Chat 💬.

7. The helper has a view tools in his bar to direct the session.
   • Request Control
   • Admin Session 🖥️
   • Laser pointer 📍
   • On-Screen Pen 🖊️
   • Fullscreen 🪟
   • Chat 💬
   • Restart machine ↩️ (only in admin mode)
   • Task manager 📟 (only in admin mode)
   • Leave

8. If the helper requests control, the sharer gets the request in his Remote Help bar, where he can Allow or Deny.

9. If you need to start an elevated window during a Remote Help session, the UAC prompt will appear on the secure desktop by default. This means your session view will go black and display a ⏸️ symbol, as you cannot see the secure desktop until an Admin Session is enabled.

Helper view	Sharer view

10. If the helper to enter credentials or have access to the UAC prompt, you can activate an Admin Session.

11. Once the Admin Session is enabled, if a UAC prompt appears, the helper will be able to view and interact with the elevated windows directly.

Helper view	Sharer view

12. When the session gets ended by either side, all parties will see a coresponding message.

Helper view	Sharer view

🔍 Monitoring ​

You can keep an eye on how Remote Help is being used right from the Intune admin center.

1. Sign in to the Microsoft Intune admin center and go to Tenant admin → Remote Help.
2. On the Monitor tab, you’ll see active sessions and some history about past sessions.

3. On the Remote Help sessions tab, you’ll find details about past sessions.

💡 Conclusion ​

Remote Help makes it easy for IT teams to support users securely and efficiently, right from Microsoft Intune. 🚀 With Entra ID sign-in, RBAC, and session auditing, you can be confident that support sessions stay safe and compliant. Whether you’re helping users on Windows, Mac, Android or even unenrolled devices, Remote Help has you covered. 💻 📱

🔧 ✅ Microsoft continues to improve Remote Help, so you’ll see even more capabilities over time. Recent updates have included support for additional platforms, enhanced security features, and improved integration with Intune and Microsoft Entra ID. Stay tuned for new features such as expanded unattended access, deeper reporting, and broader device compatibility as Microsoft responds to customer feedback and evolving IT needs.

If your organisation uses Microsoft tools, Remote Help could be a practical choice for modern endpoint support. 🤝 It's still not quite on par with other remote control solutions, but it makes great strides and its integration into the Microsoft environment gives it a huge advantage.

Microsoft Security Copilot ​

👋 Introduction ​

Security Copilot is a smart AI assistant for your IT team. It stands out as the only tool that combines an AI built specifically for security with Microsoft’s powerful tech. This unique mix allows it to spot hidden threats faster using massive amounts of data and tells you how to fix them. It connects seamlessly with the other M365 tools, like:

• Microsoft Defender XDR
• Microsoft Sentinel
• Microsoft Intune
• Microsoft Entra
• Microsoft Purview
• Microsoft Defender for Cloud
• External Attack Surface Management
• Azure security tools (eg. Azure Firewall)

Security Copilot supports Microsoft-built agents, partner agents and custom agents that you can create yourself.

👷‍♂️ What can the Security Copilot do? ​

Firstly, Security Copilot provides a large number of agents that offer specific assistance with particular tasks in Entra, Intune, Defender, Purview and Sentinel. These range from analysing conditional access policies to triaging incidents. Secondly, it enables you to query your security data using natural language, write KQL queries and more. And thirdly, you can integrate third-party plugins to extend the available data even further.

Possible use cases:

• Investigation and response: Summarize alerts and get guided steps to resolve issues
• KQL queries: Writes advanced hunting or device query scripts for you
• Security posture: Helps assess and improve your security posture
• Policy management: Reviews and suggests improvements to security policies
• Endpoint privelege management: Helps you understand if files that get requested for elevation are malicious or not
• Reports: Produces targeted reports with risks and recommended actions.

🤖 What are Agents? ​

To the point, an AI agent is a specialized algorithm built on top of an LLM (Large Language Model) that can perform a specific task autonomously or with a trigger. Usually agents are capable of using the environment around them as context to make decisions and take actions. Security Agents in particular do the excact same, just specialized on security tasks.

🫴 What are assistants? ​

An AI assistant is basically the same as an agent, with the one difference, that it requires human approval before taking any actions.

Specifically for Intune, Microsoft announced using mainly assistants instead of agents, because most Admins are not cool with an AI potentially changing settings in there whole environment without explicit approval. There is even a unified task screen in Intune since November 2025. This is specifically to help with any approvals that might come up. This is partly because of Assistants, but not exclusively. (You can learn more about Intune assistants here)

💰 What does it cost? ​

The cost of Security Copilot depends on the number of Security Compute Units (SCUs) you set up to run your workloads. You can use provisioned SCUs, which are charged by the hour or overage SCUs, which are charged consumption based. You basically pay for the amount you used each month, and if you use more, you pay extra units on top. But you need to provition 1 SCU minimum per month.

1 provisioned SCU costs 4$ per hour. 1 overage SCU costs 6$ per hour. (Dezember 2025)

You can calculate the estimated costs for your needs using the SCU Calculator from Microsoft. If you want to learn more about which action consumes how many SCUs in your environment or overall, check out the Manage security compute unit usage in Security Copilot documentation.

🖥️ What is an SCU? ​

An SCU (Security Compute Unit) is the amount of computing power you need to run Microsoft Security Copilot. You practically buy compute capacity for your prompts and tasks. The same principle as a prepaid mobile phone plan.

💿 How to provision Security Copilot ​

Prerequisites

• An active Subscription
• One of the following roles
  • Global Administrator
  • Billing Administrator
  • Entra Compliance Administrator
  • Intune Administrator
  • Security Administrator
  • Purview Compliance Administrator
  • Purview Data Governance Administrator
  • Purview Organization Management
• Contributor or Owner of the Subscriptions

Provisioning

1. Sign in to the Microsoft Security Copilot Admin Center and start the first run experience. Here you will need to select a subscription, a resource group, a name and locations. Underneath that you can select the number of SCUs you want to provision or overage, accept terms and conditions and click Continue.

2. Next screen you can opt-in to help Microsoft improve Security Copilot or not and in the screen after that you get the info that Security Copilot is obviously accessing your data.

3. Second to last configuration screen, you need to allow purview to basically be able to keep an eye on the data that Security Copilot is using. Lastly you get a screen with the default owner roles and the possebility to change them.

4. With that done, the Copilot provisioning run a few seconds and you get a success confirmation.

💡 Conclusion ​

Security Copilot a great way to making your life as an admin easier. Not only as a security analyst, helping with triaging and investigating incidents, but also as an Intune or Entra admin, helping you write policies or queries. Now that SCUs are included in the E5 license, many companies get free access to it and can try for themselfs. The amount of agents for it and plugins will only grow steeply in the future and in my opinion is help in getting better information quicker especially important now that bad actors also use AI in there attacks.

AI is just another tool in your toolbelt of making your admin life easier and keeping your environment secure.

Microsoft provides the great Security Copilot Adoption Hub if you want to read more.

Apple Business Manager ​

👋 Introduction ​

Apple Business Manager (ABM) is a web portal that helps organizations easily deploy and manage Apple devices, apps and accounts. It unifies device enrollment, app purchasing and managed account provisioning into a single, streamlined portal. You can also connect Apple Business Manager to your existing MDM to centralize management across your organization.

Key features

• Automated Device Enrollment directly from the carrier or reseller
• Central app and book purchasing
• Federated managed Apple Accounts
• Integration with MDM solutions

👨‍💼 Create Apple Business Account ​

Admins can sign up for Apple Business Manager and start using basic features in minutes without cost. You need to verify your organization to use the full feature set, like Automated Device Enrollment, App Store volume purchasing and managed Apple IDs.

Create the Account ​

1. Go to https://business.apple.com/ and select Sign up now, then Get Started.

2. Enter your information and select Continue.

3. Next, create and confirm a password for your new account, then enter your phone number.

4. Lastly follow the prompts to finish setting up your Apple Business Manager account.

Verify your company ​

After you created your Apple Business Account you should verify your company, so you can take full advantage of all the features of Apple Business Manager.

Without verifying your organization, you can’t access certain features of Apple Business Manager and Apple Business Essentials (An additional subscription service that provides a few additional features, but nothing important for device management. Learn more here):

1. Go to https://business.apple.com/, sign in and open the settings page.

2. Go to the Organization Settings and select Verify, then enter your organization’s D-U-N-S (Data Universal Numbering System) Number (To learn more about locating or requesting a D-U-N-S Number click here).

3. Enter the contact information for someone Apple can call to verify your organization. This needs to be a person with authority to speak on behalf of your organization, such as your CEO, CTO or CFO.

4. Now wait and look for an email from Apple Business Manager with the subject “Your enrollment is in review”. During the review, Apple will contact your verification contact to confirm your information. Make sure emails from any apple.com address aren’t blocked, and call back quickly if you miss a call so the process can continue.

🔗 Connect Apple Business Manager with Intune ​

Connecting an MDM to Apple Business Manager makes it easy to set up and manage Apple devices. New devices can configure themselves automatically with the right apps and settings, reducing the need for manual work. It also improves security and ensures your organization keeps control of its devices throughout their lifecycle.

Connect Apple Business Manager with Intune ​

1. Open the Microsoft Intune admin center, go to Devices -> Enrollment and open the Apple tab.
2. Now select Apple MDM Push Certificate and start the configuration.

3. First you need to give Microsoft permission to exchange data with Apple.
4. Next, click on Download your CSR to download the Intune certificate signing request (.csr) file.
5. Now go to the Apple Push Certificates Portal and sign in with the same Apple ID you used for the ABM.
6. Select Create a Certificate and accept the terms and conditions.

7. Upload the Intune certificate signing request (.csr) file you downloaded earlier and select Upload.

8. After the upload is complete, you get a confirmation that the certificate was created successfully. Then download the Apple MDM push certificate (.pem) file.

9. Now back in the Intune portal, enter the Apple ID you used to create the Apple MDM push certificate, upload the .pem file you just downloaded from Apple and click Upload.
10. After that the status of the Apple MDM Push Certificate should show as Active.

Configure automatic enrollment token ​

To now set up automatic enrollment for Apple devices, you need to create an enrollment profile in Intune and assign it to the devices in Apple Business Manager.

1. Open the Microsoft Intune admin center, go to Devices -> Enrollment and open the Apple tab.
2. Now select Enrollment program tokens under the Bulk Enrollment Methods and click Create.

3. As before you neew to give Microsoft permission to exchange data with Apple and then Download your public key (.pem) file.
4. Then open the ABM portal and go to the Settings page.
5. Under Device Management Services, select Add.

6. Give your new MDM a name, create it, open it and then click Download Token.

7. In the window that appears, you should check the box for the MDM to be able to release devices, then upload the public key (.pem) file you downloaded from Intune and click Save.

8. The token you just created should now download and you can upload it back in Intune and enter your AppleID again.

9. Click Next, add Scope Tags if needed and Review + create.

10. Lastly you should go back to the ABM Portal and configure your default MDM per device type. You can do that by opening the settings page and selecting your MDM for the different device types under Management Assignment.

Configure automatic enrollment profile ​

1. Now that you have created the enrollment token, and the Status in the Intune Portal is Active, you can create an enrollment profile by clicking on the token in the list.

2. Click on Profiles, then click Create profile and select if you want to create an iOS/iPadOS or macOS profile.

3. Now give your profile a name and description, then click Next.

4. In the Management Settings section, you can configure how your devices should enroll.

iOS/iPadOS Profile	macOS Profile

• User affinity: You can enroll with user affinity or without user affinity. iOS/iPadOS devices can additionally enroll in shared Entra mode.
• Authentication Method: You can choose between Setup Assistant (legacy) or Setup Assistant with modern authentication. iOS/iPadOS devices can additionally use the Company Portal.
• Locked enrollment: Prevents the user from removing the management profile through system preferences or terminal.
• Await final configuration: Pauses and locks Setup Assistant before the home screen so Intune can finish applying critical settings.

5. In the Setup Assistant section, you can enter the Department and Phone Number you want to show up for the end user. You can also choose which Setup Assistant screens to show or hide during device enrollment.

Example:

6. In the macOS profile you can also configure additional Account Settings, for a potential local admin and user account on the device.

7. Then click Next and Review + create.
8. In the Profile you can now, next to the automatically assigned devices, also manually assign devices that are already in Intune.

9. If you now go back to the Profiles list directly under the Enrollment token, you can also set default profiles for iOS/iPadOS and macOS.

Configure enrollment Type & Notifications & Restrictions ​

If you additionally want configure a default enrollment method for non automated enrollments you can create an enrollment type profile.

1. Open the Microsoft Intune admin center, go to Devices -> Enrollment and open the Enrollment type profile.
2. Here you can create a profile with the default enrollment method.

Or you can set restrictions to which devices can enroll in the first place.

1. Open the Microsoft Intune admin center, go to Devices -> Enrollment and open the Enrollment restrictions or Enrollment Type Restriction.
2. Here you can set per platform if it is allowed at all, if personally owned devices are allowed and which version they need to have.

If you want to set additional notification about enrollments you can also do that.

1. Open the Microsoft Intune admin center, go to Devices -> Enrollment and open the Enrollment notifications in the Apple tab.
2. Here you can configure push and email notifications.

📱 Adding managed Apple devices ​

Adding your devices to the Apple Business Manager makes sure the devices are bound to your company while also allowing you to automatically enroll them in your MDM solution during the setup process. For this Apple provides the Automated Device Enrollment (ADE), formerly known as Device Enrollment Program (DEP). Here your reseller or carrier can directly add the devices to your ABM account during the purchase process, so your devices are automatically enrolled in Intune when they are unboxed and powered on for the first time. Like this you can send the devices directly from the reseller to end users without having to manually do anymore configuration.

1. To start adding devices to your Apple Business Manager account, go to the ABM portal and open the Devices page.
2. Here you first need to add your Apple Customer Number to be able to add devices that you purchased or the Reseller Number so your reseller adds new devices on your behalf automatically.

3. As soon as you have added devices to your ABM Account, you can assign them to an MDM solution (if you didn't set a default one already), release them from your org for reselling or turn off an activation lock.

4. After assigning devices to Intune, they should show up in the Intune portal under Devices -> iOS/iPadOS or macOS.
5. If you added an enrollment profile in the previous step, they will also automatically get that profile assigned.

🍎 Managed Apple accounts ​

Using an Apple device you need an Apple ID. For personal devices, users usually create their own Apple ID, but for corporate devices this is not a good idea. If you allow this, you not only lose control over this part of your identitiy management and the security that this provides, but also create an unnecessary barrier for your users when they enroll their devices. You risk, your data getting out or saved to personal storage or mail accounts, creating potential data privacy compliance issues or simply who pays for needed apps and how this gets handelt by accounting. All unnecessary if you use Managed Apple IDs. This can easily be done by federating your Entra ID with Apple Business Manager. With this your users just use there already existing credentials for there Apple devices.

1. Open the ABM portal,go to the Settings page and select Managed Apple Accounts.
2. Here you find your automatically generated apple domain and you can start the federation process by clicking Get Started.

3. Next you select your Identity Provider of choice, in our case Microsoft Entra ID and select Sign in with Microsoft.

4. After signing in you need to consent to a view permission for the Apple Business Manager and then your Entra ID will be connected.

5. Now you see your newly federated domains in the list at the bottom of the page. Next to these you can click on Manage to turn on federation for the specific domains.

6. You click next to Sign in witch Microsoft Entra ID on Set up, the status will then change to Turning on Federation and shortly after it will be toggled on.

6. Now that your domains are federated, you need to add your user accounts to the ABM directory and for that you can enable the automatic account syncing, which will create your existing Entra users automatically in ABM as Managed Apple IDs. For this you click under Directory Sync on the 3 dots to the right and select Connect.

7. After the sync is done you can find the processed accounts info in your Activity blade.

8. And you find your users in the Users blade. Your users can start using their Entra accounts now as Apple IDs.

🛒 App Store volume purchasing ​

With the ABM you can also buy apps and books centrally in volume without the hassle of individual purchases or distributing credit card infos to your users. It’s called the Volume Purchase Program (VPP). It lets your organization retain ownership of purchased apps instead of tying them to individual accounts, making it easy to reassign licenses to other users.

1. To use the VPP with your MDM you must first connect it. For that you open the ABM portal, go to the settings page -> Payments and Billing. Here you can activate the Content Token and download the token file (.vpptoken). On this page you would also enter payment information for purchasing payed apps.

2. Now open the Microsoft Intune admin center, go to Tenant administration -> Connectors and tokens -> Apple VPP Tokens and click Create.
3. Enter a name for the token, the Apple ID you used to create the token and upload the .vpptoken file you downloaded from ABM and click Next.

4. On the next page you choose your Contry/Region and your Type of VPP account (Depending if you use the Apple Business Manager (Business) or Apple School Manager(Education)). In addition to that you can toggle if this token was used before by another MDM solution and Intune should take control (so you can continue using all the licenses seemlessly) and if you like, Automatic app updates. Then you also need to grant Microsoft the permission to exchange data with Apple, so it can send and receive data from ABM.

5. When you proceed to the next pages you can add scope tags and hit Review + create.

6. When you now go back to the ABM and select Locations you need to add a Location first, to assign apps.

7. If you select Apps and Book in the main menu then, you can find all your purchases there. To find and buy new apps you just enter the name in the search bar, select the location, the quantity and click Get.

8. After every buy the admin gets a mail with your purchase confirmation.

9. If you then go back to the Intune admin center the apps will automatically get synced to the Apps page with the Type iOS volume purchase program app (the platform at the start, changes with the type of app you purchased) and you can assign them to your devices or users.

⚙️ Device Management through Intune ​

Now that you got an Apple Account, connected it to Intune, got your managed apple id's, got your devices in and connected VPP, you can start the managing. Here now is no difference anymore between these devices and other corporate managed apple devices you might have added before via Company Portal or Apple Configurator.

➡️ Migrate Apple devices from other MDM's to Intune ​

When Apple released iOS/iPadOS/macOS 26 in August, they also added an MDM migration functionality as a new feature to ABM. That solved one of the main headaches people had with switching MDM solutions in the past. Usually, you had to do a factory reset on the devices before they could be manually re-enrolled. This new migration feature, which is directly built in to the ABM, lets IT admins move devices from one MDM to another without big end-user downtime.

Prerequisites ​

• Administrator or Device Enrolment Manager permissions in Apple Business Manager
• Intune Administrator or Global Administrator permissions in Microsoft Intune
• Devices with iOS, iPadOS or macOS 26 or later
• Devices need to be enrolled with Apple Business Manager

MDM migration - Admin experience ​

1. Document the settings in your old MDM solution.
2. Add Intune as a MDM solution to ABM as explained above (Connect Apple Business Manager with Intune, Configure automatic enrollment token).

INFO

You can also configure your MDM per device type if you need to use more then one MDM solution in your environment.

3. Open the Intune admin center and set up the documented settings from your old solution in Intune and any additional configurations you need (enrollment profiles, compliance policies, configuration profiles, apps, etc.)

4. Then you can go back to ABM and switch the Device Management for your devices to Intune. For that open the Device you want to migrate, select the three dots on the top right and click Assign Device Management.

5. Now select the new MDM, click Continue, set a migration deadline for the user, click Continue again and then Confirm the change.

MDM migration - User experience ​

1. First the enduser gets a push notification on his device that he needs to re-enroll the device.
2. When the user clicks the notification and then Start Enrollment on mac or Start Enrollmentdirectly on iOS the rest of the process is completly automatic.

macOS	iOS/iPadOS

3. At the end the user will get a notification that the enrollment is complete and thats it for him.

6. The admin can now go back to the Intune portal and the device shows under devices, with no difference to any other device that Intune manages.

MDM migration - Volume purchased apps ​

1. You first need to open your old MDM and remove the VPP token there. If you get the option to remove the apps from the devices you should decline that.
2. Next you can download the same token from ABM again and add it to Intune, as shown above in the App Store volume purchasing section.

💡 Conclusion ​

Apple Business Manager (ABM) combined with Intune gives you a powerful, modern foundation for managing Apple devices at scale. ABM centralizes device enrollment, app purchases, and managed Apple IDs, while Intune brings policy, app distribution, and lifecycle management together in a single pane. Together they reduce manual steps, improve security, and make device provisioning far more predictable for admins and users alike.

Why use the ABM?

• Automated Device Enrollment: Devices from resellers or carriers are assigned and enrolled automatically, cutting setup time for IT and end users.
• Managed Apple IDs: Federating with Entra ID lets users sign in with familiar credentials and keeps organizations control intact.
• Centralized App Licensing: VPP simplifies app distribution and license reassignment.

Why Intune?

• Microsoft works directly with Apple to support the latest features mostly on the same day they release.
• Microsoft also works constatly to bring more and more new features to Apple devices (LAPS for example).
• Without knowing every single Apple MDM out there, Intune should be on-par or better then most of them by now.
• If you are using M365 already, you got the nessecary linceses without extra costs and save on the overhead of managing multiple MDM solutions.
• If you are using Intune or Defender already, you get a single pane of glass for all your devices and security.

So taking a look does not hurt, even if you are happy with your current MDM solution or not using Intune yet. Keeping your eyes open can sometimes reveal new synergies and save money in the future.

Cloud-first approach to identity management:
Transferring Source of Authority from Active Directory to Entra ID ​

👋 Introduction ​

The Source of Authority (SOA) in identity management is the single source of truth for an identity's existence and core attributes, like name, email address and job title.

On the journey to a cloud environment, organizations sooner or later need to switch their SOA to the cloud. This means that instead of managing users and groups in an on-premises Active Directory (AD), the management is done directly in Microsoft Entra ID. To ilustrate this concept further, Microsoft provides a nice diagram how an environment can evolve from on-premises to 100% cloud.

This modernization is a crucial step in the cloud journey, it not only improves security, reduces on-prem costs but also makes the management substantially easier through automation and centralized control.

In this article, I will explain why a cloud identity management could be the right fit for your organization and the process of transferring the Source of Authority from AD to Entra. In moving the SOA, administrators enable a phased migration approach, allowing for a smoother transition to the cloud while minimizing disruption to users and services.

☁️ Is cloud identity management right for you? ​

Improvements ​

Active Directory has long been a prime target for attackers because it controls so much access. Moving your identities and application authentication to Entra ID reduces that risk. Entra ID adds protection through features like Conditional Access and Lifecycle Workflows. It also enables modern options such as passwordless sign-in and better identity governance, even for apps that were once on-prem. Overall, managing identities through Entra ID strengthens security across the organization.

• IT admins can manage identities, groups and app access from the Entra admin center or via PowerShell.
• Entra governance (Entitlement Management, Access Reviews, Lifecycle Workflows) automates user and group lifecycles and aids accountability with strong audit trails.
• Users get single sign-on to both cloud and on-prem apps with modern features like Conditional Access and passwordless login. This means fewer passwords to manage and stronger protection for their credentials.

Road to the Cloud ​

Like mentioned in the introduction, most organizations move to the cloud in phases. They usually start with a hybrid setup, using both on-premises AD and cloud services. The next step is a cloud-first stage, where more resources shift to the cloud. Over time, they work toward an AD-minimized state.

SOA transfer helps with that journey by letting you move users, groups and contacts to Entra much easier with the additional option to roll back changes if needed. This avoids major changes all at once in a big bang kind of way. Instead, you can migrate identities in phases and slowly reduce their AD footprint. But, always start with checking your applications before transferring SOA, to ensure users don’t lose access to apps relying on AD authentication.

As you start moving your apps and identities to the cloud, many users and groups will no longer be needed in Active Directory and can be removed or retired.

You can also move user creation and lifecycle management to the cloud. Using Entra ID Governance, you can manage SOA-transferred users and groups directly in the cloud and set up automation for creating new identities.

Are you ready for SOA? ​

By following this flowchart you can determine if you are ready to transfer the source of authority for your users and groups:

Moving users: SOA works for users who don’t rely on AD DS for app access. To plan the migration, you need to know which user is tied to which app.

Moving groups: For groups, start by moving security groups to the cloud. If needed, you can provision them back to AD from Entra. For Distribution Lists and Mail-Enabled Security Groups, move them when you migrated to Exchange online.

💿 Application-centric migration approach ​

The application-centric approach is one of the recommended ways to tackle cloud migration. Like this you will try to modernize your app authentication without compromising access for users.

The following steps outline an example of the process transferring your identities with SOA from AD to Entra:

1. Discover Active Directory–Integrated applications
2. Map applications to AD Security Groups
3. Clean up unused AD groups
4. Identify users for each application
5. Determine authentication methods
6. Assess modernization feasibility
• Older applications with hard-coded assumptions about AD are out of scope for this kind of migration.
7. Categorize applications and plan integration approach
• Apps that get retired or replaced
• Apps on modern auth can be moved directly to Entra (update AD FS to Entra, migrate to Azure Files)
• Kerberos/NTLM apps can be published with Entra Application Proxy or Entra Private Access and use Kerberos Delegation so Entra handles auth and AD gets Kerberos tickets
• LDAP-bound apps can use Microsoft Entra Domain Services (managed AD in Azure) so apps can bind to a cloud LDAP endpoint
• Legacy apps that can't be modernized could be hosted on Azure Virtual Desktop
• Apps without connections to the environment (High Security)
8. Mapping and planning
9. Migrate groups to the cloud
10. Handling LDAP-based applications (Directory-Bound Apps)
11. Handling Kerberos-based applications (Windows Integrated Auth)
• User lifecycle: After moving a user to cloud management, keep an AD account with the same UserPrincipalName for Kerberos
• Auth & attributes: Don’t migrate users who need password-based AD apps that can’t be changed to Kerberos. Apps that use Kerberos and read AD attributes require those attributes kept in sync (dual-write or similar).
• Devices & SSO: For seamless Kerberos SSO, devices should be Microsoft Entra–joined or hybrid-joined. Domain‑only devices with cloud-managed users often need manual logon.
12. Verify and optimize

👥 Transferring group SOA from AD to Entra ​

1. To transfer the source of authority for a group from AD to Entra, make sure that the group is synchronized to Entra.

2. When you got the groups synchronized, you can use PowerShell to change the SOA.

get-mgbetagroup -all -property * | Where-Object { $_.OnPremisesSyncEnabled -eq $true } | select Displayname, OnPremisesSyncEnabled

3. Use the following PowerShell script to change the SOA of a group from AD to Entra.

Import-Module Microsoft.Graph.Beta.Groups
Import-Module Microsoft.Graph.Authentication

# Define the Parameters
$tenantId = "[YourTenantID]"
$groupName = "[MyGroupName]"

#Connect to Microsoft Graph using delegated permissions
Connect-MgGraph -Scopes "Group.Read.All, Group-OnPremisesSyncBehavior.ReadWrite.All" -TenantId $tenantId


# Retrieve the group using group name
$group = Get-MgBetaGroup -Filter "displayName eq '$groupName'"

# Ensure group is found
if ($null -ne $group)
{
    $groupObjectID = $($group.Id)
    # Define the Microsoft Graph API endpoint for the group
    $url = "https://graph.microsoft.com/beta/groups/$groupObjectID/onPremisesSyncBehavior"

# Define the JSON payload for the PATCH request
    $jsonPayload = @{
        isCloudManaged = "true"
    } | ConvertTo-Json

# Make the PATCH request to update the JSON payload
    Invoke-MgGraphRequest -Uri $url -Method Patch -ContentType "application/json" -Body $jsonPayload

$result = Invoke-MgGraphRequest -Method Get -Uri "https://graph.microsoft.com/beta/groups/$groupObjectID/onPremisesSyncBehavior?`$select=id,isCloudManaged"

Write-Host "Group Name: $($group.DisplayName)"
    Write-Host "Group ID: $($result.id)"
    Write-Host "SOA Converted: $($result.isCloudManaged)"
}
else 
{
    Write-Warning "Group '$groupName' not found."
}

4. Now you will see that the source field in the groups changed from Windows Server AD to Cloud.

INFO

You can also check the audit logs to confirm the change.

👤 Transferring user SOA from AD to Entra ​

1. To transfer the source of authority for a user from AD to Entra, make sure that the user is synchronized to Entra.

2. When you got the users synchronized, you can use PowerShell to change the SOA.

get-mgbetauser -all -property * | Where-Object { $_.OnPremisesSyncEnabled -eq $true } | select Displayname, OnPremisesSyncEnabled

3. Use the following PowerShell script to change the SOA of a user from AD to Entra.

Import-Module Microsoft.Graph.Beta.Users
Import-Module Microsoft.Graph.Authentication

# Define the Parameters
$tenantId = "[YourTenantID]"
$userName = "[MyUserName]"

#Connect to Microsoft Graph using delegated permissions
Connect-MgGraph -Scopes "User.Read.All, User-OnPremisesSyncBehavior.ReadWrite.All" -TenantId $tenantId


# Retrieve the user using user name
$user = Get-MgBetaUser -Filter "displayName eq '$userName'"

# Ensure user is found
if ($null -ne $user)
{
    $userObjectID = $($user.Id)
    # Define the Microsoft Graph API endpoint for the user
    $url = "https://graph.microsoft.com/beta/users/$userObjectID/onPremisesSyncBehavior"

    # Define the JSON payload for the PATCH request
    $jsonPayload = @{
        isCloudManaged = "true"
    } | ConvertTo-Json

    # Make the PATCH request to update the JSON payload
    Invoke-MgGraphRequest -Uri $url -Method Patch -ContentType "application/json" -Body $jsonPayload

    $result = Invoke-MgGraphRequest -Method Get -Uri "https://graph.microsoft.com/beta/users/$userObjectID/onPremisesSyncBehavior?`$select=id,isCloudManaged"

    Write-Host "User Name: $($user.DisplayName)"
    Write-Host "User ID: $($result.id)"
    Write-Host "SOA Converted: $($result.isCloudManaged)"
}
else 
{
    Write-Warning "User '$userName' not found."
}

4. Now you will see that the source field in the users changed from Windows Server AD to Cloud.

INFO

You can also check the audit logs to confirm the change.

💡 Conclusion ​

Moving the source of authority from Active Directory to Entra ID is a practical way to make cloud migrations easier, modernize identity, improve security and reduce on-premises reliance. This shift simplifies admin tasks and sets the stage for features like self-service, conditional access and automated lifecycle management.

The safest path is pragmatic and phased: start by inventorying apps and dependencies, then pilot a small set of users or groups. Validate authentication, SSO and use the right integration method per app. As you scale, monitor closely and leverage Entra governance to automate routine processes.

Start small and try to iterate. This approach lowers migration risk, minimizes headaches, delivers better manageability and positions your organization for a more flexible and secure future.

SOA battle card infos for IT admins

These are some key points you can use to explain yourself about the benefits of transferring your identity management to the cloud.

Understanding strategic benefits

• Reduces security risks and costs, while elevating flexibility by minimizing on-premises dependencies.
• Enables modern security features (Conditional Access, passwordless, Zero Trust).
• Possibilities to streamline identity management and governance with automation.

Monitoring & accountability

• Strong audit trails for compliance and audits.
• Possibilities for delegation and clear separation of duties.
• Tools to get workflows and decisions back to the people where they belong, without the IT as middle man and without compromising security, compliance or administrative control.
• Enables self-service for users and managers, reducing IT workloads.

Resources

• Cloud transformation posture - Microsoft Learn
• Cloud-First identity management: Guidance for IT architects - Microsoft Learn

App Control for Business ​

👋 Introduction ​

App Control for Business is a security feature in Microsoft Intune that helps organizations control which apps can run on Windows devices. It ensures only approved applications are allowed while blocking anything that doesn’t meet your company’s rules. These policies are part of Intune’s endpoint security and use the Windows ApplicationControl CSP to enforce restrictions.

Intune’s managed installer policy also tags apps (not retroactively) you deploy through Intune as trusted, so software deployed through your MDM does not need to be approved, saving time when you also use Intune for your app deployment. Here Microsoft made huge steps in simplifying approving apps, with their latest update, which lets you create multiple Managed Installer rules and assign them to different groups. This seems to suggest that it is only a matter of time until other managed installers are able to be used similarly.

Why use it?

App Control for Business prevents risky or unnecessary software from running.

• Reduce risks: block untrusted apps, tampered with apps or simply unwanted apps.
• White-/Blacklisting: only approved apps are allowed.
• Shadow IT: prevent unauthorized third party apps from being installed.
• Licensing: help your compliance team keep unlicensed software installations in check.