QuickPost – allowing multiple server sessions with FSLogix Profile Containers by using Citrix UPM

Using Citrix UPM to extend the functionality of FSLogix Profile Containers? Seems a bit odd…

On the surface, yes, it does. But if you stop to have a good think about it, it makes a certain amount of sense, so let’s have a run through of the feature and look at how to enable it. Note that this applies in the main to Citrix Virtual Apps (XenApp) running published applications, although there are certain situations where it may apply to desktops.

FSLogix in multi-session scenarios

FSLogix Profile Containers are multi-session capable, but they’re slightly limited. They rely on the sessions being opened on the same server, so in the main this should be good, assuming that you have all the applications in your image and session sharing turned on (there are not many situations where it would be turned off, to be fair). In the main, if you are running published applications with session sharing and you don’t have any siloing, FSLogix Profile Containers should be good as long as they are configured correctly.

To configure them, we use the following GPO settings:-

Computer Config | Administrative Templates | FSLogix | Profile Containers | Allow concurrent user sessions | Enabled

Computer Config | Administrative Templates | FSLogix | Profile Containers | Profile type

Setting this to “direct access” means only one profile container can be used at a time, “read-only” means all secondary sessions will be non-writeable, “read-write” means all secondary sessions will be writeable and mergable (if possible, otherwise the attach will fail), whereas the last option of “try for read-write and fallback to read-only” is the most desirable because it will try to open the secondary session(s) in RW mode but fall back to RO if it can’t rather than failing to attach completely. However, as mentioned above, this applies only to sessions on the same server.

Enabling concurrent user sessions in this way changes the behaviour of your Profile Containers so that there will always be two VHD(x)s created, unless you use the “normal direct-access profile” setting. The example below shows the main VHDX and the RW difference disk.

If you have published applications that are tied to different servers, so that users need to open Citrix Virtual Apps connections to two separate devices (or maybe something happens, such as the server their sessions are on is put into maintenance mode or drain mode), you will get a bit of an issue, as the new session can’t get read access to the profile and mounts in read-only mode. Any changes made in this session will be lost. If it’s an irregular occurrence, such as maintenance, then this is probably a risk that can be absorbed, but if it is regular because of siloing, then you may need to take some action.

Here are some scenarios that show what happens when concurrency is enabled but users have resources on different Citrix Virtual Apps servers

• UserA opens AppA on HostA, FSLogix mounts profile as normal with a RW disk, all changed settings will be saved and merged back to the main VHDX when sessions are logged out
• UserA opens AppB which is available on all servers, session sharing opens the app on HostA, FSLogix mounts profile as normal with a RW disk, all changed settings will be saved and merged back to the main VHDX when sessions are logged out
• UserA opens AppC which is only available on HostB, FSLogix mounts a profile to c:\windows\temp with a RO disk. This is a copy of the existing settings, so any customizations will be available, but any changes made in this session will not be saved or merged back to the main VHDX when the session is logged out

So for Citrix Virtual Apps environments where the published applications are available on all servers within the image and session sharing is enabled, this works well. The main areas I would see where this would be a problem are:-

• Users who have resources that are tied to different images on other Citrix Virtual Apps servers in a siloing model
• Users who have resources on different Citrix Virtual Apps server farms

You generally have two options in this situation, either accept that applications launched on separate silos or farms will get a RO disk from which changes cannot be saved back centrally, or that you need to implement separate profile management implementations for each. Dependent on how your users operate, you may be able to simply absorb the risk. Of course, if the silos or farms are running different operating systems from your other servers, then you would need to have two copies of profiles anyway because there is a good chance the profile versions would be different.

However, you may find that in some situations it might be an idea to allow the apps running on different silos or farms to synchronize changes back to a central copy of the VHD or VHDX.

Desktops?

Are there any situations where users might want to launch multiple instances of published desktops? Obviously session sharing wouldn’t be commonly invoked here, for the simple reason that a user connecting to a server where they already have a desktop would normally simply take over the existing session.

