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.


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.


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.


  1. I was looking for some details on this. Should have know you would ha e this soon 🙂
    Thanks for the write up

  2. Thanks James. This will be useful, sometimes for perf reasons, eg. to isolate a cpu‬/ram intensive app on certain VDAs, we still occasionally publish from a silo and therefore do have this challenge. Will have a play – thanks!

  3. Hi James,
    Thanks for this write up… I have some doubts though: Given that “Session sharing is the ability of a seamless published application to be executed over the same connection as other seamless applications that are already running on the same server, under an existing Session ID of a user.” in which case would one need to enable concurrent user session? Also shouldn’t the scenarios given be “UserA opens AppB which is available on all servers, **concurrent sessions** opens the app on HostA,”? Because with session sharing, by definition the existing session would be reused.

    1. Not sure what you mean – the “concurrent user sessions” setting allows the creation of the different VHD(x) files AFAIK, so would be necessary in a session sharing situation.

  4. Hello,
    I have the following challenge to implement with the FSLogix tool.

    A user deploys a virtual desktop Front Windows 10×64 bits, inside this desktop they deploy virtualized applications that go to a XenApp (2008R2 & 2O16) as well as in VM Hosted App mode (Win10x32Bits)

    My concern is, should I create separate policies for profiling, or can I use the same profile to simultaneously log in to the different operating systems described?

    Best regards.

    1. The 2008 R2 profiles are incompatible with the Win10 and Server 2016 profiles so you will need at least two separate profiles (you can use variables to separate them by profile type). You could use one profile type for Windows 10 and Server 2016 but because they are not session sharing, you would have to enable some way of getting past the read-only profiles. It depends on the apps you are using and what settings you want to roam, but in your situation, I would probably look at using FSLogix for the first Win10 virtual desktop, and Citrix UPM for the 2008 R2/2016/Win10 app instances. As I said though, a lot depends on what you want to achieve.

  5. Hello James
    First of all, thanks for your reply.
    forget that the Front Win10x64 uses (Teams, O365, OneDrive), for the Win10x32, 2008R2 and 2016 application instances I require that the Apps save information in OneDrive.
    That you recommend me in this case,
    Cordial greeting

    1. So do you require the app instances to write to the OneDrive Sync Client (local cache) or directly to OneDrive online?

      1. Hello James.
        requires application instances written to OneDrive Sync Client (local cache)
        According to your experience, which one do you recommend?
        best regards

        1. If I follow this is a bit of an odd requirement – so you want the OneDrive cache to be shared amongst Win10, 2008 R2 and 2016 instances? You can’t share the containers between different profile types so this is a bit of a challenge. I’d actually suggest posting this on World of EUC Slack (https://communityinviter.com/apps/worldofeuc/world-of-euc-project) in the FSLogix channel, as it would be better to get multiple inputs on this issue.

  6. Dear,
    We need your help to configure a user profiles topic.
    The scenario is as follows:

    We have 32-bit Windows 10 released with Citrix Virtual Desktop and user profiles are being managed with FSLogix.

    Virtual machines are being created by Provisioning Services, that is, Windows 10 machines are Non-Persistent.

    The Client installs an application and each user has their own settings in the application that are stored as .INI files in the path C: / Windows

    How can I keep those settings through the profile with FSLogix?

  7. Hello James,
    We use Cloud Cache in our FSLogix setup to replicate users containers between two SMB shares (hosted on on-prem file servers). We would like to use the UPM multi-session write-back feature that you describe here. However, how would it integrate with Cloud Cache ? What would happen if we configure the UPM path to only one SMB share ? Each file server is independent, no DFS nor cluster, this is why Cloud Cache was implemented.

    1. That’s……interesting, and not a scenario I have tested. I am *thinking* that UPM probably takes its cue from the initial location where the user is pointing, and that initial FSLogix location is then merged with the UPM location. I will see if I can find anything out about this from Citrix.

  8. Hello James, and thank you for this article (and video!). I’m using 1912 LTSR and don’t find the Enable multi-session write-back for FSLogix Profile Container policy in GPO (with updated .admx/l files) or in Studio. You’d mentioned above that 2003 offered improvements over the 1912 version… Do you think Enable multi-session write-back for FSLogix might only be available in 1912 CR, or perhaps the feature only made it into the 2003 release?
    Cheers. 🙂

    1. It should be in the 1912 release of UPM, according to the documentation. Have you loaded the new ADMX files from the UPM source into your PolicyDefinitions or central store?

      1. I’ve updated my domain’s PolicyDefinitions folder with the admx/adml files from the 1912 LTSR ISO, done a gpupdate, and logged out of and back into my admin server, so that should be squared away. When I visit https://docs.citrix.com/en-us/profile-management/2003/configure.html , I am able to see “Enable multi-session write-back for FSLogix Profile Container” under “Configure” in the left-hand pane. But when I visit https://docs.citrix.com/en-us/profile-management/1912-ltsr/configure.html , I don’t see the same. I’ll have a look at the release notes for 1912 LTSR and see if I can find a reference to it. ThanQ…

        1. Hi,

          this is really annoying. Facing the same issue with LTSR 1912 Cu1. So UPM 2003 would break LTSR Support. But waiting for this new feature in the next LTSR Version is also a bad Option.

          I would love to combine these 2 Solutions for a complete UEM.

  9. I notice that Google bookmarks gets wiped out when UPM syncs the settings back to FSLOGIX. Do I need to add a sync setting in UPM to include the bookmark?

Leave a Reply

Your email address will not be published. Required fields are marked *