How to implement FSLogix Profile container using Azure Files and Active Directory authentication for Windows Virtual Desktop (WVD)

With FSLogix Profile container you can maintain user context (for example application settings) in non-persistent environments like within a Pooled Windows Virtual Desktop Host pool. It will optimize the sign-in time for the end user because the user profiles are stored in VHD(X) file that is mounted to the concerning Session host VM every time the user signs in and therefor nothing has to be downloaded first.

There are several options for the storage location like an existing (or new) Windows File server, but since Azure Files with Active Directory authentication is GA, I personally prefer this option. Azure Files is an Azure service that is scalable on-demand and which is not dependent on a VM that needs to be running 24/7.

In this blog I will show you step-by-step how to deploy FSLogix Profile container user Azure Files and Active Directory authentication for Windows Virtual Desktop. This blog is divided into the following steps:

  1. Create a Storage account with a Private endpoint
  2. Create a File Share
  3. Enable Active Directory authentication on the Storage account
  4. Configure Storage account Access control (IAM)
  5. Configure NTFS rights on the Azure File Share
  6. Install FSLogix Profile Container in your WVD Host pool
  7. Configure FSLogix Profile Container via GPO
  8. Test the results


The following prerequisites must be in place:

  • Up and running Azure tenant, including configured with Azure AD Connect
  • Up and running Windows Virtual Desktop environment (click here for guide)
  • Azure Global Administrator account
  • Owner permissions on the Azure subscription
  • For the local domain you need to have the rights to create groups, users, add ADMX files to the Policy repository and create and edit GPO objects

Performance and Account type

During the creation of the storage account you get the option to select Standard (HHD) with account type GPv2 or Premium (SSD) with account type FileStorage. Premium storage account have more IOPS, but file share size is provisioned (Standard HHD is Pay-as-you-Go), so in general you pay more for your storage, at least in the beginning. Standard storage account general-purpose file shares are good for dev/test environments with up to 200 concurrent active users.

Step 1 : Create a Storage account with a Private endpoint

Login to the Microsoft Azure Portal to perform the steps below.

Open the Storage accounts blade and click the + Add button to add a new storage account.

Select your Subscription and Resource group (or create a new one). Give this storage account a name (must be globally unique) and select the Azure Location.

Select the Performance type, Account kind (see intro of this blog for more info) and Replication type and click Next : Networking

Select the preferred Connectivity method. In this case I will use Private endpoint (for security reasons). Click the + Add button to add a Private endpoint.

Select your Subscription, Resource group and Location. Give this Private endpoint a name. Select file as Storage sub-resource.

Under Networking, select your Virtual network and Subnet. Under Private DNS integration set Integrate with private DNS zone to Yes and click OK and Next : Data protection

File share soft delete is optionally, but I think it is always good to have a quick restore option in case the Azure File Share is accidently been deleted. Therefore I will set this option to Enabled and set the File share retainment period in days to 7 days.

Click Next : Advanced

Set Secure transfer required to Enabled and Blob public access to Disabled. Click Next : Tags

Optionally you can add tags to this Storage account. Click Next : Review + create

Click Create

After the deployment is complete, click Go to resources

Step 2 : Create a File Share

In this step we are going to create the file share itself.

On the Overview page of the Storage account, click File shares

Click the + File share button

Give this File share a Name and fill in the number of GiB by Provisioned capacity. The default size of a FSLogix Profile container is 30 GiB, so in general you can use the following calculation: # of users X 30.

Click Create

The new File share is now created

Step 3 : Enable Active Directory authentication on the Storage account

For the next steps you need to logon to a domain controller and download the AzFilesHybrid PowerShell module from here. After downloading, unzip the file to a folder like c:\AzFilesHybrid.

Start an elevated PowerShell prompt and run the following commands:

Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser

Install NuGet by running the following command:

Install-PackageProvider -Name NuGet -Force

Within the PowerShell prompt, navigate to c:\AzFilesHybrid, and run the following command:

Import-Module -Name .\AzFilesHybrid.psd1

The Az PowerShell module is required, if not already installed on the machine you will be asked to install it at this moment, type for Yes to All

Connect to Azure via PowerShell by running the following command:


A login prompt will appear, login with an Azure Global Administrator account

Select an Azure Subscription by running the following command:

Select-AzSubscription -SubscriptionName "<your subscription name>"

To connect the Storage account with Active Directory, run the following command:

join-AzStorageaccountForAuth -ResourceGroupName "<Resource Group Name>" -Name "<Storage Account Name>" -DomainAccountType "ComputerAccount" -OrganizationalUnitDistinguishedName "<OU Distinguished Name>"

Close the PowerShell prompt.

When you take a look in Active Directory Users and Computers you will now find a Computer account in the OU you specified in the previous step.

