Azure Virtual Desktop FSLogix Profiles with Entra ID Only

Can we run Azure Virtual Desktop with FSLogix profiles and Microsoft Entra ID, but without keeping a traditional Active Directory environment alive purely because somebody once said that file shares require a domain controller?

When I recorded this video in March 2026, that was the question I wanted to answer. I built an Entra-joined AVD session host, stored the user profile in Azure Files and worked through the permissions and FSLogix configuration needed to make the profile attach.

The demonstration also includes something I always prefer to leave in: it fails the first time. A successful wizard tells us that the wizard works. A failed sign-in followed by the logs telling us exactly what is wrong teaches us rather more.

There has been an important change since the video was published. Microsoft made FSLogix support for cloud-only and external identities generally available in May 2026. The current supported design uses Microsoft Entra Kerberos for Azure Files, so I will explain both what the video demonstrates and how I would build the solution now.

The profile cannot stay on one session host

In a pooled Azure Virtual Desktop host pool, a user is not guaranteed to return to the same session host every morning.

If the profile lives only under C:\Users on the first VM, the user can land on a second VM and receive a new local profile. Their application settings, Outlook data, OneDrive state and personalisation appear to have vanished. Nothing has technically vanished, of course. It is sitting safely on the wrong machine, which is not much comfort to the person staring at an unfamiliar desktop.

FSLogix profile containers solve this by placing the complete Windows profile inside a VHD or VHDX file on shared storage. At sign-in, FSLogix attaches that container to whichever session host accepted the connection. Windows sees a normal profile, while the profile itself can move between hosts.

The useful mental model is:

User signs in to Azure Virtual Desktop
→ A session host accepts the connection
→ FSLogix locates the user's container on Azure Files
→ The VHDX attaches to the session host
→ Windows presents it as the user's normal profile

Compute can now be replaced or scaled independently of the profile. That separation is one of the main reasons pooled desktops are practical.

Entra-only does not mean identity-free

Removing Active Directory Domain Services does not remove authentication and authorisation. It changes which system performs them.

There are several identities involved:

• The user signs in to Azure Virtual Desktop with a Microsoft Entra identity.
• The session host is joined directly to Microsoft Entra ID.
• Azure Files must authenticate the SMB connection.
• Azure RBAC and file-level permissions decide what the user can do inside the share.
• FSLogix needs the UNC path and permission to create or attach the correct profile container.

Microsoft now fully supports Microsoft Entra joined session hosts accessing Azure Files for cloud-only FSLogix users. The current design uses Microsoft Entra Kerberos authentication for Azure Files.

The user signs in, Windows retrieves a cloud Kerberos ticket and the SMB service uses that ticket to authenticate access to the file share. There is no need for the session host to have network line-of-sight to a domain controller.

That last sentence is the important one. We have not somehow taught SMB to ignore identity; we have given it a cloud identity path.

What changed after the video?

The video shows the preview-era route I used at the time. I enabled a system-assigned managed identity on the session host, assigned Azure Files permissions to the AVD users and host identity, and configured FSLogix with AccessNetworkAsComputerObject so the storage connection could use the computer context.

The demonstration works, but a new deployment should follow the current generally available guidance rather than copy an older preview sequence without checking it.

Microsoft announced general availability for cloud-only and external-identity FSLogix profiles in May 2026. The current documented path includes:

1. Enable Microsoft Entra Kerberos on the storage account.
2. Assign share-level access and configure file-level permissions.
3. Configure the storage account’s Entra application so users can obtain tickets silently.
4. Enable cloud Kerberos ticket retrieval on the session hosts.
5. Configure credential-key roaming for the Entra account.
6. Configure FSLogix with the Azure Files UNC path.

For cloud-only groups, the storage application’s manifest also needs the kdc_enable_cloud_group_sids tag described in the Microsoft guidance. This allows the Kerberos ticket to carry the relevant cloud group SIDs.

The feature may now be generally available, but the setup has not been mistaken for a one-page wizard. Microsoft has left us some character-building work to do.

Build the storage around the desktop workload

Microsoft recommends Azure Files for most AVD FSLogix deployments. The storage account should be close to the session hosts because profile attachment is sensitive to latency. Current Azure Files guidance for virtual desktop workloads recommends keeping the profile storage in the same Azure region as the host pool.

The video uses a standard provisioned v2 file share with locally redundant storage for a small demonstration. Production choices should be based on concurrent users, profile size, sign-in IOPS, resilience and recovery requirements rather than on whatever defaults happened to be on the portal page.

Important decisions include:

• HDD or SSD Azure Files.
• Pay-as-you-go or provisioned capacity.
• The number of users and containers per share.
• Backup and recovery requirements.
• Public network access, selected networks or private endpoints.
• Redundancy and disaster-recovery design.

