QuickPost – Citrix User Profile Management store replication and container caching

I recently had to go back to Citrix User Profile Management (UPM) for a particular requirement I had, profiles-wise. The specific requirement was datacenter resiliency along with a locally cached copy to resist network outages, which made FSLogix a non-starter.

The reason FSLogix was a non-starter was that local copies of the container can only be provided in a Cloud Cache scenario, but the impact of Cloud Cache synchronization and queues onto performance could not be discounted. FSLogix has no native way to provide a local copy outside of Cloud Cache (there is the “KeepLocalDir” setting which many people think actually provides this functionality, but it’s the local_username cache only, not the full profile). Now naturally the easiest way would be simply to give the users a local profile on the VDI and then replicate the entire machine to a secondary site, but as this customer had no replication process in place nor the time to be able to procure one, I was forced back to the drawing board.

As I thought through the requirements, I found myself coming back to Citrix UPM. Normally, it’s storage requirements that see me circling back towards it – I often find myself saying “if storage constraints are a major blocker, then FSLogix isn’t the solution for you” – but there are admittedly many reasons why you’d consider UPM as an alternative to FSLogix or a similar container-based solution. Rather than me rehash them here, let me point you to James Kindon’s excellent article on the subject, most of which I heartily agree with.

Back to my issue – and this problem made me go and have a look at two relatively new features that have come to UPM recently, which ties in with a lot of the interesting improvements that have been made to UPM over the last year or so. They are “replicate user stores” and “local caching for containers”.

Let’s not forget that Citrix UPM has its own container-based solution now, so you have the option to manage your profiles as a) fully file-based, b) file-based with specific files or folders in containers, or c) fully container-based. I already covered the “fully container-based” method in a previous article, but this has improved somewhat as well.

Replicate user stores

Firstly, from my resiliency perspective, the replication of user stores is a very useful feature which came along in Profile Management version 2106. It allows the user’s profile to be synchronized to an additional store either during the user’s session, or at logoff.

You can configure multiple stores for replication simply by adding them to the policy object that you use to configure UPM. With the latest ADMX files loaded, the setting you are interested in is Computer Config | Admin Templates | Profile Management | Advanced | Replicate user stores. The syntax that can be used is exactly the same as that used in the “Path to user store” setting in the Profile Management root. Obviously, replicating the user stores has no effect unless you have UPM enabled, and configured correctly.

If you want to just synchronize at logoff, then simply configure “replicate user stores” without active write-back. If you want it to synchronize during the session, then additionally configure the “Active write back” (for files and folders) and “Active write back Registry” (for Registry hives) policies so that it can synchronize to the specified stores during the user session. Obviously, active write back means that you will have I/O and network activity during the user session, rather than just at the termination of it, but it also means that the replication is much more in synchronization with the user state.

The process is really straightforward – once the user launches a session, their profile is created in the primary store specified in “Path to user store”, and then during the session (if active write-back is configured) or at logoff (if it’s not), you will see copies of the user profile created in the specified replication paths.

What I tend to do is configure a primary share for each resource location, and have this replicated to secondary shares in other locations. So if a primary share goes offline, a user can either connect to a secondary share, or, if an entire location is lost, be assigned a machine from a secondary resource location and pick up the copy of their profile as well.

You could configure separate sets of machines with a separate “primary” replicating to other secondaries, or configure all of your machines with the same primary and secondaries. With the separate sets you’d have a slightly more automatic failover, whereas with single sets manual intervention of some sort would be required.

As far as my particular resiliency requirement goes, this gave me a quick and easy way of replicating my profiles to a secondary store. I combined this with storing a local copy on the machine so that the user profiles were fully resistant to network outages (by disabling the “Delete locally cached profiles on logoff” setting). However, what I did find is that if you configure the replication and the local copy alongside the “offline profile support” setting, you would end up corrupting the Windows 10 Start Menu as you moved from machine to machine. So if using replication and local copies, make sure you do not have “offline profile support” enabled (this setting was primarily aimed at laptop users, IIRC).

Also, this feature doesn’t work if you use UPM’s “Profile container” setting. I’m hoping it will in the future (imagine having a built-in method of container replication, it sounds really cool), but for the moment, replication to secondary stores can only be done with file-based profiles.

Local caching for containers

If you are using the container features of Citrix UPM, generally you are reduced to the same kind of options for replication that you see for FSLogix (so using tech such as bvckup2, for instance). The failover in these sort of situations isn’t generally great, as there’s no equivalent technology like Cloud Cache which is native to FSLogix.

However, if you’re using the UPM Containers feature, it can provide in-session resiliency to network failures in a similar way to Cloud Cache. The setting is inside Computer Config | Admin Templates | Profile Management | Profile container settings and is called “Enable local caching for profile containers”. In order for this feature to work, the “Profile container” setting must be set to “*” – to capture the entire user profile into the container, as below

The cache of the container is written, essentially, into the local profile on the system. If you have Profile Streaming enabled in your UPM settings, the copy of the profile is cached as it is accessed. If you’re not using Profile Streaming, then it is cached down at logon, which can extend logon times slightly.

The idea behind this is that a user with a session using a network-mounted container is now resilient to outages affecting the network share, at least for a short period of time, similar to how Cloud Cache behaves (except without the replication). Like Cloud Cache, there will be a queue of changes that need to be written back to the container when network connectivity is restored. Also, if the user logs out whilst the share is still unavailable, then they’d potentially lose any changes they had made to their profile in the interim.

Summary

UPM is slowly evolving into a better product. Container features were a big step forward, and now that it has in-built replication and resiliency features, it is making ground on its rivals. I would love to see the replication extended into the container-based profile management option, and I hope this comes along pretty soon.

There are drawbacks – there is still no support for OneDrive cache, for instance, and it would make much more sense if Citrix could bring a proper filter driver into play to emulate the capabilities of FSLogix more closely. It’s not like they haven’t got something that could do exactly that – the App Layering User Layer is precisely the technology that could achieve this.

But both of these settings give you more options around resiliency, which can only be a good thing. Especially in persistent environments where users have a lot of customized configurations, replicating the user profile gives you a head start when it comes to recovering from failure, and local backup of the container removes the spectre of interruptions from intermittent network issues. If Citrix can extend the replication to the container-based system, and even produce an option to maybe cache the entire container locally for fully offline scenarios, then they’d be making some real inroads into areas that FSLogix has dominated for a good few years.

Stay tuned, as usual – the last few episodes of the logon times series should be around imminently.