Author: admin

I had trouble with users not logging in correctly in Citrix Virtual Apps and Desktops.
VHDX files where not unmounting at logoff.

My environment was Windows Server 2019 with VAD 1912 CU1 on VMware. The issue occurs on other version combinations as well.
Also, in this farm, all users should have their profiles deleted from the server at logoff so the disks won’t fill up fast (people here tend to logon/-off often) and have a daily server reboot.

Because of a migration to Exchange Online I needed a solid Outlook caching solution. Because I am using Citrix VAD and UPM, I could use the built-in Search Index Roaming!

For those of you that do not know, Search Index Roaming is a fancy title for a system that created two VHDX files that contains the Outlook caching and indexing files. They are hard- or softlink (I always forget which one) folders like C:\Users\UserName\AppData\Local\Microsoft\Outlook that redirects to a mounted VHDX file. This file is invisible to the user but can be seen in Disk Management. The Outlook folder looks different now from the default yellow icon, so you can tell it’s working.
For more info check: https://support.citrix.com/article/CTX235347

Anyways, after I enabled all this, I thought my users where working fine as usual. I was wrong. After a while users experienced login problems, temporary profiles, etc.

Because Search Index Roaming was one of the latest things I enabled I quickly found that the users with issues had their VHDX file still mounted on the server they where logged on to.
Time to go diggin’.

There was about only one source on the whole of the interwebs that had my issue: https://discussions.citrix.com/topic/400258-outlook-ost-and-search-vhdx-not-unmounting-after-log-off/
Basically it said: do not have uppercase letters in the UPM path. Which I did not!
It is, however, a path containing a (lowercase) DFS-N name. (DFS-N stands for Distributed File System – Namespaces)

What I discovered in Disk Management was that it resolves the DFS-N name into the servername; IN CAPITAL LETTERS. (But not 100% of the time..?) Damn you!, why people, WHY?
(If you’d like to know, if you click Detach on a VHDX file within Disk Management, you get to see the real filepath before clicking OK. You can cancel this windows, so you do not have to really disconnect it!)

Conclusion:
In conclusion, my fix was to simply set my UPM profile path, in lowercase, to the servername instead of the DFS-N name. This really was all it took.

Example:
Old path: \\domain.local\dfs\upm   ->   resolved to: \\SERVER01\dfs\upm
New path: \\server01.domain.local\upm   (where upm is the sharename)

Hope this helps someone. Leave a message if it does, I would like that 🙂