We sometimes see instances of VDI where users have a development and a “work” desktop, but there isn’t often any requirement to share profile settings between these, because they are treated as independent entities. You could maybe make the case that to save on storage you could look to find a way of achieving it, but it’s probably a bit of a stretch. However, I have seen a use case recently where we had Pre-Production and Production hosted desktops served from the same farm using the same Profile Containers implementation. The idea was that Pre-Production would be used for final testing of GPO tweaks, application updates, etc. and would almost identically mirror the Production environment – hence the shared profile management. In this case, we found we might have users running two published desktops, one for Pre-Production testing and the other for Production work. As each desktop ran on a separate group of servers, the desktop that was logged on second would get a “vanilla” profile (as there was no concurrency set up). This particular use case – which I admit is fairly niche – also suggested itself as a possibility for the multi-server, multi-session feature.

UPM to the rescue!

So given that this is probably most commonly a use case in Citrix Virtual Apps published applications environments, it makes a certain kind of sense for Citrix to allow User Profile Management to help out here. Essentially, UPM is running alongside FSLogix, but is only invoked when the application invokes the Read-Only disk mode. It saves the changed settings into a “traditional” UPM folder and then merges them back into the FSLogix VHD(x) file when the sessions are all logged out.

In order to set this up, you need to firstly configure FSLogix for concurrency as we specified above. Also, make sure that the ProfileType is set to “Try for read-write profile and fall back to read-only”.

Next you’d need to install the appropriate version of UPM onto your target devices. You need at least the 1912 version of UPM – given that there were a few bugs in there that I recall, I’d recommend the 2003 version.

I know, it feels weird installing UPM alongside FSLogix Profile Containers 🙂 Make sure that, if you’re using UPM for full profile management elsewhere in the organization, that you don’t allow the “standard” UPM settings to become confused with the UPM settings we will configure here. Because they are Computer Config settings, there’s no easy way to filter them by user, so make sure they stay well apart.

Now, configure the following settings for UPM:-

Set UPM to Enabled

Configure the path to the user store where it can hold the data before it is merged back. I’ve used the same path as my FSLogix profile, just with a folder called %USERNAME%.UPM so I can easily see the different data sets.

Configure this new setting from Advanced Settings and set it to Enabled

You can optionally filter the processed groups so that this aligns with your FSLogix processed groups, if required.

Also, make sure that the Profile Streaming feature is disabled as this will prevent this feature from functioning properly.

Now, once you have this feature enabled, when you log on to published applications through session sharing to the same server, it will continue to use FSLogix with the RW difference disk method. No UPM folder is created – FSLogix is managing all of the settings within the Profile Container as normal.

However, if you have sessions open to one server and you then open a session that runs on another Citrix Virtual Apps server, you will see a UPM folder is created.

This looks pretty much like your standard UPM folder layout, and behaves much the same way by writing to the local profile and then synchronizing up to the UPM folder at logoff. However, this time, when the FSLogix sessions are logged out, the UPM folder will then merge itself into the VHD(x) file. So, for instance, I can close all of my FSLogix-managed sessions on the first server, continue to use an app on the second server (that would normally be read-only), and then log out and have any changes from the second server session merged into my normal profile. You can tell that this has been done when the RW disk disappears.

I tested this and it works pretty reliably. The main problem I had was whether the UPM data would persist and start to bloat, but it seems to overwrite itself as necessary – for instance I saw it drop from 30MB to 500KB between testing sessions, so clearly it isn’t maintained or relied on.

It also works well for multiple published desktops. I can run two published desktops mapping to the same FSLogix Profile Container implementation from different servers and the changes are merged back together. Obviously, because it relies on last writer wins tech, doing this in desktops leads to some discrepancies (particularly around Registry settings), but given that the only other option is that the second desktop gets a completely blank profile, it’s not really that much of a trade-off, to be fair.

You can also invoke this functionality through WEM, should you wish to do it that way, or simply do it via GPO or Studio policies.

Summary

So there it is – an easy way to overcome what may probably be a bit of an edge use case (although there maybe are big published apps environments that can get some real benefits from this). It feels really odd using FSLogix and UPM to compliment each other, but UPM does a good job of keeping out of the way until it is actually needed, so this feels pretty solid to me. Obviously, though, this would only be an option in Citrix environments where they already have the entitlement to use UPM – I’d be very surprised to see anyone paying for this that wasn’t already a Citrix customer.

The Citrix docs page for the feature is linked here.

Video of the setup is below.