A graphic representing how the cloud works, with an image of Bit the Raccoon on the right of it.

Last month, I published the first part of this post. You can read it here.

In the first part, I wrote about the initial setup and config experience for creating and accessing Windows Virtual Desktop (WVD). Overall, I found the experience to be good, but at times, slightly basic. This is to be expected with a brand new service that is in preview, but for the second part of this post, I wanted to explore the more advanced options of configuration that are currently available.

So in this post, I am going to discuss the following:

  • fslogix profiles
  • Load balancing
  • Depolying using a custom image
  • Availability/configuration of SSO

Starting with fslogix, I think it’s kinda cool that you are given a free license as part of WVD to use the service. The actual install was quick and easy; just download the client, run it, set up two reg keys, and you’re done. However, I wasn’t overly familiar with fslogix and as such thought it wasn’t working – I have a solid background in desktop virtualisation, so I understand profile redirection explicitly. I found the Microsoft docs for this are light currently, but clicking through to the fslogix docs I spotted the issue, the local profile cannot exist first or fslogix will ignore it.

A quick tidy up and my profiles were redirecting, loading quickly and generally behaving as expected. So far so good! I’d like to see how it scales with a ton of users, but my expectation is that we’d see similar performance to Citrix UPM. One thing that is perhaps a bit annoying out of the box is, when you choose to sign out from the web client, it simply disconnects the user from an app group. This can be fixed with some Group Policy, but I would expect sign out to mean sign out.

A little tip, check out the reg key “FlipFlopProfileDirectoryName” for a quick way to make finding your user profiles within your file share a bit easier. There are also more advanced options like “SIDDirNamePattern”, more here.

Next up is load balancing the session hosts. This obviously only applies to non-persistent session hosts, as the persistent relationship is 1:1. You also need to understand two concepts:

  • Breadth-first
    • This distributes sessions evenly across all session hosts, a max session limit is optional.
  • Depth-first
    • This fills up a session host first before distributing sessions, a max session limit is required.

Both options are simple to setup via PowerShell and behave exactly as outlined. You can find instructions on how to do this here.

Third, I created a new host pool. To do this I first needed a custom image, so I deployed a VM to Azure to convert later. I skipped a bit here by using the new Windows 10 image with 365 ProPlus pre-installed for you, which is very handy. However, I then realised this wasn’t the multi-user version and even though all is good with image creation, it fails when trying to register with WVD (30 mins later…). So to save you some time, just use the Windows 10 multi-user image instead! I installed my apps, then I made the following changes:

  • fslogix installed and enabled
  • Configured session timeout policies
  • Additional language pack and region settings

Once I had this done, to get your custom image, follow the usual docs here. Then, you can simply specify it as part of the same steps you followed previously to deploy as a host pool:

A screenshot showing a new virtual machine being configured.

Once your new host pool is deployed, you need to assign users. Don’t forget you currently can’t assign a user to more than one App Group at any one time, so I removed one of my test users from its previous group and added it to the new one.

Once logged in, everything is as expected. Profiles, custom settings and my newly added apps. For my own terrible fun I added a special app. Yes, I’m sorry, that is Windows 95 running in the HTML5 client on WVD!

A screenshot showing Windows 95 running in the HTML5 client via Windows Virtual Desktop.

One tip that could save you some time is relevant to SSO. You may notice that when signing in and launching an app/desktop, you are prompted for credentials twice. This is the current expected experience. In the comments on docs, I spotted the following response from the program group:

A comment on GitHub by Christian Montoya stating "We are finalizing the work to have single sign-on if you federate your Azure AD logon to ADFS".

So we’ll just have to wait and see how good/bad SSO functionality will be once released. If you have any questions or would like to see a third part to this series, let me know!