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:
- Create a Storage account with a Private endpoint
- Create a File Share
- Enable Active Directory authentication on the Storage account
- Configure Storage account Access control (IAM)
- Configure NTFS rights on the Azure File Share
- Install FSLogix Profile Container in your WVD Host pool
- Configure FSLogix Profile Container via GPO
- Test the results
Prerequisites
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 A for Yes to All
Connect to Azure via PowerShell by running the following command:
Connect-AzAccount
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.
Like it? Please share it!
25 comments. Leave new
[…] Check it out here: https://www.robinhobo.com/how-to-implement-fslogix-profile-container-using-azure-files-and-active-di… […]
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.
Can you clarify?
[…] via How to implement FSLogix Profile container using Azure Files and Active Directory authentication for… […]
I believe your description of the protection file share soft delete offers might be a little misleading (https://www.robinhobo.com/how-to-implement-fslogix-profile-container-using-azure-files-and-active-directory-authentication-for-windows-virtual-desktop-wvd/#aswift_0:~:text=have%20a%20quick%20restore%20option%20in%20case%20some%20VHD(X)%20files%20are%20accidently%20been%20deleted).
File share soft delete protects against accidental deletion of file shares, but not the contents of file shares.
Hi Sven, you are right, thanks for the mention, I changed it in the blog.
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.
Hi Christopher, thanks for the additional information!
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
Iv
As long as there is enough space you can. How bigger the storage space, the more IOPS you get.
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.
How about the computer account password expiration ?
See:
https://docs.microsoft.com/en-us/azure/storage/files/storage-files-identity-ad-ds-enable
How to configure this properly ?
A GPO would not work I think as the computer is not a real Windows computer system.
Did you ever resolve this? Looking into the same question now.
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.