A common question we get from Managed Service Providers (MSPs) is about the way FSLogix profiles are configured and how they work with Azure Virtual Desktop (AVD).  In this article, I’ll provide a technical overview of the technology.  This is a 200-level technical article.

First, you can find everything there is to know about FSLogix here. This is an extensive documentation repository but can be overwhelming at first glance.  I’ll try to distill the relevant information here.

What is FSLogix Profile Container technology and why should it be used?

There are actually 4 FSLogix products:

1. Profile Container
2. Office Container
3. Application Masking
4. Java Version Control

Here, we will focus on #1 only – Profile Container (PC).  Office Container benefits are automatically included in the Profile Container product, so we won’t discuss Office Container at all.  Application Masking and Java Version Control are interesting technologies that we’ll explore in future articles.

In a nutshell, Profile Container redirects a user’s profile (what’s typically stored in C:\Users) to a VHD file on a file share.  This allows a user to log into a different desktop VM each time they connect and still have access to the same user profile settings since the profile container is mounted under C:\Users whenever a user logs in. 

This functionality is what enables users to be assigned to session host pools with multiple VMs and still have a consistent user experience when they get redirected to a different VM each time by the AVD connection broker.

How is FSLogix Profile Container enabled?

Profile Container (PC) is enabled via a simple registry entry in HKLM\SOFTWARE\FSLogix\Profiles after it is downloaded and installed.  Here you enable the Profile Container and point it at a UNC of a file share location where the profile VHD file will be created when users log in.

Nerdio Note:

FSLogix Profile Container is enabled by default on the Nerdio configured AVD Windows 10 multi-session template VM.  The profile location is set to \\FS01\Profiles\%Username%.

Also, there is an XML file in the \\FS01\Profiles location that excludes the Desktop and Documents folders from being included in the FSLogix PC.  Instead, these folders are redirected to \\FS01\Users\%username% folder using Group Policy.  This reduces the size of the FSLogix VHD file and allows enables IT administrators to centrally back up and manage users’ personal data.

That’s all it takes to enable FSLogix Profile Container.

What happens when a user logs in?

When a user logs into a desktop VM where FSLogix PC is enabled, the system first checks for the presence of a local profile for the user.  If a local profile exists (e.g. a folder is present in c:\users and registry entry for the local profile exists in ProfileList key), then FSLogix PC skips the process of creating or connecting to a network profile specified by the registry entry mentioned above.

If no local profile exists, PC tries to connect to the UNC location specified in the registry and connect to a profile that already exists or will create a new one.  The user must have Modify permissions to the profile folder on the file share.  If the PC cannot mount or create a profile, it will default to using a local profile if one exists or create a new one if it does not.  In this situation, all user personalization settings will be stored in c:\users and will be lost once the user logs into another desktop VM in the future.

Nerdio Note:

To avoid a situation where a local profile that already exists on a desktop VM prevents the creation of a network-based profile, the Nerdio golden image includes an entry that will automatically delete the local profile and create a VHD one in the file share.

The registry entry is DeleteLocalProfileWhenVHDShouldApply and it is set to value of 1.

How can you tell if the Profile Container redirection is working?

There are a few ways to do this:

1. Look in C:\Users and see if there is a folder called “Local_username”. The presence of this folder with a recent modified date indicates that profile container redirection to a file share is working.
2. Look in the file share for the VHD file and note its modified date. If it is current, then redirection is likely working.
3. If the user account has local administrator rights on the desktop VM, check the disk configuration Windows utility. You’ll see a virtual mapped drive listed.

What can you do if Profile Container redirection is not working?

If you notice that profile redirection isn’t working, verify the following:

1. Profile Container operation can be controlled with local security groups that can be used to include or exclude users or groups from having their profiles redirected. Use Computer Management>Local Users and Groups to verify that that the user (or a group that includes the user) is not excluded from PC.
2. Make sure that there is not a local copy of the profile already on the desktop preventing PC from turning on. If there is, either delete the local profile or use the DeleteLocalProfileWhenVHDShouldApply registry key to have FSLogix PC do this for you automatically on the next login.
3. Make sure the user can access the UNC file path where FSLogix PC is expecting to create the profile VHD file. Make sure that the path is correct and browsable and that the user can create and delete items inside of the file share.  If not, troubleshoot share access or NTFS permissions.
4. In Event Viewer, find the FSLogix Apps operation log and look for the entry that shows whether the profile mount worked. If the exit code is not 0, look up the code here.
5. Once you’ve verified 1-4 above, see if the user may be logged in to another session host desktop VM and the VHD file on the file share is locked by that session. You can log into the file server and check Computer Management>Open files for more information.  If the profile container VHD file is locked, close the file handle and log in again.

Additional recommendations for FSLogix Profile Container

FSLogix Profile Container requires little configuration to enable and gracefully fail over from a redirected profile to a local profile.  Unfortunately, this can create a situation in which a user may not be aware that their settings aren’t being saved on the file share and are going to be discarded because they are saved locally.  To avoid this situation, it may be advisable to prevent users whose profiles cannot be redirected from logging in and using the system with local profiles.  To do so, the following two registry entries can be added on the desktop VMs and set to a value of 1.

• PreventLoginWithFailure
• PreventLoginWithTempProfile

Azure Virtual Desktop: More Information

As Managed Service Providers (MSPs) adapt to the ever-evolving landscape of virtual desktop infrastructure, understanding the potential of Azure Virtual Desktop (AVD) becomes crucial. This blog post serves as a comprehensive resource, introducing MSPs to the myriad benefits of AVD and its implications for optimizing virtual desktop experiences. By delving into the core features and capabilities of AVD, we aim to equip readers with the knowledge needed to harness its power for their clients. Whether you’re a seasoned professional or new to AVD, this guide will provide invaluable insights, practical tips, and best practices to unlock the full potential of Azure Virtual Desktop in your MSP offerings.

Read more on Azure Virtual Desktop and how to work with Nerdio

Putting it all together

Here is the recommended configuration of FSLogix on host pool template VM in the Nerdio environment.

At Nerdio, our mission is to empower MSPs to build successful cloud practices in Microsoft Azure with technology and knowledge.  Nerdio for Azure simplifies and automates the deployment, pricing, management, and cost-optimization of AVD environments in Azure, and our educational content is custom-tailored for MSPs to help them succeed with Azure and partner with Microsoft.