Once upon a time, it was all so simple.  Six questions, with yes or no answers, and you could just set up UPM by following the docs, and performing a simple if-X-then-set-Y-thus sequence.

But then came PVD and VDI-in-a-Box, and people started running provisioned XenApp on XenServer, and goodness-knows-what-else, and suddenly you had to think quite hard about some aspects of UPM configuration.  Not because you might break UPM (by which I mean, could force UPM to lose data), no.  But it was possible to create configurations that were sub-optimal in terms of speed at logon/logoff, or were over-costly in terms of resources.

A sea of troubles?

The goals of profile management (the concept, rather than the code) are to get you your profile as fast as possible, and to preserve it somewhere safe even when you’re not using it.  Sharing it across all your sessions is also important.

The techniques we use to achieve those goals are:

  • Profile Streaming
  • Local caching of profiles
  • Background Fill
  • Active Write Back

Profile Streaming leads to fast logons, by eliminating much of the network copying.  However, UPM still has to scan the network file and folder structure, to create a local copy using Reparse Points to act as placeholders for the actual files.  Again, generally a speed-up, but there are some disadvantages:

  • If the profile contains lots of small files, Profile Streaming may not save much network bandwidth compared to copying the files
  • If the local profiles are held on shared storage, you need to be aware of the IOPS incurred by setting up the Reparse Points – even though the physical space required is minimal, depending on your storage design, up to 6 I/O operations may be required per Reparse Point, which may be as costly as copying the file, but worse in terms of the impact to other users, as the I/O is “bursty”
  • If the profile has only been partly cache-filled by the end of the session, the locally-cached profile will be saved with reparse points, which will have to be deleted and recreated on the next logon, causing more IOPS.

While Profile Streaming can speed up logons, the technique that can have the biggest impact on Profile Load time is Local caching of profiles, because if the profile is already (mostly) local, then the cost of loading it is pretty small.  We still need to run a check for updates from other sessions, but that’s generally a fast operation.  So caching the profile locally is a good this to do, but there are some disadvantages:

  • On XenApp and Terminal Services (RDS) environments, it’s very easy to consume a lot of disk space with “stale” profiles that are infrequently (or never) accessed
  • In a provisioned environment, cached profiles aren’t going to survive a power cycle – but the upside is that frequent planned reboots do solve the disk space problem!
  • The complete profile must be cached, which means disabling Profile Streaming to be sure you’ve got the whole profile.  The first logon will be much longer – giving a bad first impression of the technology!

Background Fill (aka Always Cache) attempts to achieve the best of both worlds.  If you want the first-logon speed of Profile Streaming, but the long-term benefits of having a local copy, then the solution may be to enable Always Cache.  The profile is streamed at the first logon, but then in the background UPM continues to run, cache-filling all the reparse points (the “placeholders”) until the whole profile has been copied.  Then, on the next logon, there is a locally-cached profile in place, and the logon is quick.  There are, sadly, some disadvantages:

  • Downloading files in the background consumes network bandwidth, and (in pathological cases) may delay the copying of files you urgently want.
  • If the profile hasn’t been completely downloaded by the time the session ends (which will only be true if the session is unusually short, or your profile is exceptionally large), the profile will be saved with reparse points, which will need to be recreated on the next logon, as they can’t be re-used by the new session.

Active Write Back is a feature designed to help secure settings changes in volatile (provisioned) environments, including VDI-in-a-Box.  Changes are copied back to the network profile when updated files are closed, subject to no further updates in a window of 10 seconds after the close.  It’s useful if users tend to disconnect, rather than logoff, and then complain that their changes are lost if there’s a power outage.  And the disadvantages:

  • Only files are saved.  So if applications rely on paired file and registry changes, then the profile may be left in an inconsistent state.  A better solution nowadays is to use PVD.
  • In order to reduce network traffic arising from many updates, UPM enforces a “quiet time” of 5 minutes after each burst of AWB traffic , when updates are queued for sending.  If the user logs off during this period, the logoff may be slowed slightly.

And thus the native hue of resolution…

We’ll start with the question of whether or not to cache profiles.

You should not delete locally cached profiles on logoff if…

  • The (virtual) XenDesktop machine is volatile and will be destroyed on logoff.  Deleting profiles at logoff costs time.  If the machine is about to be destroyed, why bother?
  • The profile is stored in a Personal vDisk.  PVD is designed to store profiles in the vDisk, so UPM should leave the profile in place for PVD to manage
  • A special case: VDI-in-a-Box is in use.  There are two scenarios here.  In the first scenario, VDI-in-a-box is deployed with PVD, so treat as above.  In the second scenario, PVD is not present; on logoff the machine will be destroyed anyway, so why waste time deleting the profile?
  • The machine is “assigned” to one user (XenDesktop) and by implication is persistent.  The fastest logins will most likely be achieved by caching the profile on a local (persistent) disk.
  • The machine is dedicated for the use of a small number of users (XenApp/TS/RDS), and has a suitably-large persistent disk.  The case here is a small departmental server, where the number of users is capped.
  • Network availability.  If the network has poor availability, this takes us back to the Mobile/Static case in the Sixfold Way.  Configure Offline Profiles, which forces locally cached profiles to be retained and disables Profile Streaming.