The file share is not merely a cheap place to put a large file. It is in the sign-in path for every user. If it is slow or unavailable, the desktop experience will be slow or unavailable with impressive consistency.

Permissions have two layers

One of the easiest mistakes is to configure only Azure RBAC and assume that the job is complete.

Azure Files has two relevant permission layers:

• Share-level permission, normally assigned with Azure RBAC.
• Directory and file-level permission inside the share.

Users need sufficient access to create their own profile directory and then use their own container without being able to browse everybody else’s profile. Administrators need separate rights to manage the share. Microsoft provides a recommended permission model in its FSLogix and Entra ID configuration guide.

Assign access through groups rather than directly to individual users. In the video, my first test fails because Bob is not actually a member of the AVD users group that received the share permission. I temporarily assign Bob directly to prove the cause, but that is a troubleshooting step, not a design pattern.

The corrected flow is:

AVD user
→ Member of the approved profile-users group
→ Group has the required share-level role
→ File-level permissions allow the user to create and use their own folder
→ FSLogix creates or mounts the profile container

Role assignments can take time to propagate. When testing a new permission, allow for that delay before changing six other settings in frustration and making the original problem impossible to identify.

Configure the session hosts

Current AVD images often already include FSLogix, but the installed version should still be checked and updated when necessary.

The basic profile configuration lives under:

HKEY_LOCAL_MACHINE\SOFTWARE\FSLogix\Profiles

At minimum, FSLogix needs to be enabled and given the profile share through VHDLocations. Microsoft’s current profile-container configuration also recommends settings including DeleteLocalProfileWhenVHDShouldApply, FlipFlopProfileDirectoryName and VHDX as the container format.

A simplified view is:

Enabled = 1
VHDLocations = \\<storage-account>.file.core.windows.net\<profile-share>
DeleteLocalProfileWhenVHDShouldApply = 1
FlipFlopProfileDirectoryName = 1
VolumeType = VHDX

For the current Entra Kerberos design, the session hosts also need cloud Kerberos ticket retrieval enabled. Microsoft documents the Intune Settings Catalog, Group Policy and registry methods. The LoadCredKeyFromProfile policy is required so the Entra credential keys roam with the FSLogix profile instead of remaining tied to the first VM.

These settings should be delivered consistently through an image, Intune or another configuration-management system. Installing the agent and editing the registry manually is perfectly reasonable for one demonstration VM. It is a considerably less charming process on session host number 37.

Test the profile, not merely the sign-in

A successful desktop connection proves only that the user can reach a session host. It does not prove that FSLogix mounted the remote profile.

My preferred test is:

1. Use a new test user who has no existing local profile.
2. Sign in and wait for FSLogix to finish its first container creation.
3. Create a harmless file or change a visible preference.
4. Sign out cleanly.
5. Confirm that Azure Files contains the user’s SID-based profile directory and VHDX.
6. Sign in again, preferably to a different session host.
7. Verify that the file or preference followed the user.

This tests the whole chain: Entra sign-in, ticket acquisition, permissions, SMB access, container creation, attachment and persistence.

When it fails, read the FSLogix log

In the demonstration, Bob receives a desktop but no profile container appears in Azure Files. That is the useful failure.

The main FSLogix profile log is stored under:

C:\ProgramData\FSLogix\Logs\Profile

Microsoft’s FSLogix logging and diagnostics guidance recommends starting with the latest Profile_<date>.log. In my test, error 53 and “The network path was not found” point us towards the storage path and access chain rather than towards the AVD broker.

Check the problem in this order:

• Does VHDLocations contain the correct UNC path?
• Can the session host resolve the storage account name?
• Is SMB traffic able to reach Azure Files?
• Is Microsoft Entra Kerberos configured and is the cloud ticket available?
• Does the user have the correct share-level role?
• Do the file-level permissions allow creation and access?
• Is the user actually a member of the group that received the permission?
• Did an existing local profile prevent the expected container behaviour?
• Is the installed FSLogix version current?

The log usually tells us which part of the chain failed. Reading it is faster than changing registry values at random, although admittedly less dramatic.

The result: cloud-native identity with a roaming Windows profile

The finished design separates four responsibilities cleanly:

• Microsoft Entra ID authenticates the user and the Entra-joined session host.
• Microsoft Entra Kerberos provides the ticket used to reach Azure Files over SMB.
• Azure RBAC and file permissions authorise access to the correct profile location.
• FSLogix attaches the profile container to whichever AVD session host the user receives.

This removes the need to retain domain controllers solely for the AVD profile path. It does not remove the need for careful storage design, permissions, networking, backup and monitoring.

That is the broader lesson from the video. “Entra only” is not a shortcut around the moving parts. It is a different, now fully supported way of connecting them.

Watch the full demonstration above, or open it directly on Mike in the Cloud.