Within the Azure Portal, go to the Storage account and open the Configuration blade. Now you can see here that Active Directory Domain Services (AD DS) is enabled.

Step 4 : Configure Storage account Access control (IAM)

We need to set some permissions to the Storage account, there must be a Administrator (or a group of administrators) with the Storage File Data SMB Elevated Contributor rights to set NTFS permissions on the file share. Next to the administrator, all users that will use FSLogix profile container needs to have the Storage File SMB Share Contributor rights.

That’s why I created two security groups in Active Directory (as displayed in the screenshot above) and added the right users to it.

Once the AD security groups are synced to Azure AD, navigate to your Storage account within the Azure portal and open the Access control (IAM) blade. In the Add a role assignment part, click Add

Add the Storage File Data SMV Share Contributor role to your “user security group”, in my case “FSLogix Share Contributor”

Click the Add button again and give the Storage File Data SMB Share Elevated Contributor role to the “administrators security group”, in my case “FSLogix Share Elevated Contributor”.

Step 5 : Configure NTFS rights on the Azure File Share

Next step is to set the rights on NTFS level, but first we need to obtain the full UNC path of the File Share.

Navigate to the Storage account and open the Properties blade. Copy the File service URL to a Notepad.

Next, open the File shares blade and copy the File share name to the same Notepad

Remove “https://” and replace the forward slash with the back slash is shown in the screenshot above. Copy this UNC path, open Windows Explorer and past the UNC path in the address bar.

Open the Home tab and click the Properties button. Open the Security tab and click Advanced

Change the permissions to how it is displayed in the screenshot above (remove everything else).

Step 6 : Install FSLogix Profile Container in your WVD Host pool

If using WVD Image management, login to your “Master VM” (otherwise login to a Session host VM as Administrator) and download the latest FSLogix software from here.

Unzip de source file and navigate to the x64 > Release folder and run FSLogixAppsSetup

Select I agree to the license terms and conditions (if you do) and click Install

Click Close

If FSLogix is installed on the Master VM, deploy the new image in your Windows Virtual Desktop Host pool.

Step 7 : Configure FSLogix Profile Container via GPO

The final implementation step is to configure and enable FSLogix within the Windows Virtual Desktop environment. You can do this easily via GPO.

The installation source of FSLogix includes a custom ADMX and ADML file.

Copy the fslogix.admx file  to the \\<AD Domain Name > SYSVOL > <AD Domain Name> > Policies > PolicyDefinitions folder.

Copy the fslogix.adml file  to the \\<AD Domain Name > SYSVOL > <AD Domain Name> > Policies > PolicyDefinitions > en-US folder.

Open or create a GPO that will apply on your Windows Virtual Desktop Host pool Session Host VMs. And navigate to:

Computer Configuration > Policies > Administrative Templates > FSLogix > Profile Containers

Enable the following settings:

  • Set Outlook cached mode on successful container attach
  • Enabled
  • VHD location
  • Delete local profile when FSLogix Profile should apply

When enabling the VHD location setting, set the location to the Azure File share UNC path.

Navigate to: Computer Configuration > Policies > Administrative Templates > FSLogix > Profile Containers > Container and Directory Naming

Enable the following settings:

  • Virtual disk type
  • Swap directory name components

When enabling the Virtual disk type, select the VHDX format.

Step 8 : Test the results

When the GPO is applied to the Windows Virtual Desktop Session Host VMs, you can logon with a user that is member of the Storage File Data SMV Share Contributor related AD security group.

When login you will notice the Please wait for the FSLogix Apps Services notification.

