A colleague asked me to investigate why iPad registration stopped working. Didn’t stop completely, devices went through Setup Assistant without any issues, we had a JIT registration policy, Company Portal was even sent to the device. But every time someone opened Company Portal after that, they were asked to register the device. They went through it, and it asked again. A loop. The management profile was already on the device, so Company Portal couldn’t install its own copy, and it kept trying.

It took a few days to really find it, and it turned out to be two separate problems that were on top of each other. Here’s what was going on and how we solved both.

What actually changed

It turned out that the loop wasn’t a bug in our setup, but a result of something Microsoft changed and only recorded in one paragraph, in the new ADE policy announcement blog. Easy to miss if you don’t read every word, which apparently wasn’t the case.

The old enrollment profile had three settings that handled Company Portal for you: install Company Portal, install Company Portal with VPP, and run Company Portal in single app mode until authentication. All three are gone in the new ADE policy for iOS/iPadOS. Not hidden elsewhere in the wizard, not renamed. Removed.

To be precise about what Microsoft is saying here: for ADE policies with user affinity, they strongly recommend modern authentication as the most secure and seamless method. It’s not the only supported authentication method, the Intune Company Portal app is still a valid option if you specifically need things like forcing a password change or resetting during enrollment, but modern authentication is the one that Microsoft is sending everyone to, and it’s the one that Company Portal is dropping.

There is also a separate workaround if you specifically want to keep the old Company Portal authentication flow: stop user affinity, log in user less, deploy Company Portal itself with the corresponding app configuration policy. Microsoft’s own post explicitly marks that path as not recommended. It is documented as an option, not as a suggestion. And it has its own catch: you must choose the app configuration policy that matches the authentication method you use, otherwise Company Portal won’t work properly on the device, and the auto-update will stop correctly. A user-free device is also very different from a personally assigned device, so for most real-world deployments, this isn’t a live option anyway.

Here’s the mechanism, and it has nothing specifically to do with JIT. During ADE enrollment, Intune already sends the management profile to the device as part of Setup Assistant, which is how the device is initially managed. Company Portal, which opens next, performs its own enrollment step and attempts to install its own management profile to establish user/device affinity. iOS does not land a second management profile if one is already installed. So Company Portal asks you to register, the installation fails quietly because there is nothing left to install, and it asks again. That’s the loop.

Setup Assistant with modern authentication registers the device directly via MDM, no Company Portal is needed to get on the network or become manageable. Faster, safer, a good change. It just also means that nothing will install Company Portal for you in a way that tells the Company Portal what has already happened, and self-service app installation has no other path. No Company Portal that works well, no way for a user to grab an app that you have published as available-non-mandatory.

So, you must rebuild that yourself and tell the Company Portal what it has missed. Three pieces, plus one thing to check before you start.

A requirement that is easy to overlook: Microsoft Authenticator must also be installed on the device. On iOS, it’s the broker app, modern authentication, and the SSO extension both depend on it to do the authentication transfer. No authenticator, and none of this works even if Company Portal and the app configuration are both rolled out correctly. Add it as mandatory VPP app next to Company Portal, same enrollment time, same as Piece 2 below.

Piece 1: enrollment-time grouping

This is the main function of the new ADE policy anyway, so you’re probably already using it. When creating the policy, choose an Entra ID security group in the Device Group tab. Devices land in that group as soon as they enroll, not when the next dynamic group evaluation cycle occurs.

Piece 2: assign Company Portal, and Microsoft Authenticator, as required VPP apps to that group

Nothing exotic here. Two completely ordinary mandatory app commands, just like you would with any other app. The only thing that grouping during enrollment time will give you is that both lands almost immediately after enrollment instead of waiting for a group member renewal. Don’t skip Authenticator, without the broker app installed, the rest of this doesn’t matter.

Piece 3: the app config policy that actually finishes the job

This is the part that solves the loop from the story above. Without those, Company Portal has no idea that there’s already a management profile on the device, so it tries to install its own profile and gets stuck in asking to register the user, forever. You must already notify the device that the device is already enrolled, via app configuration.

Here is the actual policy from my tenant:

{
  "@odata.type": "#microsoft.graph.iosMobileAppConfiguration",
  "displayName": "mam-apc-company-portal-ios",
  "targetedMobileApps": ["<company-portal-app-id>"],
  "encodedSettingXml": "<base64-encoded-plist>"
}

Decode encodedSettingXml and this is what’s inside:

<dict>
  <key>IntuneCompanyPortalEnrollmentAfterUDA</key>
  <dict>
    <key>IntuneDeviceId</key>
    <string>{{deviceid}}</string>
    <key>UserId</key>
    <string>{{userid}}</string>
  </dict>
</dict>

{{deviceid}} and {{userid}} are built-in Intune app configuration tokens, which are resolved on a per-device basis when it’s delivered. This gives Company Portal the device and user identity that are already registered, so that it recognizes the device as already registered instead of trying to overlay its own management profile on top of the existing one. No attempt at second profile installation, no loop.

Target the same enrollment period as the sign-in command above.

The warning you'll read and should ignore, sort of

If you dig into the documentation, you’ll find a note on the Add App Configuration Policies for Managed iOS/iPadOS Devices page that says you shouldn’t manually roll out this app configuration if the enrollment policy has set Install Company Portal to Yes, because Intune already pushes the same configuration automatically. Roll it out manually anyway and Microsoft’s own documentation describes exactly the flow from the beginning of this post: end users are prompted to download a new management profile after logging in to Company Portal, when they shouldn’t, because there is already a management profile on the device.

That warning is about the old registration profile. The new ADE policy doesn’t have a setting for Install Company Portal at all, so there’s nothing that your manual deployment could conflict with. You don’t work around this, you just do what Intune used to do for you, because it doesn’t do that anymore.

Piece 4: fix the JIT policy too, if you're running one

If you don’t use JIT at all, skip this. But if part of your setup relies on the single sign-on app extension to register devices without a Company Portal, and you’ve built that policy out of the general Enterprise SSO extension documents instead of the JIT-specific ones, check it now. This is where our actual run comes from.

A requirement that is easy to overlook: on iOS/iPadOS, Apple requires the Microsoft Authenticator app to be installed together with the SSO extension, it is the broker app with which the extension communicates on the device. Users don’t need to open it or log in; it just needs to be present. But don’t add the bundle ID to the SSO extension policy itself, Microsoft’s own JIT setup documentation is explicit about this: Authenticator is a Microsoft app, so the extension is automatically applied to it, and adding its bundle ID can cause authentication issues. Just assign it separately as a mandatory app under Apps.

{
  "@odata.type": "#microsoft.graph.iosDeviceFeaturesConfiguration",
  "displayName": "cp-jit-sso-iosipados-prd",
  "iosSingleSignOnExtension": {
    "@odata.type": "#microsoft.graph.iosAzureAdSingleSignOnExtension",
    "configurations": [
      {
        "@odata.type": "#microsoft.graph.keyStringValuePair",
        "key": "device_registration",
        "value": "{{DEVICEREGISTRATION}}"
      },
      {
        "@odata.type": "#microsoft.graph.keyIntegerValuePair",
        "key": "browser_sso_interaction_enabled",
        "value": 1
      }
    ]
  }
}

device_registration is the key to the actual JIT work here. Note that the two entries use different @odata.type values, keyStringValuePair vs keyIntegerValuePair, the configurations collection is typed per input, and Graph needs the correct one on each pair, otherwise the request will fail.

Here’s the part that’s really misleading, not just under documented. The JIT setup page documents exactly two keys for this policy: device_registration and browser_sso_interaction_enabled. The Enterprise SSO app extension page documents three of them: AppPrefixAllowList, browser_sso_interaction_enabled, and disable_explicit_app_prompt, and never mentions device_registration. Both pages describe the same child object, the configurations array on iosSingleSignOnExtension, but neither tells you that all these keys can be in the same policy together. If you just read the JIT page, disable_explicit_app_prompt doesn’t exist as far as you know, and it’s a useful setting if users get unwanted login commands from apps that mishandle the protocol layer. Just read the general SSO page, and device_registration doesn’t exist, so JIT seems impossible to configure. You must read both pages and connect yourself, Microsoft never does that for you.

Here’s the part where I stop being neat and admit that this happened to us. This is the actual policy that applied to my tenant when the loop started:

{
  "displayName": "cp-jit-sso-iosipados-prd",
  "description": "Creates a single sign-on app extension policy that uses the Apple SSO extension to enable just-in-time (JIT) registration.",
  "iosSingleSignOnExtension": {
    "@odata.type": "#microsoft.graph.iosAzureAdSingleSignOnExtension",
    "configurations": [
      {
        "@odata.type": "#microsoft.graph.keyStringValuePair",
        "key": "AppPrefixAllowList",
        "value": "com.apple."
      },
      {
        "@odata.type": "#microsoft.graph.keyIntegerValuePair",
        "key": "browser_sso_interaction_enabled",
        "value": 1
      },
      {
        "@odata.type": "#microsoft.graph.keyIntegerValuePair",
        "key": "disable_explicit_app_prompt",
        "value": 1
      }
    ]
  }
}

We built this based on the Enterprise SSO app extension page, not the JIT page, because at that point, the search query that got us there first landed on that page. The name says JIT, the description says JIT, but there is no device_registration key in it. JIT never actually ran on these devices. It seemed configured, it just didn’t do the one thing that matters.

That is the other half of the original loop. JIT didn’t register any devices, so Company Portal was the only thing left to try, and it kept clashing with the management profile that ADE already had installed. Fix the JIT policy with the right key, and it will do its job again, registering the device via Teams or Outlook without Company Portal having to touch it. On top of that, fix the configuration of the Company Portal app for the self-service corner, and both problems are gone.

If you have implemented a JIT policy and enrollment loops continue to appear, check first. Get the policy from Graph and look for device_registration in the configurations array. If it’s not there, you’ve been following the same page as us.

If end-users need to browse and install available apps on their own, Company Portal must work properly, which are Pieces 1 through 3. If you’re also using JIT, Piece 4 is what ensures device registration happens rather than quietly not happening. In our case, we needed both, and the JIT solution was what stopped the loop.

That is it for now. Until next time. 👋

Anyone managing Intune compliance policies across iOS, macOS, Windows, and Android already knows this one. Apple, Google, or Microsoft ships a new major OS version, and now someone has to go through every compliance policy and every conditional launch setting in every App Protection Policy and bump osMinimumVersion by hand. Miss one and you’ve either locked out people on a perfectly good OS, or left an ancient version quietly allowed in.

I got tired of doing that manually, so I built an Azure Automation runbook for it. It pins osMinimumVersion to n-1, the second most recent major version, clears any maximum version cap, and for Android App Protection Policies it also pushes a minimum security patch level. Runs weekly. And the part I actually care about: nothing writes to Intune anywhere until you’ve explicitly whitelisted a platform yourself.

Where the version data comes from

I didn't want to scrape Apple release notes or dig through Microsoft's update catalog, so the script just pulls from endoflife.date instead. Community-maintained, one JSON schema across every platform, no auth required.

https://endoflife.date/api/ios.json
https://endoflife.date/api/macos.json
https://endoflife.date/api/windows.json
https://endoflife.date/api/android.json

Each response is an array of release cycles: cycle (version number), releaseDate, latest (latest build), end-of-life dates.

n-1 sounds simple until you actually try it

My first attempt just subtracted 1 from the major version number. Lasted about five minutes. Apple jumped iOS straight from 18 to 26 in 2025 when they switched to the year-based numbering, and that broke the math completely. So now it's positional instead: sort by major version descending, grab the second entry.

