Modern EUC by Wayne Bellows

Tag: security

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

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

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

  • Choosing the Right Nerdio Manager Installation Method: A Practical Guide for AVD Environments

    Choosing the Right Nerdio Manager Installation Method: A Practical Guide for AVD Environments

    If you’ve ever planned a Nerdio Manager for Enterprise (NME) deployment, you may be aware that there isn’t just one way to install it. Depending on how your Azure environment is structured — identities, tenants, permissions, governance, and AVD architecture — the installation path can look very different.

    This is one of the questions I’m asked most often by customers:

    “Which installation method do I actually need to use?”

    To make this easier, I created a simple decision tree (I’ll include a diagram at the end) and broke down each installation type. Whether you’re deploying for a single small environment or a global multi-tenant estate, this guide should point you in the right direction.

    Why are there multiple installation methods?

    Nerdio Manager integrates deeply with:

    • Entra ID
    • Azure subscriptions
    • Azure Virtual Networking
    • AVD / Windows 365 resources
    • App registrations
    • Service principals
    • Resource providers

    Because every customer structures their identity and resource topology differently, NME provides installation paths for a range of real-world scenarios — including restricted RBAC environments and split-tenant setups.

    Summary of All Installation Types

    Here is a high-level overview of all six installation methods available in Nerdio Manager.

    1️⃣ Standard Install (Azure Marketplace)

    The most common and simplest deployment method.

    Use this when:

    • Your user identities and AVD resources live in the same Entra ID tenant.
    • You have the required permissions to deploy and initialise NME.
    • You don’t need to customise the Entra ID application name.

    Typical customers: Most AVD/W365 deployments, POCs, and standard single-tenant setups.

    📄 Guide: https://nmehelp.getnerdio.com/hc/en-us/articles/26124313550477-Nerdio-Manager-Installation-Guide

    2️⃣ Custom Entra ID Application Name

    Some customers need to customise the app registration name (e.g., naming conventions or multiple NME instances in the same tenant).

    Use this when:

    • You do have app creation permissions.
    • You need a non-default app name.
    • You want to avoid conflicts when deploying multiple Nerdio Manager instances.

    📄 Guide: https://nmehelp.getnerdio.com/hc/en-us/articles/26124326251405-Advanced-Installation-Methods

    3️⃣ Split Identity Deployment

    This is for customers whose user identities exist in one Entra ID tenant, while the AVD session hosts and Azure resources live in another.

    This is common with:

    • NHS Trusts
    • Shared services
    • Large groups that centralise identity
    • Multi-organisation structures

    Use this when:

    • You must separate identity governance from Azure resource management.

    📄 Guide: https://nmehelp.getnerdio.com/hc/en-us/articles/26124326194573-Advanced-Installation-Split-Identity

    4️⃣ Pre-Created Entra ID Application

    Some organisations do not allow deployment engineers to create app registrations — typically due to strict RBAC, identity governance, or Conditional Access rules.

    Use this when:

    • You don’t have permission to create an Entra ID app.
    • A separate team (Identity/Security) needs to pre-create the Nerdio app for you.
    • You’ll reference the existing App ID, Secret, and Object ID during initialization.

    📄 Guide: https://nmehelp.getnerdio.com/hc/en-us/articles/26124326326669-Advanced-installation-Create-Entra-ID-application

    5️⃣ External Identities (Guest Accounts)

    Some customers have user identities mastered in another tenant but synchronised into the AVD tenant as guest / external identities. This is not split identity — everything still runs in a single AVD tenant.

    Use this when:

    • Your users are guests from another tenant.
    • You want them to connect to AVD/Windows 365 using External Identities.
    • You want to avoid maintaining a full split-tenant architecture.

    This overlays onto Install Types 1, 2, or 4.

    📄 Microsoft announcement: https://techcommunity.microsoft.com/blog/windows-itpro-blog/windows-365-and-azure-virtual-desktop-support-external-identities-now-generally-/4468103

    6️⃣ Multi-Tenant Deployment

    Once NME is installed, you can manage AVD deployments across multiple Entra tenants from a single console.

    Use this when:

    • You’re an MSP, enterprise group, or global organisation.
    • You want one Nerdio Manager instance for multiple tenants.
    • You need unified monitoring, autoscale, images, apps, and governance across tenants.

    📄 Guide: https://nmehelp.getnerdio.com/hc/en-us/articles/26124299740685-Tenants-Overview

    Putting It All Together — The Installation Decision Tree

    I created a simple flowchart to help customers quickly identify the correct installation type. It includes:

    • Tenant topology
    • Permissions
    • Identity architecture
    • Guest user model
    • Multi-tenant requirements
    Nerdio Manager for Enterprise deployment decision tree
    NME deployment decision tree

    Final Thoughts

    Choosing the right installation method is crucial for:

    • Proper AVD lifecycle management
    • Compliance with your organisation’s identity model
    • Ensuring NME has the permissions it needs
    • Avoiding rework later
    • Supporting multi-tenant or cross-tenant architectures

    If you’re planning a new deployment or reviewing your existing setup, this guide (and the diagram) should help you pick the correct path with confidence.