Are Multiple User Profile Connections Possible?

Having concurrent or multiple connections to user profiles means the user is connected to multiple hosts/sessions and using the same user profile stored on remote storage. Concurrent or multiple connections are not recommended in Azure Virtual Desktop, because they may result in temp profiles on a concurrent session and lead to data loss. The best practice is to create a different user profile storage for each host pool. Users cannot have concurrent sessions on the same host pool, so you can use only one profile storage per host pool.

Profile Storage Performance Requirements

FSLogix depends on the storage type used for the user profile VHDx files, as well as on the host pool location and storage location.

Profile storage IOPS needs to be considered and calculated properly for all users while selecting profile storage. For example, you may need around 1,000 input/output operations per second (IOPS) for 100 users, and around 5,000 IOPS during sign-in and sign-out. If you increase the number of users or if many users log in during a short period of time creating a log-in storm, then it will impact the Azure Virtual Desktop performance.

Storage Options for FSLogix Profile Containers

Azure offers multiple storage solutions that you can use to store your FSLogix user profile container. Azure recommends storing FSLogix profile containers on Azure Files or Azure NetApp Files for most customer scenarios. Check Chapter 3 for the difference between Azure Files and Azure NetApp Files before you select the profile storage solution for your organization.

Azure NetApp Files has been proven to be a great managed storage solution for FSLogix user profiles and Azure Virtual Desktop. The low latency and high amount of IOPS is a great combination for enterprises at scale.

Azure File Share Best Practices for Pooled User Profile Storage

Azure Virtual Desktop offers full control over the size, type, and count of VMs so that the customer can configure Azure Virtual Desktop based on their requirements, but at the same time the customer has to follow all the best practices for a better user experience. See Figure 6-2. The following are the best practices for using an Azure file share for pooled user profile storage.

VHDLocation vs. the Cloud Cache

There are two ways to define the profile locations in FSLogix for Azure Virtual Desktop. The first is the traditional SMB share path, which allows you to write to effectively any represented SMB share including a Windows file share and Azure storage file share. If you use the VHDLocation setting for the Azure Virtual Desktop pooled user profile, then there will be only one active profile location. FSLogix does not limit you to defining one location in the VHDLocation registry; however, only one location based on the order defined in registry and the location which is reachable and readable will be considered as active.

The second option is the FSLogix cloud cache, which provides the active profile locations. The cloud cache allows you to define multiple profile storage locations including an SMB share and an Azure blob at the same time. All the locations mentioned in the registry will be updated if there are changes in the profile data, and it’s a better option if you want to consider DR for the primary region.

If the profile container is the option you want to go with, then follow the next steps to configure the profile container settings in the image or go to the “Configure the Cloud Cache” section.

Configure the Profile Container Registry Settings

The profile container can be enabled through the registry settings and FSLogix user groups. As you have learned, the registry settings may be managed manually inside the image or manually on each session host or with GPOs, and you can make the decision based on your requirements. It is always recommended to automate the profile registry by GPO or image creation to avoid typing mistakes. The configuration settings for the profile container are set in HKLMSOFTWAREFSLogixProfiles on each VM inside the same host pool.

Adding a Profile Container Registry Key

Follow these steps:

1. 1.

   You have to get the Azure file share path from the storage account we created for the user profile before you add the registry key. Let’s go to the user profile storage account and click “+File share.” See Figure 6-22.

    

1. 2.

   Click the three dots in front of the file share and click Connect. See Figure 6-23.

    

1. 3.

   Copy the storage account path from the Connect pop-up, as shown in Figure 6-24.

    

1. 4.

   Now log in to the image VM using Bastion and open the registry with the Administrator context (Run as Administrator). Browse the registry path HKLMSOFTWAREFslogixProfiles and create both registry keys mentioned in Table 6-2. See Figure 6-25.

    

Table 6-2

VHDLocation Registry Key

Value	Type	Configured Value	Description
Enabled (required setting)	DWORD	1	0: Profile containers disabled. 1: Profile containers enabled.
VHDLocations (required setting)	MULTI_SZ or REG_SZ		A list of file system locations to search for the user’s profile VHD(x) file. If one isn’t found, one will be created in the first listed location.

Optional Registry Settings for Profile Container

Table 6-3 shows the addition registry keys.

Can User Groups Be Included and Excluded in FSLogix?

Yes, you can include and exclude user groups in an FSLogix profile. There are often users whom you want to keep local profiles for such as local administrators. During installation, four user groups are created to manage users whose profiles are included and excluded from the profile container and office container redirection. See Figure 6-26.

By default, everyone is added to the FSLogix Profile Include List group, which means all users who log in to the VM/system will have an FSLogix remote profile. See Figure 6-27.

It always recommends using a dedicated group for the Azure Virtual Desktop permission such as Azure file share permissions, FSLogix include group, and Azure Virtual Desktop app group so that it will be easy to add/remove permissions by simply adding/removing members in the group. You can remove everyone from the include group and add the group you created for AVD users, as shown in Figure 6-28.

Adding a user to the FSLogix Profile Exclude List group means that the FSLogix agent will not create FSLogix remote user profile (profile container) for the user and the user profile remains locally. Exclude takes priority in case the user is a member of both the exclude and include groups.

In Figure 6-29, VMadmin is member of the Everyone group, meaning part of include as well as exclude, so the exclude will take priority, and the profile will remain locally.

Once both the mandatory registry keys are added to all the VMs in the pool, then users can log in with the user ID that is part of the include group and also have permission on the file share and verify whether the profile is on the Azure storage file share.

What Are the Possible Scenarios with the Profile Container?

These are the options:

Single SMB file share with FSLogix: You can have a single file share (any file or Azure file share) to store a user profile using FSLogix as shown in Figure 6-30. If you use Azure file share, then it can be connected over a private endpoint from the AVD virtual network.

There is one more option distributed file system (DFS file share) that comes with file shares in different locations and syncing with each other, and you will get a single namespace that you can use in the VHDLocation registry key. You can set up DFS on Windows Server inside the AVD virtual network and set up a replica in a DR location, and DFS will take care of replicating data to another region share. See Figure 6-31.

Multiple SMB shares with FSLogix: You can have multiple file shares (any file or Azure file share) to store the user profile using FSLogix, as shown in Figure 6-32. Only one file share at a time will be active and available based on the order the shares are added in the FSLogix config. The replication between two shares needs to be managed by you using different tools like robocopy/AZ copy/CLI/PowerShell.

What Is the Cloud Cache?

The cloud cache is an alternative to the profile container, and it also provides some additional functionality to the profile container. The cloud cache uses a local profile to service all reads from a redirected profile or office container, after the first read. The cloud cache also allows the use of multiple remote locations, which are all continually updated during the user session. Using the cloud cache can insulate users from short-term loss of connectivity to remote profile containers. The cloud cache can also provide a real-time, “active-active” redundancy for the profile container and office container.

It’s important to understand that, even with cloud cache, all initial reads are accomplished from the redirected location. Likewise, all writes occur to all remote storage locations, although writes go to the local cache file first.

The cloud cache doesn’t improve the users’ sign-on and sign-out experience when using poorly performing storage. It’s common for environments using cloud cache to have slightly slower sign-on and sign-out times, relative to using traditional VHDLocations, using the same storage. After initial sign-on, the cloud cache can improve the user experience for subsequent reads of data from the profile container or office container, as these reads are serviced from the local cache file.

Cloud Cache Design and Functionality

The cloud cache uses one or more remote profile containers, along with metadata. The combination of a profile container and metadata is referred to as a cloud cache provider. The cloud cache uses a local cache file that contains part of the dataset stored in the cloud cache providers. The data gets stored and accessed from the local cache file after any read from a cloud cache provider. Additionally, the local cache file will service any writes from the system and then send those writes to all cloud cache providers in the cloud cache configuration registry. This is a synchronous process that depends on the performance of the various components such as client, network, and storage.

If a provider is not available, then the system will continue to operate with the remaining provider. If a provider that was unavailable becomes available before the user signs out, then it will be brought up-to-date from the local cache. When a provider isn’t available when the user signs out, it will be brought up-to-date in subsequent sessions by having all its data replaced from an existing and up-to-date provider. If all remote providers are stale, the provider with the latest metadata is considered the source of truth.

Configure Registry Settings for the Cloud Cache with SMB

The following are two different examples of using the cloud cache with a file share or blob.

Cloud Cache with File Share

Table 6-4 shows the registry key for a file share.

Cloud Cache with Blob

Combing a File Share and Blob for a Single Host Pool

Adding a Cloud Cache Registry Key with a File Share

Here are the steps to add a cloud cache registry key with a file share:

1. 1.

   You have to get the Azure file share path from the storage account we created for the user profile before you add the registry key. You can follow the same instructions mentioned in the profile container to get the file share name.

    
2. 2.

   Now log in to the image VM using Bastion and the open registry with an Administrator context (Run as Administrator). Browse the registry path HKLMSOFTWAREFslogixProfiles and create both registry keys mentioned in Table 6-7. Note: If there is a VHDLocation key present, you have to delete it before adding the cloud cache key. See Figure 6-33.

    

Table 6-7

CCDLocation Registry Key for File Share

Registry Value	Type	Value
CCDLocations	REG_SZ / MULTI_SZ	type=smb,connectionString=<Location1Folder1>;type=smb,connectionString=<Location2folder2>
Enabled	DWORD	1

1. 3.

   Make sure that the correct user group is added in the FSLogix include group. See Figure 6-34.

    

Adding a Cloud Cache Registry Key with a Blob

Here are the steps to add the cloud cache registry key with a blob:

1. 1.

   You have to get the Azure blob connection string from the storage account we created earlier for the user profile, before you add the registry key. See Figure 6-35.

    

1. 2.

   Since we have the storage name and key in the connection string, we should not store it directly in the registry, because users can read the registry with read permission. So, the best way to protect the storage account name and key is to store them in a credential manager on a VM. To do that, you must log in to the image VM using Bastion, open the command prompt as an administrator (CMD), and go to the C:Program FilesFslogixApps folder. See Figure 6-36.

    

1. 3.

   Type the following command and change the storage account name before executing the command. See Figure 6-37.

    

1. 4.

   Add the storage account key using the following command. See Figure 6-38.

    

Table 6-9 shows the registry key syntax without the credential manager. See Figure 6-39.

Table 6-9

CCDLocation Without Credential Manager

Registry Value	Type	Value
CCDLocations	REG_SZ / MULTI_SZ	type=azure,connectionString="DefaultEndpointsProtocol=https;AccountName=;AccountKey=;EndpointSuffix="; type=azure,connectionString="DefaultEndpointsProtocol=https;AccountName=;AccountKey=;EndpointSuffix=";
Enabled	DWORD	1

1. 7.

   Make sure that the correct user group is added in the FSLogix include list group. See Figure 6-40.

    

1. 8.

   Restart the VM and try to log in with a user ID that is a member of the group added in the FSLogix include list group and verify if the user profile gets created on the file share. See Figure 6-41.

    

What Are the Possible Scenarios with the Profile Container?