Modern EUC by Wayne Bellows

Author: Wayne Bellows

  • How to run Azure Virtual Desktop with cloud-only and external identities using FSLogix

    How to run Azure Virtual Desktop with cloud-only and external identities using FSLogix

    If you’ve ever tried to stand up Azure Virtual Desktop in a properly cloud-native tenant, with no on-premises Active Directory and no Entra Domain Services, you’ll know where it falls over. Not the session hosts. Not the networking. The profiles.

    FSLogix has needed some form of Active Directory for years, which made it the one component that kept dragging a “cloud-only” AVD design back towards a domain controller. That’s now changed. FSLogix profile containers on Azure Files can authenticate with Microsoft Entra Kerberos, which means cloud-only users, and even external guest users, can get a real, persistent profile with no domain controller anywhere in the picture.

    This post covers how to set that up end-to-end. It also covers the part that isn’t in the announcement posts: a Windows Kerberos hardening change landing in 2026 that can break FSLogix profile access on Active Directory-integrated storage, including shares you built years ago. It’s a good reason to understand the cloud-only path, because that path sidesteps the whole problem. Read that section before you touch production.

    The problem cloud-only AVD always hit

    FSLogix works by redirecting the user’s profile into a VHD(X) container on an SMB file share, then attaching it at sign-in. On a pooled host pool, that’s what gives a user the same desktop, settings, and Outlook cache on whichever session host they land on.

    The catch was always authentication to that file share. Azure Files historically required on-premises AD DS or Entra Domain Services to handle the Kerberos side. In a tenant that had neither, your options were ugly: stand up Entra Domain Services purely to host profiles, or accept that cloud-only and guest users got a fresh temporary profile every session. No roaming, no persistence, no cached sign-ins. For a genuinely cloud-first organisation, that was the line item that stopped the whole design from being clean.

    What Entra Kerberos changes

    Microsoft Entra Kerberos lets Entra ID issue the Kerberos tickets needed to reach an Azure Files share over SMB, without any domain controller involved. Applied to FSLogix, which unlocks three identity types on Azure Files:

    • Hybrid identities from Entra joined, or Entra hybrid joined session hosts, with no network line-of-sight to a domain controller. Supported in Azure commercial, Azure for US Government, and Azure operated by 21Vianet.
    • Cloud-only identities (users who only exist in Entra ID and never in an on-premises AD).
    • External identities (B2B guests invited into your tenant).

    The cloud-only and external paths are supported in the Azure commercial cloud only. If you’re running in US Gov or 21Vianet, only the hybrid path is available to you, so don’t design around cloud-only profiles there.

    The practical upshot: a pure Entra-joined session host can now load a persistent FSLogix profile for a user who has never existed in an on-premises directory. That’s the missing piece for cloud-native AVD, and it’s genuinely useful for any estate that hands desktops to contractors or partners as guests.

    Read this first: the RC4 to AES-SHA1 change

    Here’s the bit that isn’t in the launch coverage, and the reason I’d check your existing estate before building anything new.

    Starting with the April 2026 Windows cumulative update, Kerberos default behaviour changes. When an Active Directory object’s encryption type is left unset (null), Windows defaults to AES-SHA1 instead of the legacy behaviour that often landed on RC4. This is a Windows platform security change tied to CVE-2026-20833, and to be clear, the Azure Virtual Desktop service itself isn’t being modified.

    The thing to understand is what’s actually in scope. This affects FSLogix profile storage that authenticates over SMB integrated with Active Directory: on-premises AD, a NAS, a file server, or Azure Files joined to AD DS, where the relevant AD objects or service accounts are RC4-only or have encryption left null. If a dependent system doesn’t support AES-SHA1 for Kerberos, authentication can fail, and profiles can stop loading.

    Notice what’s not on that list: a pure Entra Kerberos, cloud-only share. Entra Kerberos isn’t AD Kerberos, so by the mechanism described, the cloud-only path in this post sidesteps this particular change. The deployments most exposed are the older, domain-joined FSLogix shares, exactly the ones a cloud-native design is trying to move away from. If you’re migrating off a hybrid AD DS setup, the legacy share is the thing to remediate before you decommission it.

    One caveat on that, because the two Microsoft sources don’t word it identically. The FSLogix product documentation states the warning more broadly: file shares hosting FSLogix containers that aren’t upgraded to AES-SHA1 might have access issues, and customers who have already moved to AES-SHA1 aren’t affected. The detailed hardening blog is the one that ties the actual mechanism to AD object encryption and AD-integrated SMB storage. I read the technical scope as AD-Kerberos paths, which is why I’m calling out the domain-joined shares specifically, but the safe operational rule Microsoft is pushing is simpler: make sure any Azure Files share holding FSLogix profiles is on AES-SHA1, and validate it, rather than assuming you’re exempt. If you’re not certain which Kerberos path a given share uses, treat it as in scope and check.

    The timeline matters. From April 2026, enforcement mode is the default on domain controllers, with audit mode available as a manual rollback until July 2026. From July 2026, audit mode is removed, and enforcement is the only option. Microsoft recommends remediating by the end of June 2026, especially for non-Azure Files SMB storage and Azure Files with AD DS.

    So before anything else: identify RC4 usage and null encryption settings on the AD objects tied to your FSLogix storage, move them to AES-SHA1, and validate sign-in and profile load end-to-end. Microsoft’s FSLogix blog (“Action required: Windows Kerberos hardening (RC4) may affect FSLogix profiles on SMB storage”) is worth ten minutes before any of the steps below.

    Setting it up: the storage account

    With that warning logged, here’s the build. Start with the Azure Files side.

    First, a constraint that catches people out: a storage account can authenticate with one identity method only. Entra Kerberos, or AD DS, or Entra Domain Services, not a mix. If your account is already wired to AD DS for an existing share, you can’t bolt Entra Kerberos onto the same account.

    The sequence on the storage account is:

    1. Create the storage account and an Azure Files share for the profiles, if you don’t already have them.
    2. Enable Microsoft Entra Kerberos authentication on the storage account. This creates the Entra ID app registration for the account and lets you assign permissions to Entra groups.
    3. Assign share-level permissions, either through the default share-level permission on the identity source page or with Azure RBAC roles.
    4. Configure the directory and file-level permissions for the profile containers, following Microsoft’s recommended FSLogix permission set, so users can create and use their own profile while admins retain management access. For cloud-only and external users, you do this through the Manage access control on the share.
    5. Grant admin consent to the new service principal, so users can request Entra tokens for the storage account.
    6. Disable multifactor authentication on the storage account.

    That last one always raises an eyebrow, so it’s worth being clear about why. The Kerberos ticket is acquired silently during sign-in, and there’s no interface at that point to perform a step-up MFA prompt. If MFA is enforced on the storage account, the silent ticket request fails, and the profile won’t mount. You’re not weakening user sign-in MFA here; Conditional Access on the user still applies. You’re allowing the storage account’s own token acquisition to complete without a step-up, it has no way to satisfy.

    Setting it up: the session host

    Now the session host. The profile won’t attach until the host knows to fetch a cloud Kerberos ticket at logon.

    Enable CloudKerberosTicketRetrievalEnabled using whichever of these fits your management approach:

    • Intune Settings Catalog (the modern route): the Kerberos Policy CSP setting CloudKerberosTicketRetrievalEnabled. Worth noting that Windows multi-session client editions now support this setting when it’s applied through the Settings Catalog, which wasn’t always the case.
    • Group Policy: Administrative Templates\System\Kerberos\Allow retrieving the cloud kerberos ticket during the logon.
    • Registry, if you’re baking it into an image:
    reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1

    Next, let the FSLogix credential keys roam. When you use Entra ID with a roaming profile, the Credential Manager keys have to belong to the profile that’s currently loading, otherwise you’re effectively pinned to one machine. Set:

    reg add HKLM\Software\Policies\Microsoft\AzureADAccount /v LoadCredKeyFromProfile /t REG_DWORD /d 1

    Then the FSLogix configuration itself. If your session hosts were built by the Azure Virtual Desktop service, FSLogix is already installed. Set the usual two values:

    • Enabled = 1
    • VHDLocations = \\<storage-account-name>.file.core.windows.net\<file-share-name>

    Sign in with a test account that’s been assigned to an app group on the host pool and has permission to the share. If it’s worked, you’ll see a directory on the share named like <user SID>_<username>. Use a fresh test account, or enable DeleteLocalProfileWhenVHDShouldApply, so an existing local profile doesn’t mask whether the container is actually mounted.

    The cloud-only step everyone misses

    If your users are cloud-only and you assign share access by Entra group, there’s one more step that is easy to skip and fails silently when you do.

    You have to add an app manifest tag to the storage account’s Entra app registration so that Entra includes cloud-only group SIDs in the Kerberos ticket. Without it, Entra only puts on-premises group SIDs in the ticket; your cloud-only groups never appear, and group-based permissions to the share simply don’t take effect. No error that points to the cause, just access that doesn’t work.

    In the app registration manifest, add kdc_enable_cloud_group_sids to the tags array. This step is mandatory for cloud-only identities. Hybrid identities don’t need it, which is exactly why it catches people moving from a hybrid design to a cloud-only one. The thing that worked before now quietly doesn’t, and the difference is one manifest tag.

    External identities: real, but mind the preview line

    External (guest) identity support is the newest part of this story, and it’s worth being precise about what’s actually shipped. Connecting to Azure Virtual Desktop and Windows 365 with an external identity is generally available. Using FSLogix to give those external identities a persistent profile is still in public preview.

    That distinction matters if you’re planning a rollout. A contractor can sign in to your AVD environment today on a fully supported path. Giving them a roaming FSLogix profile that follows them across session hosts is the preview part, so treat it accordingly: pilot it with a small guest cohort, don’t promise it in a contract yet.

    A few requirements specific to external identities are easy to miss. Microsoft Entra single sign-on must be configured for the connection. The session host has to be Entra joined and running Windows 11, version 24H2 or later with the September 2025 cumulative update (KB5065789) or newer. And for Azure Virtual Desktop, you also have to assign the Virtual Machine User Login Azure RBAC role to the external identity on the VMs they’ll sign in to, which you don’t have to think about for your own member users. It’s commercial-cloud only, like the cloud-only path.

    Wrapping up

    Cloud-only and external identity support for FSLogix removes the last real reason a cloud-native AVD design had to drag a domain controller, or Entra Domain Services, along for the ride. For genuinely cloud-first organisations, that’s a meaningful simplification, and for anyone serving guests, it opens a door that used to be shut.

    Just sequence it correctly. If you’ve still got legacy FSLogix storage joined to AD DS, sort out the RC4 to AES-SHA1 migration on it before the Windows enforcement deadlines force the issue, because that’s the part that affects deployments you’ve already got running. The cloud-only Entra Kerberos path you’re building towards doesn’t carry that particular baggage, which is one more reason to make the move. And if your use case is external guests, remember the FSLogix profile piece is still in preview, so pilot before you promise.

    If you’re running cloud-only AVD already, or about to, I’d genuinely like to know how the external-identity profiles are holding up for you. Drop a comment.

  • Context-Based Redirection in Azure Virtual Desktop and Windows 365: A Practical Guide

    Context-Based Redirection in Azure Virtual Desktop and Windows 365: A Practical Guide

    For years, redirection in end-user computing has been a light switch. Clipboard redirection: on or off. Drive redirection: on or off. Printer and USB: same deal. You set it at the host pool or the Cloud PC, and that was the experience for every user, on every device, from everywhere.

    That made sense when “everywhere” meant the office and maybe a corporate laptop at home. It makes a lot less sense now. The same user connects from a managed, compliant laptop in the morning and a personal tablet on the train an hour later. One policy can’t tell the difference, so you end up choosing: lock everything down and annoy people on trusted devices, or open things up and accept the data leakage risk on the ones you don’t control.

    Microsoft’s answer is context-based redirection, now in public preview for Azure Virtual Desktop and Windows 365. This post covers what it is, why it’s worth your attention, and the exact steps to configure it for both platforms, including the gotchas that’ll trip you up if you go in cold.

    What context-based redirection actually changes

    The shift is small to describe and big in practice. Instead of asking “should clipboard redirection be allowed?”, you can now ask “should clipboard redirection be allowed for this session?” — where the session carries context like who the user is, whether their device is compliant, and where they’re connecting from.

    It works by tying a redirection setting to a Microsoft Entra authentication context, which in turn is governed by a Conditional Access policy. The Conditional Access policy is where the actual decision lives: require a compliant device, require a trusted location, whatever your risk appetite calls for. The redirection setting just points at that context and says, “follow those rules.”

    The four redirections you can control this way today are:

    • Clipboard
    • Drive
    • Printer
    • USB

    So a managed, compliant device connecting from a known location can get full clipboard and drive redirection, while the same user on an unmanaged personal device gets neither. Same user, same host pool, different trust, different experience. That’s the whole point.

    Why you’d actually use it

    The honest answer is data leakage control without the usual usability tax.

    Most organisations that care about data exfiltration end up blocking clipboard and drive redirection outright, because the alternative is trusting every endpoint equally. Context-based redirection lets you stop punishing your well-managed estate for the existence of BYOD. Compliant devices get a frictionless experience; everything else gets the locked-down one. You’re matching the control to the actual risk of the session rather than the lowest common denominator.

    It’s the same Zero Trust thinking that’s already shaping authentication, finally applied to device redirection. Less static policy, more dynamic trust.

    Before you start: prerequisites and one big gotcha

    A few things need to be true before any of this works.

    You need Microsoft Entra ID Premium (P1 or P2). Authentication contexts and Conditional Access policies are premium features. If your tenant has no premium licences, the “New authentication context” button is simply greyed out and you’ll go no further. Worth checking first, under Entra ID > Licenses, before you waste twenty minutes.

    It’s still rolling out. This is public preview, and the configuration options are appearing tenant by tenant. If you open your host pool’s RDP properties and don’t see the new dropdown option yet, you’re not doing anything wrong; it just hasn’t reached you. Keep checking back.

    The most restrictive policy wins. This is the one that’ll catch you. If you already manage redirections through other Intune settings or Group Policy, those existing policies can override your context-based configuration, because Windows applies the most restrictive setting. Before testing, set the redirections you want to control to Not configured or Enabled in any existing policies. Otherwise, you’ll configure everything correctly, test it, see nothing change, and lose an afternoon working out why.

    Step 1: Create the authentication context and Conditional Access policy

    This part is identical for both AVD and Windows 365. You’re building the rule that everything else points at.

    1. Sign in to the Azure Portal and search for Microsoft Entra Conditional Access.
    2. Go to Manage > Authentication contexts.
    3. Select New authentication context.
    4. Give it a name and description, something you’ll recognise later, like Compliant devices — full redirection.
    5. Tick Publish to apps and pick a value from the ID dropdown.
    6. Select Save.

    Now, create the Conditional Access policy that gives the context its meaning:

    1. Still in Conditional Access, go to Policies and select New policy.
    2. Name it clearly.
    3. Under Users or agents, include All users (scope this to a pilot group while you test).
    4. Under Target resources, change the dropdown to Authentication context and select the context you just created.
    5. Under Grant, choose Grant access and tick Require device to be marked as compliant, then select.
    6. Set Enable policy to On and select Create.

    That’s the trust decision defined. Compliant device, access granted to the context; non-compliant, denied. Everything downstream now inherits that logic.

    Step 2 (AVD): Map the context in host pool RDP properties

    For Azure Virtual Desktop, the mapping happens at the host pool level, so it applies to every session host in that pool.

    1. In the Azure Portal, search for Azure Virtual Desktop and open it.
    2. Select Host pools and choose your host pool.
    3. Open RDP Properties, then the Device redirection tab.
    4. Find the redirection you want to control — say, Clipboard redirection.
    5. In its dropdown, select Dynamically configure using authentication context.
    6. An Authentication context selector appears. Choose the context from Step 1.
    7. Select Save.

    Repeat for any of the other three redirections you want governed the same way. The Device redirection tab is also where you’ll confirm the preview has reached you: if the dropdown only offers the old static choices (available / isn’t available / not configured), the dynamic option hasn’t rolled out to your tenant yet.

    Step 2 (Windows 365): Map the context in Intune

    For Cloud PCs, the mapping lives in Intune through a Remote Connection Experience policy.

    1. In Intune, go to Devices > Manage Windows 365 Cloud PCs > Cloud PC Settings.
    2. Select Create > Remote Connection Experience (preview).
    3. Give it a name and description.
    4. Under Configuration settings > Device redirections, find your target redirection and select Authentication context: Context-based redirection.
    5. Choose your authentication context in the selector that appears.
    6. Set any scope tags, then move to Assignments.

    This is the second gotcha worth burning into memory: assign the Remote Connection Experience policy to device groups (your Cloud PCs), not user groups. Context-based redirection for Windows 365 is enforced at the device level. Assign it to users, and it simply won’t apply. Finish with Review + create.

    Step 3: Validate it works

    Testing needs two devices at different trust levels, which is the only honest way to prove it’s working.

    1. Connect from a managed, compliant device that satisfies your Conditional Access policy. Confirm the configured redirections are available in the session.
    2. Connect to the same host pool or Cloud PC from a BYOD or non-compliant device. Confirm the redirections are restricted or gone.

    If the behaviour isn’t what you expect, work through this list before assuming the feature is broken:

    • Check the Conditional Access policy assignment and the authentication context configuration.
    • Check the device’s compliance status in Microsoft Entra ID / Intune.
    • Check the host pool RDP property (AVD) or the Remote Connection Experience policy assignment (Windows 365).
    • Check for any existing redirection policy that might be overriding it — remember, most restrictive wins.

    That last point is, nine times out of ten, the culprit.

    Where this fits

    Context-based redirection won’t change your architecture, but it does close a gap that’s been awkward for a long time: the gap between “trust this endpoint completely” and “trust it not at all.” Most real estates live somewhere in the middle, and until now, the tooling didn’t.

    It’s preview, so treat it as preview — pilot it, don’t roll it across production on day one, and keep an eye on the docs as the configuration surfaces light up across tenants. But it’s the kind of incremental, sensible control that’s genuinely useful the moment it lands. If you run Azure Virtual Desktop or Windows 365 and you’ve ever had the BYOD-versus-data-leakage argument, this is one to test.

    Found this useful? I’d be interested to hear how you’re approaching device trust in your own EUC estate — drop a comment.

  • Microsoft Just Packaged Azure Expertise into a Plugin. Here’s What It Means for AVD Admins.

    Microsoft Just Packaged Azure Expertise into a Plugin. Here’s What It Means for AVD Admins.

    Picture a normal AVD admin morning. A user can’t connect. You want to know which session host they’re on, whether that host is even healthy, how many other people are sharing it, and whether the host pool has spare capacity. None of that is hard. But answering it means a portal tab for the host pool, another for the session hosts, a PowerShell window for the session list, and possibly Cost Management in a fourth tab to check you’re not bleeding money on hosts nobody is using.

    Microsoft now has an answer to that, and it’s bigger than I expected. The Azure Skills Plugin, released in beta earlier this year and currently sitting at version 1.1.48, packages curated Azure expertise, the Azure MCP Server and the Foundry MCP server into a single install. You can drop it into Claude Code, GitHub Copilot, VS Code, the Copilot CLI or Cursor. One package, about a minute to install, and your AI agent suddenly knows how Azure work actually gets done.

    What the Azure Skills Plugin actually is

    Microsoft frames the launch this way: “Azure work is not just a code problem. It is a decision problem: which service fits this app, what needs to be validated before deployment, which tools should run, and what guardrails matter.”

    That’s a useful sentence, because it gets at what’s been missing. The Azure MCP Server, on its own, gives an agent the hands to operate Azure. 200+ tools across 40+ services, all callable through the Model Context Protocol. But hands without a brain produce confident nonsense. The agent can run a Resource Graph query, but it doesn’t know which query, or what to do with the result, or which guardrail you’d want checked first.

    The Azure Skills Plugin bundles three things into one install to fix that:

    • The skills layer. 19+ curated Azure skills covering build and deploy (azure-prepare, azure-validate, azure-deploy), troubleshoot and monitor (azure-diagnostics, azure-resource-lookup, azure-quotas), optimise (azure-cost, azure-compute, azure-resource-visualizer) and cross-domain work (azure-rbac, azure-storage, entra-app-registration). This is the expertise layer. Workflows Microsoft engineers actually use.
    • The Azure MCP Server. The 200+ tools that do the real work. The same server I’d previously have written about on its own.
    • The Foundry MCP server. Extra tools for Microsoft Foundry scenarios like model discovery and deployment. Less relevant for AVD work, but it’s in the box.

    Microsoft is explicit that this “is not a prompt pack. It is a packaged Azure capability layer”. The distinction matters. Prompt packs make an agent sound informed. This makes an agent actually competent at a set of Azure tasks, because the skills know what to check, in what order, and what tools to call.

    A note for anyone nervous about pointing this at production. Authentication is Entra ID, and every call runs in the context of the signed-in user, bound by Azure RBAC. The agent can’t do anything you couldn’t do yourself in the portal. If your account is read-only on a subscription, so is the agent.

    The part that matters for EUC

    The honest bit first: there is no dedicated AVD skill in the bundle today. The 19 curated skills are organised around general Azure work like cost, deployment and diagnostics, not the AVD lifecycle specifically. But the Azure MCP Server underneath does ship a dedicated Azure Virtual Desktop tool namespace, virtualdesktop, and it currently does three things, all of them about visibility:

    • List host pools in a subscription or resource group
    • List session hosts in a host pool
    • List user sessions on a specific session host

    So with the plugin installed you can type things like:

    “Show me all host pools in my subscription.”

    “List the session hosts in the production-hostpool host pool.”

    “What users are connected to session host avd-prod-04 in host pool production-pool?”

    You get a straight answer in the chat panel, with no portal navigation and no pausing to remember whether it’s Get-AzWvdSessionHost or Get-AzWvdUserSession this time.

    The AVD surface today is mostly a window onto your estate rather than a control panel for it. The agent can see everything: every host pool, every session host, who’s logged in where. It can also stop and start session hosts, since those are just virtual machines underneath. What it can’t do is the AVD lifecycle work you’d actually reach for, like draining a host before patching, signing out a stuck session, or scaling a pool up before Monday morning. None of that has shipped yet.

    That sounds like a limitation, and it is. But read-first is the right order. An AI agent with unattended write access to your session hosts is a genuinely bad failure mode, and “show me my estate accurately” is the capability you’d want to trust before any other.

    Where it gets useful: skills working together on your AVD estate

    The three AVD tools on their own are convenient. The reason the plugin format matters is what happens when the skills layer pulls those tools together with everything else.

    Take the questions you actually want answered about an AVD estate:

    • “Which session host VMs are running right now but have zero user sessions?” That’s an idle-capacity question, and idle capacity is wasted money. Without the plugin, an agent would need you to spell out the join between the virtualdesktop tools and the VM power state. With azure-cost and azure-resource-lookup in the picture, it knows to do that, and to express the answer in money rather than VM IDs.
    • “List every session host VM across all my subscriptions that isn’t on the current image version.” That’s a drift question. The azure-resource-lookup skill is built around exactly this pattern of Azure Resource Graph queries.
    • “Show me the monthly cost of each resource group that contains a host pool.” azure-cost plus the AVD tools, and it’s the question finance keeps asking you, answered in one sentence.
    • “Do any of my session host VMs have RDP open to the internet?” azure-compliance plus azure-rbac plus the VM tooling, and the answer is a list rather than an audit project.

    The point isn’t any one of these queries. It’s that the skills know which checks belong together, which tools to call, and what good output looks like. That’s the gap a raw MCP server leaves, and that’s the gap this plugin fills.

    This matters for AVD because the estate is rarely just AVD. A session host is a VM, behind a NIC, on a vNet, with a managed identity, pointed at an FSLogix storage account, scaled by an Automation Account, monitored by Log Analytics. Asking sensible questions about it means asking sensible questions across half a dozen Azure services. That’s exactly the surface area the skills cover.

    Bonus: turning a question into a diagram, for free

    One skill in the bundle is worth calling out on its own: azure-resource-visualizer. Ask the agent to “analyse this session host and show how it connects to the rest of the infrastructure” and you get back a real architecture diagram of the live environment: the VM, its NIC, the vNet, the public IP, the FSLogix storage account, the managed identity and what it can reach.

    For AVD that’s quietly valuable. Architecture documentation for a virtual desktop estate is almost always missing or badly out of date. Being able to regenerate an accurate diagram of a host pool and everything around it, on demand from the live environment, makes an audit or a handover meaningfully less painful. Previously you’d have wired up a separate community-built draw.io MCP server to get this. Now it’s just a skill in the box.

    Setting it up

    This is the part where the plugin format earns its keep. Setup is genuinely a minute. You install once, and the same package runs across whichever agent host you’re using: VS Code with GitHub Copilot, Claude Code, the Copilot CLI, Cursor, Gemini CLI, Codex CLI or IntelliJ. No separate config per tool, no duplicated setup work if your team uses more than one agent.

    For my Claude Code setup it was a single install command and a sign-in prompt the first time an Azure tool ran. The agent then operates as me, against my Entra ID, with my RBAC. Nothing else to configure. No service principal, no secret to store, no separate permissions to manage.

    Microsoft’s documentation has the current step-by-step for each host. Given this is beta, treat the docs as the source of truth rather than anything I’d write here.

    Where this fits, and where it doesn’t

    A few honest caveats, because this is a personal blog and not a product page.

    It’s beta and moving fast. The plugin is on its ninth release in a few months, and the MCP server underneath is on 3.0.0-beta.11 for a reason. Tools and skills are being added and changed release to release. Don’t build a process around a specific skill name until things settle.

    It’s a developer-side tool. Microsoft is explicit that this is intended for developer and admin use within your organisation, not for external applications or as a production automation backbone. It’s a smarter way to interact with Azure from your editor. It is not an unattended automation platform.

    There is no AVD-specific skill yet. The plugin gets you the virtualdesktop MCP tools and a lot of useful cross-domain skills around them, but the AVD lifecycle work (draining, scaling, image management) isn’t expressed as a curated skill. It’s the obvious next gap.

    And for AVD specifically, the actual AVD surface is read-only today. It will tell you about your estate. It won’t run your estate. It doesn’t replace whatever management layer, scaling automation or operational tooling your team already relies on to keep host pools healthy. It’s a fast way to ask questions. It sits alongside your existing tools, not on top of them.

    None of that makes it less interesting. It just means you should be precise about what it is.

    The takeaway

    The headline isn’t “AI now runs your AVD estate”. It doesn’t, and you wouldn’t want it to yet. The smaller, more useful headline is this: the distance between having a question about your Azure estate and having a sensible answer just got a lot shorter. And Microsoft’s curated Azure expertise now travels with your agent, whichever one you use.

    For an AVD admin, that distance has always been measured in portal tabs and half-remembered PowerShell. Swap that for a plain-English question, answered in the editor you already work in, against the permissions you already have. That’s a real quality-of-life improvement, even in a read-only beta.

    Read-only is where it starts. Deployment and validation skills already sit in the same plugin. The direction of travel is fairly obvious.

    Found this useful? Share it with whoever owns your AVD estate.

    Wayne Bellows is a Technical Account Manager at Nerdio. He writes about Azure Virtual Desktop, Windows 365, Intune and the EUC industry at modern-euc.com.

    Further reading

  • AVD-Assess: a free, open-source Well-Architected health check for Azure Virtual Desktop

    AVD-Assess: a free, open-source Well-Architected health check for Azure Virtual Desktop

    The Well-Architected Framework for Azure Virtual Desktop is genuinely good documentation. Five pillars, dozens of concrete recommendations, all the right guidance on scaling plans, FSLogix redundancy, Trusted Launch, Private Link, and the rest. If you run AVD at any scale, you’ve probably read it at least once.

    So why do so many AVD estates still drift away from it?

    The problem was never the guidance. It’s that turning a framework into an actual answer for your environment has, until now, meant one of three things: pay for a commercial assessment tool, sit through a manual review where someone clicks around the portal for a day, or (let’s be honest) do nothing and hope the next outage isn’t the one the framework warned you about.

    I got tired of that gap, so I built something to close it. This post is what it is, the problem it solves, and how it works under the bonnet.

    The problem, stated plainly

    A framework is a checklist you have to apply yourself. The WAF for AVD tells you that pooled host pools should have a scaling plan, that multi-session hosts want Premium SSD, that public network access on a host pool is rarely necessary in an enterprise with site-to-site connectivity. All true. All useful.

    But “apply this 80-page framework to a five-subscription estate, by hand, every quarter” is not a realistic ask for a team that already has a day job. The guidance is free; the act of operationalising it isn’t. That’s the bit that was missing: a free, automated way to take the framework and produce an answer you can act on and hand to a sponsor.

    What AVD-Assess actually is

    AVD-Assess is a single PowerShell script. You point it at a subscription, it connects, reads your AVD environment, runs 25 best-practice checks across all five WAF pillars (Cost, Reliability, Security, Operational Excellence, and Performance Efficiency), then writes a self-contained HTML report with traffic-light scoring and specific remediation for every finding.

    No agent. No install beyond the Az modules you almost certainly already have. Nothing leaves your tenant. It’s MIT-licensed and lives on GitHub. A run takes about five minutes.

    The part I care about most is that every finding is specific. Not “consider reviewing your scaling plans”. Instead:

    0 of 5 pooled host pool(s) have a scaling plan. Uncovered: Ar-TEST1, CS-Multisession, QKEntra, RF-EntraIDOnly, RF-MultiSession.

    followed by exactly what to do about it and a link to the relevant Microsoft Learn article. A finding you can’t act on isn’t a finding. It’s a feeling.

    How it works

    The flow is deliberately boring, because boring is reliable:

    # One-time: install the modules
    Install-Module Az.Accounts, Az.DesktopVirtualization, Az.Compute, Az.Monitor, `
      Az.Resources, Az.Network, Az.Storage, Az.Security -Scope CurrentUser
    git clone https://github.com/waynebellows/AVD-Assess.git
    cd AVD-Assess
    ./AVD-Assess.ps1 -OpenReport

    It signs you in, or reuses your existing context with -UseExistingConnection, which is handy in Azure Cloud Shell where you’re already authenticated. It then collects everything up front: host pools, session hosts, VMs, NICs, disks, diagnostic settings, Defender pricing, private endpoints. Every check reads from that one snapshot rather than making its own calls, so a run is consistent and doesn’t hammer the API.

    Permissions are intentionally modest. Reader on the subscription covers the bulk of it. Two checks want a little more scope (Defender for Cloud coverage and Service Health alerts), and if they don’t have it, they degrade to an informational result rather than failing the run. A tool that needs Owner to tell you about your scaling plans is a tool nobody runs.

    The scoring model

    Each check returns a status and a score from 0 to 100:

    • Pass (green): meets best practice.
    • Warning (amber): a partial gap.
    • Fail (red): a real cost, reliability, or security risk.
    • Info (teal): couldn’t be evaluated, or doesn’t apply to this environment.

    Category scores are the average of the scored checks; the overall score is the average of the categories. The design decision I’m most pleased with is how Info is handled: it’s excluded from the averages entirely. If a VM fetch failed on a permissions boundary, the affected checks go Info, and the report says 4 of 6 scored next to the donut instead of quietly pretending a green ring is the whole story. A score that flatters you is worse than no score.

    What it checks, across the five pillars

    A flavour rather than the full list:

    • Cost: scaling plan coverage on pooled pools, Start VM on Connect, unhealthy hosts still accepting sessions, max session limits.
    • Reliability: session host health, RDP Shortpath, agent update rings, availability-zone spread, FSLogix profile redundancy.
    • Security: drive and clipboard redirection, Trusted Launch and Secure Boot, Entra ID join status, Defender for Cloud coverage, AVD Private Link.
    • Operational Excellence: diagnostic settings flowing to Log Analytics, resource tagging, Service Health alerts, load-balancing algorithm.
    • Performance Efficiency: Accelerated Networking, Premium OS disks on multi-session hosts, Gen2 VMs, FSLogix region colocation.

    Every one names the affected resources and links to the official documentation, so the report is the start of the fix, not just a verdict.

    From a snapshot to a trend

    A one-off score tells you where you are. It doesn’t tell you whether you’re getting better, and “is this improving?” is the question a sponsor actually asks. Running the London Marathon taught me that a single training run means very little; the line through all of them means everything. The same is true of an estate’s health.

    So the latest version turns AVD-Assess from a snapshot into a tracking tool. It can emit a structured, versioned JSON document alongside the HTML, ready to feed into a dashboard or a pipeline gate. Point it at a previous JSON report and every score, down to the individual check, gets a movement badge: improved, regressed, or unchanged. New checks are flagged; checks no longer assessed are listed separately so nothing silently disappears between runs.

    # Baseline today
    ./AVD-Assess.ps1 -UseExistingConnection -OutputFormat Both -OutputPath .\avd.html
    # Next month, see what moved
    ./AVD-Assess.ps1 -UseExistingConnection -OutputFormat Both -CompareTo .\avd.json

    Real estates also span more than one subscription: production, development, disaster recovery. There’s a sweep mode that assesses every subscription your identity can see in a single pass, writes a report per subscription, and produces a roll-up landing page. A subscription you can’t read is skipped with a reason rather than aborting the whole run, because one inaccessible subscription shouldn’t cost you the other four.

    Why it’s free and open source

    Because the framework is free, and the tooling to apply it should be too. There’s also a selfish reason: open source means the checks get scrutinised, and scrutinised checks are trustworthy checks. If you disagree with how a threshold is scored, you can read exactly how it’s calculated and tell me I’m wrong. That’s the point.

    It’s not a replacement for knowing your environment. It won’t catch everything, and a green score is not a certificate of perfection. It’s the absence of the specific problems it knows how to look for. Treat it as a fast, honest first pass that frees you up to think about the things a script can’t.

    Where to start

    Clone it, run it against a development subscription first, and look at your lowest-scoring pillar. Pick one finding. Fix it. Run it again next month and watch that arrow go green. That loop (measure, fix one thing, then measure again) is worth more than any single report.

    It’s on GitHub here: https://github.com/waynebellows/AVD-Assess

    If you run it and something’s wrong, or a check should score differently, open an issue. I’d genuinely rather hear it.

  • Your Most Locked-Down Users Just Got AVD’s Biggest Connectivity Upgrade in Years

    Your Most Locked-Down Users Just Got AVD’s Biggest Connectivity Upgrade in Years

    You know the user. They’re in financial services, healthcare, or government. Their network team blocks UDP at the firewall because it’s harder to inspect than TCP, and the risk appetite is zero. They’ve heard you talk about RDP Shortpath and how it transforms the AVD experience — lower latency, better audio, fluid video, no session drops. And then they remind you, politely, that none of that applies to them.

    Because their UDP is blocked. Has been for years. Probably always will be.

    For these users, Azure Virtual Desktop has always meant one thing for connectivity: a single TCP tunnel punched through port 443 to Microsoft’s Azure Gateway infrastructure, via a mechanism called Reverse Connect. No shortcuts, no direct paths, no Shortpath. Just TCP — and if that one path hiccups, the session degrades or drops.

    Microsoft just changed that. And it’s bigger than the announcement makes it sound.

    First, a Quick Primer on How AVD Connectivity Actually Works

    Before unpacking what’s new, it’s worth being precise about the layers involved — because the terminology gets muddled.

    AVD has two fundamental transport modes:

    RDP Shortpath (UDP): A direct or relayed UDP connection between the Windows App client and the session host. This uses STUN (Simple Traversal Underneath NAT) for direct peer-to-peer discovery, or TURN (Traversal Using Relays around NAT) when a relay is needed. UDP is faster, has lower latency, and handles packet loss more gracefully than TCP for interactive desktop traffic. This is what most people mean when they say “optimised AVD connectivity.”

    Reverse Connect (TCP): When UDP is unavailable — blocked firewall, restrictive proxy, NAT that won’t play ball — AVD falls back to a TCP connection routed through Microsoft’s Gateway infrastructure on port 443. Every hop goes through Azure’s control plane. It works, but it’s a longer path, more sensitive to latency, and historically, it’s been a single connection with no redundancy.

    RDP Multipath — introduced in public preview last year — added intelligence on top of this. Rather than just connecting on one path and hoping for the best, Multipath continuously evaluates multiple network routes simultaneously and keeps backup paths warm on standby. If the active path degrades, it silently switches to the next best option — no reconnection required, no session drop, often imperceptible to the user.

    The original Multipath implementation focused on UDP paths. Multiple STUN routes, multiple TURN relays, intelligent failover between them. For organisations running RDP Shortpath over UDP, it was a genuine step forward in session resilience.

    But for TCP-only environments? Nothing changed. You still had one TCP tunnel, and Multipath’s safety nets didn’t extend to you.

    Until now.

    What Redundant TCP Multipath Actually Does

    Microsoft this week announced public preview of redundant TCP transport paths for RDP Multipath. The headline is short, but the implication is significant.

    Here’s what it means in practice:

    For environments where UDP is available, Multipath now maintains redundant UDP paths and standby TCP paths simultaneously. UDP remains the preferred and primary transport — it’s faster, and if it’s working, you want it. But when UDP paths degrade or fail, the system now has TCP paths pre-established and ready to take over instantly, rather than scrambling to establish a new connection under duress.

    For environments where UDP is blocked entirely — the financial services firms, the government agencies, the healthcare organisations — this is the more significant change. These environments have historically relied on a single active TCP Reverse Connect path. Now, Azure Virtual Desktop can establish multiple standby TCP paths in parallel. If the active TCP tunnel becomes degraded or fails, the system automatically switches to the next available TCP path without requiring a reconnect.

    Think about what that means operationally. A transient ISP hiccup, a brief VPN instability, a brief network path interruption — these used to manifest as a session freeze followed by a reconnect dialogue. With redundant TCP paths, the session moves silently to the next available path. The user might not notice anything at all.

    Why This Matters More Than It Seems

    The AVD connectivity story has always had an implicit two-tier problem.

    Tier one: organisations that can open UDP ports and run RDP Shortpath. These users get low-latency, high-quality sessions with increasingly sophisticated resilience features. Microsoft has invested heavily here.

    Tier two: organisations where network policy, compliance requirements, or legacy infrastructure means UDP isn’t an option. These users have always had a degraded experience by comparison — not because AVD couldn’t deliver quality, but because the transport architecture underneath it left them with fewer options.

    Multipath’s original launch improved tier one significantly. Redundant TCP Multipath is the first meaningful improvement for tier two. And tier two is disproportionately large in the enterprise segments where AVD is growing fastest — regulated industries where network teams run tight ships.

    This also matters for a subtler reason. Even in environments where UDP is available, there are scenarios where redundant TCP paths matter: a mobile device roaming between networks, a user on a hotel Wi-Fi that quietly blocks UDP, a VPN split-tunnelling configuration that misbehaves. Having TCP redundancy as a backstop makes the entire connectivity architecture more robust, not just for the edge cases.

    The Technical Reality of “Silent Failover”

    It’s worth being specific about what “automatic switching” means here, because it’s not magic.

    RDP Multipath uses ICE (Interactive Connectivity Establishment) — the same protocol that video conferencing platforms have been using for years to negotiate optimal network paths between peers. ICE discovers and ranks available routes, keeps them evaluated continuously, and triggers a path switch when the active route falls below the threshold.

    For TCP paths specifically, Multipath uses a mechanism called Rendezvous to establish Reverse Connect paths. Multiple Rendezvous connections are established to different relay endpoints, maintained on standby, and promoted to active status if the primary path fails. The session state is preserved throughout — the switch happens at the transport layer, not the application layer, so the desktop session itself continues uninterrupted.

    This is the same basic architecture that makes modern video conferencing resilient. Teams, Zoom, and WebRTC-based applications have solved this problem. It’s taken longer for RDP — a protocol with very different characteristics — to get there. But it’s getting there.

    How to Enable It and What You Need

    This is currently in public preview, and there are two requirements:

    Host pool side: You need to opt your host pool into the Validation ring. The feature is enabled by default for host pools in validation, with no additional configuration required.

    Client side: Users must be running Windows App version 2.0.1069.0 or later on a Windows device. This is important — the classic Remote Desktop client doesn’t support this. Other platforms (macOS, iOS, Android) aren’t currently supported either. If your user population is Windows-heavy, you’re well-positioned. If you have significant macOS or Linux client usage, you’ll need to wait.

    To verify Multipath is active, users can check the connection bar in their remote session — it will indicate RDP Multipath is enabled. Administrators can validate connectivity patterns in Azure Virtual Desktop Insights under the connection reliability use case.

    If you want to test without the validation ring, you can also enable Multipath manually via registry on individual session hosts:

    reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RdpCloudStackSettings" /v SmilesV3ActivationThreshold /t REG_DWORD /d 100 /f

    Users need to disconnect and reconnect after the registry change takes effect.

    The Bottom Line

    Redundant TCP Multipath isn’t going to transform your AVD environment overnight, and it doesn’t close the gap between TCP and UDP performance — UDP is still faster, and you should still strive to enable Shortpath where network policy allows.

    But it quietly solves a problem that has affected some of the most demanding enterprise AVD environments for years: the fragility of single-path TCP connectivity in restrictive networks.

    If you have customers or users in finance, healthcare, government, or any sector where the network team is conservative, and UDP isn’t on the table — put this on your radar, opt a test host pool into validation, and start building the evidence for a change.

    The users who’ve always had the worst AVD connectivity experience are finally getting some of the resilience that everyone else has had for a while. That’s worth paying attention to.

    More on AVD connectivity architecture at modern-euc.com. Follow me on LinkedIn for weekly EUC insights.

    References:

  • Windows 365 Business: What It Is, Who It’s For, and How to Get Started

    Windows 365 Business: What It Is, Who It’s For, and How to Get Started

    Microsoft will cut Windows 365 Business prices by 20%, effective 1 May 2026. If you’ve been sitting on the fence about Cloud PCs for your organisation, this is a good moment to revisit the conversation. But before you can decide whether Windows 365 Business is the right fit, you need to understand what it actually is, what it isn’t, and where it makes sense to deploy it.

    This post covers all of that, plus a quick-start guide to get your first Cloud PC provisioned.

    What Is Windows 365 Business?

    Windows 365 Business is Microsoft’s Cloud PC offering for smaller organisations — specifically, tenants with up to 300 users. It delivers a full Windows 11 desktop, hosted in Microsoft’s cloud, streamed to virtually any device a user already owns: Windows, macOS, iOS, Android, or a web browser.

    Unlike Azure Virtual Desktop (AVD), which requires you to manage Azure infrastructure, session hosts, and networking, Windows 365 Business is fully managed by Microsoft. You buy a license, assign it to a user, and within about 30 minutes, they have a Cloud PC waiting for them at windows365.microsoft.com. No Azure subscription required. No virtual network to configure. No infrastructure to maintain.

    The trade-off for that simplicity is control — more on that shortly.

    Who Should Use Windows 365 Business?

    Windows 365 Business is built for small to medium-sized businesses with up to 300 users that want the benefits of a cloud-hosted desktop without the complexity of a traditional VDI deployment or the licensing overhead of Windows 365 Enterprise.

    It’s particularly well suited to:

    Businesses without a dedicated IT team. If there’s no one managing Intune policies or Azure environments, Windows 365 Business gives you a manageable Cloud PC through the familiar Microsoft 365 Admin Center. Setup is genuinely straightforward.

    Organisations with high contractor or seasonal worker turnover. Instead of imaging laptops, shipping hardware, and reclaiming devices, you assign a license and revoke it when the engagement ends. The Cloud PC is ready in minutes and leaves no data on the contractor’s personal device.

    Remote or hybrid teams. Users can pick up exactly where they left off from any device, anywhere. The full desktop experience — apps, files, settings — is persistent and consistent regardless of what endpoint they’re connecting from.

    BYOD environments. Windows 365 Business lets users run a corporate Windows environment on their personal Mac or Windows laptop without any corporate management touching their personal device. The Cloud PC is isolated in the cloud.

    Disaster recovery and business continuity. If a laptop dies or an office becomes inaccessible, users can log into their Cloud PC from any available device and keep working. Hardware failure becomes a minor inconvenience rather than a productivity outage.

    Windows 365 Business vs Windows 365 Enterprise: Know the Difference

    This is the question that trips most people up. Here’s the short version:

    Windows 365 BusinessWindows 365 Enterprise
    User limitUp to 300Unlimited
    Licensing prereqsNoneRequires Windows 10/11 Enterprise + Intune + Entra ID P1
    ManagementMicrosoft 365 Admin CenterMicrosoft Intune admin center
    Policy management (GPO/MDM)Not supportedFully supported
    Custom imagesNot supportedSupported
    Monitoring & analyticsNot supportedEndpoint Analytics via Intune
    Conditional AccessEntra ID P1 requiredSupported via Intune or Entra
    Microsoft Defender for EndpointRequires separate E5 licenseIntegrated with E5

    The headline: Windows 365 Business is for simplicity; Windows 365 Enterprise is for control. If you need to push apps, enforce security baselines, deploy compliance policies, or manage more than 300 Cloud PCs, Enterprise is your path. If you need to get a small team productive quickly without building out an Intune environment, Business is the right fit.

    Pricing (prediction – Updated May 2026)

    Microsoft’s 20% price cut brings Windows 365 Business down to three clean tiers:

    PlanSpecsPrice per user/month
    Basic2 vCPU, 4 GB RAM, 128 GB storage$25
    Standard2 vCPU, 8 GB RAM, 128 GB storage$33
    Premium4 vCPU, 16 GB RAM, 128 GB storage$53

    Basic suits light productivity users: web browsing, email, Teams calls, and basic Microsoft 365 apps. Standard is the sweet spot for most knowledge workers running a full suite of productivity tools and line-of-business applications. Premium is for users running heavier workloads — data processing, software development, or resource-intensive line-of-business apps.

    If your organisation already licenses Windows 10 or Windows 11 Pro, you may also qualify for additional discounts through Windows Hybrid Benefit. Worth checking before you buy.

    Quick Start: Setting Up Your First Windows 365 Business Cloud PC

    No Azure subscription. No virtual network. Here’s all you need to do.

    Step 1 — Check your Entra device settings.
    Before anything else, make sure Users may join devices to Microsoft Entra ID is set to All in your Entra admin center. Cloud PCs will fail to provision if this is locked down.

    Step 2 — Purchase licenses.
    Go to the Windows 365 Business pricing page or navigate to Billing > Purchase services in the Microsoft 365 Admin Center and search for Windows 365 Business. Select your tier based on user workload needs, enter the number of seats, and complete the purchase.

    Step 3 — Assign a license to a user.
    In the Microsoft 365 Admin Center, go to Billing > Licenses, find your Windows 365 Business subscription, and assign it to a user. Alternatively, assign directly from windows365.microsoft.com under Quick actions > Manage your organisation.

    Step 4 — Wait ~30 minutes.
    Windows 365 automatically provisions the Cloud PC using a standard Windows 11 gallery image. No further action needed from you.

    Step 5 — User connects.
    The user visits windows365.microsoft.com, signs in with their Microsoft 365 credentials, and their Cloud PC is waiting. They can also connect via the Windows App or Microsoft Remote Desktop client on any platform.

    That’s genuinely it. No imaging, no infrastructure, no VNet configuration.

    Is Windows 365 Business Right for You?

    If you’re running a business with fewer than 300 users, your team is remote or hybrid, you have BYOD challenges, or you’re spending too much time on endpoint management — Windows 365 Business is worth a serious look, especially at the new pricing.

    The 20% price reduction makes the TCO case significantly more compelling. Gartner noted in April 2026 that cloud-hosted PCs now offer lower total cost of ownership than traditional laptops when you factor in hardware refresh cycles, IT support overhead, and device management costs. At $25–$53 per user per month, Windows 365 Business is squarely in that conversation.

    The simplicity is real, but so are the limitations. If your organisation needs Intune-based policy management, custom images, or advanced security integration, you’ll want to evaluate Windows 365 Enterprise or Azure Virtual Desktop instead.

    For most small businesses and SMBs looking to modernise their desktop estate without a large IT investment, Windows 365 Business is a clean, low-friction option. And right now, it’s the cheapest it’s ever been.

    Have questions about sizing Cloud PCs for your team, or whether Business or Enterprise is the right fit for your environment? Drop a comment below or reach out directly.

  • Microsoft Entra Backup and Recovery: The Safety Net Your Tenant Has Always Needed

    Microsoft Entra Backup and Recovery: The Safety Net Your Tenant Has Always Needed

    Every Entra ID administrator has a horror story.

    Maybe it was a bulk user import that went wrong and overwrote attributes across half your directory. Maybe it was a well-intentioned change to a Conditional Access policy that cascaded into a lockout at 11pm on a Friday. Maybe it was a compromised account that quietly weakened your MFA requirements before anyone noticed.

    Up until recently, recovering from those situations meant one of three things: rebuilding from memory, combing through audit logs and manually reversing changes one by one, or restoring from a third-party backup tool you may or may not have had the budget for.

    Microsoft has quietly shipped something that changes that equation. Microsoft Entra Backup and Recovery entered public preview in March 2026, and if your tenant has Entra ID P1 or P2 licensing, it’s already running — no setup required.

    Here’s what it actually does, what it doesn’t do, and what you should do with it right now.

    What It Is

    Entra Backup and Recovery is a built-in, automated snapshot service for your Entra ID tenant. Once a day, Microsoft takes a point-in-time backup of the critical objects in your directory and retains the last five days of history. Crucially, the backups are tamper-proof — no user, application, or admin (including Global Administrators) can delete, modify, or disable them. Backup data is stored in the same geo-location as your tenant, determined at tenant creation.

    From those snapshots, you can:

    • View available backups — a rolling five-day history available in the Entra admin centre
    • Create difference reports — compare any backup snapshot against the current state of your tenant and see exactly what changed
    • Recover objects — restore all objects, specific object types, or individual objects by ID to their backed-up state
    • Review recovery history — audit completed and in-progress recovery operations

    What Gets Backed Up

    This is where the detail matters. Entra Backup and Recovery covers a defined set of object types, and within those types, a defined set of properties. It’s not a full serialisation of every attribute on every object — but it covers the things that matter most.

    Conditional Access policies and named locations

    This is arguably the most valuable part of the whole feature. All properties of Conditional Access policies are in scope, as are all properties of named location policies. This is the scenario most admins will reach for this tool first. A misapplied policy, a deleted exclusion group, a grant control that got changed — all of that is now recoverable.

    Users

    A broad set of user properties is included: display name, UPN, account enabled/disabled state, department, job title, mail, mobile, usage location, employee data, and more. What’s notably not in scope: manager and sponsor relationships. Those won’t be restored.

    Groups

    Core group properties are covered: display name, description, mail settings, security settings, classification, and theme. Group ownership changes are out of scope. Dynamic group rule changes are also out of scope — so if someone modified a dynamic membership rule, that won’t appear in the diff.

    Applications and service principals

    For app registrations, properties like display name, sign-in audience, required resource access, optional claims, and redirect URI configuration are included. For service principals, the backup extends further: when a service principal is recovered, Entra also restores the OAuth2 delegated permission grants and app role assignments tied to it. That’s important — it means recovering an enterprise app brings back the permissions alongside it, not just the object itself.

    Authentication method policies

    The backup covers the configured state of individual authentication methods: FIDO2 passkeys, Microsoft Authenticator, SMS, voice call, email OTP, Temporary Access Pass, certificate-based authentication, and third-party OATH tokens. If someone disables passkey authentication or weakens your Authenticator configuration, that’s recoverable.

    Authorization policy

    Guest user role settings are covered — specifically, the permission level assigned to guest users in your tenant (member access, guest access, or restricted guest). It also covers the blockMsolPowerShell setting.

    Organisation-level MFA settings

    Tenant-wide per-user MFA settings are included — available MFA methods, whether app passwords are blocked, and device remembering settings.

    What It Doesn’t Cover

    It’s equally important to understand the scope boundaries.

    Hard-deleted objects are not recoverable through this feature. If a user, group, or application has been permanently deleted (either manually hard-deleted, or after the 30-day soft delete window expires), Entra Backup and Recovery cannot restore them. That’s what soft delete and the recycle bin are for — more on that below.

    On-premises synced objects are excluded from recovery. If you’re running hybrid identity with AD Connect or Cloud Sync, changes to synced objects will appear in difference reports, but they’re automatically excluded from recovery. That’s by design: the source of truth for those objects is on-premises AD, so recovery has to happen there. The exception is if you’ve converted objects to cloud-managed (moved the source of authority to the cloud) — those become fully recoverable.

    Not every attribute on every object is included. The supported property list is well-defined and growing over time, but it’s not a complete object dump. If the change you’re trying to reverse involves an attribute outside the supported set, the backup won’t capture it.

    The Difference Between This and Soft Delete

    A point worth emphasising: these are two different tools for two different problems.

    Soft delete handles object deletion. When you delete a user, group, M365 group, or application, it goes into the recycle bin for 30 days. You can restore it from there through the portal or Graph API with all its properties intact. Soft delete is on by default and is your first line of defence against accidental deletions.

    Entra Backup and Recovery handles attribute corruption. If an object still exists but its properties have been changed — by a misconfiguration, a bad import, or a malicious actor — that’s where backup and recovery steps in. It restores the values of supported properties back to their backed-up state.

    The scenario you need to think about for a security incident is both:

    1. A bad actor might corrupt attributes (that’s where backup and recovery helps)
    2. A bad actor might also delete objects and then hard-delete them from the recycle bin to prevent recovery

    Which brings us to the companion feature.

    Protected Actions: Locking Down the Recycle Bin

    If you’re setting up Entra Backup and Recovery as part of a resilience posture, you should do this alongside it.

    Protected actions let you require step-up authentication before specific high-risk operations can be performed. The one to configure immediately is microsoft.directory/deletedItems/delete — the action that hard-deletes an object from the recycle bin.

    By assigning a Conditional Access authentication context to that protected action, you can require that anyone trying to permanently purge a directory object must first satisfy strict conditions — phishing-resistant MFA, a compliant device, maybe even a Secure Access Workstation (SAW). Even a compromised Global Administrator account would be blocked from hard-deleting objects if the device or authentication method doesn’t meet the bar.

    Combined, the picture looks like this:

    • Soft delete keeps deleted objects recoverable for 30 days
    • Protected actions prevent hard deletion without step-up authentication
    • Entra Backup and Recovery lets you restore attribute values from the last five days
    • Audit logs and Entra ID Protection signals alert you when changes happen

    That’s a layered identity resilience posture, not just a backup feature.

    The Two New RBAC Roles

    Entra Backup and Recovery introduces two new built-in roles:

    Microsoft Entra Backup Reader — Read-only access to backups, difference reports, and recovery history. Useful for security auditors or operations teams that need visibility without the ability to trigger changes.

    Microsoft Entra Backup Administrator — Everything in Backup Reader, plus the ability to initiate difference reports and trigger recovery operations. Note that all Backup Administrator permissions are already included in the Global Administrator role, so your existing GA accounts can use this without role assignment. For least-privilege, use the dedicated role.

    One preview caveat: early reports indicate the Backup Administrator role can be difficult to assign through the UI during preview. If you hit that, PowerShell (via Microsoft Graph) works as a workaround.

    How to Use It: The Practical Workflow

    Finding it: In the Entra admin centre, look for Backup and recovery in the left navigation pane. You’ll see four sections: Overview, Backups, Difference Reports, and Recovery History.

    Running a difference report: Select one of your five available backups, choose “Create difference report,” and select your scope — all object types, specific types, or individual object IDs. The first time you run a report against a particular backup, it takes longer (the service needs to load the backup metadata). A first run for a small tenant can take over an hour in the current preview. Subsequent reports against the same backup run much faster since the data is already loaded. This is a known limitation that Microsoft is expected to improve before general availability.

    Reading the report: The output shows you changed objects, grouped by type. For each object, you can drill into the specific attributes that changed and see the old value (from the backup) versus the current value. This is genuinely useful for understanding what happened before you decide whether to recover.

    Triggering recovery: From a difference report, you can choose to recover — scoping to all changed objects, specific object types, or individual object IDs. Recovery time scales with the number of changes involved. Small targeted recoveries (a handful of users, a few CA policies) are fast. Large-scale recoveries across hundreds of thousands of objects can take significantly longer.

    Best practice from Microsoft’s own documentation: Always run a difference report first. Review the changes, confirm you understand the scope, and then trigger recovery. This also pre-loads the backup data, which speeds up the recovery operation itself.

    What to Do Right Now

    Given that this is already running in your tenant if you have P1/P2, there are a few things worth doing today:

    Check that it’s visible. Go to the Entra admin centre and navigate to Backup and recovery. Confirm you can see your last five daily backups. If you can’t, verify your licensing and role assignment.

    Run your first difference report against yesterday’s backup. Even if you don’t expect anything to be wrong, this is worth doing for two reasons: you’ll understand the interface before you’re under pressure, and it pre-loads the data so your first real recovery runs faster.

    Set up protected actions for hard-delete. Go to Roles and Administrators > Protected Actions, find microsoft.directory/deletedItems/delete, assign an authentication context, and wire up a Conditional Access policy with appropriately strict controls. This takes 20 minutes and significantly raises the bar for a malicious actor trying to permanently destroy directory objects.

    Test a recovery in a development tenant. Before you need this in production, run a test. Make a deliberate change to a test user or a non-production CA policy, wait for the next daily backup (or use your existing snapshot), run a diff, and recover. Know how it works before the stakes are real.

    The Bigger Picture

    Entra Backup and Recovery is still in preview, and it has real limitations — the five-day retention window is narrow, the initial diff report performance needs work, and the scope of recoverable properties will keep expanding. It’s not a replacement for a well-documented change management process or a broader identity resilience strategy.

    But it’s a meaningful step forward. For the first time, Entra ID has a native, tamper-proof, automatically-maintained safety net for the objects and policies that your entire cloud environment depends on. The cases where an admin mistake, a bad import, or a compromised account could previously cause hours of manual remediation work now have a straightforward, auditable recovery path.

    Set it up. Test it. Pair it with protected actions. And make sure your team knows where to find it before they need it.

    Resources:

  • Windows 365 Cloud Apps Just Got Serious: APPX and MSIX Support Changes Everything for Frontline

    Windows 365 Cloud Apps Just Got Serious: APPX and MSIX Support Changes Everything for Frontline

    Windows 365 Cloud Apps went generally available in November 2025, and the concept is compelling: stream individual apps from a Cloud PC to a user’s device, without giving them a full desktop. Think RemoteApp, but cloud-native and managed entirely through Intune.

    The problem? Until this week, Cloud Apps only supported Win32 applications. That meant Microsoft Teams and the new Outlook — both packaged as APPX or MSIX — couldn’t be published through it. For most real-world scenarios, that was a deal-breaker.

    As of the week of March 23, 2026, Microsoft added APPX and MSIX application support to Cloud Apps. It sounds like a packaging update. In practice, it removes the single biggest barrier to Cloud Apps adoption.

    This post covers what Cloud Apps is, how it works architecturally, what this update actually changes, and where it fits alongside a full Cloud PC deployment.

    What Are Windows 365 Cloud Apps?

    Cloud Apps is a delivery model within Windows 365 Frontline that lets you publish individual applications to users instead of provisioning a full Cloud PC desktop for each person.

    The experience from the user’s perspective: they open Windows App, see only the specific apps that have been published to them, and click to launch. The app opens in its own window on their local device — no desktop, no taskbar, no Start menu. Just the app.

    From an architecture perspective, Cloud Apps runs on top of Windows 365 Frontline Cloud PCs operating in shared mode. When a user launches a Cloud App, it initiates a RemoteApp connection to one of the shared Cloud PCs in the pool. The Windows UI is stripped away so only the application window is rendered in the remote session. The user sees an app. Under the hood, it’s a Cloud PC running in shared mode, with concurrency tied to the number of Frontline licences assigned to the provisioning policy.

    The key distinction from a full Cloud PC: users don’t get a persistent desktop environment. There’s no personal desktop, no file explorer, no Start menu. They get access to the specific applications IT has published — nothing more.

    How App Discovery and Publishing Works

    This is where it gets interesting, and where the APPX/MSIX limitation was most painful.

    Cloud Apps discovers available applications by scanning the Start Menu of the underlying Cloud PC image. When you create a provisioning policy with the experience type set to “Access only apps,” Windows 365 enumerates every application that has a Start Menu entry on the image. Those apps are then listed in the Intune admin centre as “Ready to publish.”

    Admins select which apps to publish, and those apps become available in Windows App for all users assigned to the provisioning policy. You can edit display names, descriptions, and icons — but the core app discovery is driven by what’s on the image.

    Here’s the catch that tripped up the original release: the discovery and publishing pipeline only supported Win32 executables. APPX and MSIX packages register themselves differently in Windows — they use the modern app model with package identity, containerised execution, and different Start Menu registration paths. The Cloud Apps discovery engine simply didn’t know how to find them.

    That’s what changed this week. The discovery pipeline now supports APPX and MSIX packages alongside Win32 apps. Any application on the image that creates a Start Menu entry — regardless of packaging format — can now be discovered and published as a Cloud App.

    Why This Matters More Than It Sounds

    If you’re not deep in Windows packaging, “we added APPX/MSIX support” might sound like a minor technical improvement. Here’s why it’s not.

    Microsoft has been steadily moving its own applications to modern packaging formats. Teams is an MSIX package. The new Outlook is an APPX package. Many apps delivered through the Microsoft Store and via Intune’s app catalogue are MSIX. The direction of travel is clear: MSIX is the future of Windows app packaging.

    A Cloud Apps deployment that can only publish Win32 apps is a deployment that can’t publish Microsoft’s own flagship productivity tools. That’s not a niche gap — it’s a fundamental limitation that made Cloud Apps impractical for most organisations.

    With APPX and MSIX support, a Cloud Apps deployment can now publish Teams, the new Outlook, and any other modern-packaged app that’s on the image. The feature goes from “interesting concept with a big asterisk” to “genuinely viable for production frontline scenarios.”

    A Quick Primer: Win32 vs APPX vs MSIX

    For context on why these packaging formats matter and what makes them different:

    Win32 is the traditional application model that’s been around for decades. MSI installers, EXE files, and applications that write directly to Program Files, the registry, and shared system locations. They’re flexible but messy — installs can leave residual files, uninstalls aren’t always clean, and conflicts between applications sharing system resources are common.

    APPX was introduced with Windows 8 for Universal Windows Platform (UWP) apps. APPX packages run in a containerised environment with their own virtualised filesystem and registry. They install cleanly, uninstall completely, and can’t interfere with other apps. The trade-off: they were originally designed for UWP-only, limiting their usefulness for traditional desktop applications.

    MSIX is the evolution that bridges both worlds. It brings the clean install/uninstall behaviour and containerisation of APPX to traditional Win32 and .NET Framework applications. MSIX supports differential updates (only downloading what changed), mandatory digital signing for security, and a 99.96% install success rate according to Microsoft’s data. It’s designed to be the single packaging format for all Windows app types going forward.

    The reason Cloud Apps struggled without APPX/MSIX support is that Microsoft has been packaging its own apps in these formats for years. Teams, the new Outlook, and many Store-delivered apps aren’t Win32 — they’re MSIX or APPX. If your app delivery platform can’t see them, you can’t publish them.

    Cloud Apps vs Full Cloud PC: When to Use Which

    Cloud Apps doesn’t replace a full Cloud PC. They solve different problems for different user personas. Here’s how to think about when each model fits.

    Cloud Apps makes sense when:

    The user needs access to a small number of specific applications — typically two or three. They don’t need a full desktop environment, file management, or the ability to install additional software. Think frontline retail workers who need a POS system and Teams. Field service staff who need a single line-of-business app on shared devices. Contractors who need controlled access to specific tools without a full managed desktop. Seasonal or temporary staff where provisioning and deprovisioning full Cloud PCs per person would be operationally heavy.

    A full Cloud PC makes sense when:

    The user needs a persistent desktop environment with their own files, settings, and application state. They work with multiple applications simultaneously and switch between them throughout the day. They need the ability to open apps ad hoc — not just pre-published ones. Their workflow involves file management, browser-based tools alongside desktop apps, or other activities that need a complete Windows desktop.

    The shared licensing model underneath:

    Both Cloud Apps and shared-mode Frontline Cloud PCs use the same Windows 365 Frontline licensing. The licence model allows unlimited user assignments per licence, but only one concurrent active session per licence at a time. So if you have 50 Frontline licences assigned to a Cloud Apps provisioning policy, up to 50 users can have active Cloud App sessions simultaneously.

    This makes Frontline significantly more cost-effective than Enterprise Cloud PCs for shift-based or part-time workers. You’re not paying for a dedicated Cloud PC per user — you’re paying for concurrent capacity.

    Security Consideration: Published Apps Can Launch Other Apps

    There’s one architectural detail worth flagging that catches some admins off guard.

    When a user launches a published Cloud App, that app runs on a full Cloud PC under the hood. The published app can launch other applications that exist on the Cloud PC image, even if those other apps haven’t been published as Cloud Apps.

    For example: if you publish Outlook as a Cloud App and a user clicks a link in an email, it can launch Edge — even if Edge isn’t published. If an app has a “Open in Explorer” option, it could launch File Explorer.

    For many scenarios, this is fine and even expected behaviour. But if you’re in a regulated environment or need strict application control, you should layer Application Control for Windows (formerly Windows Defender Application Control) on top of Cloud Apps to enforce exactly which executables can run on the underlying Cloud PC.

    Don’t assume that publishing three apps means only three apps can run. The published app list controls what the user can launch directly — not what can execute on the session host.

    What’s Still in Preview

    A few things to be aware of that are still in preview or coming soon:

    Enhanced user experiences for Cloud Apps are in public preview. This includes improved Windows Snap support, full-screen mode, better DPI handling, and visual refinements like borders, shadows, and theme integration. These improvements use the same RemoteApp enhancements available in Azure Virtual Desktop.

    Autopilot Device Preparation support for Cloud Apps is also in public preview. This gives you an alternative to custom images for getting apps onto the underlying Cloud PCs — you can use Autopilot Device Preparation policies to install apps during provisioning, and Cloud Apps will discover them once installed.

    User Experience Sync allows app settings and data to persist between user sessions on shared Cloud PCs. Since Cloud Apps runs on shared-mode Frontline Cloud PCs, user state would normally be lost when a session ends. User Experience Sync preserves settings and data, which is important for apps that store user preferences locally.

    The Bigger Picture

    Cloud Apps has been a “watch this space” feature since it launched. The concept was right — not every user needs a full desktop, and app-only delivery is often the better fit for frontline and contractor scenarios. But the Win32 limitation made it hard to recommend for production use when you couldn’t even publish Teams.

    With APPX and MSIX support, that changes. The feature is now capable of delivering the apps that most organisations actually need in frontline scenarios. Combined with the Frontline shared licensing model, it’s a genuinely cost-effective alternative to provisioning full Cloud PCs for users who only need a handful of apps.

    If you evaluated Cloud Apps earlier and parked it because of app support gaps, it’s worth taking another look. The gap that mattered most is now closed.

    Wayne Bellows is a Technical Account Manager at Nerdio. He writes about Azure Virtual Desktop, Windows 365, Intune, and the EUC industry at modern-euc.com.

  • Habit #7: Optimise Log Analytics

    Habit #7: Optimise Log Analytics

    Visibility is essential — but it shouldn’t come at any cost.

    Monitoring is a critical part of running Azure Virtual Desktop.

    Without it, you’re blind to performance issues, login delays, and user experience problems.

    But there’s a trade-off that many teams don’t fully realise:

    Observability isn’t free.

    And in many environments, Log Analytics quietly becomes one of the largest — and least optimised — costs in Azure.

    That’s where Habit #7 comes in.

    Highly effective admins don’t just enable monitoring.
    They optimise it.

    The Hidden Cost of Visibility

    Log Analytics is incredibly powerful.

    It provides deep visibility into:

    • Session performance
    • User experience
    • Host health
    • Application behaviour

    But it works by ingesting data.

    And in Azure, you don’t pay for storing most of that data (at least initially).
    You pay for ingesting it.

    That means:

    The more frequently you collect data, the more you pay.

    In many AVD environments, default configurations collect data far more frequently than needed for day-to-day operations.

    The result?

    High ingestion volumes… and unexpectedly high costs.

    What Log Analytics Optimisation Really Means

    Optimising Log Analytics isn’t about turning monitoring off.

    It’s about collecting the right data, at the right frequency, for the right purpose.

    In Nerdio Manager for Enterprise, admins have control over how telemetry is collected and retained.

    This includes:

    • Data collection frequency (polling intervals)
    • Performance counters being captured
    • Retention periods

    The goal isn’t to reduce visibility.

    It’s to remove unnecessary noise.

    The Three Pillars of Habit #7

    Like every habit in this series, this comes down to consistent, repeatable behaviour.

    Pillar 1: Review What You’re Collecting

    Most environments collect far more data than they actually use.

    Highly effective admins regularly review:

    • Which performance counters are enabled
    • Whether those metrics are actively used
    • Which dashboards or reports depend on them

    A simple question helps guide this:

    “If we stopped collecting this data, would anyone notice?”

    If the answer is no, it’s likely unnecessary.

    Pillar 2: Adjust Collection Frequency

    One of the biggest cost drivers in Log Analytics is how frequently data is collected.

    By default, many metrics are captured every 30 seconds.

    For most environments, that level of granularity isn’t required.

    Adjusting polling intervals to:

    • 60 seconds
    • 120 seconds
    • Or even longer for certain metrics

    …can significantly reduce ingestion volume without materially impacting visibility.

    The data is still there.

    It’s just collected more efficiently.

    Log Analytics Optimisation in Nerdio Manager.

    Pillar 3: Align Retention with Real Needs

    Not all data needs to be kept forever.

    Highly effective admins:

    • Align retention periods with operational requirements
    • Keep short-term data for troubleshooting
    • Retain longer-term data only where it adds value

    For many teams, a 30-day retention window is more than sufficient for operational analysis.

    Anything beyond that should be intentional.

    What This Habit Enables

    When Log Analytics is optimised properly:

    • Monitoring costs drop significantly
    • Data ingestion becomes predictable
    • Dashboards remain effective
    • Troubleshooting capability is preserved

    Most importantly:

    You maintain visibility — without overpaying for it.

    Common Mistakes to Avoid

    Log Analytics optimisation is often overlooked or misunderstood.

    Some common pitfalls include:

    • Leaving default collection settings unchanged
    • Collecting high-frequency data that’s never used
    • Retaining data longer than necessary
    • Reducing data collection too aggressively without understanding impact

    The goal is balance.

    Too much data increases cost.
    Too little data reduces visibility.

    How Habit #7 Builds on the Previous Habits

    By this stage, the environment should already be well optimised:

    • Images are standardised
    • Patching is predictable
    • Applications are decoupled
    • Autoscale is tuned
    • VM sizing is aligned with demand

    Habit #7 completes the picture.

    It ensures that the monitoring layer itself is optimised, not just the infrastructure it observes.

    The Real Takeaway

    Monitoring is essential.

    But more data doesn’t always mean more value.

    Highly effective admins understand this.

    They don’t collect everything.

    They collect what matters.

    And they do it efficiently.

    Closing the Series

    That’s the final habit in the series.

    The 7 Habits of Highly Effective Nerdio Admins aren’t about individual features.

    They’re about operational discipline:

    • Build consistently
    • Patch predictably
    • Separate concerns
    • Optimise continuously
    • Use data to drive decisions

    Individually, each habit adds value.

    Together, they create environments that are:

    • Stable
    • Scalable
    • Cost-efficient
    • Predictable

    And ultimately — easier to manage.

  • Why Your Intune Policies Don’t Apply Instantly — And How That’s Changing

    Why Your Intune Policies Don’t Apply Instantly — And How That’s Changing

    If you’re moving from SCCM (Configuration Manager) to Microsoft Intune, one of the first things that catches teams off guard is the timing question: “I made a change — why hasn’t it hit the device yet?”

    With SCCM, you had more direct control over deployment schedules and could see exactly what was happening in the pipeline. Intune works differently. It’s not slower by design — it’s built on a fundamentally different architecture. And once you understand how it actually works, both the current behaviour and the improvements Microsoft is rolling out make a lot more sense.

    This post breaks down what happens from the moment you make a change in Intune to the moment a device reflects it — and what’s being done to close that gap even further.

    Intune Is an Eventual Consistency System (And That’s by Design)

    The first concept to get your head around is eventual consistency. Unlike SCCM’s more synchronous delivery model, Intune doesn’t push changes to devices instantly. Instead, devices converge to a desired state over time.

    Think about using your laptop on a flight with no internet. Everything still works — your files, your apps, your settings — because the device operates independently. The moment you land and reconnect, everything reconciles seamlessly. That’s eventual consistency in action.

    The trade-off is that until a device checks in, Intune doesn’t truly know its current state. Are there pending changes? Has something shifted locally? Is the device still compliant? All of that gets resolved at check-in time — which is exactly why check-in timing matters so much.

    The Three Types of Device Check-Ins

    Not all check-ins are the same. Intune buckets them into three main categories:

    1. Single device check-ins These happen when an admin or user takes an explicit action on a specific device — for example, triggering a sync manually from the Company Portal or the Intune admin centre.

    2. Client-initiated check-ins These happen in the background to keep devices healthy when nothing else is going on. They’re essentially the device saying “just checking in, anything new?” on a regular schedule.

    3. Change-based check-ins (the Fast Lane) These are triggered when a service-side change happens that affects one or more devices. This is where most of the action is — and where Microsoft has been focused on driving improvements.

    What Is the Intune Fast Lane?

    The Fast Lane is how Intune accelerates policy delivery when a change occurs. When a service-side change occurs, Intune sends a push notification to affected devices, instructing them to check in immediately rather than wait for their next scheduled check-in.

    Four things trigger a Fast Lane notification:

    1. An admin modifies the targeting of a payload — for example, adding an Entra group to an existing policy assignment
    2. An admin modifies the contents of a payload — like changing a configuration value in a policy
    3. Entra group membership changes — when users are added or removed from groups that have policies assigned
    4. App updates from the store — automatic updates to assigned apps

    The last two are worth flagging for teams coming from SCCM: these can happen entirely behind the scenes. A group membership change driven by HR provisioning, or an automatic app update, still triggers a Fast Lane notification from Intune’s perspective. It’s worth understanding that the system is reacting to more events than an admin might consciously initiate.

    Where the Delays Actually Happen

    The journey from admin change to device compliance looks like this:

    1. Admin makes a change
    2. Intune compiles the list of affected devices
    3. Intune sends push notifications to those devices
    4. Devices receive the notification and check in
    5. Intune applies the changes
    6. Devices report status back to the admin

    Most of the latency sits in the handoff between step 3 and step 4 — between Intune sending the notification and the device actually checking in. That’s the seam Microsoft has been focused on closing.

    The last-mile delivery of notifications relies on platform providers: WNS for Windows, APNS for Apple, and FCM for Android/Google devices. These are best-effort systems — not guaranteed — and can be affected by the device being offline, network issues, or platform delays. That part of the pipeline isn’t fully visible to Intune (or to you as an admin), which is something Microsoft has been working to address.

    What Microsoft Has Been Improving

    Here’s where it gets genuinely interesting for teams that have been frustrated with policy delivery timing. Microsoft has made — or is very close to releasing — five specific improvements to this pipeline.

    1. Smarter, More Targeted Notifications

    The system was sending a lot of noise. Around 40% of Fast Lane notifications didn’t result in any actual device changes. Meanwhile, 65% of all MDM check-ins also produced no changes. The system was accelerating check-ins for devices that didn’t need it, while potentially backing up devices that did.

    The fix: Intune has overhauled its notification system to be far more precise about which devices actually need to check in. The result is a 35% reduction in unnecessary notifications and the ability to process 40% more sessions. Today, 97% of notification-based check-ins are handled on the first attempt.

    That 97% sounds impressive — and at Intune’s scale, it is. But as Albert Caveo from the Intune team puts it: “If your water heater was working 97% of the time, you wouldn’t brag about the hot showers. You’d never forget that one cold shower.” The goal is to keep pushing toward 99.9%.

    2. Intelligent Check-In Prioritisation

    Previously, Intune’s prioritisation algorithm only distinguished between “maintenance” and “non-maintenance” check-ins. That meant a device falling out of compliance due to a detected threat competed equally with a routine background check-in from a healthy device.

    The new model introduces a priority tier system based on impact. Devices with pending changes can now jump to the front of the queue when capacity limits are hit. And the system is moving from those two broad categories to explicit SLO-backed tiers — so a remote wipe or a new device enrolment will always get handled ahead of a background health check.

    The goal: critical check-ins seldom need to retry, and high-priority check-ins complete within one hour.

    3. No More Dropped Notifications

    In the old model, Intune would send one Fast Lane notification per device per 30-minute window. If multiple changes came through in that window, additional notifications were simply dropped. They weren’t queued — they were gone. The device would catch up at its next scheduled check-in, which could be hours away.

    The new system introduces per-device notification timers. When a change occurs, rather than firing a notification immediately, Intune starts a short timer (a couple of minutes). If more changes come in for the same device during that window, the timer extends slightly — up to 10 minutes — allowing the device to pick up all pending changes in a single check-in.

    After notifying, if there are still more changes queued, Intune will always schedule another notification rather than dropping it. The practical outcome: every change you make will result in a push notification. No more changes silently falling through because of notification window collisions.

    4. Fast Lane Expansion to More Payloads

    The Fast Lane previously didn’t cover everything. Scripts, Win32/classic apps, custom compliance policies, and payloads delivered through the Intune Management Extension (IME) or MMPC gateway had inconsistent Fast Lane coverage.

    That’s changing. Fast Lane notifications are being expanded to cover all gateways and all payload types, including IME-delivered content on both Windows and Mac. The experience will be consistent regardless of how a payload is delivered.

    5. Better Windows Notification Reliability via IC3

    For Windows specifically, Intune is adding a second notification channel alongside the native Windows notification service (WNS). The new channel uses IC3 — the same communications protocol that Microsoft Teams uses — delivered via the Intune Management Extension.

    This gives Intune more control over end-to-end notification delivery on Windows, including delivery receipts, better diagnostics, and the ability to reason across all pending changes and device actions in one place. It also lays the groundwork for future capabilities like presence awareness and more targeted notifications.

    The main thing you need to ensure on your end: keep your network and firewall rules up to date with the required Intune network endpoints. Microsoft publishes these, and they occasionally change as new capabilities roll out.

    Bonus: iOS Maintenance Check-In Optimisation

    For iOS specifically, Microsoft has redesigned how maintenance check-ins are handled. Previously, iOS devices had three service-initiated maintenance check-ins daily (roughly every eight hours), and during peak hours these were accounting for up to 40% of all Intune traffic — most of which produced no device changes.

    The new model is smarter: during peak hours, if a device has already checked in recently, the maintenance check-in is deferred. During off-peak hours, it continues as normal. The result: 99.5% of changes to iOS devices are now delivered faster, while overall delayed check-ins across all platforms are reduced by 10%.

    What This Means for Your SCCM Migration

    If you’re mid-migration or planning one, here are the practical takeaways:

    You don’t need to change how you work. All of these improvements are being built directly into the Intune platform. There are no configuration switches to flip or extra steps to take. They apply across the board.

    Understand the model, not just the tools. The eventual consistency model is genuinely different from SCCM. Policies don’t hit devices the instant you save them — but with the improvements above, the window between “change made” and “device updated” is shrinking significantly for anything that matters.

    Watch your network endpoints. The IC3/IME notification improvements require up-to-date firewall and network rules. Worth a check with your networking team if you’re seeing notification delivery issues.

    Use the Fast Lane triggers intentionally. Know that changes to Entra group membership — not just explicit policy changes — trigger Fast Lane notifications. Factor that into how you design your group structures and assignment targeting.

    Closing Thoughts

    Intune timing has historically been one of the more frustrating aspects of the SCCM-to-cloud migration conversation. The “eventual” in eventual consistency felt a little too eventual at times. What’s encouraging about Microsoft’s current direction is that they’re not just adding more notifications or shorter timers — they’re building genuine intelligence into the system. Priority awareness, noise reduction, smarter notification timers — these are architectural changes, not patches.

    For teams managing thousands of endpoints, the difference between “it’ll apply within the next maintenance window” and “critical changes apply within the hour” is meaningful. And that’s the direction Intune is heading.

    Adapted from the Microsoft session “Intune timing demystified: what really happens behind the scenes” presented by Albert Caveo, Principal Product Manager, Microsoft Intune Core Platform team.