Modern EUC by Wayne Bellows

Author: Wayne Bellows

  • Nerdio Global Pools: From a Fixed Split to a Deliberate One

    Nerdio Global Pools: From a Fixed Split to a Deliberate One

    If you manage Azure Virtual Desktop at any real scale, you already know the uncomfortable truth about host pools: they don’t know who your users are. A host pool has capacity, a region, and a desktop image. It doesn’t have an opinion about whether the person connecting to it is in Manchester or Mumbai, whether they need the finance app set or the sales one, or whether the pool next door has spare capacity and this one doesn’t.

    For years the answer to “how do I place users properly across a large AVD estate” has been: manually, pool by pool, in a spreadsheet somewhere. Nerdio’s new Global Pools feature, currently in Public Preview for AVD Premium, is the first serious attempt to turn that into policy instead of a project. The preview lays the foundation of an MVP feature that has huge potential for how you manage your host pools.

    The feature you’re probably already running: Host Pool Business Continuity

    Before Global Pools, there’s a feature most Premium customers already have switched on (or should): Host Pool Business Continuity Multi-Region Setup. It’s worth starting here, because it’s the feature Global Pools is quietly built to go beyond.

    It splits new VMs across a primary and secondary Azure region, evenly, and replicates FSLogix profiles between them using Cloud Cache. If a region goes down, users land in the surviving one. It’s a genuinely useful safety net, and it’s available today at host pool level.

    The catch is in that word “evenly.” The split is fixed at 50/50. There’s no weighting, and no way to choose which users go where. A user in Manchester has as much chance of landing in your secondary US region as a user based there already. The feature was built to survive a region failing, and it does that well, but it was never built to place people deliberately. It doesn’t know who the user is, or where they are; it just needs somewhere for them to land.

    That gap is exactly where Global Pools starts.

    What Global Pools actually is

    Nerdio’s own description, from the published KB article: Global Pools let administrators group multiple AVD host pools under shared assignment and failover policies, so users are automatically routed to the right host pool instead of being managed one pool at a time.

    The important architectural point is what it doesn’t touch. Global Pools sits on top of native AVD host pool logic and on top of Nerdio’s own Auto-scale engine. Global Pools is a placement and policy layer, not a new kind of host pool.

    Two things worth knowing before you go looking for it: it’s currently Public Preview, and it’s Premium edition only.

    How it works, in practice

    Strip away the marketing and the mechanics are fairly plain:

    • Assignment is driven by Entra ID group membership. You define policies that route members of specific Entra groups to specific Pool Groups (more on those in a second), with a configurable priority order for anyone who happens to sit in more than one group.
    • Pool Groups bundle one or more host pools together under a shared distribution mode (depth-first or breadth-first), and Nerdio automatically rebalances users across the host pools inside a Pool Group as capacity changes.
    • Sync runs every 15 minutes, automatically, with a manual sync button for when you don’t want to wait.
    • Auto-scale sizing can be percentage-based as well as the traditional fixed host count, useful if you want capacity to track the size of the pool rather than a hard number.
    • Failover policies redirect users from one Pool Group to another for planned maintenance or an outage. In the current release this is a manual cutover: an admin triggers it, it doesn’t happen on its own yet.
    • RemoteApps and the desktop image are defined once per Global Pool, not per Pool Group. The nice touch: you can build the RemoteApp catalogue as a placeholder before any host pool exists in the Global Pool at all. Native AVD doesn’t let you do that.

    None of that requires touching an API, incidentally, because there isn’t one yet. Everything is configured through the Nerdio Manager UI, and you’ll need the Nerdio Admin role to do it.

    Where this is meant to fit

    Nerdio names three scenarios for Global Pools, and they’re a reasonably honest description of who actually needs this:

    1. Large AVD deployments with enough host pools that manual per-pool assignment has stopped scaling.
    2. Failover between Pool Groups during planned maintenance or an outage.
    3. Organisations running multiple identity tenants who want one unified assignment model.

    What it doesn’t do yet

    Nerdio is upfront that this is Public Preview, and the documented gaps back that up:

    • Single-session desktops aren’t supported. If you’re running personal (1:1) host pools, Global Pools isn’t for them yet.
    • No import of existing host pools. Every host pool in a Pool Group has to be created fresh, one at a time, with its workspace and application group deployed manually. If you’re picturing dragging your current 200 host pools into a Global Pool this weekend, that’s not available yet.
    • Assignment is Entra group matching only. No percentage-based or attribute-based assignment, so you can’t yet say “60% of this group goes here, 40% goes there.” (Percentage-based auto-scale sizing is a separate feature and is available; don’t let the two get confused, because it’s an easy mix-up.)
    • Only core host pool profiles are supported inside a Global Pool: Active Directory, VM, and RDP/FSLogix. If your host pool profile relies on something outside that set, it’s not covered yet.
    • No public API yet. Everything is configured by hand in the Nerdio Manager UI.
    • Limited in-UI guardrails. Configuration issues like overlapping failover group membership aren’t flagged for you, so review your policy setup carefully before switching it on.

    None of that is a criticism. It’s a Preview feature, and Nerdio is treating it as one, which is the right call given how much is still moving underneath it.

    What to actually do about it

    If you’re running a handful of host pools, Global Pools probably isn’t solving a problem you have yet. If you’re managing dozens or hundreds across multiple regions, the shape of what Nerdio is building is worth understanding now, even before it’s something you’d put into production.

    Two practical steps:

    First, if you’re not already on it, check Azure Capacity Extender. It’s a separate, established Premium feature that lets you define fallback VM sizes when your preferred size runs out of capacity in a region. I’ve walked more than one customer through exactly that scenario this year, and it costs nothing unless it’s invoked, yet in a lot of estates it’s sitting there switched off. It solves a narrower problem than Global Pools (keeping a host pool running, not placing users across pools) but it’s available today and worth auditing regardless of where you land on Global Pools.

    Second, if you’re running enough host pools that manual assignment has become a real operational cost, get onto the Public Preview and give Nerdio feedback. The honest ask at this stage is “come and tell us what you need it to do,” not “go and build your architecture around this.” Preview features get shaped by the people willing to poke at them early. The gap between “staggered image rollout is listed as a scenario” and “staggered image rollout actually works” is exactly the kind of thing that gets closed faster when real admins are testing against real estates.

    Global Pools is trying to solve a problem that’s been genuinely unsolved in AVD: making user placement a policy decision instead of a spreadsheet. It’s not there yet. But the direction is right, and for anyone running AVD at real scale, it’s worth watching closely rather than waiting for the GA announcement to start paying attention.

    —

    Found this useful? I’d be glad to hear how you’re thinking about host pool placement at scale. Drop a comment, or find me at the next Nerdio event.

  • Golden Image, 2026-08-31: Allow three new Windows 365 endpoints by 5 October

    This week’s Golden Image is out: Allow three new Windows 365 endpoints by 5 October.

    Read it at weekly.modern-euc.com →

  • Golden Image, 2026-08-23: SMS sign-in is gone for Entra ID Free tenants

    This week’s Golden Image is out: SMS sign-in is gone for Entra ID Free tenants.

    Read it at weekly.modern-euc.com →

  • FSLogix: What Belongs in a Profile, What Doesn’t, and How to Keep It That Way

    FSLogix: What Belongs in a Profile, What Doesn’t, and How to Keep It That Way

    Four questions come up in nearly every FSLogix health check I run. What should be in the profile. What shouldn’t. How big it needs to be. And why it keeps growing even after someone swears they turned on cleanup.

    This week I’ve gone through the first three on LinkedIn: the beliefs that quietly cost money, what actually happens at logon, and the config I’d set before a single user signs in. This post is everything in one place, with the registry paths, so you can check your own environment against it rather than take my word for it.

    What FSLogix actually does

    Skip this if you already know it, but it’s worth thirty seconds because it explains almost everything downstream.

    FSLogix doesn’t copy a profile to the session host the way old-style roaming profiles did. It mounts a VHD or VHDX file from a network share and attaches it at the file system level using a kernel driver. Windows sees C:\Users\<username> and has no idea it’s actually a disk sitting on Azure Files or a file server somewhere else. No copy at logon, no copy at logoff. That’s why it’s fast, and it’s also why almost every strange failure traces back to that mounted disk: what’s inside it, how big it’s allowed to get, and whether the network path stays up for the whole session.

    What belongs in the container, and what doesn’t

    Microsoft’s own guidance has settled on a single answer here: use one Profile Container that holds everything, rather than splitting profile data from Office data into a separate ODFC container. ODFC exists for organisations already running a different profile solution and using FSLogix only for Office data. If that’s not your situation, one container is simpler, and it’s what Microsoft recommends.

    Inside that container, two things get handled for you automatically, and it’s worth knowing about them rather than assuming they don’t exist.

    Deletion-based exclusions. Non-roamable app data (MSIX package cache, temp state) gets stripped out at logoff so it never bloats the container. More importantly, identity data tied to the device itself — Entra broker tokens, TokenBroker, OneAuth, the AAD registry keys — is excluded by design. There’s a setting called RoamIdentity that looks like it would fix Entra sign-in quirks by roaming that data instead. Don’t touch it. Microsoft is explicit: never enable RoamIdentity on an Entra-joined or Intune-managed device. It ties identity to the wrong thing, and you’ll get worse authentication problems than whatever you were trying to fix.

    Custom exclusions via redirections.xml. If you need to exclude something Microsoft doesn’t already handle, this is the mechanism — an XML file, deployed centrally via RedirXMLSourceFolder, that lists paths to exclude or redirect. Microsoft’s own warning on this page is worth repeating verbatim: profile data isn’t designed to be removed, and unless you understand the application well, don’t exclude it. Every well-known FSLogix teardown agrees on the same short list worth actually redirecting: browser cache, the Outlook OST, OneDrive’s sync cache, and Teams. Beyond that, keep the file short. Every redirection is I/O overhead multiplied by every signed-in user.

    Two of Microsoft’s own defaults are worth knowing precisely because they surprise people. IncludeTeams in ODFC settings defaults to 0 — Teams data isn’t redirected unless you turn it on, and for the current MSIX-based Teams client you need this set for the app to even register correctly at sign-in. And RoamSearch, the setting that roams the Windows Search index inside the container, is something Microsoft now says isn’t needed on Windows Server 2019 (1809+), Windows 10, or Windows 11 multi-session. It solved a real problem years ago. On a modern image, it mostly adds I/O.

    Sizing that actually works

    SizeInMBs defaults to 30,000, roughly 30 GB, and it’s a one-way setting. Raise it and every existing container expands to match on next logon. Lower it and nothing happens — it has zero effect on containers that already exist. The only way down is compaction or rebuilding the container from scratch.

    Keep IsDynamic at its default of 1. A dynamic VHDX starts small and grows as data is written; a fixed one allocates the full size immediately and can never be compacted. There’s no scenario where fixed is the better choice for a profile container.

    Thirty gigabytes is a reasonable starting point, not a number to trust blindly. A light knowledge worker with a small OST and everything else in OneDrive might genuinely need 10 to 15 GB. Someone with a large mailbox and local app data can eat 60 GB without anything unusual happening. Measure actual profile sizes on your existing share before you commit to a number, and size for the largest real profile you have plus headroom, not for a round figure that felt safe when the host pool was built.

    Why containers grow and never shrink on their own

    This is the one that catches people out months after go-live. When a user deletes files inside their profile, FSLogix marks the space as free inside the VHDX. The file on the share stays exactly the same size. Nothing shrinks by itself. A profile that briefly ballooned to 25 GB during a big OneDrive sync stays at 25 GB on disk forever, even after the sync settles down.

    Built-in compaction exists to fix this and runs automatically at every sign-out, but it has two conditions that quietly stop it working, and neither produces an error when they do.

    First, it only runs if at least 20% of the consumed space is recoverable. A container using 12 GB with a 10 GB minimum supportable size has 2 GB recoverable, which is under the 2.4 GB threshold — so compaction skips it silently every time, and the profile never gets smaller.

    Second, compaction depends on the Windows Optimize Drives service, defragsvc. If that service is set to Disabled anywhere in your image, which is common in hardened builds, FSLogix can’t query the minimum supportable size, and compaction doesn’t run at all. No error, no log entry that jumps out. It just quietly does nothing every single sign-out.

    If you’re maintaining an older estate where containers have already ballooned past what per-sign-out compaction can claw back, both the community Invoke-FslShrinkDisk script and Nerdio Manager’s built-in “Shrink FSLogix Profiles” scripted action exist to do a bulk pass offline. Worth knowing the community script sits in the FSLogix GitHub organisation and isn’t a Microsoft-supported product feature — test it before you trust it against production data.

    One more setting worth turning on while you’re in there: CleanupInvalidSessions, which ships disabled. It has FSLogix clean up stale artefacts left behind by sessions that ended abruptly rather than signing out cleanly, and it’s a small thing that prevents a class of “why won’t this profile attach” tickets later.

    Storage, and the 9am problem

    Microsoft’s IOPS guidance for FSLogix is specific: budget 10 IOPS per user at steady state, and 50 IOPS per user during sign-in or sign-out. For 100 users, that’s roughly 1,000 IOPS most of the day and a burst toward 5,000 IOPS in the window everyone arrives at once. Size for the burst, not the average, or the first twenty minutes of every morning will be the worst part of your users’ day.

    On tier, Microsoft’s own workload table draws the line at 200 users for the “Light” category: under 200 light users, Azure Files Standard can work. Above that, or for anything heavier than light, Premium is the recommendation regardless of headcount. Standard is priced on transactions as well as capacity, which makes its performance genuinely variable under load — not what you want for something every user depends on to log in.

    The failure modes worth knowing before they bite

    Wrong FSLogix permissions are, by most practitioner accounts I trust, the single biggest generator of AVD support tickets. Get the NTFS ACLs on the share root right from day one: modify for the user group, full control for admins, and Creator Owner set to modify on subfolders and files only so each user’s own container inherits correctly. Exclude admin accounts from FSLogix profiles entirely — if something goes wrong, you want an unencumbered way in to fix it.

    Antivirus exclusions are the other classic. It’s not just the VHD or VHDX file itself. The small sidecar files sitting next to it on the share — .VHD.lock, .VHD.meta, .VHD.metadata and their VHDX equivalents — need the same exclusion, or AV locking them produces the exact same sharing violations and temp profiles as locking the disk file. A logon storm with twenty users all having their containers scanned at once is a fast way to bring a host to its knees.

    Two authentication issues are worth knowing about specifically because they’re recent and easy to miss. Microsoft’s Kerberos hardening, moving domain controllers to require AES-SHA1 instead of RC4 for objects with no encryption type explicitly set, took effect with the April 2026 cumulative update, and the audit-mode rollback that let you defer it was removed at the end of July. If your profiles sit on an on-premises SMB share, or on Azure Files using AD DS authentication, and anything in that chain is still RC4 or has no encryption type set, it breaks. Entra Kerberos authentication isn’t affected by this particular change.

    Entra Kerberos has its own separate limitation worth planning around if you’re cloud-native: the ticket that authorises access to Azure Files lasts about 10 hours, and Entra ID currently can’t renew it. Cross that mark in a single session and the container drops, usually with a bad username or password error that has nothing to do with the actual password. Microsoft’s documented fix is cloud trust, issuing tickets from AD DS instead — which isn’t an option if you’re genuinely Entra-only. If that’s your situation and you have users on long shifts, budget time to look at a scheduled ticket refresh as a workaround.

    Cloud Cache: when it earns the extra complexity

    Cloud Cache sits on top of the profile container and changes where the writes go. Instead of writing straight to the network share, it writes to a local cache on the session host first and syncs to one or more remote storage providers in the background. Microsoft positions it for multi-region deployments and for keeping users working through a storage outage — genuine high availability, not a substitute for backup and restore.

    It’s not free. It needs fast local storage for the cache, adds a few seconds to logon, and on non-persistent session hosts that get rebuilt regularly, the local cache is gone every time — meaning every logon rehydrates fully from remote storage anyway, which defeats the point. For a single-region deployment already sitting on Zone Redundant Azure Files Premium, the honest answer is usually that Cloud Cache adds complexity without adding much you didn’t already have.

    Where none of this applies

    Windows 365 Cloud PCs don’t use FSLogix profile containers, and this trips people up when they’ve spent years thinking in AVD terms. A Cloud PC is persistent and assigned 1:1 to one user. The profile lives on the Cloud PC itself between sessions, the same way it would on a physical laptop, so there’s nothing to roam.

    The same logic extends further than most people realise. AVD Personal host pools work the same way: one session host assigned persistently to one user. Microsoft’s own guidance on when a roamed profile is genuinely needed centres on pooled host pools, where a user might land on a different host every time they sign in — the scenario a persistent, dedicated assignment simply doesn’t create. I haven’t found a Microsoft page that states this as flatly as I’d like, so take it as my reading of how the mechanism works rather than a quoted policy: on a Personal host pool, FSLogix is there for convenience and portability, not because the architecture requires it the way a pooled deployment does.

    Doing this at scale

    Everything above is something you can configure by hand through Group Policy and the registry, and for a single host pool that’s entirely reasonable. Where it gets tedious is doing it consistently across a growing estate, and keeping it consistent as new host pools get added.

    Nerdio Manager applies FSLogix configuration as policy at the host pool level rather than per-image, and ships the offline compaction runbook mentioned above as a built-in scripted action rather than something you maintain yourself. If you’re already on NME, it’s worth checking those settings are actually being applied the way you think they are rather than assuming the defaults match what’s above.

    Where to start

    If you only do three things after reading this: check whether defragsvc is disabled anywhere in your image, add the sidecar file exclusions to your antivirus policy, and measure real profile sizes on your share before you next touch SizeInMBs. None of them take an afternoon, and each one is a support ticket you won’t get later.

  • Teams WebRTC optimisation is retiring: what AVD and Windows 365 admins need to check before October

    Teams WebRTC optimisation is retiring: what AVD and Windows 365 admins need to check before October

    Sometime in early August, some of your users are going to open Teams inside their session and get a dialogue box they’ve never seen before. It’s dismissible, so most of them will close it and carry on. A few will raise a ticket.

    That dialogue is the first visible step in retiring the WebRTC-based Teams optimisation for Windows endpoints. Microsoft set it out in Message Center post MC1239928, and it covers Azure Virtual Desktop, Windows 365 and Citrix.

    What what makes this different from most deprecations? The work isn’t really on the session host. It’s on the endpoint. And endpoints are usually the part of the estate you control least, especially if you’ve got thin clients, contractors, or people connecting from their own machines.

    This post covers what’s changing, the requirements at both ends, how to check where you actually stand today, and what stops the new stack working in locked-down environments.

    The two milestones

    The dates straight from the documentation.

    1 October 2026, End of Support. WebRTC-based optimisation carries on working, but Microsoft and Citrix no longer support it when the connection comes from a Windows endpoint. Two months before this, users see dismissible dialogues at application launch. That’s the August dialogue.

    1 April 2027, End of Availability. WebRTC stops working and the new optimisation is enforced. Two months before this one, the warning becomes a modal dialogue rather than a dismissible one. Legacy optimisation policies stop taking effect entirely.

    So there’s a six month window where the old stack still works but nobody will help you if it breaks. Plan for April. Treat October as the date support disappears, not the date you start looking at it.

    What replaces it, and why it’s actually worth having

    The new optimisation is built on SlimCore, a media engine that ships as an MSIX package and runs on the endpoint rather than inside the session.

    The feature gap is wider than I expected when I first read through it. Things the new stack does that WebRTC never did:

    • 1080p video
    • Hardware acceleration on the endpoint
    • Gallery view at 3×3 and 7×7
    • Quality of Service
    • Presenter mode
    • User-uploaded background effects, and organisational custom backgrounds with a Teams Premium licence
    • Media bypass, location-based routing and Operator Connect
    • Full Call Quality Dashboard and Teams admin center reporting, where WebRTC only gave you limited data

    The last one is the most useful for anyone running a service desk. If you’ve ever had a call quality complaint from a virtual desktop user and had almost no telemetry to work with, that changes.

    So this isn’t a deprecation that costs you features. It’s a deprecation that gives you a better product, provided you get the prerequisites lined up.

    The requirements sit at both ends

    This is where teams can get caught out. There are two version floors, and they’re in different places managed by different people.

    On the session host or Cloud PC, you need Microsoft Teams 24193.1805.3040.8975 or higher for Azure Virtual Desktop and Windows 365. If you’re patching Teams as part of your image pipeline, you’re probably fine already.

    On the endpoint, you need Windows App for Windows 2.0.352.0 or higher. The Remote Desktop client for Windows is no longer supported at all; the guidance is to move to Windows App. The endpoint also needs Windows 10 1809 as an absolute floor, four cores at 1.10 GHz, and 4 GB of RAM.

    Two details worth pulling out.

    Thin clients are explicitly covered. Windows 10 LTSC 2019 and 2021, and Windows 11 LTSC 2024, are supported as endpoints. So a thin client estate isn’t a blocker on OS grounds, though the CPU and RAM minimums are worth checking against whatever you bought three years ago. Note that this is an endpoint allowance only; LTSC is a different story on the session host side, where the Teams desktop app isn’t supported on it.

    Mac endpoints have a trap in them. You need Windows App for Mac 11.3.4 or higher, and it must be the non-App Store version, the standalone .pkg. The App Store build doesn’t bundle the plugin, so those users stay on WebRTC no matter what else you do. If you’ve got Mac users who installed Windows App themselves from the App Store because that was the obvious route, they’re on the wrong build and nothing in your management tooling will tell you.

    The plugin itself, MsTeamsPluginAvd.dll, comes bundled with Windows App. You don’t deploy it separately for AVD or Windows 365.

    How to find out where you actually stand

    Before you plan anything, get the current state. There are a few ways in, and they answer different questions.

    Inside a session, the VDI Status Indicator sits at the top left of the Teams interface. You can also go to the ellipsis, then Settings, then About. What you’re looking for is one of two strings:

    • AVD SlimCore Media Optimized means you’re on the new stack
    • AVD Media Optimized means you’re still on WebRTC

    That’s your quickest sanity check, and the one to give your service desk. If a user rings up in September asking about a dialogue box, the engineer can read the indicator and know immediately which side of the migration that user sits on.

    On the endpoint itself, SlimCore installs as an MSIX package into C:\Program Files\WindowsApps, which is locked down. Don’t go changing ACLs to look inside it. List the packages instead:

    Get-AppxPackage Microsoft.Teams.SlimCore*

    On a working endpoint with the current split package architecture you’ll get back two entries, something like Microsoft.Teams.SlimCoreVdiHost.win-x64 and Microsoft.Teams.SlimCoreVdiFwk.win-x64.<version>. Nothing returned means SlimCore never installed, and that’s your signal to look at the next section.

    Neither of those scales, though. For a fleet view, if your endpoints are Intune-managed then the Windows App version is discoverable, and that’s the number that gates everything else. Start there rather than trying to survey Teams sessions one at a time.

    The MSIX trap in locked-down estates

    This is the part I’d flag hardest, because it fails quietly and it fails specifically in the environments that are most tightly managed. Which is to say, the ones most likely to be running virtual desktops in the first place.

    SlimCore is fetched by the plugin and staged onto the endpoint as an MSIX package. That happens with no admin rights, no reboot, and no prompt. It relies on the App Readiness Service on the endpoint.

    If AppLocker, WDAC, or Group Policy blocks non-admin packaged app installation, the staging fails and Teams falls back to WebRTC. The user sees nothing; the failure lands in Event Viewer on the endpoint, as an install error. So unless someone is looking there, they simply don’t get optimised, and after April they get server-side rendering instead.

    The specific policy to look for is the one that prevents non-admin users installing packaged Windows apps. If you’ve got BlockNonAdminUserInstall enabled, you can still allow SlimCore through, but you need a recent enough Windows build for the allow-list policy to exist: KB5052094 for Windows 11 23H2 and 22H2, KB5052093 for Windows 11 24H2, KB5055612 for Windows 10 22H2, or anything later.

    That introduces a Group Policy called “Allowed package family names for non-admin user install”, under Computer Configuration, Administrative Templates, Windows Components, App Package Deployment. Allow-list the SlimCore package family names. There are two of them now, because the installer was split into a Host package and a Framework package, so a regex is cleaner than listing them:

    Microsoft.Teams.SlimCoreVdi*.*_8wekyb3d8bbwe

    If you’re running kiosk or assigned access configurations with a per-application AllAppList, SlimCore follows the UWP model, so it needs an entry there too:

    <App AppUserModelId="Microsoft.Teams.SlimCoreVdiHost.win-x64_8wekyb3d8bbwe!MsTeamsVdi" />

    This isn’t too difficult. It’s just invisible until you go looking, and it sits with whoever owns endpoint policy, who may not be the person reading the Teams Message Center post.

    What “not optimised” actually costs you

    Worth being precise about the failure mode, because it changes how you prioritise this.

    After End of Availability, if Teams can’t optimise, it falls back to server-side rendering. All the multimedia processing happens on the virtual machine.

    So it isn’t only a user experience problem. It’s a capacity problem. Media processing on the session host eats CPU you sized for something else, and on a pooled host that cost is shared with everyone else on the box. A handful of unoptimised users on a busy host pool will be felt by people who did nothing wrong.

    If you’ve done any careful sizing work, or you’re running auto-scaling with tuned thresholds, this is the bit to take seriously. Unoptimised Teams calls change the shape of your load.

    A staged plan that fits in the time available

    You’ve got until April, and the work splits reasonably cleanly.

    Start now, before the August dialogues, by getting your Windows App version distribution. That single number tells you the size of the problem. While you’re there, check the Teams version on your images so you can rule the session host side in or out.

    Before October, brief the service desk. Give them the two status indicator strings and a one-line explanation of the dialogue, so the first wave of tickets closes in thirty seconds instead of escalating to you.

    Before Christmas, deal with the awkward cohorts. Mac users on the App Store build. Thin clients that might not meet the CPU or RAM floor. Anything still on the old Remote Desktop client. These take longer than they look, because they usually involve someone else’s budget or someone else’s device.

    Then in Q1, validate the MSIX path in your locked-down configurations and confirm end to end on a real endpoint of each type you support. Get-AppxPackage plus the status indicator is enough evidence.

    Wrapping up

    The headline is a deprecation, but the substance is an upgrade. SlimCore brings 1080p, QoS, hardware acceleration and proper call quality telemetry to virtual desktops, and those are things people have been asking for on AVD for years.

    The risk isn’t the technology. It’s that this deprecation lands on the endpoint rather than the session host, so it can fall between two teams and get discovered by users instead of by you. Two months of dismissible dialogues is a generous warning, and it’s aimed at your users rather than your inbox, which is exactly why it’s worth getting ahead of.

    If you only do one thing this week, pull your Windows App version numbers. Everything else follows from that.

    Have you started auditing your endpoints for this yet? I’d be interested to hear whether the Mac App Store build has caught anyone else out, because I suspect that one is more common than people realise.

  • 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: