Tuesday, 17 December 2019

Use FSLogix Containers for Windows Virtual Desktop profiles

Recently I published a blog post of my first experience with Windows Virtual Desktop. In this post we'll look at how to integrate with FSLogix containers for profile management. This is now the recommended profile management solution for WVD. The User Profile Disk (UPD) solution has been around for a long time (introduced in Windows Server 2012). However it is scheduled for deprecation. This was inevitable since Microsoft acquired FSLogix in 2018.

So what is FSLogix all about? 

Remember roaming profiles? I've always hated them. They grow in size and out of control. When a user logs in the entire profile is copied from a central location to the desktop. This can takes ages and provides a very poor user experience. I've always seen roaming profiles as nothing but trouble so have avoided implementing them at all costs to avoid the 9am madness. 

FSLogix is designed to provide "roaming-profile-like" functionality in remote computing environments, such as WVD. When a user logs into a VM in the host pool, the FSLogix container is dynamically attached using a natively supported Virtual Hard Disk (VHD) or a Hyper-V Virtual Hard Disk (VHDX). The user profile is immediately available and appears in the system exactly like a native user profile. No data is actually copied so the performance and user experience are first class (which is why FSLogix have been the industry leader in this space for quite some time).

How do I buy FSLogix?

FSLogix is not licensed independently (and doesn't actually require a license key to install). It is included with many Microsoft licensing bundles (e.g. Microsoft 365 E3/E5). You can find the full list here.

Storage option

Where do we begin? The first thing we must do is decide where the FSLogix containers will be stored. There are a number of options in Azure.

You can use any of the following technologies:
  • Azure Files
  • Azure NetApp files
  • Storage Spaces Direct
You can read about these technologies and the pros and cons of each in the official Microsoft documentation.

For my testing I've decided to keep it simple. I'll use a traditional fileshare. Obviously this fileshare cannot be on one of the host pool VMs so I'll need another VM for that.


I created a new Azure VM (WVDShare).


It was on the same virtual network as my host pool VMs. It had a public as well as private IP address so I would be able to connect remotely via RDP.


DNS was already configured on this virtual network (that's the IP address of my DC). The VM was joined to the Active Directory domain.


I created an AD group and added my test user.


Finally I created a share (\\WVDShare\FSLogix) on the VM and assigned full control to the AD group.

Install and configure FSLogix

Next FSLogix had to be installed on all the VMs in the host pool. I only had three so I did this manually. However you could use a management tool like ConfigMgr to automate the installation.

The host pool VMs were not configured with public IP addresses by default so the easiest way to connect was via WVDShare which was on same virtual network but had a public IP address.


The FSLogix software was downloaded using this link

https://go.microsoft.com/fwlink/?linkid=2084562


The files were extracted.


I was interested in x64. I launched the installer (FSLogixAppsSetup.exe).


Accepted the license terms for the various components and started the installation.


The installation was short......


….and finished successfully.


The FSLogix folder structure.


App could be seen in "Programs & Features". It could now be configured - which really meant some registry changes.

Ran RegEdit as an administrator. Navigated to HKLM\Software\FSLogix.

Created a key named Profiles.

Created the following values for the Profiles key:

Name: Enabled
Type: DWORD
Value: 1


Name: VHDLocations
Type: Multi-String Value
Value: \\WVDShare\FSLogix


This told FSLogix where to save the user profile.


Unfortunately this gave me an error, although it seemed to work:

Data of type REG_MULTI_SZ cannot contain empty strings. Registry editor will remove any empty strings found. 


I don't like messy so I re-created the value as a string value and didn't get the error. After all I only had a single value.

The registry settings should then be configured on the other host pool VMS. This can be done with a GPO but for simplicity I just exported the key and imported to the other VMs. 


See the local groups created by the installation. By default the Include group contains "Everyone" and the Exclude group contains the "Administrator" account.

Members of the Include group are subject to the FSLogix policy. Members of the Exclude group are not.

User Experience

All the configurations had been carried out so I just needed to log in to the host pool to see the profile management solution working. However it didn't work for me first time. I didn't see anything in the \\WVDShare\FSlogix folder.

I followed this procedure to configure logging.

HKLM\Software\FSLogix\Logging

Name: LoggingEnabled
Type: DWORD
Value: 2



This was the log file I needed.


There was my answer. 

"Local profile already exists. Do nothing".

I hadn't read anything in the docs about local profiles and the fact that they should not exist for the FSLogix solution to function. However when I looked further I found it in this troubleshooting doc.


I deleted the local profile and signed in again.


This looked a little better.


I created a file on the desktop of GH-2.


Signed out of the VM. Looks like the profile was being saved to the FSLogix container.

 

I signed in to the host pool again. This time I got GH-0 and there was my file on the desktop - cool.


Finally I could see content in the FSLogix share.


It's a VHD as expected.

I really like the integration of FSLogix and WVD. It's very effective and really easy to set up and configure. I hope this helps you to do the same.

Until next time.....

No comments:

Post a Comment