QuickPost – Citrix UPM Profile Containers feature

Some of you may have noticed that as of version 2009, Citrix User Profile Management has extended the capabilities of the “Profile Container” feature that they introduced in 1903. The limitation of the original feature was that it could only be used to capture specific folders, not the entire profile.

However, as from 2009 you now have the capability to put a wildcard * as the folder path, which will capture the entire user profile from the root into the VHD file. Sound familiar? Well of course it does, it’s essentially the same capability as FSLogix Profile Containers (although without a lot of FSLogix’s secret sauce on top). It is very interesting that Citrix would go for what is almost a like-for-like copy of the FSLogix functionality, and even split their profile management capabilities into three distinct methods – full UPM file-based, full UPM container-based, or a hybrid of file-based and container-based simply using the Profile Container to capture specific folders. I’m not sure of the full value-add here – it’s not like FSLogix was eating into Citrix sales in any way, and we’ve even seen UPM being extended to compliment the functionality of FSLogix recently – but what this change is probably down to is Citrix reacting to a request from a customer with deep pockets.

As I said already, you need to be aware that this new functionality is a replacement for, rather than an extension to, Citrix UPM’s “traditional” method of persisting the profile. So be very careful that you don’t apply both standard UPM policies and the “wildcarded” full Profile Container feature. If you configure both together, I’m not sure what will happen – best case scenario would give you two “competing controllers” that simply vie with each other for who gets to manage the profile and the first one to hook in wins, but there also could be the chance you might see a lot of drag and performance impact and possible instability. So when you configure your policies for this, try and filter or order them so that you can’t get your “traditional” UPM policies and your “container-based” UPM policies applying to the same bunch of users. This can be a little tricky, given that UPM settings are computer-specific, so you may have to separate them by Delivery Group instead. Some people think they can simply apply the “Processed groups” setting (below) from two separate policies to get around this, but because there is only one “Processed groups” policy per machine, you can’t solve it in this way.

In order to enable the Profile Container feature in “full” management mode, simply configure it as follows:-

Obviously, you need to set the Profile Management feature to “Enabled” and configure a path for the user’s store! The Profile Containers will be put in a subfolder of the store path called “ProfileContainer\OS“. Then configure these additional settings

Computer Config | Admin Templates | Profile Management | Profile Container settings | Profile Container

There are also two additional settings you can configure, Folders to exclude from profile container and Folders to include in profile container. The exclusion policy functions pretty much like redirections.xml in FSLogix, except without the flexibility. However it means you can easily avoid the tremendous bloat that you get from the first run of Teams 🙂

Computer Config | Admin Templates | Profile Management | Profile Container settings | Folders to exclude from profile container

The include setting must be tied to the exclude setting. The include setting allows you to specify subfolders of the excluded folders that are then persisted

Computer Config | Admin Templates | Profile Management | Profile Container settings | Folders to include in profile container

If you want to continue using the Profile Containers setting just to capture individual cache folders rather than the entire profile, then simply use the setting with the specific folders specified rather than the wildcard *

Permissions for the file share need to be the same as they were for the container function prior to this functionality being extended. Occasionally I’ve seen instances where Domain Computers needed to be added to the ACL, but in general the same permissions as used by FSLogix Profile Containers should suffice

Share permissions

• Authenticated Users, Full Control

NTFS permissions on the profile share root

• CREATOR OWNER – Full Control (Apply onto: Subfolders and Files Only)
• SYSTEM – Full Control (Apply onto: This Folder, Subfolders and Files)
• Administrators – Full Control (Apply onto: This Folder, Subfolders and Files)
• Users – Create Folder/Append Data (Apply to: This Folder Only)
• Users – List Folder/Read Data (Apply to: This Folder Only)
• Users – Read Attributes (Apply to: This Folder Only)
• Users – Traverse Folder/Execute File (Apply to: This Folder Only)

Now here’s the important bit – how well does it function?

The profile disks are mounted into subfolders for each operating system, so you can’t share between OSes. The virtual disks always seem to be created as VHDX files rather than VHD.

Using VHDX, though, means that there’s no support for Windows 7 or 2008 R2. I tried it on Windows 7 and it created the folder but failed to create the container – which is obviously right as Windows 7 can’t address a VHDX, only VHD. 2012 R2 worked fine, but I didn’t have time to spin up a Windows 8.1 instance (hopefully nobody is using Windows 8.1!)

When a user logs on, it uses the same concurrency method as FSLogix does – using a Read/Write VHDX

However, if a user hits two different servers for applications or desktops and is sharing the same Profile Container implementation, then (like FSLogix), it uses a Read-Only VHDX from which changes will be discarded. FSLogix uses the system TEMP directory for this, whereas the UPM version writes it to the file share.

This obviously means that changes in the session on a different server will be discarded. One thing I do like, though, is that UPM actually tells you you’re in a read-only session – although maybe that will cause helpdesk calls when the users see it, so potentially a double-edged sword.

As the user logs out, you may see (possibly for 10-20 seconds) a LockFile in the user’s profile folder – this didn’t seem to cause any issues, but it may be that trying to launch another session during this lock situation may fail to mount the container – I haven’t tested that though.

When a user is logged in, a difference you will notice is that the c:\Users folder shows a junction point rather than the mount being invisible like it is on FSLogix. You can also see that the Excluded folders use pretty much the same method as FSLogix, redirecting to a folder ending with _local

