Modern EUC by Wayne Bellows

Tag: technology

  • 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 #6: Regularly Right-Size Using Nerdio Advisor

    Habit #6: Regularly Right-Size Using Nerdio Advisor

    The environment you designed six months ago probably isn’t the environment you’re running today.

    Most Azure Virtual Desktop environments start out well-designed.

    VM sizes are carefully chosen.
    Host pool capacity is planned.
    Autoscale is configured.

    At the beginning, everything fits.

    But environments rarely stay static.

    Users come and go.
    Applications change.
    Workloads evolve.

    Over time, what was once the right size often becomes the wrong size.

    That’s why Habit #6 exists.

    Highly effective admins don’t assume their original VM sizing decisions are still correct.

    They validate them regularly.

    Environment Drift Is Inevitable

    Even the most disciplined environments drift.

    Over time, you may see:

    • Increased user density on session hosts
    • New applications changing resource demands
    • Departments adopting new workflows
    • Seasonal fluctuations in usage

    None of this means that something was configured incorrectly.

    It simply means the environment evolved.

    The risk comes when sizing decisions stay frozen while everything else changes.

    That’s where right-sizing becomes essential.

    What Right-Sizing Actually Means

    Right-sizing isn’t about aggressively shrinking VM sizes.

    It’s about aligning infrastructure with real demand.

    In Nerdio Manager for Enterprise, Nerdio Advisor helps surface opportunities where VM sizes or host counts no longer match usage patterns.

    It analyses:

    • CPU utilisation trends
    • Memory utilisation
    • Host density
    • Historical workload behaviour

    From this data, it can highlight potential opportunities to:

    • Reduce VM size
    • Adjust host counts
    • Improve session density
    • Eliminate unused capacity

    Advisor doesn’t force changes.

    It simply shows where optimisation may exist.

    The Three Pillars of Habit #6

    Like the other habits in this series, right-sizing becomes effective when it’s treated as a repeatable behaviour rather than a one-time task.

    Pillar 1: Review Advisor Recommendations Regularly

    Right-sizing should be part of your operational rhythm.

    Highly effective admins review Advisor recommendations periodically to understand how their environment is evolving.

    These reviews help answer questions such as:

    Are hosts consistently underutilised?
    Are machines running close to resource limits?
    Has user demand changed since the environment was first deployed?

    Looking at these trends regularly prevents small inefficiencies from turning into long-term overspend.

    Pillar 2: Validate Host Pool Sizing Against Real Demand

    Advisor recommendations are a starting point.

    Before making changes, administrators should validate recommendations against how the environment is actually used.

    Important considerations include:

    • Login storms
    • Peak usage periods
    • Critical applications
    • Future growth expectations

    Right-sizing should always balance efficiency with user experience.

    The goal is optimisation — not risk.

    Pillar 3: Make Incremental Adjustments

    The most successful optimisation strategies are gradual.

    Highly effective admins:

    • Test smaller VM sizes in validation pools
    • Adjust session density carefully
    • Monitor performance after changes
    • Iterate based on real results

    This approach ensures improvements are sustainable and predictable.

    Large, aggressive changes introduce uncertainty.

    Small, measured adjustments build confidence.

    What This Habit Enables

    When environments are regularly right-sized, several things happen.

    First, infrastructure becomes more efficient.

    Unused capacity is eliminated, and VM sizes better match the workloads they support.

    Second, costs become more predictable.

    Right-sizing ensures organisations are paying for what they actually use — not what they once needed.

    Finally, operational confidence improves.

    Administrators know their environment reflects current demand rather than historical assumptions.

    Common Mistakes to Avoid

    Right-sizing is powerful, but it can be misunderstood.

    Some common pitfalls include:

    • Treating right-sizing as a one-time exercise
    • Blindly applying recommendations without validation
    • Optimising based on short-term usage spikes
    • Reducing VM sizes too aggressively

    Good optimisation is disciplined.

    It balances cost efficiency with stability.

    How Habit #6 Builds on the Previous Habits

    By the time organisations reach Habit #6, the earlier habits have already created a stable foundation.

    Images are standardised.
    Patching is predictable.
    Applications are decoupled from images.
    Autoscale behaviour is understood.

    Only once that foundation exists does right-sizing become safe.

    Without it, changing VM sizes can introduce instability.

    With it, right-sizing becomes one of the most powerful cost optimisation tools available.

    The Real Takeaway

    Infrastructure decisions age.

    What worked six months ago may not be optimal today.

    Highly effective admins recognise this.

    They don’t rely on past assumptions.

    They validate them.

    Regular right-sizing ensures that the environment you’re running today reflects the demands of today — not the design decisions of yesterday.

    That’s the essence of Habit #6.

    Next in the series:
    Habit #7 — Optimise Log Analytics

    Monitoring is essential for maintaining visibility into your environment, but unmanaged telemetry can quietly inflate Azure costs. The final habit explores how to maintain observability while keeping analytics costs under control.

  • Habit #4: Act on Auto-Scale Insights

    Habit #4: Act on Auto-Scale Insights

    Don’t set it and forget it.

    Auto-scale is one of the most powerful features in Azure Virtual Desktop.

    It promises elasticity.
    It promises cost control.
    It promises performance stability.

    But here’s the reality:

    Most environments drift.

    Auto-scale gets configured once — often during deployment — and then quietly left alone. Months later, usage patterns have changed, user numbers have shifted, and application behaviour has evolved… but scaling logic hasn’t.

    That’s where Habit #4 comes in.

    Highly effective Nerdio admins don’t treat auto-scale as a static configuration.
    They treat it as a feedback loop.

    Auto-Scale Drift Is Normal

    Even well-designed environments don’t stay optimal forever.

    Over time:

    • Users join or leave
    • Working hours shift
    • Seasonal spikes come and go
    • Applications change resource profiles

    None of this means the original configuration was wrong.

    It just means the environment evolved.

    The problem isn’t drift.
    The problem is ignoring it.

    What Auto-Scale Insights Actually Do

    Auto-Scale Insights in Nerdio Manager for Enterprise surface where your configuration no longer reflects reality.

    They highlight:

    • Idle capacity
    • Inefficient scaling schedules
    • Burst logic that may be too conservative — or too aggressive

    Insights don’t make changes for you.
    They show you where opportunity exists.

    They turn instinct into evidence.

    The Three Pillars of Habit #4

    Like the other habits, this one breaks down into repeatable behaviours.

    You don’t need a dramatic reconfiguration.
    You need a disciplined review.

    Pillar 1: Review Insights Regularly

    Auto-scale should have an operational cadence.

    Highly effective admins:

    • Review Insights monthly (or at minimum quarterly)
    • Look for trends, not one-off anomalies
    • Treat it like a performance and cost dashboard

    Small adjustments made regularly compound over time.

    What’s dangerous isn’t one imperfect configuration.
    It’s leaving it untouched for a year.

    Pillar 2: Validate Provisioning Against Real Usage

    The question isn’t “Is autoscale enabled?”

    The question is:

    Does our current provisioning reflect how the environment is actually being used?

    Review:

    • Active and disconnected sessions per host
    • Scale-out frequency
    • Ramp, peak, and taper events
    • Host counts during low-demand periods

    As a general rule of thumb, sustained utilisation below ~60% often signals overprovisioning. Sustained utilisation above ~80% may indicate constrained performance.

    The goal isn’t to chase perfect numbers.

    The goal is alignment between capacity and demand.

    Pillar 3: Optimise Safely, Not Aggressively

    Cost optimisation should be invisible to users.

    Highly effective admins:

    • Adjust VM size incrementally
    • Modify session limits gradually
    • Tune burst thresholds cautiously
    • Validate performance after changes

    Aggressive optimisation introduces risk.

    Disciplined optimisation builds confidence.

    What This Enables

    When Auto-Scale Insights are acted on consistently:

    • Compute costs drop meaningfully
    • Scaling becomes predictable
    • Surprise overruns decrease
    • Performance stabilises

    More importantly, optimisation becomes a data exercise — not guesswork.

    This aligns strongly with my broader emphasis on disciplined, data-driven decision making.

    Common Mistakes to Avoid

    Even experienced teams fall into these traps:

    • Blindly applying every recommendation without context
    • Optimising based on one week of data
    • Ignoring seasonal workload patterns
    • Tuning autoscale before stabilising images and applications

    Order matters.

    Autoscale optimisation works best when:

    • Images are consistent
    • Patching is predictable
    • Applications are disciplined

    That foundation makes scaling behaviour easier to interpret — and safer to adjust.

    How Habit #4 Builds on the Foundation

    Habit #4 doesn’t stand alone.

    It builds on:

    • Habit #1: Standardised image management
    • Habit #2: Predictable patching
    • Habit #3: Controlled application delivery

    Only when the environment is stable does autoscale optimisation become safe.

    Otherwise, you’re just scaling instability faster.

    The Real Takeaway

    Autoscale isn’t about turning machines on and off.

    It’s about continuously aligning capacity with reality.

    Set it.
    Measure it.
    Refine it.

    That’s the habit.

    Next up: Habit #5 — Analyse Auto-Scale History
    Insights show what might be wrong. History tells you why.

  • March 31, 2026, is coming: New Azure VNets won’t have outbound internet by default — here’s the EUC-ready fix (NAT Gateway v2)

    March 31, 2026, is coming: New Azure VNets won’t have outbound internet by default — here’s the EUC-ready fix (NAT Gateway v2)

    The change that won’t hurt… until it does

    If you run Azure Virtual Desktop (AVD) or Windows 365 (Cloud PCs) in Azure, you’ve probably relied on a quiet convenience for years:

    Deploy a VM in a subnet and—without doing anything special—it can reach the internet.

    That “it just works” behavior is going away by default for new networks.

    Microsoft has confirmed that after March 31, 2026, newly created Azure Virtual Networks will default to private subnets, meaning no default outbound internet access unless you explicitly configure an outbound method.

    And here’s the trap: nothing breaks on day one. Your existing VNets keep working as they do today. Then, weeks later, someone builds a new VNet (or a new subnet), tries to deploy AVD session hosts or provision Cloud PCs… and suddenly:

    • Hosts can’t download what they need
    • Windows activation and updates don’t behave
    • Intune enrollment/sync gets weird
    • Provisioning workflows fail in ways that look like “AVD is broken” (it’s not)

    Microsoft explicitly notes that certain services (including Windows activation and Windows updates) won’t function in a private subnet unless you add explicit outbound connectivity.

    So, let’s make this change boring—in a good way. ✅

    What exactly is changing on March 31, 2026?

    ✅ What changes

    • New VNets created after March 31, 2026 will default to private subnets (Azure sets the subnet property defaultOutboundAccess = false by default).
    • Private subnets mean VMs do not get “default outbound access” to the internet or public Microsoft endpoints unless you configure an explicit egress method.

    ✅ What does not change

    • Existing VNets are not automatically modified.
    • New VMs deployed into existing VNets will continue to behave as those subnets are configured today, unless you change those subnets.

    Also important: you still have control

    Microsoft’s guidance is “secure by default,” but you can still configure subnets as non-private if you truly need to keep the default outbound behavior for a period of time.
    That said… for EUC, the better long-term move is to standardize on explicit outbound now.

    Why AVD and Windows 365 teams should care (more than most)

    EUC workloads have a long list of dependencies on outbound connectivity. A few high-impact examples:

    AVD session hosts

    • Agent/bootloader downloads and updates
    • Host registration and service connectivity
    • Windows activation + KMS / public activation flows
    • Windows Update / Defender updates
    • App install flows that fetch from internet endpoints (MSIX, Winget, vendor CDNs, etc.)
    • Telemetry and management paths (depending on your architecture)

    Windows 365 (Azure Network Connection / ANC)

    Microsoft is explicit here: for Windows 365 ANC deployments using VNets created after March 31, 2026, Cloud PC provisioning will fail unless outbound internet access is explicitly configured.

    So the question becomes: what’s the cleanest, most repeatable outbound design for EUC networks?

    Your outbound options (EUC decision guide)

    Azure recognizes several “explicit outbound” patterns.
    For EUC, these are the common ones:

    1) NAT Gateway (recommended default for most EUC spokes)

    Best when:

    • You want simple, scalable outbound for session hosts / Cloud PCs
    • You need a predictable egress IP for allow-lists
    • You don’t need deep L7 inspection for all traffic (or you’re doing that elsewhere)

    2) Firewall/NVA + UDR (hub-and-spoke inspection)

    Best when:

    • You need central inspection, TLS break/inspect, egress filtering at scale
      Trade-offs:
      • Complexity and cost
      • SNAT scaling considerations
      • You may still use NAT Gateway with firewall designs (more on that below)

    3) Standard Load Balancer outbound rules

    Best when:

    • You already have SLB, and outbound rules are a deliberate part of your design
      Trade-offs:
    • More moving parts than NAT Gateway for a simple “give the subnet internet” outcome

    4) Public IP per VM (usually a “no” for EUC)

    Trade-offs:

    • Operational overhead
    • Increased attack surface
    • Harder to govern at scale for pooled hosts / Cloud PCs

    For most AVD and Windows 365 environments, the sweet spot is:
    ➡️ NAT Gateway for outbound simplicity and scale.

    And now we have a better version of it.

    Enter NAT Gateway v2: the “make it simple” fix

    Microsoft announced StandardV2 NAT Gateway and StandardV2 Public IPs to match it. The headline improvements are exactly what EUC architects care about:

    • Zone-redundant by default (in regions with Availability Zones)
    • Higher performance (Microsoft calls out up to 100 Gbps throughput and 10 million packets/sec)
    • IPv6 support
    • Flow logs support
    • Same price as Standard NAT Gateway (per Microsoft’s announcement)

    But know the gotchas

    From Microsoft’s NAT SKU guidance:

    • Requires StandardV2 Public IPs (Standard PIP won’t work)
    • No in-place upgrade from Standard → StandardV2 NAT Gateway (replace it)
    • Some regions don’t support StandardV2 NAT Gateway (check your target region list)

    If you’re designing for EUC scale + resilience, the zone redundancy alone is a big deal.

    Walkthrough: Deploy NAT Gateway v2 for AVD / Windows 365

    Below is a practical, EUC-focused setup using the Azure portal.

    Architecture target

    • You have a VNet with one or more EUC subnets (e.g., AVD-Hosts, CloudPCs)
    • You attach one NAT Gateway v2 to those subnets
    • All outbound traffic from those subnets egresses via the NAT’s public IP(s)

    NAT Gateway is associated at the subnet level, and a subnet can only use one NAT gateway at a time (so plan accordingly).

    Step 0: Confirm your subnet posture (private vs not)

    After March 31, 2026, new VNets will default to private subnets.

    In the subnet configuration in Azure:

    • Find Default outbound access
    • If you want the secure-by-default posture, set it Disabled (private subnet)
    • Then ensure you provide explicit outbound (NAT Gateway)

    Note: if you change an existing subnet’s default outbound access setting, existing VMs may need a stop/deallocate to fully apply the change.

    Step 1: Create a StandardV2 Public IP

    NAT Gateway v2 requires a StandardV2 Public IP.

    Azure portal:

    1. Create Public IP address
    2. Set:
      • SKU: StandardV2 (static)
      • IP version: IPv4 (or dual-stack if required)
    3. Create it

    Step 2: Create the NAT Gateway (StandardV2)

    Azure portal:

    1. Create NAT gateway
    2. Set:
      • SKU: StandardV2
      • TCP idle timeout: leave default unless you have a reason
    3. On Outbound IP, attach the StandardV2 Public IP you created
    4. Create

    Microsoft’s announcement emphasizes StandardV2 NAT Gateway is zone-redundant by default in AZ regions.

    Step 3: Attach NAT Gateway v2 to your EUC subnet(s)

    Now associate it with the subnets where your session hosts / Cloud PCs live.

    Option A (from NAT Gateway):

    • NAT Gateway → Networking → add VNet/subnet associations

    Option B (from Subnet):

    • VNet → Subnets → select subnet → set NAT gateway → Save

    Once attached:

    • VMs in that subnet gain outbound connectivity through the NAT Gateway
    • Your egress IP becomes the NAT’s public IP (useful for allow-listing)

    Step 4: Validate (don’t skip this)

    For EUC, I like three quick validations:

    1. Effective routes
    • Confirm the subnet has the expected path for internet-bound traffic (0.0.0.0/0) via the platform egress with NAT.
    1. Outbound IP check
    • From a session host / Cloud PC, verify outbound IP matches your NAT public IP.
    1. EUC-specific smoke tests
    • Windows activation / licensing behavior
    • Windows Update connectivity
    • Intune enrollment/sync (if applicable)
    • Any app deployment mechanisms that pull from vendor CDNs

    Remember: Microsoft explicitly warns that private subnets need explicit outbound for services like Windows activation/updates.

    Common EUC deployment patterns (what I recommend)

    Pattern A: “EUC spoke NAT” (simple + effective)

    • Each EUC spoke VNet has a NAT Gateway v2 attached to EUC subnets
    • Keep routing simple
    • Use NSGs for egress control + consider NAT flow logs for visibility (where needed)

    Pattern B: “Hub inspection + NAT scale”

    If you route everything through a firewall/NVA for inspection, NAT Gateway can still be relevant in designs where you need scalable SNAT characteristics for outbound (especially when you’ve seen firewall SNAT constraints in the wild). This becomes an architecture conversation, but the key is: private subnets force you to be explicit, and NAT Gateway is the simplest explicit egress building block.

    “Do this before March 31, 2026” checklist

    For AVD admins, Windows 365 admins, and EUC architects:

    • Identify where your org creates “new VNets” (projects, regions, subscriptions)
    • Update your EUC network templates to include explicit outbound (NAT Gateway v2 is the default pick)
    • Standardize an allow-listing approach using the NAT’s static public IP(s)
    • Decide logging posture (do you want NAT flow logs for troubleshooting/top talkers?)
    • Run a “new VNet” dry run now (don’t wait for the deadline)
    • For Windows 365 ANC: confirm your provisioning pipelines won’t fail on new VNets without explicit outbound

    Final thought: make your cloud consistent

    This change is “secure by default,” but operationally it creates a nasty split-brain risk: old VNets behave one way, new VNets behave another.

    The easiest way to keep EUC stable is to choose a consistent outbound pattern everywhere. For most AVD + Windows 365 environments, NAT Gateway v2 is the cleanest baseline: zone-resilient, scalable, and straightforward to operate.

  • Habit #3: Centralise and Automate Application Management

    Habit #3: Centralise and Automate Application Management

    Once desktop images are standardised and patching is automated, many environments hit the next friction point: application management.

    This is often where complexity quietly creeps back in.

    Applications are installed in different ways, updated inconsistently, and tied to specific images or host pools “just to make things work.” Over time, this undermines the stability gained from good image and patch discipline.

    Highly effective admins avoid this by treating application management as a centralised, automated operating model — not a collection of one-off installs.

    This is Habit #3.

    Why application sprawl undermines otherwise well-run environments

    In less mature AVD environments, application delivery tends to evolve organically:

    • Some apps are baked into images
    • Others are installed manually
    • Updates are handled inconsistently
    • Different teams use different tools

    Initially, this can feel flexible. At scale, it becomes fragile.

    Common symptoms include:

    • Bloated desktop images
    • Longer image rebuild and testing cycles
    • Unclear ownership of applications
    • Increased support tickets following updates

    The issue isn’t the tools — it’s the lack of a consistent operating model.

    The mindset shift: applications should not define your images

    Highly effective admins make a deliberate separation:

    Images provide the foundation. Applications provide the functionality.

    When applications are tightly coupled to images:

    • Every app update forces an image change
    • Testing effort increases
    • Rollbacks become harder and riskier

    Decoupling applications from images allows teams to:

    • Keep images minimal and stable
    • Update applications independently
    • Reduce the blast radius when something breaks

    This is where Nerdio Manager for Enterprise becomes a control plane for application delivery — not just a place to manage hosts.

    The three pillars of Habit #3

    Highly effective admins consistently apply three principles when managing applications.

    Pillar 1: Decouple applications from desktop images

    Images should change slowly. Applications often don’t.

    Highly effective admins:

    • Avoid baking applications into images unless there’s a clear technical reason
    • Keep images focused on OS configuration, runtimes, and baseline security
    • Allow applications to evolve independently of the image lifecycle

    This results in:

    • Faster image rebuilds
    • Lower testing overhead
    • More predictable recovery and rollback

    Key idea:

    Images provide stability. Applications provide flexibility.

    Pillar 2: Centralise app delivery into a single operating model

    Modern AVD environments require flexibility. Different applications need different deployment approaches.

    Highly effective admins embrace this reality — but they manage it centrally, rather than allowing application delivery to fragment.

    This may include:

    • Public or private WinGet packages
    • Scripted installs using Shell Apps or Scripted Actions
    • Intune-managed applications
    • MSIX app attach (where it makes sense)
    • Legacy tooling where required, such as SCCM

    The critical point isn’t which method is used — it’s that:

    • The choice is intentional
    • Deployment is automated
    • Behaviour is predictable

    Centralisation provides:

    • Clear visibility into how applications are delivered
    • Consistent update behaviour across environments
    • Faster troubleshooting when issues arise

    The result is flexibility without fragmentation.

    Key idea:

    Different tools. One control plane.

    Pillar 3: Assign applications by intent, not infrastructure

    A common anti-pattern is allowing application differences to dictate:

    • New images
    • New host pools
    • Environment-specific workarounds

    Highly effective admins avoid this by assigning applications based on intent, such as:

    • User role
    • Team or department
    • Business requirement

    Instead of asking:

    “Which host gets this app?”

    They ask:

    “Who actually needs this app?”

    This approach:

    • Reduces image and host pool sprawl
    • Simplifies onboarding and offboarding
    • Keeps environments easier to reason about

    Importantly, this does not require App Attach. User- or group-based assignment can be achieved through multiple delivery methods, with App Attach used selectively where it provides clear value.

    Key idea:

    Apps should be delivered by need — not by where a user logs in.

    Automate application updates deliberately

    Application updates are one of the most common sources of instability.

    Highly effective admins:

    • Automate updates where appropriate
    • Control timing and scope
    • Avoid surprise changes during business hours

    Just like OS patching, application updates work best when treated as a repeatable workflow, not an ad-hoc task.

    Automation doesn’t remove control — it formalises it.

    The operational payoff

    When application management is centralised and automated:

    • Images remain lean
    • Updates become predictable
    • Rollbacks are simpler
    • Administrative effort drops significantly

    More importantly, teams gain confidence to:

    • Introduce new applications faster
    • Standardise environments
    • Scale without increasing complexity

    How Habit #3 builds on Habits #1 and #2

    Habit #3 only works because the earlier habits are already in place:

    • Habit #1 stabilises the image
    • Habit #2 stabilises the host lifecycle

    With those foundations:

    • Applications can be delivered independently
    • Updates don’t force image rebuilds
    • Failures are isolated and recoverable

    Each habit compounds the value of the last.

    Final thoughts

    Highly effective Nerdio admins don’t let applications drive infrastructure design.

    They:

    • Decouple applications from images
    • Centralise delivery
    • Assign applications by intent
    • Automate updates predictably

    This is how AVD environments remain flexible without becoming fragile.

    This article is part of an ongoing series exploring the 7 Habits of Highly Effective Nerdio Admins. Upcoming deep-dives will cover autoscale optimisation, right-sizing, and cost visibility.

  • Goodbye Hidden Single Points of Failure: AVD Regional Host Pools Explained

    Goodbye Hidden Single Points of Failure: AVD Regional Host Pools Explained

    What would you do if Azure went down in your region today?
    Not a total global outage — but a partial, messy one where your VMs are healthy, storage is fine, yet users still can’t connect.

    This scenario is why Microsoft has introduced Regional Host Pools for Azure Virtual Desktop, now available in public preview.

    This is not about making your session hosts multi-region.
    It is about removing a long-standing single point of failure in the AVD control plane.

    Let’s break down what’s changed, why it matters, and how to start using it.

    Azure resilience isn’t one thing — it’s layered

    Microsoft Azure resilience works across multiple layers:

    • Global geographies
    • Regions
    • Availability zones
    • Datacentres

    Some services (like Azure DNS or Front Door) are fully global.
    Others — virtual machines and storage — are tied to a region.

    AVD has always sat somewhere in between.

    • The control plane (metadata, brokering, app groups, workspaces) is globally distributed
    • But metadata databases were shared at a geography level

    That meant a database issue in one region could affect host pools in entirely different regions.

    Regional Host Pools are Microsoft’s fix for that architectural risk.

    What are Regional Host Pools?

    Historically, all AVD host pools used a geographical deployment model, where metadata was stored in a shared database for an entire Azure geography.

    With Regional Host Pools:

    • Each supported Azure region gets its own AVD metadata database
    • Metadata is still:
      • Replicated across availability zones
      • Replicated to a paired region for disaster recovery
    • But cross-region dependencies are removed

    The result:

    • Outages are isolated to a single region
    • The AVD control plane becomes significantly more resilient
    • You gain explicit control over where metadata lives

    This is especially important for:

    • Regulated industries
    • Public sector
    • Customers with strict data sovereignty requirements

    What actually changes when you deploy one?

    Functionally? Almost nothing.

    Architecturally? A lot.

    The only visible difference during deployment is a new field:

    Deployment Scope

    • Geographical (legacy)
    • Regional (new)

    Everything else — host pool type, validation environment, assignment type — stays the same.

    ⚠️ This does not:

    • Make session hosts multi-region
    • Replicate FSLogix profiles
    • Replace Azure Site Recovery

    It only hardens the AVD control plane.

    Public preview details (important)

    During preview:

    • Supported regions:
      • East US 2
      • Central US
    • Metadata is replicated between those paired regions
    • More regions will be added gradually as the service approaches GA

    Unsupported features (for now):

    • Session host configuration & updates
    • Dynamic autoscaling
    • Private Link
    • App Attach (still geographical only)
    • Log Analytics errors & checkpoints for regional hosts

    These will hopefully be fix by the time this feature goes GA.

    Enabling the preview

    Azure Portal

    1. Go to Subscriptions
    2. Select your subscription
    3. Settings → Preview features
    4. Register: AVD Regional Resources Public Preview

    PowerShell

    Register-AzProviderFeature `
      -ProviderNamespace Microsoft.DesktopVirtualization `
      -FeatureName AVDRegionalResourcesPublicPreview

    If you’re deploying via PowerShell, you’ll also need:

    • Az.DesktopVirtualization 5.4.5-preview
    • The -DeploymentScope Regional parameter

    Can you convert existing host pools?

    Not yet.

    Currently, you have three options:

    • Wait for Microsoft’s upcoming migration tooling
    • Create a new regional host pool, then:
      • Generate a new registration token
      • Reinstall the AVD agent
      • Move hosts across
    • Use this in testing and labs only (the safest option during preview)

    Also note:

    • Regional objects cannot be linked to geographical ones
    • Host pools, app groups, and workspaces must all share the same deployment scope

    Why this really matters

    Microsoft has been very clear:

    Regional host pools are the future of Azure Virtual Desktop.

    At some point:

    • Creating geographical host pools will be blocked
    • Geographical infrastructure will be retired
    • Regional will be the default — and the expectation

    This change:

    • Removes a hidden single point of failure
    • Improves outage isolation
    • Gives customers real control over metadata placement

    It’s one of the most meaningful architectural improvements AVD has had in years.

    Final thoughts

    If you’re running production workloads today:

    • Start planning your transition
    • Track feature parity as preview limitations close
    • Begin using regional host pools for new environments

    This isn’t a flashy feature — but it’s a foundational one.
    And those are usually the changes that matter most.

  • Habit #1: Standardise and Automate Desktop Image Management

    Habit #1: Standardise and Automate Desktop Image Management

    If you want a stable, cost-efficient Azure Virtual Desktop environment, everything starts with the desktop image.

    Before auto-scale tuning, before patch automation, before application strategy — the quality and consistency of your image determines how effective everything else can be.

    In almost every inefficient AVD environment I’ve reviewed, image management is either:

    • Manual
    • Inconsistent
    • Poorly documented
    • Or all three

    Highly effective admins treat image management as a repeatable, automated process, not a one-off task. This is where real operational and cost gains begin.

    Why desktop image management is foundational

    Your desktop image influences:

    • How quickly can new session hosts be deployed
    • How predictable the user experience is
    • How easy it is to troubleshoot incidents
    • How confidently can we automate later stages

    If image management is inconsistent, every downstream optimisation becomes harder and more expensive.

    The common anti-patterns

    In less mature AVD environments, image management often looks like this:

    • Images built manually in the Azure portal
    • Multiple “golden images” with no clear owner
    • No versioning or rollback strategy
    • Apps are baked in inconsistently
    • No naming or governance standards

    These patterns increase:

    • Operational risk
    • Engineering effort
    • Time to recover from issues

    How highly effective admins manage images

    Highly effective admins standardise and automate image management using Nerdio Manager for Enterprise as the control plane.

    Their approach focuses on consistency, governance, and repeatability.

    1. Create images directly in Nerdio

    Images are created and managed inside Nerdio rather than manually in Azure.

    This provides:

    • A guided, repeatable workflow
    • Built-in automation for image creation and sealing
    • Clear visibility into image state and lifecycle

    The goal is not speed — it is consistency.

    Understanding how Nerdio captures images (and why it matters)

    It’s worth briefly explaining how image capture works in Nerdio, as this directly impacts where applications, automations, and OS changes should be applied — and it’s one of the most common areas of confusion I see with customers.

    When you create a desktop image in Nerdio, the process starts by creating a source image VM.

    At this point, you have two paths.

    Option 1: “Do not create image object” (recommended)

    If you select Do not create image object during image creation, Nerdio will:

    • Create the source image VM
    • Stop the workflow at that point

    No image object is captured yet.

    This is useful when you want to:

    • Install applications
    • Run automations or scripted actions
    • Apply OS or security configuration

    …directly on the source VM before capturing the image.

    This approach ensures the source VM is always:

    • Fully up to date
    • Free of security vulnerabilities
    • Aligned with what admins expect to see when they later edit the image

    Because of this, this is the approach I generally recommend.

    Option 2: Automatic image capture via a temporary VM

    If you don’t select this option, Nerdio will:

    • Take a copy of the source VM’s OS disk
    • Create a temporary VM from that disk
    • Run any configured automations or application deployments on the temp VM
    • Sysprep the temp VM
    • Capture the final image object

    The key thing to understand here is:

    Any configurations applied during image creation are applied only to the temporary VM, not the source VM.

    This distinction is subtle but important — and it’s the single biggest cause of confusion I see when customers later expect to find changes on the source image VM.

    Nerdio Image Creation Process
    Nerdio Image Creation Process

    Why this matters operationally

    If admins later:

    • Edit the source image VM
    • Expect applications or settings to be present
    • Or assume the source VM reflects the deployed image

    They can be caught out if those changes were applied only to the temp VM.

    For that reason, keeping the source image VM as the authoritative, up-to-date representation of the image avoids ambiguity and reduces operational risk.

    Common image creation pitfalls to be aware of

    Trusted Launch and BitLocker

    Trusted Launch is a great security feature and one I generally recommend — but it’s important to understand its side effects.

    • Enabling Trusted Launch automatically enables BitLocker
    • If BitLocker is enabled when Sysprep runs, image capture will fail

    To avoid this:

    • Either disable BitLocker before capturing the image
    • Or select Trusted Launch supported instead of Trusted Launch

    The Trusted Launch supported option keeps the image compatible with Trusted Launch host pools without enabling BitLocker on the image VM.

    Marketplace images and BitLocker (Windows 11 / 25H2)

    When building a desktop image from newer marketplace images (such as Windows 11 25H2), BitLocker is enabled by default.

    Before capturing an image, you must:

    • Explicitly disable BitLocker on the source VM

    Why does BitLocker sometimes re-enable itself

    I’ve also seen cases where:

    • BitLocker is disabled on the source VM
    • An image is captured successfully
    • Session hosts are deployed
    • BitLocker later re-enables automatically

    If this behaviour is not desired, you can prevent it by setting the following registry value on the image:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BitLocker
    PreventDeviceEncryption

    This ensures BitLocker does not automatically re-enable on newly deployed hosts.

    2. Maintain a single source-of-truth image per workload

    Once image creation is standardised, the next critical step is controlling image sprawl.

    Highly effective admins deliberately limit the number of desktop images they manage. Rather than creating bespoke images for every host pool or team, they define a single source-of-truth image per workload.

    Examples might include:

    • A core Office/knowledge worker image
    • A Power BI or data analyst image
    • A developer tooling image

    Each image has a clear purpose, a defined owner, and a documented scope.

    Why image sprawl is so expensive

    In environments where image governance is weak, I often see:

    • Slightly different images per host pool
    • “Temporary” images that become permanent
    • Multiple images solving the same problem in different ways

    This quickly leads to:

    • More patching effort
    • More testing effort
    • Inconsistent user experience
    • Longer incident resolution times

    Every additional image increases operational cost — even if Azure spend looks unchanged.

    What “source of truth” actually means

    A source-of-truth image is:

    • The authoritative image for a workload
    • Used consistently across environments
    • Updated intentionally, not ad hoc

    When something breaks in production, admins can immediately ask:

    “Did this come from the image — or somewhere else?”

    That clarity is invaluable during incidents and change reviews.

    Shared images across environments

    Highly effective admins use the same image version across:

    • Test
    • Validation
    • Production
    • (Where appropriate) DR

    This does not mean skipping testing. It means:

    • Test the image once
    • Promote the same version forward

    This dramatically reduces:

    • Duplicate testing
    • Configuration drift
    • Environment-specific surprises

    Avoiding the ‘one image per host pool’ trap

    A common misconception is that:

    “Each host pool needs its own image.”

    In reality, most differences between host pools can be handled through:

    • Application delivery mechanisms
    • Configuration at host creation
    • User or group targeting

    Keeping the image itself generic and workload-focused preserves flexibility while keeping maintenance overhead low.

    Operational benefits

    Maintaining a single source-of-truth image per workload:

    • Simplifies troubleshooting
    • Reduces admin effort
    • Improves predictability
    • Makes audits and reviews easier

    More importantly, it ensures image management scales with the business, not against it.

    Where this fits in the bigger picture

    Without this discipline:

    • Patch automation becomes risky
    • Reimaging becomes inconsistent
    • Autoscale amplifies mistakes faster

    With it:

    • Every downstream automation becomes safer and easier to reason about

    This is why source-of-truth images are a core maturity marker in well-run AVD environments using Nerdio Manager for Enterprise.

    3. Keep desktop images intentionally minimal

    One of the biggest differentiators between mature and immature AVD environments is what gets baked into the image.

    Highly effective admins design desktop images to be intentionally minimal. The goal is not to create a “fully loaded” desktop, but a stable, predictable foundation that can be reused everywhere.

    What belongs in the image

    A well-designed image typically includes:

    • Core OS configuration
    • Required runtimes and frameworks (e.g., VC++ redistributables, .NET)
    • Baseline security and system settings

    These are components that:

    • Change infrequently
    • Are required for almost every user
    • Would cause instability or performance issues if missing

    What does not belong in the image

    Equally important is what you intentionally exclude.

    Highly effective admins avoid baking in:

    • Frequently updated applications
    • Department-specific tools
    • User-driven or role-specific software
    • Anything that requires frequent testing

    Including these increases:

    • Image rebuild frequency
    • Testing effort
    • Risk of regressions

    And, over time, image management becomes a bottleneck rather than an enabler.

    Why “fatter” images create operational drag

    Images that try to do everything tend to:

    • Take longer to build and validate
    • Break more often
    • Require more rollbacks
    • Slow down troubleshooting

    When something goes wrong, it becomes much harder to determine:

    “Is this an app issue, or an image issue?”

    Minimal images dramatically reduce that ambiguity.

    Design images to change slowly

    A good rule of thumb is:

    If something changes weekly, it probably doesn’t belong in the image.

    Highly effective admins treat the image as:

    • A stable baseline
    • Updated deliberately
    • Changed only when there is a strong justification

    This allows image updates to be:

    • Planned
    • Tested
    • Communicated clearly

    Minimal images enable flexibility later

    Keeping images lean gives you more options downstream:

    • Applications can be layered or targeted
    • Different user groups can share the same image
    • Host pools remain flexible without image duplication

    This is what allows a single source-of-truth image to support multiple use cases without compromise.

    The operational payoff

    Minimal images result in:

    • Faster image build times
    • Easier validation
    • Lower maintenance overhead
    • Fewer production incidents

    Over time, this translates directly into:

    • Lower operational cost
    • Higher platform confidence
    • Easier scale

    Why this matters before moving on

    If images are overloaded:

    • Patching becomes risky
    • Reimaging becomes disruptive
    • Automation amplifies mistakes

    Minimal images are what make safe automation possible, which is why this step is a prerequisite for everything that follows.

    4. Version images deliberately and manage them through Azure Compute Gallery

    Once images are standardised, minimal, and controlled, the next maturity step is treating them as versioned assets rather than mutable objects.

    Highly effective admins never modify images in place. Every meaningful change results in a new image version, managed and stored through Azure Compute Gallery (ACG).

    Why in-place image changes are risky

    Without proper versioning, image changes tend to:

    • Overwrite working configurations
    • Remove rollback options
    • Obscure the root cause of issues

    When something breaks, the question becomes:

    “What changed — and when?”

    If you can’t answer that confidently, versioning isn’t being used effectively.

    What good image versioning looks like

    Effective image versioning has a few consistent traits:

    • Each image change produces a new version
    • Versions are immutable once created
    • There is a clear promotion path (test → prod)
    • Old versions are retained only as long as they add value

    This creates:

    • Predictable change management
    • Safer deployments
    • Faster incident resolution

    Why Azure Compute Gallery matters

    Storing images in Azure Compute Gallery adds governance that manual image management simply can’t provide.

    It enables:

    • Native image versioning
    • Controlled replication
    • Cross-region reuse if required
    • Lifecycle management of old versions
    • Trusted Launch and Confidential VM support

    For organisations with multiple regions or DR requirements, this becomes essential rather than optional.

    Controlling image sprawl with retention policies

    Highly effective admins don’t keep every image version forever.

    They:

    • Retain a defined number of previous versions
    • Automatically clean up older images
    • Keep enough history for rollback without creating clutter

    This avoids:

    • Unmanaged image growth
    • Confusion during deployments
    • Unnecessary storage overhead

    Versioning without retention is just delayed sprawl.

    Operational clarity during incidents

    When images are versioned and centrally managed, incident response becomes much simpler.

    Admins can immediately identify:

    • Which image version is in use
    • When it was introduced
    • What changed compared to the previous version

    This shortens:

    • Mean time to identify issues
    • Mean time to recover
    • Overall impact on users

    Why does this enable everything that follows

    Image versioning is what makes:

    • Patch automation safe
    • Scheduled reimaging predictable
    • Autoscale reliable
    • Rollbacks low-risk

    Without it, automation amplifies uncertainty. With it, automation becomes controlled and reversible.

    The maturity signal

    If you want a quick indicator of image maturity, ask:

    Can we roll back our desktop image confidently and quickly?

    If the answer is yes, versioning is working. If not, it isn’t.

    5. Apply clear naming standards and lightweight image governance

    By the time image creation, scope, minimalism, and versioning are in place, the final step is often the most overlooked — making images easy to understand and safe to operate.

    Highly effective admins apply simple, consistent naming standards and lightweight governance to prevent mistakes before they happen.

    Why naming matters more than it seems

    In environments without naming standards, images quickly become:

    • Hard to distinguish
    • Easy to misuse
    • Risky during changes or incidents

    Admins end up asking:

    “Is this the current image?” “Is this safe to deploy?” “What does this image actually contain?”

    Those questions cost time — and time costs money.

    What good image naming looks like

    Effective naming conventions are:

    • Predictable
    • Descriptive
    • Human-readable

    A common and effective pattern is:

    OS | Workload | Image Version | Build Date

    For example:

    Win11 | Office | v1.3 | 2025-01

    From the name alone, anyone should be able to tell:

    • What OS is it based on
    • Who it’s intended for
    • Whether it’s current or obsolete

    Clearly distinguish active vs deprecated images

    Highly effective admins make it obvious which images:

    • Are approved for deployment
    • Are retained for rollback only
    • Should no longer be used

    This can be achieved through:

    • Naming conventions
    • Descriptions or tags
    • Controlled access – stage image as inactive

    Ambiguity is one of the most common causes of accidental misconfiguration.

    Keep governance intentionally lightweight

    Image governance does not need to be heavy or bureaucratic.

    In practice, it usually means:

    • Defined ownership of each image
    • Clear promotion criteria (e.g., tested, approved)
    • Agreement on when images are retired

    The goal is not process for its own sake — it’s operational safety.

    Why this matters at scale

    As environments grow:

    • More admins get involved
    • Changes happen more frequently
    • The cost of mistakes increases

    Clear naming and governance:

    • Reduce human error
    • Speed up troubleshooting
    • Make handovers and audits easier

    It’s one of the highest ROI habits you can adopt.

    The final maturity check

    A simple test:

    Could a new admin confidently select the correct image without asking for help?

    If the answer is yes, governance is working.

    The cost optimisation impact

    Standardised image management:

    • Reduces build and provisioning time
    • Lowers troubleshooting effort
    • Prevents configuration drift
    • Enables every downstream automation to work reliably

    While image management alone won’t cut your Azure bill in half, it enables every other optimisation habit to work properly.

    Final thoughts

    If your image process is manual or inconsistent, no amount of auto-scale tuning will fully compensate for it.

    Highly effective Nerdio admins:

    • Standardise and automate image creation
    • Govern image usage
    • Version everything
    • Let automation do the heavy lifting
    • Treat images as managed assets

    This is the foundation that makes all other AVD cost and performance optimisations possible.

    Once image management is under control, you can safely move on to automating patching and host lifecycle, which is where Habit #2 begins.

    This article is part of an ongoing series expanding on the 7 Habits of Highly Effective Nerdio Admins. Deep-dives into each habit will follow, with practical guidance you can apply directly to your environments.

  • 7 Habits of Highly Effective Nerdio Admins

    7 Habits of Highly Effective Nerdio Admins

    How the best teams optimise Azure Virtual Desktop with Nerdio Manager

    Optimisation in Azure Virtual Desktop (AVD) is not achieved through a single setting or feature. The most successful environments are run by admins who apply consistent operational habits, leverage automation, and regularly review data-driven insights.

    After working with many production AVD environments, a clear pattern emerges. The most efficient, stable, and cost-effective deployments all share the same behaviours.

    Below are 7 habits of highly effective Nerdio admins and how they use Nerdio Manager for Enterprise to optimise without sacrificing performance or user experience.

    1. Standardise and automate desktop image management

    Highly effective admins never build images manually in Azure.

    Instead, they:

    • Create and manage desktop images directly in Nerdio
    • Automate sysprep, sealing, and versioning
    • Maintain clean, repeatable image pipelines

    This approach:

    • Eliminates configuration drift
    • Reduces troubleshooting time
    • Enables predictable re-imaging and scaling
    • Lowers operational overhead

    A well-maintained image is the foundation of every efficient AVD environment.

    2. Automate Windows patching (and stop firefighting)

    Manual patching is expensive — not just in Azure costs, but in engineer time and risk.

    Effective admins:

    • Automate Windows Updates on desktop images
    • Patch personal host pools directly where appropriate
    • Schedule updates x days after Patch Tuesday
    • Combine patching with automated image updates and host re-imaging

    The result:

    • Consistent security posture
    • Reduced downtime
    • Fewer emergency maintenance windows
    • Predictable change control

    Automation here directly translates to lower operational cost and reduced risk.

    https://nmehelp.getnerdio.com/hc/en-us/articles/35702669333133-How-can-I-automate-Windows-patching-on-desktop-images-and-session-hosts

    3. Centralise application management with Unified Application Management

    Application sprawl is one of the fastest ways to lose control of costs.

    Top Nerdio admins use Unified Application Management (UAM) to:

    • Deploy applications at image build or host creation
    • Automate app updates
    • Eliminate manual installs and custom scripts

    They standardise on supported methods such as:

    • Public and private WinGet
    • Shell Apps
    • Intune
    • App Attach
    • SCCM integrations

    This delivers:

    • Faster host provisioning
    • Fewer image rebuilds
    • Reduced support incidents
    • Lower administrative effort over time

    Consistency equals efficiency.

    4. Act on Auto-Scale Insights — not assumptions

    Auto-scale configuration should never be “set and forget”.

    Highly effective admins:

    • Regularly review Auto-Scale Insights recommendations
    • Validate whether host pools are under- or over-provisioned
    • Adjust scaling logic based on real usage patterns

    These insights surface:

    • Idle capacity
    • Over-sized VM SKUs
    • Inefficient scaling schedules

    Admins who act on this data consistently achieve meaningful compute cost reductions without impacting user experience.

    5. Analyse Auto-Scale history to understand real behaviour

    Insights tell you what might be wrong. History tells you why.

    The best admins:

    • Review Auto-Scale Configuration History
    • Correlate scale-out and scale-in events with session counts
    • Analyse CPU and memory utilisation over time

    This enables:

    • Fine-tuning of session limits per host
    • Right-sizing VM families
    • Confident scaling decisions backed by evidence

    Cost optimisation becomes a data exercise — not guesswork.

    6. Regularly right-size using Nerdio Advisor

    Even well-designed environments drift over time.

    Effective admins:

    • Review Nerdio Advisor right-sizing recommendations
    • Validate host pool sizing against current demand
    • Identify opportunities to reduce VM size or count

    This is especially powerful after:

    • User growth or reduction
    • Application changes
    • Seasonal usage patterns

    Small, regular adjustments prevent long-term overspend.

    7. Optimise Log Analytics instead of accepting default costs

    Monitoring is essential — but unmanaged telemetry can quietly inflate Azure bills.

    Highly effective admins:

    • Review Log Analytics data collection
    • Adjust polling intervals and counters
    • Reduce retention where appropriate
    • Balance visibility with cost

    By tuning Log Analytics properly, teams maintain observability while avoiding unnecessary ingestion and storage costs.

    Final thoughts

    Optimisation in AVD is not about cutting corners — it is about operating deliberately.

    Admins who adopt these seven habits:

    • Spend less on Azure
    • Reduce operational toil
    • Improve stability and security
    • Scale with confidence

    If you are already using Nerdio Manager, these capabilities are available today. The difference is not tooling — it is how consistently the tooling is used.

    This is the starting point. I’ll be sharing detailed deep dives into each habit soon, focusing on practical configuration and optimisation tips.

  • AVD Full Cloud-Native Setup With Nerdio- FSLogix with Entra-only Azure Files (No Domain Controllers)

    AVD Full Cloud-Native Setup With Nerdio- FSLogix with Entra-only Azure Files (No Domain Controllers)

    If you’ve been waiting to run Azure Virtual Desktop (AVD) + FSLogix without Windows AD domain controllers or Microsoft Entra Domain Services, Microsoft has now introduced a public preview capability that makes it possible: Microsoft Entra Kerberos authentication for Azure Files SMB with cloud-only identities.

    This unlocks a true cloud-native pattern where:

    • Users are sourced from Microsoft Entra ID (cloud-only)
    • Session hosts are Entra-joined
    • FSLogix profile containers are stored on Azure Files
    • No DCs / no AAD DS required

    Microsoft announced this preview in late 2025 as part of the broader “cloud-native identity” push for Azure Files.

    https://techcommunity.microsoft.com/blog/azurestorageblog/cloud-native-identity-with-azure-files-entra-only-secure-access-for-the-modern-e/4469778

    Important Preview Notice

    This feature is an early public preview, so expect:

    • Documentation changes
    • Portal UI differences (including preview portal links)
    • Updated prerequisites/limitations as it approaches GA

    Treat this as lab first → pilot → production.

    High-Level Steps

    1. Create a storage account and enable Microsoft Entra Kerberos authentication with default share-level permissions (current preview limitation)
    2. Grant admin consent to the Storage Account service principal
    3. Update tags in the App Registration manifest
    4. Disable / exclude MFA for the storage account (Conditional Access)
    5. Configure FSLogix Profile and Session Hosts to Retrieve Kerberos Tickets (registry)
    6. Configure Directory and File-Level Permissions for FSLogix (Critical)
    7. Test end-to-end using an Entra-joined session host + cloud user

    Prerequisites (Read This First)

    OS requirements

    Entra Kerberos for cloud-only identities requires:

    • Windows 11 Enterprise/Pro (single or multi-session), or
    • Windows Server 2025, with the latest updates applied.

    https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-hybrid-identities-enable?tabs=azure-portal%2Cintune

    Identity-source limitation

    A Storage Account cannot authenticate to multiple directory sources simultaneously (you must pick one method per account).

    https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-hybrid-identities-enable

    Share-permissions limitation (preview)

    For cloud-only identities in this preview, default share-level permissions are the supported approach (applies to all authenticated users accessing shares in the account).

    https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-assign-share-level-permissions

    Cloud availability

    This capability is currently scoped to the Azure public cloud, with limitations outlined in Microsoft documentation.

    https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-hybrid-identities-enable

    Recommended test design

    • AVD host pool with Entra ID-joined session hosts
    • Azure Files Premium
    • Two Entra groups: Storage Admin / Cloud Users

    Step 1 — Create Storage Account and Enable Microsoft Entra Kerberos Authentication on Storage Account with Default Share-Level Permissions

    1. In Nerdio Manager, navigate to Storage → Azure Files
    2. Select New Azure Files
    3. Enter the storage account name, location, performance, replication, file share name, and capacity
    4. Enable Share-level permission, select SMB Share Contributor, and add the user(s)/group(s) into Permissions (SMB share contributors)
    5. Enable Join AD or Entra ID and select Entra ID
    6. For NTFS file-level permissions, select None
    7. Ok
    Create Azure Files Share in NME
    Create Azure Files Share

    This links Azure Files SMB identity-based access to Entra Kerberos.

    https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-hybrid-identities-enable

    Step 2 — Grant Admin Consent to the Storage Account Service Principal

    You must grant admin consent once per storage account used with Entra Kerberos.

    1. Go to Microsoft Entra ID
    2. Navigate to App registrations → All applications
    3. Find the Storage Account app registration (it typically appears with a bracket prefix, [Storage Account xxx.file.core.windows.net])
    4. Open it → Manage → API permissions
    5. Click Grant admin consent for your tenant
    6. Yes

    This enables the storage account’s app registration to operate correctly for the Entra Kerberos flow.

    https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-hybrid-identities-enable

    Step 3 — Update Tags in the Application Manifest File

    This is one of the “preview sharp edges.”

    1. In the same App Registration, go to Manifest
    2. Locate the tags attribute
    3. Add “kdc_enable_cloud_group_sids”
    4. Save
    Tags in the application manifest
    Tags in the application manifest

    In GA, this may become automated, but for now it’s part of the manual setup path.

    https://learn.microsoft.com/en-us/entra/identity/authentication/kerberos

    Step 4 — Disable MFA for Storage Account Access (Conditional Access Exclusion)

    Entra Kerberos does not support MFA for Azure Files SMB access. If MFA is enforced, you may see errors such as System error 1327 / sign-in restrictions.

    Everyone’s Conditional Access policies will be different; you’ll need to ensure any policies enforcing MFA for all resources and applied to AVD users have an exclusion for the storage account.

    What to do:

    1. Go to Conditional Access
    2. Identify policies that target all resources
    3. Add an exclusion for the Storage Account “app” (search it by name [Storage Account xxx.file.core.windows.net])
    4. Save

    This is a common “why can’t I map the drive” failure mode during testing.

    Step 5 — Configure FSLogix Profile and Session Hosts to Retrieve Kerberos Tickets

    If you skip this, you may get:

    • Credential prompts when mapping the share
    • System error 86

    You must add a registry key to each Entra-joined session host that will access the share. Nerdio can configure this registry value and the FSLogix settings as part of the FSLogix Profiles Storage Configuration.

    • Nerdio Manager → Profiles Management → New profile → FSLogix
    • Enter the profile name
    • Select Configure session hosts registry for Entra ID joined storage
    • Enter the FSLogix Profiles path (VHDLocation), the UNC path of your storage account, share, and directory (\\<storageaccount>.file.core.net\<share>\<directory>]
    • Configure your remaining FSLogix profile settings
    • Ok
    NME FSLogix Profiles Storage Configuration
    FSLogix Profiles Storage Configuration

    https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-hybrid-identities-enable

    Important caveat: This setting can prevent on-premises AD-joined clients from accessing storage accounts via the legacy flow; if you need both Entra and Windows AD access patterns, realm mapping may be required (scenario-specific).

    Step 6 — Configure Directory and File-Level Permissions for FSLogix (Critical)

    Even if FSLogix “works” without this, you risk a serious security issue:

    • Users may be able to access other users’ profile containers

    6A) Validate you can mount the share (from an Entra-joined session host)

    Log on to a session host as a member of your “Storage Admin” Entra group, then run from Command Prompt:

    • net use X: \\<storageaccount>.file.core.windows.net\<share>

    If it fails:

    • Verify Step 5 registry key is present
    • Reboot the session host (often required during early preview workflows)

    6B) Set ACLs using Azure Portal “Manage access” (not File Explorer / icacls)

    In cloud-only identity mode, Microsoft provides an Azure Portal ACL experience for Windows-style permissions on Azure Files SMB.

    https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-configure-file-level-permissions

    Preview portal link:

    (If “Manage access” is not visible in the standard portal UI, use that preview link.)

    • In the Azure portal, navigate to your storage account
    • Data storage → Files shares → select share → Browse → three dots → Manage access
    • Delete everything except the CREATOR OWNER
    • Add your storage admin group with Full control
    • Add your user group and change it to Applies to this folder with Modify access
    Azure Files Share Manage Access
    Manage access

    https://learn.microsoft.com/en-us/fslogix/how-to-configure-storage-permissions

    Why this works:

    • Users can create their own profile folder
    • Creator Owner grants them rights within the folder they created
    • They cannot access other users’ folders
    • Storage admins can troubleshoot, recover, and clean up profiles

    Once configured, save and re-check permissions in the portal or via folder security view (Windows UI may show Entra objects as SIDs in some builds).

    https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-configure-file-level-permissions

    Step 7 — Test End-to-End (Moment of Truth)

    1. Log in to AVD as a user in your AVD Users Entra group
    2. Confirm the session signs in successfully (good indicator)
    3. On a session host logged in as a Storage Admin, open the share
    4. Confirm a new user folder is created
    5. Confirm folder/file ACLs show

    You can validate per-folder permissions either:

    • In the Azure portal → Browse → drill into the user profile folder → Manage access
    • Or via Windows folder properties/security view (bearing in mind Entra objects may show as SIDs).

    https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-configure-file-level-permissions

    Operational Notes for Production

    Conditional Access design

    You will likely need a targeted strategy such as:

    • Exclude the storage account app from MFA requirements
    • Keep MFA for interactive user sign-in, but avoid breaking SMB access. This is a common real-world friction point.

    Keep tracking preview updates

    Microsoft is positioning this as a foundational capability for modern workloads, including AVD/FSLogix.

    https://techcommunity.microsoft.com/blog/azurestorageblog/cloud-native-identity-with-azure-files-entra-only-secure-access-for-the-modern-e/4469778

    References (Microsoft)

    References (Nerdio)