After login, you can open Disk Management, if FSLogix is configured correctly, a Profile-<name> disk is mounted to the VM.


  • Unable to Configure NTFS rights on the Azure File Share – prompts for login details but everything i am entering – ( Admin/user account on configured domain) seems to be rejected

    • Hi, I too was experiencing the same issue as described by Mark. The only way I could access the file share was by allowing access to all networks, which is not what I would like to do for security reasons. Does anyone have any suggestions to what additional steps I need to do to enable access to selected networks?

      • Not entirely sure what step you are on, but if you are using security groups, it’s most likely your problem. Security groups seem to work off an on in general but definitely take longer to go in to affect VS adding individual users. This seems to also plague Azure Netapp files. I have the Netapp team looking in to this as I was able to show them during a call. So if you wiped all root accounts and just added in your own security groups, that’s where you problem is. Give it 45 minutes to an hour and it should start working. Could take longer depending on your environment setup for AD sync and then Azure AD sync. But be ready as security groups in general are unstable. I have 1 user out of 10 in a security group that would not work (Kept giving authentication dialog box and this security had been added for days at this point). I ultimately had to add them individually in both NTFS and Roles. I haven’t yet tested removing them to see if they go picked up in the security groups because i’m learning permissions for Azure file shares with Active Directory is not immediate by any means.

        • I resolved the issue, I had to create a Private Endpoint and then create a Forwarder in DNS. Which makes sense, I can only access the file shares within our network.

  • I believe your description of the protection file share soft delete offers might be a little misleading (

    File share soft delete protects against accidental deletion of file shares, but not the contents of file shares.

  • Hi Robin, great guide! A few things I want to point out.
    1. Users should be aware that whichever computer they are running the join-azstorageacountforauth command on will set that logged in user as owner of the share. This can be changed afterwards though.
    2. On Step 5, I was getting Denied when trying to make changes. Reading the MS document it states you have to mount the share using the Access Keys and storage account name which gives you super user access. After doing this, I was able to make the changes.

      • Need to make a correction that I pointed out. It isn’t running the command that set the logged on users as owner of the share. The owner of the share is assigned based on the first account to log in to it. So if you don’t use the storage account and key to mount the share first (this will assign owner SYSTEM) when changing permissions and just go to straight to the UNC of the fileshare, the user you are logged in as when you go the fileshare will be assigned owner.

  • Hi Robin,
    Thanks for the clear and concise guide. One thing to note that caught me out first time, the storage account name must be 15 characters or less for the domain join.

    Thanks again for your efforts!

  • Hi Robin,
    Very informative article. Thank you for the post.
    How scalable is the Azure files solution? Can it support hundreds or thousands of FSLogix profiles? Thanks

      • One small note on that: the bigger the storage space, the more IOPS you get is true only in the Premium tier. The Standard tier has a fixed amount of IOPS. At some point, Azure Files Premium becomes more expensive than Azure NetApp Files, so it’s another solution worth exploring.

        Another point is that the number of profiles isn’t so important as is the number of concurrent users.

  • I was able to finally get this working, after some trial and error. The mounting issue in Step 5 was one, which I resolved by setting the vnet/subnet for the File Share (somehow I missed that). Lastly, the VM I was signing on to wasn’t in the OU’s Computers folder. Once I moved it in, the GPO fired and I got my share. Thank you Robin for this awesome guide!

  • Any advice on how to migrate from an existing File Server to Azure Files? When we first deployed WVD we simply spun up a VM to act as a traditional FS. We’re now looking to move these profiles over to Azure Files but having a little trouble around permissions. We’ve tried various switches in Robocopy such as /MIR /SEC /SECFIX and /COPYALL but the process always errors out. If there a best practice for moving these profiles with their existing permissions?

  • I have this working also but now face the challenge of transferring user profile data (about 100 accounts) to the fslogix profiles. I don’t see a way to do it except manually through each user’s logged on account. Any ideas on this?

  • Robin, do you know how I can get my existing user profile data copied over to the fslogix profiles? I have researched and am coming up empty. I am migrating from Terminal Server/Remote Desktop user profiles.

  • Really good guide.. I used this to deploy it a few months back and have deployed a few for clients since then. However, one thing that I’ve noticed is that my admin accounts in the SMB Enhanced Share Access Group can no longer the users folders containing each users VHDX files despite nothing changing.

    I have to go in as the user and open their own profile to see the permissions, the folders show as having the User as the Owner as expected and also show STORAGEACCOUNT\Administrators as having full control.

    This did work around the time of deployment but it’s only coming back to it now that I’ve found it comes back with access denied. I removed and applied the IAM settings but still no luck with accessing them with the admin so I can’t run any admin tasks against the profile disks. Is this something you’ve come across?

  • SO , first, thanks for the guide! We we’re one of the first companies to go live on WVD (now called classic?) and found FSLogix was broken before the pandemic and had to disable it. Building the replacement for it now and I figured out networking issue mentioned here that was left out regarding the file shares. I just tried it for the first time, and I am having an apparent permissions issue with the profile. The VHDX gets created, but then the server apparently can’t write to it and gets a warning instead that it has been logged to a temp profile. Upon second login there is another VHDX created and the old one gets marked with CORRUPT__ on the front of the file. I also noticed that while I can see all the files in Azure, I cannot gain access with my Admin acct to any users folder via SMB. My set permissions match what is in the blog. Thoughts?

    • OK, resolved it myself. It was not a permissions issue (exactly). Group Policy (possibly coming from Intune, since it was not set on the OU or above it) had Bitlocker policy set to deny writing to fixed and removable (sure only removable drive was issue) drives not Bitlockered. Only was able to track down after recommendation to check FSLogix logs (C:\ProgramData\FSLogix\Logs\Profile). Definitely important for any troubleshooting.

About Robin Hobo

I am a Technology Specialist working for Microsoft with focus on the Modern Workplace. I am specialized in Microsoft Intune, Azure Virtual Desktop (AVD), Windows 365, Windows 11 and Azure AD. Also interested in mental health, NLP and personal development.

For more information, see the About Me page or my LinkedIn profile.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.