Now, this raises an issue that may affect people. As you may know, OneDrive doesn’t support junction points, and if you have the OneDrive Sync Client installed, then it will try to point to a user profile location by default. So if you are using the Profile Container from UPM (either to capture the entire profile, or even just to try and capture just the OneDrive folder), this will fail – in fact you won’t be able to set up OneDrive at all (you can’t even send it to another drive – Microsoft don’t support this, which has ramifications if you’re using local drive hardening policies).

Interestingly, this doesn’t happen when you use the User Personalization Layers feature that is now available in Citrix (for Windows 10 only though – at the moment). This is because App Layering (which drives UPL) uses (like FSLogix does) a filter driver rather than just an old-fashioned junction point to do its stuff. Of course, to use UPL you need to be using MCS or PVS (which probably accounts for a lot of Citrix customers, but certainly not all).

What about Teams? Citrix are now recommending using their own Profile Container setting when using Teams to capture the cache, along with a bunch of exclusions that appear to be a mish-mash of Microsoft’s weird recommendations and some from the community. Teams does work OK like this, but again, it is configured using a junction point which doesn’t seem to cause any issues, but given that I’m not a heavy Teams user, I can’t possibly speak to how it would perform when under heavy load.

One thing I did notice was that it fails utterly on Windows 10 2004 – and quite destructively, if I am honest. You get this error initially

And the Start Menu, WinX menu and Search are all broken and unresponsive. When you look in the Users folder, there is no junction point for your user profile, so essentially – you’re running your session profile-less. Not good! It is created in the remote file share successfully (in a Win10_2004 folder), so it is trying to work, but for some reason it isn’t accessible from the VDA.

Now, some have mentioned that 2004 is not listed as a supported version for 2009 UPM, but the Citrix documentation says precisely this “Citrix Profile Management supports the latest version of Windows 10 available at the release time of Profile Management”. It is also listed as supported for the 2003 and 2006 versions of UPM so I don’t see why 2009 should be any different. But as I said – it doesn’t work currently for 2004.

If you are using the “Enable search index roaming for Outlook” setting from within UPM, which mounts the user’s Outlook search database and offline data to separate containers, this setting (if configured) alongside the Profile Container setting will still create the Outlook VHDs as separate files, sitting in a “VHD\OS” subfolder of the UPM profile path

However, the Outlook OST and Search containers do not support concurrency, so if you are using the Outlook features and running concurrent sessions, you may see Outlook issues and potentially reporting that the OST file is out of date. I’d recommend capturing the Outlook files as part of the entire Profile Container in this situation, but you may have reasons for separating the two still.

One final note about my testing (quick though it has been) – you can’t break the Profile Container VHD into separate parts, even if you specify multiple folders in the “List of folders to contain on the profile disk” setting. They are all just appended into the same VHD, so if you have the wildcard present, there’s little point adding anything else.

Also, combining the UPM Profile Container feature with FSLogix Office365 Containers doesn’t appear to work either. I have a few more configurations to test, but it would certainly seem that the two solutions can’t be run alongside each other.

One of the highest profile pieces of the FSLogix suite, obviously, is Cloud Cache, which delivers a ready-made resilience and replication solution for the enterprise. There’s no such equivalent that Citrix provide, and UPM in general has traditionally always been tricky to configure resilience and HA for, especially in active/active situations.

Summary

So this is a bit of a curveball from Citrix. I thought they were going to embrace FSLogix’s ownership of the container-based profile area, particularly when they introduced the UPM fallback feature. But here we are – and they’ve produced a half-decent effort at emulating it, although it lacks the FSLogix secret sauce that gives them more backwards compatibility, and the capability to cache not just Outlook and Search but OneNote, Teams, Sharepoint and Skype caches as well. The lack of support for OneDrive is a big problem, as is the failure of Windows 10 2004, but overall – I have to say, from a profile management perspective, it seems to work pretty well. I roamed quite a lot between Windows 10 1909 instances and Server 2016/2019, and although I did see some very small niggles, it captured everything I threw at it on a Windows level. In all fairness, not a bad effort.

As I said previously, you now have three choices with profile management as far as UPM goes:-

• The “traditional” file-based UPM method, where you synchronize the profile to/from a file share
• A combination of file-based and container-based, using the Profile Container feature and the Outlook search roaming features in UPM to add VHDs for cached areas to supplement the file-based base
• A full capture of the user profile to a VHD, using the Profile Container feature with the wildcard specified

The second option here could be possibly the best for environments where the maximum possible profile load time needs to be achieved (although there are many other ways of achieving this). It would be interesting to see this combined with the standard UPM cross-OS settings, but as usual for that sort of approach, would involve a lot of overhead and management.

However, I don’t really see the reasoning behind this move, other than to show parity with FSLogix. If they want to try and compete with FSLogix directly then they really need a filter driver, and obviously melding with User Personalization Layers to leverage that would be the way forward. But there appears to be no direct business benefit here – it’s not like FSLogix is pulling business away from Citrix, UPM is just a component of CVAD. I can only reason there must have been a particularly influential customer who was unwilling to jump to FSLogix and insisted that the functionality come from within UPM to ease their progression to a container-based solution and to gain the benefits of that model.

Only time will tell how much development gets put into this feature and see where it ends up. Personally, I still prefer FSLogix – it’s more mature and has more capability, and it doesn’t just do profiles, you get all the App Masking and Java features on top. But if, for whatever reason, you are unwilling to accept Microsoft’s free offering, then Citrix have come up with a competent container-based profile management option that you can use in your deployments.