function Get-NMinus1Baseline {
    param([string] $Product, [object[]] $Cycles)

    if ($Product -eq 'windows') {
        $builds = $Cycles | Select-Object -ExpandProperty latest -Unique `
            | Sort-Object { [version] $_ } -Descending
        if ($builds.Count -lt 2) { throw "Not enough Windows release history" }
        return $builds[1]
    }

    $sorted = $Cycles | Where-Object { $_.cycle -match '^\d+$' } `
        | Sort-Object { [int] $_.cycle } -Descending
    if ($sorted.Count -lt 2) { throw "Not enough $Product release history" }
    return "$($sorted[1].cycle).0"
}

iOS, macOS, and Android use the cycle field, filtered down to numeric-only values so things like Android’s 4.4w (that’s Wear) don’t get picked up by accident. Windows is annoying in a different way: cycle IDs like 11-25h2-e don’t sort sensibly at all, so for Windows I use the actual build numbers from latest instead.

If the API is down, or hands back something the script doesn’t recognize, that platform just gets skipped for the run. No guessing. I’d rather have a platform quietly not update this week than have it update to something wrong.

What it actually touches

Compliance policies.

Pulls all device compliance policies over Graph, matches each one to a platform by @odata.type:

$odataPlatformMap = @{
    '#microsoft.graph.iosCompliancePolicy'               = 'ios'
    '#microsoft.graph.macOSCompliancePolicy'              = 'macos'
    '#microsoft.graph.windows10CompliancePolicy'          = 'windows'
    '#microsoft.graph.androidCompliancePolicy'            = 'android'
    '#microsoft.graph.androidWorkProfileCompliancePolicy' = 'android'
    '#microsoft.graph.androidDeviceOwnerCompliancePolicy' = 'android'
}

Every match gets osMinimumVersion set to the computed baseline, and osMaximumVersion cleared.

App Protection Policies (conditional launch).

For iOS and Android, it also goes after the conditional launch settings on Managed App Protection policies. iOS just gets minimumRequiredOsVersion set to the n-1 baseline. Android gets that plus minimumRequiredPatchVersion, which defaults to six months back from today (yyyy-MM-01):

$minimumPatchVersion = (Get-Date).ToUniversalTime().AddMonths(-$PatchLevelMonthsBack).ToString('yyyy-MM-01')

Six months is just a default. -PatchLevelMonthsBack changes it if you want something else.

Making sure it can’t do anything stupid on day one

The whole time I was building this I kept thinking about the version of me that deploys it, forgets about it, and gets paged three weeks later because it silently rewrote a production policy. So there’s a two-layer gate.

First: the -Apply switch. Without it, everything is a dry run, no exceptions. Second: an Automation Variable, IntuneOSVersion-AutoApplyPlatforms, a comma-separated list of platforms actually allowed to be written (ios, macos, windows, android). Even with -Apply on, nothing gets touched unless its platform shows up in that list.

That’s what lets you link the schedule with Apply = true on day one and still stay completely in control, since the actual on/off switch is just editing a variable in the portal. There’s also IntuneOSVersion-ExcludePolicyIds, for any specific policy GUIDs you never want touched, useful if there’s some legacy compliance policy someone’s deliberately keeping on an old version.

Dry-run output looks like this:

Baseline for 'ios': osMinimumVersion = 18.0
Baseline for 'macos': osMinimumVersion = 15.0
Baseline for 'windows': osMinimumVersion = 10.0.26200
Baseline for 'android': osMinimumVersion = 16.0
--- Compliance Policies ---
DRY RUN 'dc-win10-prd' [windows] (309f7e0c-a8f5-406a-bd3c-d575b06510fc): osMinimumVersion '10.0.1904' -> '10.0.26200', osMaximumVersion '' -> (blank)
DRY RUN 'dc-win-cpc-prd' [windows] (36a277be-577b-4e1a-b835-596c95271da2): osMinimumVersion '10.0.2' -> '10.0.26200', osMaximumVersion '' -> (blank)
DRY RUN 'dc-win11-me-prd' [windows] (4093f181-94dc-412d-bbef-04a9ed85e55c): osMinimumVersion '10.0.2' -> '10.0.26200', osMaximumVersion '' -> (blank)
DRY RUN 'dc-win-shd-prd' [windows] (6fd6786b-78aa-439c-b445-5ef437cfe1c7): osMinimumVersion '10.0.2' -> '10.0.26200', osMaximumVersion '' -> (blank)
DRY RUN 'dc-win-edu-prd' [windows] (7a49eddf-0d6a-45ff-a1e0-75b7ea86c394): osMinimumVersion '10.0.2' -> '10.0.26200', osMaximumVersion '' -> (blank)
DRY RUN 'dc-byod-and-prd' [android] (84c879d0-979d-447b-b6fb-3f0cfec379b1): osMinimumVersion '13.0' -> '16.0', osMaximumVersion '' -> (blank)
DRY RUN 'dc-win-ksk-prd' [windows] (9b6104bf-d928-4013-9a1b-e6c00636b72c): osMinimumVersion '' -> '10.0.26200', osMaximumVersion '' -> (blank)
DRY RUN 'dc-block-deepseekai-ios-prd' [ios] (ab17aa5d-d8d2-41ed-898c-0e3320918115): osMinimumVersion '' -> '18.0', osMaximumVersion '' -> (blank)
DRY RUN 'dc-mac-prd' [macos] (ad90f617-5dc5-457f-9b7d-bd2c92be2f63): osMinimumVersion '26' -> '15.0', osMaximumVersion '' -> (blank)
DRY RUN 'dc-win-dev-prd' [windows] (d9dd90ac-e02a-456a-a734-d6c7a0f250a0): osMinimumVersion '10.0.2' -> '10.0.26200', osMaximumVersion '' -> (blank)
DRY RUN 'dc-managed-ksk-ipados-prd' [ios] (df63645c-a1d6-45c0-a27e-073d50199e0c): osMinimumVersion '18.4.1' -> '18.0', osMaximumVersion '' -> (blank)
DRY RUN 'dc-win11-prd' [windows] (fed326e5-3984-478f-9c92-d8a6364de121): osMinimumVersion '10.0.2' -> '10.0.26200', osMaximumVersion '' -> (blank)
Compliance policies: 14 scanned, 12 needed changes, 0 written.

--- App Protection Policies (conditional launch) ---
Android minimum patch level: 2026-02-01 (6 months back)
OK (no change) APP: 'mam-app-ios-allapps' [ios] minimumRequiredOsVersion=18.0
DRY RUN APP 'mam-app-android-allapps' [android] (T_d6c0627f-46af-4006-a97a-0031c80a66ca): minimumRequiredOsVersion '' -> '16.0', minimumRequiredPatchVersion '2023-04-01' -> '2026-02-01'
App Protection Policies: 1 needed changes, 0 written.
Done.

Deploying it

Prerequisites:

You'll need an Azure subscription, the Azure CLI, the Microsoft.Graph.Applications PowerShell module, and either Global Administrator or Privileged Role Administrator rights for the permission-grant step later on.

Step 1: deploy the Automation Account.

The repo has a deploy.sh that does the whole thing in one shot:

./deploy.sh \
  -g "rg-intune-automation" \
  -l "westeurope" \
  -a "aa-intune-osversion" \
  -s "<your-subscription-id>"

You end up with a resource group, an Automation Account with a system-assigned managed identity, a PowerShell 7.2 runbook already uploaded and published, two empty Automation Variables, and a weekly schedule set for Monday mornings at 06:00 UTC.

Here's the catch though: the script creates that schedule but can't link it to the runbook. The az automation schedule commands just don't support job schedule linking, at least not as of when I wrote this. So that part's manual, in the portal:

Automation Account → Runbooks → select the runbook → Link to schedule → select Weekly-IntuneOSVersionCheck → set the parameter Apply to true.

Don't worry about setting Apply = true right away. The variables from Step 4 are still empty at this point, so nothing's actually going to write anywhere yet.

Step 2: grant Graph permissions.

The managed identity needs two application permissions: DeviceManagementConfiguration.ReadWrite.All for compliance policies, DeviceManagementApps.ReadWrite.All for app protection policies. Run this from a machine where you're logged in as a Global Admin:

./Grant-ManagedIdentityGraphPermissions.ps1 `
    -AutomationAccountManagedIdentityObjectId "<object-id-from-identity-blade>"

The Object ID is on the Automation Account's Identity blade.

Behind the scenes, this connects to Graph interactively, finds both app roles on the Microsoft Graph service principal, and assigns them:

$roleNames = @(
    'DeviceManagementConfiguration.ReadWrite.All',
    'DeviceManagementApps.ReadWrite.All'
)

foreach ($roleName in $roleNames) {
    $appRole = $graphSp.AppRoles | Where-Object {
        $_.Value -eq $roleName -and $_.AllowedMemberTypes -contains 'Application'
    }
    New-MgServicePrincipalAppRoleAssignment `
        -ServicePrincipalId $AutomationAccountManagedIdentityObjectId `
        -PrincipalId $AutomationAccountManagedIdentityObjectId `
        -ResourceId $graphSp.Id `
        -AppRoleId $appRole.Id
}

Small thing that got me the first time: permission propagation can take up to 15 minutes. If your first run throws a 403, that's probably it. Just wait and retry.

Step 3: first dry run.

Kick the runbook off manually from the portal (Automation Account → Runbooks → pick the runbook → Start), no parameters. Everything defaults to dry run.

Before touching anything else, read through the output properly. Are the baselines actually correct (iOS 18.0, macOS 15.0, whatever it comes back with)? Are the right policies getting matched? Does the Android patch level look reasonable?

Step 4: turn writes on, one platform at a time.

This is the step that's easy to get wrong the first time, mostly because it's not obvious where in the portal it lives. In the Automation Account, look under Shared Resources → Variables in the left nav. deploy.sh already created both variables for you, empty, so you're just opening and editing them rather than creating anything new.

IntuneOSVersion-AutoApplyPlatforms: open it, you’ll see a Value field and a Type dropdown. Type is String. Leave Encrypted as No, there’s nothing sensitive in a list of platform names. Leave the value blank for now and hit Save.

IntuneOSVersion-ExcludePolicyIds works the same way. Type = String, and leave it empty unless you’ve already got a specific policy GUID in mind that should never be touched. If you do, comma-separate them, no spaces.

Leaving both blank is exactly what keeps everything in dry-run mode even after the schedule's linked with Apply = true, so don't feel like you need to fill these in right away.

Step 5: turn writes on, one platform at a time.

Once a few dry runs have looked good, go back to Shared Resources → Variables, open IntuneOSVersion-AutoApplyPlatforms, and set the value to whatever you actually trust. I started with iOS and macOS, since their versioning behaves the most predictably:

ios,macos

Save it. That's genuinely it, there's no publish step or extra toggle, the runbook just reads the current variable value on every run.

Add Android and Windows the same way, once you've watched a few more runs and you trust it. One thing worth repeating: -Apply on the schedule still needs to be true too. Both gates have to be open before anything writes.

Step 6: verify in Intune.

After a write run, go check the actual policy in the Intune admin center and confirm the values landed where they should have.

Worth checking the audit log too: Intune admin center → Tenant administration → Audit logs, filtered down to the compliance or app protection policy in question.

Rollback

If a run ever computes something wrong, fixing it is refreshingly boring. Go into Intune, set the version back manually. The audit log shows exactly what changed and when. And the script never touches anything beyond osMinimumVersion / osMaximumVersion on compliance policies and minimumRequiredOsVersion / minimumRequiredPatchVersion on app protection policies, nothing else on those policies is ever in scope.

Rough edges

A few things worth knowing before you rely on this. Windows build numbers can be a mess, enablement-package feature updates don't always bump the build number the way you'd expect, so keep an eye on your first few Windows dry runs specifically. Android major-version compliance is honestly a pretty blunt tool, most orgs care a lot more about patch level than OS version anyway, and if I'm being honest the patch-level enforcement on the App Protection Policies is doing more of the real work here than the major-version check on compliance policies is. And obviously the whole thing depends on endoflife.date staying up and accurate. It's community-run, and it's held up fine for me, but if it ever returns bad data one day, the dry-run gate is what catches it before it matters.

The code

It’s all on my GitHub: scripts/auto-update-compliance-policy at main · BurgerhoutJ/scripts

• Update-IntuneOSVersionCompliance.ps1: the runbook

• Grant-ManagedIdentityGraphPermissions.ps1: one-time Graph permission setup

• deploy.sh: infrastructure deployment via Azure CLI

That is it for now. Until next time. 👋

I’m Jeroen Burgerhout, and this is a show about modern workplace IT — Intune, Entra ID, Windows 365, Autopilot, and conditional access policies.

No fixed schedule here. I record when there’s someone in the field with something worth saying — a war story, a fix, a good rant about Conditional Access. If there’s nothing worth recording, you don’t hear from me. That’s the deal.

If you’ve ever waited on a sync or explained Entra ID to a confused exec for the fifth time — you’re in the right place.

I’m Jeroen Burgerhout. See you whenever there’s something worth talking about.

Get more from Jeroen Burgerhout ☁️ | MVP in the Substack app

Available for iOS and Android

Get the app

I’m excited to announce that I’ll be speaking at Workplace Ninja Summit 2026 this year. Looking forward to sharing real-world about the design and implement a practical Windows 11 Shared PC baseline with Intune for sign-in, applications, updates, and security.

Event Details

• Event: Workplace Ninja Summit 2026

• Date: September 14 - 17, 2026

• Location: Baden, Switzerland

• Session time: Halle 36.1, Tuesday 15th @ 13:10

• Website: https://summit.wpninjas.global/

• Registration: https://summit.wpninjas.global/home-2026/registration-2026/

About the Event

Workplace Ninja Summit 2026 brings IT professionals, consultants, and Microsoft enthusiasts together for four days of technical sessions focused on Microsoft Intune, security, Windows management, identity, and the modern workplace ecosystem.

With over 100 sessions, a strong community vibe, and direct interaction with speakers and sponsors, the summit is a relaxed but highly technical environment where attendees can learn, network, and share real-world experience.

My Session

Windows 11 Shared PCs done right: Secure, fast, and low-touch with Microsoft Intune

Build a practical Windows 11 Shared PC baseline with Intune covering sign-in, apps, updates, security, and real-world troubleshooting, so shared devices stay fast, compliant, and easy to run.

Shared Windows PCs are everywhere: frontline devices, training rooms, labs, meeting spaces, call centers, and kiosk-style scenarios. But without the right configuration they quickly become slow, messy, and hard to secure especially with multiple users, shifting shifts, and limited local IT access.

In this session you’ll learn how to design and implement a Windows 11 Shared PC configuration using Microsoft Intune. We’ll translate the “Shared PC” concept into a reusable blueprint: identity choices (local vs Entra sign-in), account management, storage cleanup, app delivery (Win32/MSIX/Store), policy essentials, update strategy, and security hardening without ruining the user experience.

Expect a practical walkthrough with real-world do’s and don’ts, plus troubleshooting patterns for the issues you only see in shared environments (stale profiles, disk bloat, sign-in loops, OneDrive/Teams behavior, and mis-scoped policies).

Session Resources

Slides

will follow after the summit

Let’s Connect

If you’re attending Workplace Ninja Summit 2026, feel free to say hi before or after the session. Always happy to talk about Intune, security, Windows 11, or Modern Workplace challenges.

In the previous part of this series, we looked at managing Cloud PCs after they have been provisioned.

Now it’s time to make sure those Cloud PCs stay up to date.

If you are already using Windows Autopatch for your Windows endpoints, the good news is that Windows 365 Enterprise Cloud PCs are fully supported. There is no need to create a separate update management strategy just because these devices run in the cloud.

In this article, I will configure Windows Autopatch for Windows 365 Enterprise Cloud PCs.

Enable Windows Autopatch for Windows 365

The easiest way to enable Autopatch for new Cloud PCs is directly from the Windows 365 provisioning policy.

Open the Microsoft Intune admin center and navigate to:

Devices → Windows 365 → Provisioning policies

Create a new provisioning policy or edit an existing one.

During the provisioning policy configuration, you will find the Additional Services section.

Enable Windows Autopatch and select an existing Autopatch group.

This registers newly provisioned Cloud PCs with Windows Autopatch automatically.

Once the provisioning policy is assigned, every new Cloud PC created through this policy will automatically be registered with Windows Autopatch.

What happens next?

That’s it.

One of the nice things about the Windows 365 and Windows Autopatch integration is that there is no additional enrollment workflow required.

When a Cloud PC is provisioned, it will automatically appear in the Windows Autopatch experience and will follow the configured update management process.

From there, administrators can monitor:

• Update status

• Deployment progress

• Device health

• Potential update issues

Checking your Cloud PCs in Windows Autopatch

After the Cloud PC has been provisioned, it’s always worth verifying that everything is working as expected.

Under the Device → Overview section, select Autopatch management status. Open the Windows Autopatch section in the Intune admin center and check your Cloud PC devices.

Things to verify:

• Is the device registered?

• Is the device up to date?

• Are there any alerts?

• Which types of updates?

Windows Autopatch helps keep Windows devices updated by managing update deployment, monitoring health, and reducing the manual effort required from administrators.

What about existing Cloud PCs?

One thing to keep in mind: enabling Windows Autopatch in a provisioning policy is mainly intended for newly created Cloud PCs.

If you already have an existing Windows 365 environment, check the current registration status of your Cloud PCs before making changes.

Don’t assume that updating a provisioning policy will automatically update existing devices.

A Cloud PC is still a Windows endpoint.

Creating completely separate update processes for physical devices and Cloud PCs increases operational complexity and makes troubleshooting harder.

Final thoughts

There isn’t much configuration needed, and that is exactly the benefit.

Windows 365 Enterprise and Windows Autopatch are designed to work together. Enable the option in your provisioning policy, provision the Cloud PC, and let Autopatch handle the update management.

Simple, consistent, and aligned with a modern workplace approach.

In the next part of this series, we will look at Windows 365 Link and Microsoft Intune, including how to configure and manage Windows 365 Link devices.

That is it for now. Until next time. 👋

In the previous articles, we covered the fundamentals of Windows 365 and walked through the deployment of a Windows 365 Enterprise environment.

Once your Cloud PCs are provisioned, the real management begins.

Unlike a traditional physical endpoint, Windows 365 provides several management actions that can significantly reduce support time and improve the end-user experience. Features like restoring a Cloud PC, resizing it to a more powerful SKU, or restarting it remotely are all available directly from Microsoft Intune.

In this article, we'll explore the most important Cloud PC management actions, explain when you should use them, and share a few best practices from real-world deployments.

We'll cover:

• Navigating to your Cloud PCs

• Restarting a Cloud PC

• Restoring a Cloud PC

• Resizing a Cloud PC

• Reviewing device information

• Best practices

Where can you manage Cloud PCs?

All Cloud PC-specific management actions are available from within Microsoft Intune.

Navigate to Devices → Manage Windows 365 Cloud PCs → All Cloud PCs

Here you'll find an overview of every Cloud PC in your environment, including:

• Device name

• Assigned user

• Provisioning status

• License type

• Device health

• Last sign-in

• Provisioning policy

Selecting a Cloud PC opens the device management page, where you'll find all available management actions.

Restarting a Cloud PC

Sometimes the simplest solution is still the best one. Whether a Windows Update requires a reboot or an application has become unresponsive, administrators can restart a Cloud PC without requiring the user to initiate the action.

When should you use it?

Typical scenarios include:

• Completing Windows Updates

• Troubleshooting application issues

• Refreshing system services

• General maintenance

How to restart a Cloud PC

1. Open the Intune Admin Center.

2. Navigate to Devices → Manage Windows 365 Cloud PCs → All Cloud PCs.

3. Select the Cloud PC.

4. Click Restart.

5. Confirm the action.

Restoring a Cloud PC

This is probably one of my favorite Windows 365 features. Instead of rebuilding an entire desktop after something goes wrong, you can restore the Cloud PC to an earlier restore point.
In many situations, this saves hours of troubleshooting.

When should you use Restore?

Examples include:

• A faulty software installation

• Corrupted Windows components

• Configuration changes causing instability

• Testing software that didn't go as planned

How to restore a Cloud PC

1. Open Devices → Manage Windows 365 Cloud PCs → All Cloud PCs.

2. Select the Cloud PC.

3. Click Restore.

4. Select the desired restore point.

5. Click Restore again.

6. Confirm the action.

Things to know

• The operating system is restored to the selected point in time.

• Applications installed after that restore point may need to be reinstalled.

• Files stored in OneDrive remain unaffected.

• Restore requires point-in-time restore to be configured/enabled first.

Resizing a Cloud PC

Business requirements change, and so do user workloads. Fortunately, Windows 365 allows administrators to resize a Cloud PC without starting from scratch.

Whether a developer needs additional RAM or a project requires more processing power, resizing is a straightforward operation.

Typical scenarios

• Developers

• Engineers

• Designers

• Temporary projects

• Power users

How to resize a Cloud PC

1. Open Devices → Manage Windows 365 Cloud PCs → All Cloud PCs.

2. Select the Cloud PC.

3. Click Resize.

4. Choose one of the available license configurations.

5. Confirm the resize operation.

Things to know

• Only supported upgrade paths are displayed.

• The Cloud PC will restart during the resize.

• User data and installed applications remain available.

• Resize depends on available license inventory and Enterprise disk downgrades aren't supported.

Reviewing Cloud PC information

Every Cloud PC contains a wealth of operational information that can help administrators and helpdesk engineers troubleshoot issues.
Some of the most useful properties include:

• Provisioning Status

• Device Health

• Assigned User

• Provisioning Policy

• Cloud PC Size

• Region

• Last Sign-in

• Device Name

Knowing where to find this information can often save valuable troubleshooting time. You can find some overviews about the Cloud PCs at Reports → Windows 365 → Windows 365 monitoring (prview) or Windows 365 overview

Best Practices

After working with Windows 365 in several customer environments, a few recommendations consistently stand out.

Keep your Cloud PCs standardized

Avoid creating unnecessary image variations or provisioning policies.
The more standardized your environment is, the easier it becomes to manage.

Use Restore before Reprovision

Reprovisioning should not be your first reaction.
Whenever possible, try a Restore first.

Resize only when necessary

A larger Cloud PC also means higher licensing costs.
Validate whether the bottleneck is actually hardware-related before upgrading.

Manage Cloud PCs like any other endpoint

Windows 365 doesn't require a completely new management strategy.

Continue using:

• Configuration Profiles

• Compliance Policies

• Security Baselines

• Application Deployment

• Windows Autopatch / Windows Update policies

A Cloud PC is simply another Windows endpoint managed through Intune.

Final Thoughts

Provisioning a Cloud PC is only the beginning.

Windows 365 includes several management capabilities that can significantly reduce operational overhead while improving the end-user experience.

Understanding features like Restart, Restore, and Resize enables administrators to resolve issues more quickly and keep users productive with minimal disruption.

In the next part of this series, we'll look at Windows Autopatch and explore how to keep Cloud PCs secure, compliant, and automatically up to date.

That is it for now. Until next time. 👋

A few weeks ago, I was working with a customer who asked me a simple question:

"If we're already moving to Windows 365 and Microsoft Intune, do we still need all these other tools?"

It sounded like an easy question, but the more we talked about it, the more I realized it deserved a proper comparison. Not based on marketing slides or feature matrices, but based on real-world scenarios and the challenges organizations are actually trying to solve.

So I spent some time researching the different options on the market. Looking at endpoint privilege management, remote support, endpoint analytics, application management, and digital employee experience solutions from various vendors. Some of these products have been around for years and have built an excellent reputation in their own area of expertise.

What surprised me wasn't necessarily that Microsoft had equivalents for many of these capabilities. It was how much the conversation had shifted from comparing individual features to evaluating an integrated platform.

This isn't intended to be a "Microsoft versus everyone else" article. There are plenty of scenarios where dedicated third-party solutions still make perfect sense. Instead, I wanted to take a practical, fact-based look at where Windows 365 and Intune Suite fit into today's modern workplace, where they shine, and where organizations should still carefully evaluate their options.

The traditional endpoint management toolbox

If you look at many enterprise environments today, it's not uncommon to find solutions from multiple vendors, each solving a specific problem.

You might have:

• Remote support

• Endpoint privilege management

• Digital Employee Experience (DEX)

• Third-party application packaging and patch management

• Device management

• Security and compliance tooling

Individually, these products often do an excellent job. Many organizations have invested in them over several years and built mature operational processes around them.

The challenge isn't necessarily functionality anymore.
The challenge is complexity.

Every additional product introduces another management portal, another integration, another licensing model, another deployment process, and another operational workflow for administrators to maintain.

Windows 365 changes the conversation

Windows 365 isn't just another virtual desktop offering.

It changes how organizations think about endpoint management.

Instead of managing a mix of physical devices, VPN dependencies, and complex infrastructure, organizations can provide Cloud PCs that are managed through the same Microsoft Intune platform they're already using for Windows endpoints.

Identity becomes the primary control plane.
Policies are applied consistently.
Security is integrated by design.
Management becomes significantly more predictable.

When customers adopt this model, they naturally start asking whether they still need separate products for every operational task.

And in many conversations I've had recently, that's exactly what's happening.

Looking beyond feature comparisons

When evaluating solutions, it's tempting to compare feature lists side by side.
In reality, customers don't buy features.
They buy solutions to operational problems.

So instead of comparing products, let's compare scenarios.

Endpoint Privilege Management

One of the most common requests from IT departments is surprisingly simple:

"A user needs administrator rights to install a printer driver or approved business application."

Historically, organizations often solved this by granting local administrator rights or deploying dedicated privilege management products.

Solutions from vendors such as BeyondTrust or CyberArk have built strong reputations in this space and continue to provide extensive capabilities for organizations with advanced requirements.

Endpoint Privilege Management in Microsoft Intune takes a different approach by allowing administrators to elevate approved applications without making users permanent local administrators.

For many Windows-first organizations, that may provide exactly the level of control they need while remaining fully integrated with Microsoft Intune and Microsoft Entra.

Will it replace every advanced privilege management platform? Probably not.

Will it be enough for a large number of organizations? Absolutely.

Remote Help

Remote support has traditionally been an area dominated by specialized vendors.

Products like TeamViewer and BeyondTrust have earned their place by providing mature and feature-rich remote assistance capabilities.

Intune Remote Help approaches the problem from within the Microsoft ecosystem. Authentication integrates with Microsoft Entra ID. Role-based access aligns with existing administration models.

Security and compliance policies remain part of the same management platform administrators already use every day.

For organizations already standardized on Microsoft technologies, reducing the number of separate support platforms can simplify operations considerably.

Enterprise App Management

Application packaging remains one of the biggest ongoing administrative tasks for IT teams.

Packaging applications, testing updates, and maintaining installers consumes significant time and resources.

Enterprise App Management helps reduce much of this overhead by providing a managed catalog of third-party applications that integrate directly with Microsoft Intune.

Especially for smaller IT departments and managed service providers, this can remove a significant amount of repetitive work.

Will it replace every dedicated third-party patch management solution? Not necessarily.
But it addresses a problem that many organizations have struggled with for years while remaining integrated into existing Intune workflows.

Intune Advanced Analytics

One area that deserves special attention is Intune Advanced Analytics.

When people hear "analytics," they often think of complex Digital Employee Experience (DEX) platforms with deep telemetry, sentiment analysis, and extensive reporting capabilities. Vendors such as Nexthink, Lakeside, and ControlUp have been focusing on this space for years and continue to offer very mature solutions.

However, that's not necessarily what every organization needs.

In many of the environments I work with, customers are primarily looking for answers to practical operational questions:

• Why are users experiencing slow logons?

• Which devices are performing poorly?

• Are application crashes increasing after a recent update?

• Which startup processes are impacting performance?

• Are there recurring reliability issues that we should investigate?

This is where Intune Advanced Analytics becomes particularly interesting.

Instead of introducing another standalone platform, organizations can gain valuable insights directly from within the Microsoft Intune portal they're already using to manage their endpoints and Cloud PCs. Administrators can identify trends, investigate performance issues, and proactively detect problems before they result in support tickets.

For organizations already invested in Windows 365 and Microsoft Intune, this integrated approach can be a significant advantage. The data is available in the same management experience, reducing the need to switch between multiple tools and simplifying day-to-day operations.

Will it replace every enterprise-grade DEX platform on the market? Probably not.

Organizations with highly specialized requirements or mature Digital Employee Experience programs may still benefit from dedicated solutions that offer deeper analytics and broader capabilities.

But for many organizations, Intune Advanced Analytics provides exactly what they're looking for: actionable insights that help improve the end-user experience without adding yet another management platform to the stack.

And to me, that's one of the recurring themes throughout the Microsoft ecosystem: not necessarily replacing every specialist tool, but reducing complexity while delivering the capabilities that most organizations actually need.

The biggest differentiator isn't a feature

After comparing the various solutions, I came to a somewhat unexpected conclusion.

The biggest differentiator isn't Endpoint Privilege Management.
It isn't Remote Help.
It isn't Enterprise App Management.

It's the platform itself.

Windows 365, Microsoft Intune, Microsoft Entra ID, and Microsoft Defender increasingly work together as one integrated management and security platform.

Identity, device management, compliance, application management, and Cloud PCs all share the same ecosystem.

Administrators don't need to jump between multiple consoles.
Security signals are shared.
Policies work together.
Management becomes simpler.
Operational overhead is reduced.

That's difficult to capture in a comparison table, but in day-to-day operations it can make a significant difference.

Does this make third-party solutions obsolete?

No.

And I don't think that's the right conclusion to draw.

Many organizations have existing investments that continue to deliver tremendous value. Others have complex environments, multi-platform requirements, or advanced operational needs that justify specialized products.

Technology decisions should always be based on business requirements, not vendor loyalty. The good news is that customers now have more options than ever before.

Final thoughts

The customer's original question was simple:

"Do we still need all these other tools?"

My answer was equally simple:

Maybe not as many as you think.

Windows 365 combined with Microsoft Intune and the growing capabilities available through Intune Suite have fundamentally changed the conversation.

Rather than evaluating products feature by feature, organizations should look at the bigger picture: platform integration, operational simplicity, reduced complexity, and a unified management experience.

For some organizations, dedicated third-party solutions will absolutely remain the right choice.

For many others, the Microsoft platform has matured to the point where fewer products, fewer management consoles, and fewer integrations can actually lead to a better overall outcome.

And in my experience, making things simpler is often one of the biggest wins you can achieve.

That is it for now. Until next time. 👋

This article reflects my own experience working with customers and researching the available options in the market. Every environment is different, and the right solution will always depend on an organization's specific technical and business requirements.

In the first part of this series, we covered the basics of Windows 365, licensing, and the differences between Business and Enterprise.

Now it’s time to actually build a Windows 365 Enterprise environment.

Unlike Windows 365 Business, the Enterprise edition gives administrators much more control over:

• networking

• identity

• management

• security

• provisioning

The tradeoff is simple:
more flexibility also means more configuration.

In this post, I’ll walk through the core components required to successfully deploy Windows 365 Enterprise using Microsoft Intune.

I’ll cover:

• prerequisites

• networking

• Azure Network Connection

• provisioning policies

• images

• assignments

• common deployment mistakes

Understanding the architecture

A Windows 365 Enterprise deployment consists of several components working together:

• Microsoft Intune

• Microsoft Entra ID

• Windows 365 licensing

• provisioning policies

• Cloud PC images

At a high level, the provisioning flow looks like this:

From an administrator perspective, most of the work happens before the first Cloud PC is created.

Good preparation prevents most provisioning failures later on.

Prerequisites

Before configuring anything, validate the following requirements.

Required components

At minimum you need:

• a Windows 365 Enterprise license

• Microsoft Intune

• Microsoft Entra ID

• supported networking

• administrative permissions

In most modern environments, this is already enough to start deploying Cloud PCs relatively quickly.

One of the biggest advantages of Windows 365 Enterprise is that administrators can keep the deployment relatively straightforward while still maintaining enterprise-grade management capabilities.

Provisioning policies explained

Provisioning policies define how Cloud PCs are created. Think of them as the deployment blueprint. A provisioning policy controls:

• region

• image

• join type

• language settings

• assignments

Without a provisioning policy, no Cloud PCs will be created.

Creating a provisioning policy

1. Inside Intune, navigate to -> Devices -> Manage Windows 365 Cloud PCs -> Provision Cloud PCs

2. Click on Create policy

3. In the Name field, give the policy the desired name

4. Choose at Experience, in this example, for Access a full Cloud PC Desktop

5. At License type, click Enterprise.

6. At Join type, click Microsoft Entra Join

7. At Network, click Microsoft hosted network

8. Choose your Geography and regions

9. Check the box for Microsoft Entra Single sign-on

10. Click Next

11. Choose an Image type

12. Choose the Language & Region

13. Create a Device name template

14. Optional: Link an Autopilot Device preparation policy

15. At Additional Services, I choose for Autopatch, because I have that running in this tenant.

16. Click Next

17. Click Next.

18. Assign the policy to the group of licensed users

19. Review the settings and click Next

For most deployments, the default Microsoft-hosted networking configuration is more than sufficient and keeps the deployment process much simpler.

Selecting images

Windows 365 supports multiple image options.

Gallery images

Microsoft provides prebuilt images including:

• Windows 11

• Microsoft 365 Apps

• Teams optimization

These are the easiest to maintain and are ideal for most deployments.

Custom images

Organizations can also deploy their own images.
This is useful for:

• preinstalled applications

• hardened configurations

• specialized workloads

• legacy software requirements

My recommendation:
Start with gallery images unless there is a strong business reason not to.

Custom images increase operational overhead quickly.

Assigning users

Once the provisioning policy is configured, assignments determine who receives a Cloud PC. Typically this is done using:

• Entra ID groups

• dynamic groups

• department-based assignments

As soon as:

• the user has a valid license

• and receives the provisioning policy

the Cloud PC deployment starts automatically.

Provisioning usually takes between 20 minutes to several hours, depending on:

• image type

• deployment complexity

• assigned applications and policies

Intune enrollment

After provisioning completes, the Cloud PC automatically enrolls into Intune. From there, it behaves almost like a normal Windows endpoint.

Administrators can deploy:

• compliance policies

• configuration profiles

• applications

• security baselines

• Defender policies

• update rings / Autopatch

This is where Windows 365 becomes especially powerful for organizations already using Intune extensively.

The management experience is very familiar for endpoint administrators because most existing Intune workflows continue to work exactly the same.

Common deployment mistakes

I’ve seen the same problems come up again and again during deployments in recent months. I'll mention a few from my experiences.

Overcomplicating the first rollout

Keep the initial deployment simple.

Do not immediately introduce:

• custom images

• dozens of applications

• complex security baselines

• advanced networking requirements

Validate the platform first.

Deploying too many applications during provisioning

Heavy application deployments can slow down the user onboarding experience significantly.

Especially large Win32 apps may delay the first login experience.

Using custom images too early

Custom images sound attractive, but they also become operationally expensive.
Many organizations can achieve the same result using:

• Intune

• application deployment

• configuration profiles

without maintaining image lifecycles manually.

Treating Cloud PCs differently from endpoints

A Cloud PC is still a Windows endpoint. Many existing Intune and security principles still apply.

Final Thoughts

Windows 365 Enterprise is relatively straightforward once the foundational components are designed correctly.
Most deployment challenges are not caused by Windows 365 itself, but by:

• unnecessary complexity

• overengineering

• or introducing advanced scenarios too early

My recommendation is always: start simple, validate the platform, and scale gradually.

In the next part of this series, we’ll take a closer look at Cloud PC settings, management capabilities, and the options administrators have after deployment.

That is it for now. Until next time. 👋

A practical look at Windows 365, including architecture, Business vs. Enterprise, licensing, benefits, trade-offs, and where it fits.

Most organizations want the same thing from modern endpoint computing: a Windows experience that is secure, flexible, easy to manage, and available from anywhere. The problem is that getting all of that at the same time has never been simple. Traditional laptops solve one part of the puzzle, and classic VDI solves another, but both usually come with trade-offs in complexity, cost, or user experience.

That is why Windows 365 has become such an interesting option for IT teams: it aims to deliver the simplicity of a managed endpoint with the flexibility of cloud-delivered desktop computing.

Windows 365 is Microsoft’s Cloud PC platform, delivering a persistent, personalized Windows desktop from the Microsoft Cloud to virtually any endpoint. Rather than running Windows locally on a physical device, users connect to a dedicated Cloud PC hosted in the Microsoft Cloud.

In this first post in the series, I want to walk through the fundamentals and give some practical context around:

• What Windows 365 is

• The differences between Business and Enterprise

• Licensing basics

• Key advantages and disadvantages

• When Windows 365 makes sense and when it doesn’t

So, What Is Windows 365 Really?

If you come from a traditional VDI background, the easiest way to think about Windows 365 is as a managed Cloud PC service that hides much of the underlying complexity from both IT and end users.

A Cloud PC is a persistent Windows desktop hosted in Microsoft Cloud. Each user is assigned a dedicated environment that retains core state across sessions, including:

• Applications

• Settings

• Data

• User profile

• Management policies

From the user perspective, the goal is to make the session feel as close as possible to working on a physical Windows endpoint.
From an IT perspective, Cloud PCs are managed similarly to physical Windows endpoints through Microsoft Intune.

Users can access their Cloud PC through multiple client options, including:

• Windows

• macOS

• Linux

• iPadOS

• Android

• HTML5 browser sessions

Because compute and state live in the cloud, the local endpoint matters a lot less than it does in a traditional desktop model. In my experience, that makes Windows 365 especially useful in scenarios such as:

• Contractors

• Temporary workers

• Bring your own device (BYOD)

• Secure admin workstations

• Remote employees

• Shared or shift-based frontline scenarios

• Disaster recovery workspaces

Windows 365 Business or Enterprise?

One of the first decisions you need to make is which Windows 365 edition actually fits your environment.

The two primary editions are:

• Windows 365 Business

• Windows 365 Enterprise

On paper, the editions can look fairly similar. In practice, the differences show up quickly once you look at management depth, networking, and integration with the rest of the Microsoft stack.

Feature Business Enterprise Intune integration Limited Full Networking control Microsoft managed Azure Network Connection Conditional Access Limited Full Custom images No Yes Granular management Limited Extensive Hybrid support No Yes Best suited for Small organizations Enterprise environments

The practical distinction is simple:

• Business is built for simplicity.

• Enterprise is built for control and scalability.

If you are already invested in Microsoft Intune and Microsoft Entra ID, Enterprise will usually be the more logical option and in many cases, the one you will probably want long term.

💡

For smaller organizations with fewer than 300 users, Windows 365 Business can be a good fit, especially when simpler management and reporting capabilities are sufficient.

Let’s Talk About Licensing

If there is one area where people tend to pause with Windows 365, it is licensing. The platform itself is straightforward, but the licensing story needs a bit more attention.

In most cases, licensing is determined by four variables:

• vCPU

• RAM

• Storage

• User assignment

Each licensed user is assigned a dedicated Cloud PC with a fixed hardware profile.

Common examples include:

• 2 vCPU / 8 GB RAM / 128 GB storage

• 4 vCPU / 16 GB RAM / 256 GB storage

• And so on

Check this website for all Cloud PC SKUs.

A few licensing details matter in practice:

• Windows 365 Business includes the Windows license.

• Windows 365 Enterprise requires additional Microsoft licensing prerequisites.

• Windows 365 Flex (Frontline) licensing is available for shift-based scenarios.

• GPU-enabled Cloud PCs are available for specialized workloads.

Microsoft also differentiates licensing and deployment models based on:

• Microsoft-hosted networking

• Customer-managed networking

• Dedicated versus shared usage scenarios

This is one of those areas where proper sizing really matters. If you choose the wrong SKU, cost can climb quickly, so it is worth mapping licenses to actual user behavior and workload requirements rather than guessing.

Why So Many Organizations Are Looking at Windows 365

What makes Windows 365 compelling is that it is not just another virtualization platform. For a lot of organizations, it is a way to standardize desktop delivery without taking on the full complexity that usually comes with VDI.

Simplicity

Compared with traditional VDI platforms, Windows 365 is generally easier to deploy, govern, and operate.

In many environments, provisioning can be completed in minutes rather than weeks.

Consistent user experience

Users work on the same desktop experience regardless of:

• location

• device

• network

That consistency translates into a more predictable support model.

Security

Because corporate data remains inside the Cloud PC session, organizations can reduce the risk of data exposure on unmanaged or personally owned devices.

When combined with controls such as:

• Conditional Access

• Microsoft Intune

• Defender for Endpoint

Windows 365 can play a strong role in a Zero Trust endpoint strategy.

Fast onboarding

Need to bring a temporary worker online quickly?

In practical terms, that means you can assign a license, apply a provisioning policy, and have a desktop ready for the user very quickly.

Reduced dependency on hardware

It also reduces the pressure on local hardware, because most of the heavy lifting happens in the cloud rather than on the endpoint itself.

Where Windows 365 Is Not the Best Fit

As with most cloud services, the strengths of Windows 365 are also what define its boundaries. It is a great fit in many environments, but not in every scenario.

Monthly operational costs

Cloud PCs introduce recurring subscription costs that can become significant at scale.

This is especially relevant for:

• power users

• GPU workloads

• 24/7 usage

Internet dependency

Without a stable and well-performing internet connection, the user experience can degrade quickly.

Latency, packet loss, and network quality still matter.

Not every workload fits

Workloads that depend on intensive graphics, very low latency, or specialized peripheral integration may be better served by other solutions.

Less flexibility than traditional AVD

Compared with Azure Virtual Desktop, Windows 365 gives you less architectural flexibility by design. That is not necessarily a weakness, it is part of the value proposition but it does mean AVD may still be the better option for more specialized scenarios. AVD gives more flexibility around multi-session, pooled desktops, application streaming, and custom architecture designs.”

In many cases, that trade-off is exactly the point, but it is still a trade-off.

So When Does Windows 365 Make Sense?

From my perspective, Windows 365 delivers the most value when organizations are looking for:

• Predictable management

• A simplified VDI model

• Strong integration with Intune

• Rapid deployment

• Secure remote work

• Lower operational overhead

Typical scenarios include:

• Consultants

• Remote employees

• Outsourced teams

• Mergers and acquisitions

• Temporary projects

• Secure admin environments

• Shared desk setups

Final Thoughts

For me, the most important thing to understand about Windows 365 is that it is not simply “VDI in Azure.”

It is Microsoft’s attempt to modernize endpoint delivery by combining cloud management, identity, security, and desktop virtualization into a more standardized operating model. That is exactly why it resonates with so many organizations that want the benefits of cloud-delivered desktops without building and maintaining a full VDI platform themselves.

If you are already standardized on the Microsoft ecosystem, especially Intune and Entra ID, Windows 365 can be a very strong addition to your endpoint strategy.

In the next post in this series, I’ll build out a Windows 365 Enterprise environment and walk through the provisioning flow in Microsoft Intune step by step.

That is it for now. Until next time. 👋

Finally, the jetlag has disappeared and after some preparations for the upcoming renovation at home, I have now found time to write a piece about the past MVP Summit.

Last week I attended the Microsoft MVP Summit 2026 in Redmond, Seattle. An inspiring week full of technical discussions, reconnecting with the community, and sharing feedback directly with the Microsoft product teams.

In this post I'll share some highlights of the week. As always, I will not share anything covered by NDA, but I will focus on the experience, learnings, and moments that stood out.

What is the MVP Summit?

The Microsoft MVP Summit is an annual event where MVPs from around the world come together at the Microsoft campus in Redmond.

The event focuses on:

• direct interaction with Microsoft product teams

• deep technical sessions

• sharing feedback from the field

• connecting with other MVPs

• learning about upcoming developments

Most sessions are under NDA, which allows for open discussions and honest feedback between the community and Microsoft.

For me personally, this event is always valuable because it connects real-world customer challenges with the people building the products.

Travelling to Seattle (Saturday)

Traveling always feels like it’s really about to begin. The downside is sitting in a plane for about 10 hours. For me, the journey went via Paris to Seattle.

At Schiphol I met Oktay, Sander and Raymond, so the four of us travelled to Seattle on the same flights.

Once we arrived at Seattle Airport, we had to wait for the rest of the Intune MVPs from the Netherlands, as they were on another flight. After that it was time to pick up the car and drive to Bellevue to check in.

Of course, the day ended with food and drinks at Joey’s.

Sunday

On Sunday mornings we now traditionally go on a hike with a group of MVPs and Microsoft people, organized by Sangee.

This year we went to the Twin Falls Trail, a walk of about 5 km. Unfortunately, we couldn’t complete the full trail because part of it was closed.

Afterwards we drove to an outlet, had lunch, did some shopping and then returned to the hotel, as we had to be in Seattle later that day for a party hosted by the Workplace Ninja US team.

Pre-Day (Monday)

The Pre-Day is typically focused on picking up your badge and meeting other MVPs.

One of the highlights of the Pre-Day is the roundtable sessions, where MVPs can provide direct feedback to Microsoft product teams.

At the end of the day it was time to collect the badge and the swag, after which we headed back to the hotel.

Later that evening, together with Erik and Kenneth, we drove to Topgolf in Renton. Almost all Experts Live teams were present, including from the Netherlands, United Kingdom, Germany and more.

Tuesday

Today the MVP Summit really started.
We had breakfast at the hotel and then drove to the Microsoft campus in Redmond.

After an exciting day on campus, the day ended with the CxE Welcome Reception. Later we returned to the hotel and eventually ended up at Fogo de Chão for dinner.

Wednesday

Day two of the MVP Summit.

We had breakfast on campus and then attended many sessions throughout the day. Some sessions were very strong, while others were a bit less relevant.

At the end of the day we returned to the hotel to prepare for the Patch My PC party at the golf club in Newcastle.

The buffet was already ready when we arrived, so we could start eating immediately. One of the highlights of this location is the beautiful sunset over Seattle and Bellevue, although the weather was slightly less impressive than last year.

After dinner and picking up some gadgets, we returned to the hotel for just one drink.

Thursday

Day three of the MVP Summit.

Rudy and I decided to sleep in a bit longer, which was a success. Around 9 AM we met in the hotel lobby and walked to a nearby breakfast place.

After breakfast and coffee, we walked to the train station to take public transport to the Microsoft campus. That was a nice experience.

From there we took the shuttle to Building 36, where the sessions took place.

At the end of the afternoon we returned to the hotel and around 6 PM attended the Intune & Windows social gathering on the other side of the street.

Later that evening we went back to the hotel for a drink before heading to sleep.

Friday

Last full day in Seattle.

We visited downtown Seattle, walked along the boulevard, explored Pike Place Market, and did an underground tour through old Seattle.

We ended the day at Daniel's Broiler, enjoying a (very expensive) but excellent wagyu New York rib.

After that, I went to bed early as the return journey required an early start.

Saturday – Travel home

Return journey time.

At 8 AM, I took the shuttle to Seattle Airport, flew to Salt Lake City for a transfer, and then continued to Amsterdam.

Finally landed on Sunday around 10 AM.

Wrapping up

The MVP Summit remains one of the most valuable events of the year.

It is not just about technology, but also about:

• sharing knowledge

• strengthening the community

• improving real-world implementations

• helping shape the future of the Microsoft ecosystem

Thanks to Microsoft, the product teams, and the MVP community for another great week.

That is it for now. Until next time. 👋

I’m excited to announce that I’ll be speaking at Workplace Ninjas NL Connect this year. Looking forward to sharing real-world about the design and implement a practical Windows 11 Shared PC baseline with Intune for sign-in, applications, updates, and security.

Event Details

• Event: WP Ninjas Connect

• Date: February 4, 2026

• Location: Gorinchem, Netherlands

• Website: https://nl.wpninjas.global/wpninjas-connect-2026/

• Registration: https://nl.wpninjas.global/wpninjas-connect-2026/

About the Event

Workplace Ninja Connect brings IT professionals, decision-makers, and community experts together to learn, share, and connect around the latest developments in Workplace Technologies. Whether you are looking for deep technical insights, strategic guidance, or inspiration from peers, this event is designed to help you take the next step in modern workplace and security.

My Session

Windows 11 Shared PCs done right: Secure, fast, and low-touch with Intune

Design and implement a practical Windows 11 Shared PC baseline with Intune for sign-in, applications, updates, and security. The result: shared devices that remain fast, are compliant, and are a pleasure to use in everyday situations.

Shared Windows PCs are everywhere: frontline environments, training rooms, labs, conference rooms, call centers, and kiosk-style scenarios. Without a well-thought-out configuration, however, these devices quickly turn into slow, cluttered, and difficult-to-secure systems—especially with multiple users, shift work, and limited local IT access.

In this session, you’ll learn how to design and manage a Windows 11 Shared PC configuration with Microsoft Intune. We’ll translate the Shared PC concept into a reusable blueprint, including identity options (local or Entra sign-in), account and profile management, storage cleanup, app distribution (Win32, MSIX, and Store), essential policy settings, update strategies, and security hardening without negatively impacting the user experience.

You can count on a hands-on walkthrough with practical tips, common pitfalls, and proven patterns for issues specific to shared environments, such as outdated profiles, unnecessary disk usage, login loops, OneDrive and Teams behavior, and misapplied policies.

Session Resources

Slides

sessions/2026 at main · BurgerhoutJ/sessions

Let’s Connect

If you’re attending WP Ninja Connect, feel free to say hi before or after the session. Always happy to talk about Intune, security, Windows 11, or Modern Workplace challenges.

Somewhere between the last meeting of the year and that first “ok, now what?” moment, I always try to pause.
Not to celebrate. Not to optimise. Just to look back and be honest.

2025 was full. Busy. Sometimes chaotic. But also very much on purpose. Less chasing, more choosing. And that made all the difference.

Speaking: Practical Stories From the Field

Speaking remained a constant factor in 2025. And honestly, I still enjoy everything around the session more than the session itself.

This year I had the privilege to speak at events like Workplace Ninja US and Experts Live Netherlands, as well as smaller community meetups and internal sessions. Different stages, same goal: talk about things that actually happen when theory meets reality.

Some of the sessions I spent most time on this year:

• Security Copilot in Entra and Intune: The Ultimate Trio for Cybersecurity and Maybe World Domination

• What Zombies Can Teach You About Security Baselines

• Demystifying Cloud Security: Unlocking Certificate-Based Authentication and PKI Best Practices

• Houston, We Have a Solution: Microsoft Cloud PKI

The real value never sits in the deck.
It lives in hallway chats, the “we tried that too”, and the quiet “oh… that explains a lot” moments. That’s the stuff that sticks.

Writing: Thinking Out Loud

I kept writing in 2025. Sometimes structured. Sometimes slightly ranty. Always honest.

Most blog posts came straight from the field. Things that broke. Things that confused customers. Licensing questions that kept coming back. Designs that looked great on paper but fell apart in real life.

Topics ranged from:

• Cloud PKI with certificate-bases authentication

• MacOS posts, from introduction to how to enroll and managing

• The new Windows LAPS policy settings

• NIS2 with Microsoft Security

• The importance of RBAC

• Windows Shared PCs

Writing is still how I slow my thinking down. If I can’t explain it clearly, I probably don’t understand it well enough yet.

Community: The Quiet Constant

Community isn’t just stages and blog views. 2025 proved that again.

A lot of the meaningful work happened quietly:

• Sharing scripts, templates, and baselines on GitHub

• Helping someone shape their first session abstract

• Internal knowledge sessions with colleagues

Some of the best feedback I received this year never showed up publicly. Just a short message saying something worked. That’s more than enough.

Teaching Keeps You Honest

Explaining things to others has a funny side effect. It exposes every shortcut you take in your own thinking.

Teaching in 2025 reminded me of something simple:
If something feels “too complex to explain”, that’s usually a design problem. Not a communication one.

Looking Ahead

I’m heading into 2026 with the same intent.
Keep sharing what I learn. Keep simplifying where possible. Keep showing up. Even when it’s messy.

More sessions. More writing. More conversations.
And hopefully enough space to pause again next year.

Thanks, Honestly

If we talked in 2025. At a conference. After a session. Through a blog post. On GitHub. Or via a random message. Thank you.

This year wasn’t defined by features or tools.
It was defined by people, conversations, and shared learning.

And that’s exactly why it was a good year.

That is it for now. Until next time. 👋

Last week was the very first Workplace Ninjas US event in Dallas, TX, USA.
I was invited to come and speak with my good friends Oktay, Joery and Maxime. More on that later.

The trip started on Saturday, December 6 with the flight from Amsterdam to New York and then to Dallas. Eventually I was at the hotel around 23:00.

Sunday 7 December

In the morning, I and other speakers went to the Dallas Cowboys' stadium, AT&T Stadium. There we did a VIP tour which took about 2 hours. Since I had left the hotel in an Uber with Simon Binder, we went to Maple & Motor after the tour, on the advice of on Jon. I think I ate the best hamburger of all time there. And, for a decent price. Then we went back to the hotel.

In the meantime, good friend Jose had also arrived from Australia. And in the afternoon, we walked around in a shopping mall and then went to a Katy Trials beer/taproom. In the meantime, Simon Binder had also arrived and the 3 of us drank a few beers. Then it was time to eat and a block away was a good Mexican restaurant. Absolutely great! Then we walked back to the hotel through a neighborhood with the well-known Christmas decorated houses. Once back at the hotel we sat at the bar for a while and then went to bed.

Monday 8 December

Hackathon day!

As a kind of pre-day, the team of Workplace Ninja's US had organized a hackathon at Westlake Brewery Company. The attendees could also just be here. I shook hands a lot with new MVPs / speakers and chatted with the MVPs / speakers I had already spoken to or known from previous events.

There were five teams made with nice team names. I was in team OOPS.EXE with good friend Somesh as team captain together with Oktay, Joery, Maxime and Ashley (from the scholarship program). Unfortunately, we didn't win.

In the evening it was time for the speaker dinner at Chamerlain's. Here all speakers were invited to eat and catch up together.

Tuesday 9 December

The official start of the Workplace Ninja's US has begun.

Started with the keynote by Jon and then the attendees went to several breakout sessions.

In between, I had an appointment with Ryan Huang and colleague from IKEA IT to go through how you can best use and configure Windows 11 Shared PCs. This was a nice 1:1 session.

I did the session "Security Copilot in Entra and Intune: The Ultimate Trio for Cybersecurity and Maybe World Domination" with Joery and Maxime at 15:15 and we were accompanied by Lavanya Lakshman from Microsoft who also did a small presentation.

In the evening, we went out for dinner with a whole group at Hibiki. Since I don't eat sushi and fish, there were plenty of options for meat. At the end of the evening, back to the hotel.

Wednesday 10 December

Day 2 of the Workplace Ninja's US. Today the day started with a keynote by Christiaan Brinkhoff and Scott Manchester about Cloud PCs and AI.
Then the attendees went to different breakout sessions spread over 3 tracks. As the last session of the day, it was my and Oktay's turn for our session "What Zombies Can Teach You About Security Baselines". In this session we entered the room as zombies. Must honestly say that Oktay pretended to be a zombie much better then I did. Check the video below.

Then the closing was with the Golden Clippy Awards and later in the evening we ended up in a restaurant. We ended the evening with a drink in the hotel and then it was time for bed.

Thursday 11 December

Last day in Dallas. But first I’m looking for a soccer jersey from FC Dallas. I've been looking online for days where I can buy these jerseys, otherwise my daughter won't let me come home. Found a store, but yes, Dallas, so another half hour drive. Together with Jose we went that way, found jersey, and went back to the hotel and then not much later went to the Fort Worth Stockyards.

Here you imagine yourself back in the Wild West. Show how cattle were driven through the streets. Sitting at a brewery in the sun with beer and food. After a few hours, we went back to Dallas to quickly eat and drink something and then it was really time for bed.

Friday 12 December

Back home. Said goodbye to many people and eventually went to the airport with Somesh (and family), Joery and Oktay to get on the same plane to Paris. In Paris we split our own ways because of several flights to Amsterdam.

Conclusion

WHAT A WEEK!

I really enjoyed the whole event.

Well done, Jon and team, if you happen to read this. Dallas is seen from east to west and from north to south. Seen nice places, "met" the wild west and much more.

See you all in February 2027 in Arizona!

Shared PCs are a perfect fit for frontline, education, or shift-based environments, where devices are used by multiple users throughout the day. But managing them right requires the right balance between security, performance, and user experience.

In this post, I’ll walk you through how to configure Windows Shared PCs with Microsoft Intune, explain the key differences from kiosk mode, and share a few best practices.

Difference Between Kiosk and Shared PC

While both Kiosk and Shared PC modes aim to simplify multi-user scenarios, they serve very different purposes.

• Kiosk mode is designed for single-app or multi-app lockdowns — think digital signage, reception screens, or terminals running just one or two apps.

• Shared PC mode, on the other hand, enables multiple users to sign in (with Entra ID accounts) and provides a consistent, managed experience while automatically cleaning up inactive user profiles.

Shared PC mode supports:

• Microsoft Entra ID accounts

• Guest accounts

• Automatic cleanup policies

• Fast sign-in and optimized performance

• OneDrive synchronization

If your environment requires multiple users logging in with their own accounts and accessing productivity tools, Shared PC mode is the way to go.

Licensing Requirements for Shared PCs

Licensing Shared PCs can be confusing, but here’s the clean and correct version without the noise.

Do you need Microsoft Intune Plan 1 Device?

In most Shared PC scenarios, you do NOT need the Microsoft Intune Plan 1 Device license.

You only need Microsoft Intune Plan 1 Device if the device is used by users without Intune-eligible licenses, such as:

• Temporary workers without M365/EMS licenses

• Generic/shared accounts

• Local or on-prem AD accounts

• Walk-up or public-access PCs

If your Shared PC is used by employees or students who already have:

• Microsoft 365 F3 / E3 / E5

• Microsoft 365 Business Premium

• Microsoft 365 A3 / A5

• EMS E3 / E5

Then Intune management is already covered, policies, compliance, Conditional Access, Windows Hello for Business and Personal Data Encryption all work normally, without a separate Microsoft Intune Plan 1 Device.

Enrollment of Shared PCs

Enrolling a Shared PC into Intune follows the same technical flow as any other Windows device, but the ownership model behave differently, and this is where many admins get confused.

Autopilot Enrollment

Shared PCs are usually registered with Windows Autopilot. Yes, there are other ways to register, but that is manual, and I prefer the fully automatic process. That is why I will explain how it works with Autopilot. In my opinion, it is very simple.
The advantage of Autopilot in combination with Self-Deploying mode is that no end user needs to be involved to complete the enrollment.

So the most important option to enable in the Autopilot profile is Self-Deploying mode, as shown in the screenshot below.

Understanding the “Primary User”

In Intune, every device normally gets a Primary User, which is used for:

• Helpdesk and ownership views

• Intune audit trails

• App assignment optimizations

• Usage reporting

• Licensing visibility

But in Shared PC mode there is no meaningful Primary User!

The device is intentionally designed to have multiple rotating users, so Intune does not track a primary owner.

You may still see:

• “None” as Primary user

• A generic system account

But this does not affect the functionality.

OneDrive Configuration

OneDrive plays a huge role in the Shared PC experience.
By default, user data isn’t stored locally for long, so you’ll want to make sure Known Folder Move (KFM) and Files On-Demand are properly configured.

A few tips:

• Enable OneDrive auto sign-in using the user’s Entra ID credentials.

• Use Files On-Demand to prevent unnecessary sync and save disk space.

• Redirect Documents, Desktop, and Pictures to OneDrive to make sessions stateless.

• Enable the EnableSharedPCModeWithOneDriveSync setting for a smoothless OneDrive synchronization.

This combination keeps user data safe in the cloud, even if profiles are removed by the cleanup policy.

Microsoft 365 Apps in Shared Mode

Deploying Microsoft 365 Apps on Shared PCs requires a small but important configuration tweak.
Instead of installing them in the default mode, use the Shared Computer Licensing (SCL) option.

This allows multiple users to sign in with their own M365 credentials without requiring separate activations.

💡

Put the following rule in the XML-file: <Property Name="SharedComputerLicensing" Value="1" />

This ensures users get a seamless M365 experience, each using their own license, no conflicts, no sign-in headaches.

💡

Go to https://config.office.com to create your M365 Apps XML, which you can use to create a win32app for deployment. If you have any questions about this, let me know.

Login with Password or Windows Hello for Business

Shared PCs fully support password-based logins, but you can (and should) also enable Windows Hello for Business (WHfB).

⚠️

The maximum number of supported WHfB enrollments on a single device is 10. This lets 10 users each enroll their face and up to 10 fingerprints.

It is unclear whether PIN also falls under this limitation.

When combined with FIDO2 or PIN-based authentication, users can sign in faster and more securely.
For shared environments, consider enabling PIN reset option or using security keys for flexibility.

Another option for logging in is to use web sign-in. With web sign-in, you can log in without a password using methods such as the Microsoft Authenticator app.

The key is to balance security and usability:

• Keep WHfB enabled for enrolled users

• Allow fallback to passwords for normal and guest accounts

• Combine with Intune compliance and Conditional Access for control

Personal Data Encryption (PDE)

One of the newer and often overlooked security layers for Shared PCs is Personal Data Encryption (PDE).
It’s designed to protect user data on the device by encrypting personal files and settings tied to their sign-in credentials.

Here’s how it works:

• When a user signs in with Windows Hello for Business, their identity key encrypts their personal files.

• When they sign out or their session expires, the encrypted data can’t be accessed by anyone else.

• This makes PDE ideal for shared environments — especially when combined with automatic profile cleanup and OneDrive KFM.

You can enable PDE via Endpoint Security -> Disk Encryption, ensuring user files stay protected even if local data remnants remain temporarily on disk.

Despite this notice on the Learn website

💡

If you sign in with a password or a FIDO2 security key, you can't access Personal Data Encryption protected content.

it is still possible to access the encrypted documents using a FIDO2 key or, as a fallback, a password. Don't ask me why, but I will raise this with Microsoft. Even my first login.

In short: PDE ensures that even on a shared or temporary device, user data remains private, encrypted, and unreadable to others.

Power Settings and Maintenance

In principle, you don't have to configure separate power settings for a Shared PC. Because as soon as Shared PC mode is enabled, power settings are already set in the local GPO. The settings which will be set are:

Policy setting Status System/Power Management/Button Settings/Select the lid switch action (on battery) Enabled > Sleep System/Power Management/Button Settings/Select the lid switch action (plugged in) Enabled > Sleep System/Power Management/Button Settings/Select the Power button action (on battery) Enabled > Sleep System/Power Management/Button Settings/Select the Power button action (plugged in) Enabled > Sleep System/Power Management/Button Settings/Select the Sleep button action (on battery) Enabled > Sleep System/Power Management/Button Settings/Select the Sleep button action (plugged in) Enabled > Sleep System/Power Management/Energy Saver Settings/Energy Saver Battery Threshold (on battery) Enabled > 70% System/Power Management/Sleep Settings/Allow standby states (S1-S3) when sleeping (on battery) Enabled System/Power Management/Sleep Settings/Allow standby states (S1-S3) when sleeping (plugged in) Enabled System/Power Management/Sleep Settings/Specify the system hibernate timeout (on battery) 0 (Hibernation disabled) System/Power Management/Sleep Settings/Specify the system hibernate timeout (plugged in) 0 (Hibernation disabled) System/Power Management/Sleep Settings/Turn off hybrid sleep (on battery) Enabled System/Power Management/Sleep Settings/Turn off hybrid sleep (plugged in) Enabled

The same applies to the Maintenance schedule. This is also set when the Shared PC mode is set.

Policy setting Status Windows Components/Maintenance Scheduler/Automatic Maintenance Activation Boundary 2000-01-01T00:00:00 (midnight) Windows Components/Maintenance Scheduler/Automatic Maintenance Random Delay Enabled PT2H (2 hours) Windows Components/Maintenance Scheduler/Automatic Maintenance WakeUp Policy Enabled

Bonus: Global Secure Access Private Access

Finally, let’s talk about Global Secure Access (GSA), Microsoft’s modern approach to secure connectivity.
By combining Shared PCs with GSA Private Access, you can provide Zero Trust network access to on-premises resources without requiring a traditional VPN client.

Users can:

• Access internal web apps or file shares securely

• Authenticate with Entra ID

• Stay compliant with Intune and Conditional Access policies

In shared environments (like retail or classrooms), this means users get secure access, without exposing the full corporate network.

💡

To use Entra Private Access, you need a separate license, namely Microsoft Entra Private Access. This is a user-based monthly license. Of course.
Here in the Netherlands, this license starts at around €4.30 excluding VAT.

Download the Policies

Want to get started right away?
You can download my preconfigured Shared PC Intune policies directly from GitHub:
👉 Download from GitHub

These templates include:

• Shared PC configuration profiles

• OneDrive configuration

• Settings Page configuration

• Autopilot profile

• M365 Apps Shared PC XML

• PDE configuration

Wrap-up

Windows Shared PC mode is one of those hidden gems in the Intune ecosystem, lightweight, secure, and perfect for environments with rotating users.
When configured with OneDrive, M365 Apps, WHfB, Personal Data Encryption, and GSA, it becomes a flexible, modern, and secure shared workspace.

If you have any questions, feel free to reach out. Always happy to share ideas and tips from the field.

That is it for now. Until next time. 👋

If you've ever tried to set up Role-Based Access Control (RBAC) in Microsoft Intune, you know it can quickly become messy.
Too many roles, too many scopes, and suddenly everyone is a full administrator “to make everything work.” I've been there.

Over the past few months, I've refined my own RBAC model, not only for my own tenants, but also for customers and MSP scenarios.
In doing so, I also created an Excel matrix with all available Intune RBAC roles and permissions.

You can download it for free from my GitHub:
👉 Download the Intune RBAC matrix (Excel)

In this post, I share my best practices for setting up RBAC in Intune so you can stay in control, stay secure, and truly trust your delegation settings.

Why RBAC matters

RBAC is one of those features you only start to appreciate when something goes wrong.
Giving someone full access “just to deploy an app” can quickly lead to accidental policy changes, deleted profiles, or worse, broken devices in production.

With proper RBAC you can:

• Apply the least privilege principle

• Separate duties between admins, helpdesk, and security

• Keep your audit trails clean

• Stay compliant and reduce risk

It’s not just about security, it’s about structure and peace of mind.

My RBAC best practices

This is what I've learned after many environments, mistakes, and late-night troubleshooting sessions 👇.

1. Start small.
   Only grant access to what is necessary. You can always expand later.

2. Use the built-in roles first.
   Microsoft already covers most use cases; custom roles are for the exceptions.

3. Align with Entra ID groups.
   Keep naming consistent across your groups and roles. This will save you a lot of confusion.

4. Separate functions.
   Think in terms of help desk, policy management, app management, and security management.

5. Document your assignments.
   Who has what access and why. Sounds boring, but it's worth its weight in gold during audits.

6. Check regularly.
   Schedule a quarterly access review and clean up old assignments.

7. Use PIM (Privileged Identity Management).
   Especially for global or security roles: time-bound access keeps everything secure.

8. Check the audit logs.
   Intune Audit logs tell you exactly who did what. Make use of them.

The Excel RBAC Matrix

If you want to dive deeper into this, download the Excel file I created with all Intune RBAC roles, permissions, and scopes.
This is an easy way to filter and plan your access model before you get started with production.

👉 Download it on GitHub.

I regularly update this file when Microsoft adds or changes RBAC permissions in Intune.

Wrapping up

RBAC might not be the most exciting feature, but it’s one of the most important for long-term maintainability.
Once you set it up right, everything else like policy management, app deployment, troubleshooting, just flows better.

If you’ve got questions, or if you use your own RBAC structure, I’d love to hear how you’re doing it.
Drop me a message or comment. I'm always happy to exchange ideas.

That is it for now. Until next time. 👋

It’s totally outside of my comfort zone, but I created this for a customer — and it turned into something I think a lot of MSPs and Modern Workplace professionals can use.

The new NIS2 Directive reshapes how organizations in Europe, and their IT partners, approach cybersecurity and compliance. For MSPs and Modern Workplace professionals, this isn’t just a regulatory checkbox. It’s about proving that you run a secure, resilient, and trustworthy service environment.

The NIS2 Quality Mark framework makes that measurable through three progressive levels: QM10, QM20, and QM30.

Let’s break down what these levels mean, and how Microsoft’s security ecosystem can help you reach and demonstrate compliance.

What are the NIS2 Quality Marks?

The NIS2 Quality Mark provides a structured way to show that your organization meets the cybersecurity expectations of the NIS2 Directive.
It’s managed by independent certification bodies (like DigiTrust or Kiwa) and comes in three maturity levels:

Level Target audience Focus Audit intensity QM10 – Basic Low-risk suppliers or subcontractors to NIS2 entities Basic cyber hygiene and awareness Light audit / self-assessment QM20 – Substantial IT and managed service providers (MSPs) with access to customer environments Advanced controls and incident response Full third-party audit QM30 – High Critical service providers and operators of essential infrastructure Continuous monitoring, forensics, SOC integration High audit frequency and evidence depth

Why this matters for MSPs

If you manage or secure Microsoft 365, Intune, or Azure environments for your customers, you’re part of their supply chain — and that makes you relevant to NIS2.

Your clients might soon ask:

Which Quality Mark level do you comply with — QM10, QM20, or QM30?

This means your own environment, tools, and governance must reflect the same standards you apply for your customers.
Luckily, the Microsoft ecosystem provides almost everything needed to cover the technical part of NIS2 compliance.

Mapping QM10–QM30 to Microsoft Security

Domain QM10 QM20 QM30 Identity & Access Entra ID Basic + MFA + Conditional Access (P1) Entra ID P2 (PIM, Identity Protection) Full Zero Trust enforcement, JIT access, access reviews Endpoint Security Defender for Endpoint Plan 1 Defender for Endpoint Plan 2 (EDR, ASR rules) Integration with SOC/Sentinel and threat hunting Email & Collaboration Defender for Office 365 Plan 1 Plan 2 + Safe Links/Attachments + auto response Advanced hunting, SOC integration Data Protection Purview DLP (basic) Purview Info Protection + Endpoint DLP Full Purview Suite + lifecycle and eDiscovery Monitoring & Detection Basic logging via M365/Azure Monitor Microsoft Sentinel (SIEM/SOAR) + Defender for Cloud 24/7 SOC, threat intel integration, automation Network & Infra Security Basic firewall/VPN Azure Firewall + Bastion + Zero Trust segmentation Advanced network protection & cross-tenant policies Continuity & Recovery M365 backup / retention Azure Backup + Site Recovery Automated failover + DR drills Governance & Awareness Security awareness + Intune compliance RBAC, audit logging, policy enforcement Full SOC governance, forensic logging, vendor mgmt.

Microsoft Licensing Path

NIS2 Level Recommended License Key Capabilities QM10 🟢 Microsoft 365 Business Premium (or M365 E3 + Add-ons) Entra ID P1, Defender for Office P1, Intune, BitLocker, basic DLP QM20 🟡 Microsoft 365 E5 Security or full M365 E5 Defender P2, Entra ID P2, Sentinel, Compliance Manager QM30 🔵 Microsoft 365 E5 + Sentinel (SOC/MSSP) + Defender for Cloud 24/7 monitoring, advanced detection, compliance auditing, threat intel

In short: M365 Business Premium → E5 Security → E5 + Sentinel mirrors the QM10 → QM20 → QM30 maturity journey.

The Modern Workplace Roadmap

Step Goal Microsoft Actions 1. Establish a baseline (QM10) Implement security fundamentals Enable MFA, Conditional Access, device compliance, Defender for Endpoint, backups 2. Strengthen and monitor (QM20) Professionalize security management Deploy Sentinel, Defender for Cloud Apps, Purview DLP, PIM & Identity Protection 3. Mature and automate (QM30) Build a resilient, continuously monitored environment 24/7 SOC, automation playbooks, threat intelligence, regular tabletop exercises

Key takeaway

NIS2 Quality Marks offer a structured path to prove your cybersecurity maturity.

With the right Microsoft Security stack, you can cover 90% of the technical requirements — from basic cyber hygiene to full SOC-level resilience.

The remaining 10%?
That’s about governance, processes, and people — and that’s where MSPs make the difference.

Want to start mapping your NIS2 level?

If you’re an MSP or IT partner delivering Microsoft 365, Intune, or Azure services, start with your QM10 baseline and gradually build toward QM20.
Combine your operational excellence with Microsoft’s security stack, and you’ll be NIS2-ready long before the audits begin.

Questions or feedback?

If you have any questions about NIS2, Microsoft Security, or how to prepare your organization for compliance, feel free to reach out to me on LinkedIn or via burgerhout.org/contact.

Always happy to share ideas, experiences, and lessons learned from the field.

That is it for now. Until next time. 👋

I was poking around Microsoft Intune yesterday (as one does on a chill afternoon 😅), and I noticed something new in the Windows LAPS policy section. Thought I would share in case you missed it! They have rolled out some fresh settings that give you way more control over local admin accounts.

These new features are shipped with the service release 2503.
Here is the official source: https://learn.microsoft.com/en-us/intune/intune-service/fundamentals/whats-new#new-settings-for-windows-laps-policy.

Let us see what they added to Windows LAPS.

🆕 New Settings

1. Automatic Account Management Enable Account - This setting allows you to enable or disable the automatic management of local administrator accounts.

2. Automatic Account Management Enabled - Once enabled, this ensures that the specified local admin account is managed automatically.

3. Automatic Account Management Name Or Prefix - Here, you can define a specific name or prefix for the local admin account that's being managed.

4. Automatic Account Management Randomize Name - Want to add an extra layer of security? This setting lets you randomize the local admin account name.

5. Automatic Account Management Target - This determines which accounts on the device are targeted for automatic management.

6. Passphrase Length - Now, you can set the desired length for passphrases, giving you more control over password complexity.

🛠️ Tweaked Existing Settings

Password Complexity has new options like:

• Passphrase (long words)

• Passphrase (short words)

• Short words with unique prefixes (basically, passwords that are harder to crack but easier to remember? Yes please.)

Post-Authentication Actions now includes an option that:

• Resets the password, logs the account off, and kills any leftover processes. (This is a much welcome setting)

📺 Show me

Yes. Here we go. In the below screenshot you will see the new settings in Intune -> Endpoint security -> Account protection. Edit your existing one or create a new Local admin password solution (Windows LAPS) policy.

Once you have created, or edited your policy, your devices will pick up the new policy and the result will be like the following screenshot.

That is it for now. Until next time. 👋

Now that your macOS devices are enrolled in Microsoft Intune, it’s time to focus on security and compliance. In this post, we'll cover:

✅ Compliance policies (password rules, OS updates, encryption)
✅ FileVault encryption enforcement
✅ Firewall & Gatekeeper settings
✅ Monitoring compliance & security status

Why Security & Compliance Matter for macOS in Intune

Organizations need to protect sensitive data and ensure macOS devices meet security requirements.

🔥 Common Security Risks for macOS Devices:

• Unencrypted devices – Data loss if a Mac is stolen

• Weak passwords – Easy access for attackers

• Malware & unauthorized apps – Compromised systems

• Outdated OS & patches – Vulnerabilities

📌 Solution? Microsoft Intune allows IT admins to enforce compliance policies, encryption, and security settings to keep macOS devices secure.

Key Security & Compliance Features in Intune

Feature What It Does Recommended For Compliance Policies Enforce security rules (passwords, OS updates) All managed Macs Security Baselines Apply preconfigured security settings Corporate-owned Macs FileVault Encryption Encrypts disk to prevent unauthorized access Laptops & sensitive data Firewall & Gatekeeper Controls network access and app execution policies All Macs Conditional Access Blocks access to company resources if non-compliant All managed devices

Configuring Compliance Policies for macOS

Creating a Compliance Policy

1. Sign in to Microsoft Intune Admin Center

2. Navigate to Devices -> macOS -> Compliance

3. Click + Create Policy

4. Click Create for the new policy

5. Give the policy a name

6. Configure the settings according to your needs

7. Click Next

8. Configure the actions for non-compliant devices

9. Assign the policy to a group of MacOS devices

10. Click Create

11. The policy is now active

Key Compliance Settings

Setting Description Recommended Setting Password Requirements Enforces complex passwords ✅ At least 8 characters, mix of letters/numbers Encryption (FileVault) Requires devices to be encrypted ✅ Required OS Version Ensures macOS is up to date ✅ Latest 2 versions Firewall Enabled Protects against unauthorized network access ✅ Enabled Gatekeeper Enabled Blocks unverified apps from running ✅ Enabled

Enforcing FileVault Encryption

FileVault encrypts the entire macOS drive, preventing unauthorized access, like Bitlocker for Windows devices.

Since it is recommended to start FileVault during enrollment via ADE, we need to do 2 things, namely:

• In the Setup Assistant, display the FileVault screen. See the previous post about the screens in the Setup Assistant

• Create a policy to start FileVault during the Setup Assistant.

How to Enforce FileVault with Intune

1. Go to Devices -> macOS -> Configuration

2. Click + Create Profile

3. Select Profile type: Settings Catalog

4. Give the policy a name

5. Click + Add Settings

6. Select Full Disk Encryption

7. Configure the following FileVault settings:

   • Recovery Key Rotation In Months: 1 month

   • Enable: On

   • Show Recovery key: Enabled

   • Use Recovery key: Enabled

   • Force Enable in Setup Assistant: True

   • Prevent FileVault From Being Disabled: True

   • Location:

6. Assign the policy to a group of macOS devices

✅ Best for: Laptops with sensitive company data.

💡

🔑 Recovery Key Backup: Users can retrieve their recovery key from Intune Company Portal.

Managing Firewall and Gatekeeper Settings

Firewall and Gatekeeper help protect against network threats and unauthorized apps.

Enforcing macOS Firewall with Intune

1. Go to Devices -> macOS -> Configuration

2. Click + Create Profile

3. Select Profile type: Settings Catalog

4. Give the policy a name

5. Configure the following Networking settings:

   • Enable Firewall: True

   • Block All Incoming: False

   • Enable Stealth Mode: True

6. Configure the following Networking settings:

   • Allow Identified Developers: True

   • Enable Assessment: True

   • Enable XProtect Malware Upload: Disable

7. Assign to a group with macOS devices

8. Click on Create

💡

Tip: Enabling Gatekeeper and Firewall together provides strong macOS security.

Monitoring Security & Compliance Status

Checking Device Compliance Reports

1. In Intune Admin Center, go to Reports > Device Compliance

2. Filter for macOS devices

3. Check non-compliant devices and their issues

Using Microsoft Defender for Endpoint (Optional)

For advanced threat protection, integrate Microsoft Defender for Endpoint with Intune.

✅ Provides real-time threat monitoring
✅ Detects malware and vulnerabilities
✅ Blocks suspicious network activity

📌 See this page Microsoft Learn for more information on configuring Defender for Endpoint.

Next Steps

Now that macOS security policies are in place, you can:

• Deploy apps securely (Mac App Store, PKG, DMG)

• Configure Conditional Access (block non-compliant devices)

• Monitor security with Defender & Intune Reports

🚀 Up next: Deploying and Managing Apps on macOS with Intune!

Want to Stay Updated?

🔹 Follow this blog for more Intune macOS management tips!
🔹 Leave a comment if you have any questions!

That is it for now. Until next time. 👋

In Part 1, we covered the basics of macOS management in Intune. Now, let’s focus on how to enroll macOS devices into Intune using three different methods.

Depending on whether the device is corporate-owned or BYOD (Bring Your Own Device), Microsoft Intune offers three primary enrollment methods:

1. Automated Device Enrollment (ADE) – Best for corporate-owned devices, requires Apple Business Manager (ABM).

2. Device Enrollment (Manual) – For company-owned or personal devices without ABM.

3. User Enrollment (BYOD) – Ideal for employees bringing their own macOS devices.

Understanding macOS Enrollment Methods

Enrollment Method Best For Requires Apple Business Manager? Management Level Automated Device Enrollment (ADE) Corporate-owned devices ✅ Yes Full control (Supervised) Device Enrollment (Manual) Any device ❌ No Full control User Enrollment (BYOD) Personal devices ❌ No Limited control (Work profile only)

Prerequisites for macOS Enrollment

Before enrolling macOS devices, ensure you have the following:

✅ General Requirements

✔ Microsoft Intune License (included in Microsoft 365 E3/E5 or as a standalone license)
✔ Apple MDM Push Certificate configured in Intune
✔ Apple Enrollment Program Token configured in Intune
✔ Company Portal App installed on macOS devices (required for User Enrollment)

🏢 For ADE (Automated Device Enrollment):

✔ Apple Business Manager (ABM) account
✔ macOS devices linked to ABM, either via reseller or manual via the Configurator 2 app

Method 1: Automated Device Enrollment (ADE) via Apple Business Manager

In this blog post, I am assuming that you already have an active Apple Business Manager and thus have already made the connection between ABM and Intune. If you haven't done so yet, check out this Microsoft Learn article on how to accomplish this.

Step 1: Deploy Enrollment Profile

1. In Intune, go to Devices -> macOS -> Enrollment -> Enrollment Program Tokens

2. Select your Token name and go to Profiles

3. Click on Create Profile and select macOS

4. Give the enrollment profile a name

5. Configure:

   • User Affinity: Enroll with user affinity

   • Authentication method: Setup assistant with modern authentication

   • Await final configuration: Yes

   • Locked enrollment: Yes

6. Configure:

   • Department: Fill in a department

   • Department Phone: Fill in a number

   • Setup Assistant Screend: Choose the screens which you want to show to the end-user. For more detailed information about these setup screens, go to the Setup Assistant screen reference.

7. Configure:

   • Create a local primary account: Yes

   • Prefill account info: Yes

8. Click on Create

9. Click on Default profile and select under the macOS Enrollment Profile, the newly created profile.

Step 2: Turn on the macOS Device and Enroll

• When a new or wiped macOS device starts up, it will automatically enroll in Intune

• The user logs in with their Entra ID credentials

• Policies, apps, and configurations are pushed from Intune

✅ Best for: Corporate-owned, fully managed macOS devices

🎥 Below is a recording of an enrollment of a macBook with ADE. 👇

Method 2: Device Enrollment (Manual Enrollment)

For corporate or personal devices that are not in Apple Business Manager, use manual enrollment.

Step 1: Enable "Personal" Device Enrollment in Intune

1. In Intune Admin Center, go to Devices > macOS > Enrollment > Device Platform Restrictions

2. Ensure that Personally owned devices is allowed

💡

Key takeaway: It's better to add the serial number of the macOS device as a corporate identifier, so BYOD is still blocked. Using corporate device identifiers in Intune enables automatic enrollment, ensures only authorized company devices can register, and streamlines zero-touch deployment (e.g., Autopilot). Common identifiers include serial numbers, IMEI, and hardware hashes.

Step 2: Install the Company Portal App

3. The user downloads Microsoft Intune Company Portal via https://aka.ms/EnrollMyMac

4. Launch the Company Portal and sign in with their Entra ID credentials

Step 3: Install the MDM Profile

5. The user will be prompted to install the MDM profile

6. Open System Settings -> General -> Profiles, and approve the MDM profile

7. Once installed, the Mac will start receiving Intune policies

✅ Best for: Non-ABM corporate-owned devices or personal Macs

Method 3: User Enrollment (BYOD)

For employees using their personal Macs, User Enrollment provides a work-only profile with limited control.

Step 1: Enable User Enrollment in Intune

1. In Intune Admin Center, go to Devices > macOS > Enrollment > Device Platform Restrictions

2. Ensure that Personally owned devices is allowed or use the corporate identifiers.

Step 2: Install the Company Portal App

3. The user downloads Microsoft Intune Company Portal at https://aka.ms/EnrollMyMac

4. Signs in with their Entra ID credentials

5. The user will be prompted to install the MDM profile

6. Open System Settings -> General -> Profiles, and approve the MDM profile

Step 3: Manage Work Apps and Policies

• Only work-related apps and policies will be managed

• The user's personal data remains untouched

• IT can enforce work-related security policies

✅ Best for: Employee-owned devices (BYOD)

Verifying and Managing Enrolled macOS Devices

Checking Enrollment Status in Intune

1. In Intune Admin Center, go to Devices > macOS

2. Click on the device name to check enrollment status

3. Ensure it shows Compliant / Enrolled

Applying Compliance and Configuration Policies

• Go to Devices > macOS > Compliance policies

• Create and assign policies for passwords, encryption, firewall, etc.

• Deploy configuration profiles for Wi-Fi, VPN, certificates

Next Steps

Now that your macOS devices are enrolled in Intune, you can:

• Configure security policies (FileVault, password enforcement)

• Deploy applications (PKG, DMG, Mac App Store)

• Monitor compliance and reporting

🚀 Up next: Managing macOS Security and Compliance in Intune

Want to Stay Updated?

🔹 Follow this blog for more Intune macOS management tips!
🔹 Leave a comment if you have any questions!

That is it for now. Until next time. 👋

As more businesses adopt Apple devices, IT administrators need an efficient way to manage and secure macOS machines. Microsoft Intune, a cloud-based MDM (Mobile Device Management) solution, allows organizations to:

✅ Enforce security policies on macOS devices (e.g., password rules, encryption)
✅ Deploy applications remotely
✅ Ensure compliance with organizational policies
✅ Monitor and troubleshoot macOS devices

Unlike traditional on-prem solutions like Active Directory GPOs, Intune is cloud-based, making it ideal for modern, distributed workforces.

What is Microsoft Intune?

Microsoft Intune is part of the Microsoft Endpoint Manager (MEM) suite. It provides IT admins with a centralized way to manage and secure devices across different platforms, including Windows, macOS, iOS, and Android.

With Intune, you can:

• Configure security policies (passwords, encryption)

• Deploy and manage macOS applications

• Ensure compliance with company policies

• Automate tasks with scripts and policies

How is macOS Management in Intune different from Windows?

Many IT pros are familiar with Windows management in Intune, but macOS works differently. Here’s a comparison:

Feature Windows macOS Enrollment Azure AD Join, Hybrid Join, Autopilot Apple Business Manager (ABM), User Enrollment, Device Enrollment App Deployment EXE, MSI, Microsoft Store PKG, DMG, Mac App Store Security & Compliance BitLocker, Defender for Endpoint FileVault, Defender for Endpoint Configuration GPOs, CSPs, PowerShell scripts Configuration Profiles, Shell scripts Remote Management Full remote control Full remote control, Remote wipe (only supervised)

Prerequisites for macOS Management in Intune

Before enrolling macOS devices, ensure you have the following:

1. Microsoft Intune License – Included in Microsoft 365 E3/E5 or as a standalone license.

2. Apple Business Manager (ABM) or Apple School Manager (ASM) – Needed for Automated Device Enrollment (ADE).

3. Apple MDM Push Certificate – Required to allow Intune to communicate with Apple devices.

4. Apple Enrollment Program Token - Required for remote management.

5. Intune Company Portal App – Needed for user-driven enrollments.

6. A macOS device running macOS 11 (Big Sur) or later – Recommended for full compatibility.

What You Can and Cant Do with macOS in Intune

✅ What Intune Can Do:

• ✔ Enforce security settings (password policies, encryption)

• ✔ Deploy applications (PKG, DMG, Mac App Store apps)

• ✔ Configure Wi-Fi, VPN, and certificates

• ✔ Enforce compliance policies (OS version, encryption, etc.)

• ✔ Deploy shell scripts for advanced configurations

• ✔ Local Admin Password Solution (LAPS)

🚫 What Intune Can’t Do (Yet):

• ❌ Custom compliance policy

• ❌ Remediation scripts

While Intune provides solid macOS management, it’s not as advanced as dedicated Apple MDMs like Jamf.

Next Steps: Getting Ready for macOS Enrollment

Now that you understand the basics, it’s time to prepare for macOS enrollment. In the next post, we’ll cover how to enroll macOS devices in Intune using:

• Automated Device Enrollment (ADE)

• User Enrollment (BYOD)

• Device Enrollment (manual method)

Want to Stay Updated?

🔹 Follow this blog for more Intune macOS management tips!
🔹 Leave a comment if you have any questions!

🚀 Up next: How to Enroll macOS Devices in Intune – A Step-by-Step Guide

That is it for now. Until next time. 👋