You should delete locally cached profiles on logoff if…

  • The machine is a persistent server (XenApp/TS/RDS).  Delete profiles on logoff, to avoid the proliferation of stale profiles.  Alternatively, use delprof or similar to delete stale profiles which have not been used for “a long time”
  • The machine is XenDesktop pooled.  Delete profile on logoff if the desktops can be recycled between users, rather than being created/destroyed on demand.

That said, it is always “safe” to delete locally cached profiles on logoff – unlike the Microsoft Roaming Profile, conceptually the UPM profile exists always and only in its entirety on the network user store, making brief forays to cast its shadow on endpoints.  (By contrast, the Microsoft Roaming Profile exists quantum-like in many endpoints simultaneously, but only one of them turns out to be real – the last to be “observed” by a logoff turns out to have been the “real” one all along.)

So, having made our decision to cache or not to cache the profile locally, that helps us decide how to set Profile Streaming.

In principle, if we’re going to cache the profile, we really want to get the whole profile down before logoff, so there are two choices.

Choice 1: Disable Profile Streaming.  This guarantees that the profile will be present in full as soon as the logon completes.  Disadvantages:

  • It means the first logon will be slow, while the complete profile is copied down.

Choice 2: Enable Profile Streaming, but also set Always Cache and configure a size of 0.  This causes a background thread to copy the profile down, file-by-file, until the complete profile is copied down.  Disadvantages:

  • There is no guarantee that the copy will be complete by the time the user logs off, in which case UPM will save the locally-cached copy of the profile with Reparse Points – these will have to be re-created by the next session, as (for security reasons) they can’t be re-used by the next session.  UPM will eventually catch up, and all files will eventually be cached locally, so the cost is (only) the extra IOPS to recreate the reparse points.
  • There is no way to inform the user that the copy is complete
  • Downloading files in the background, such as large video files, could delay access to files that the user wants urgently.  Pathological case – see below

Ultimately this a choice for the administrator, though the UPM Config Check tool is set to recommend choice 1 – to disable Profile Streaming.

The other situation, when profiles are not cached locally, generally occurs when there is no persistent store, in which case to enable Profile Streaming makes perfect sense.  Disadvantages:

  • The IOPS consideration – each logon will be accompanied by a burst of Reparse Point creation, which may impose a heavy load if the cached local profile resides on shared storage .

So now we turn to Always Cache, which is designed to work alongside Profile Streaming.  There are two scenarios where you might want to set Always Cache.

Scenario 1: You want both a fast logon and also to get the whole profile down, because you’ve decided you want to keep locally-cached profiles on logoff.  Set Always Cache, with a size of 0 (zero).

Scenario 2: You want a fast logon, but also want to download your biggest files in the background, so you don’t have to wait if you decide to use them.  Set Always Cache, with the size set to the lower limit on the size of files you want to automatically cache fill, in MB.

Large files, however, are typically “business data” rather than settings, and are most likely to be found in My Documents, My Pictures or My Videos.  These folders are best kept separate from the settings parts of the profile, so that folder redirection is a better alternative.

UPM Config check will always recommend a value of 0 (zero) if delete locally cached profiles on logoff is set, otherwise it will simply report the configured value, but will make no recommendation.

Finally, we look at Active Write Back.  This is designed to write back file changes to the network to guard against data loss in volatile environments.

If PVD is active, disable Active Write Back.

If the machine is not volatile, disable Active Write Back.

Otherwise, enable Active Write Back.  Disadvantages:

  • Active Write Back does not capture registry changes.  Applications may require both registry changes and file changes to be preserved in order for certain features to operate.

UPM Config Check will recommend using PVD in volatile workstation environments.  In volatile server environments, UPM Config Check will recommend Active Write Back with a warning.

Enterprises of great pitch and moment

Also known as the conclusion.

This article supersedes the advice for setting the four policies

  • Profile Streaming
  • Delete locally cached profiles on logoff
  • Always Cache
  • Active Write Back

presented in eDocs at http://support.citrix.com/proddocs/topic/user-profile-manager-sou/upm-plan-decide-wrapper.html , taking into account the presence of

  • Provisioning technologies such as PVS and MCS
  • PVD
  • VDI-in-a-Box

The name of action…

A new version of the UpmConfigCheck tool that implements the above recommendations (and lots of other enhancements) is in preparation (it’s coded, but still being tested). I’ll post again when it’s available.