For years now, UPM has been a neat, impartial kind of component. It’ll happily work with XenApp and equally happily work with XenDesktop. There’s a sort of comfortable clunkiness to the configuration – ADM templates are never going to set the world on fire with their UI design – but they are pretty reliable and well understood. Plus UPM is a bit of a hermit. It doesn’t really interact with the user and if it’s set up right, you don’t even know it’s there.
So there’s a slightly disconcerting, two-tier approach to the latest UPM release. It’s got a set of integrations with the XenDesktop 7 release, and some features that are only available to XenDesktop users, which after years of neutrality is certainly worth checking out.
There are, however, a number of new features available for the non-XD 7 world, too, so that’s where I’ll start.
File change notification
Let’s start with the new file change notification mechanism. Previously UPM used a file change notification mechanism based on getting notifications that reference the NTFS Master File Table (MFT). This mechanism dates from the earliest days of UPM, before we had any driver components, and had the advantage that it could be handled wholly within the UPM Service. The disadvantage was that the change notifications from Windows didn’t contain the actual name of the changed file, but only the File Reference Number (FRN), so UPM had to scan the MFT in order to build a map between the FRN and the file path. Once built, the MFT cache then gave a very quick lookup to determine whether a file change was in the user’s profile or not.
The problem with this approach was most evident in provisioned systems. In a persistent machine, the cache file – once built – can be saved, and is available following a reboot. On a provisioned machine, however, changes made during a session may be discarded at the end of the session, when the machine is simply thrown away. On subsequent reboot, therefore, the MFT cache would have to be built afresh during startup, leading to long logon times.
By switching to a file system filter driver, we avoid the need to look up FRNs – the filename is visible to the driver and can be passed back with the notification. Moreover, the MFT notifications didn’t handle some obscure file operations supported by NTFS, specifically NTFS Transactions. Why would anyone write an application to perform NTFS transactions in the profile, I don’t know. Anyway, if someone has written such an application, the new UPM architecture will pick it up.
Far more important, of course, is the performance improvement on startup in provisioned systems, through not having to scan the MFT and build the cache file.
Logoffs instead of temporary profiles
We’ve added an option to force logoff, rather than give the user a temporary profile. If, for whatever reason, UPM is configured to manage a user’s profile, but is unable to do so, UPM has always given the user a temporary profile.
The up-side of this is that the user is still able to log on, and notionally is able to work. The downside is that in the real world, a user may fail to notice that they have a temporary profile, save their work in the normal way, and get a nasty surprise when their work gets lost.
So in the case where there’s a risk that work would be lost – as administrator, you have to make this call (it’s not something UPM has the intelligence to decide) – UPM can now be configured to log the user off in this scenario.
The user will see a pop-up from UPM, warning them of the imminent logoff. There is no choice – if you as administrator have decided it’s too risky to proceed with a temporary profile, the end user has to accept that.
In a previous blog, I’ve taken the position that automatic configuration is quite risky. Nevertheless, we’ve taken the decision that where we can reliably determine the environment, using supported Citrix APIs, then automatic configuration is something UPM should perform. As a safeguard, this feature only takes effect when the administrator chooses default settings. UPM won’t override an explicitly configured policy.
The automatic configuration is designed around the ideas in my blog Profiles: To cache or not to cache, that is the question… (which are now also official Citrix recommendations for UPM configuration), so only a few policies are affected, but they are important policies – they can make a big difference to the performance of UPM.
The other area affected by Automatic Configuration is the Process Local Administrators policy, which defaults to Enabled for desktop OSs and to Disabled for server OSs.
Excluded groups came about through a customer request – someone wanted to have UPM manage a 4000+ user AD group, but with a few tweaks to remove a few users. Rather than replicate the large group and manually remove about 800 users (leading to having to maintain 2 large groups), the customer asked if we could simply define a new policy that would let him exclude a smaller group from the larger group. It turned out to be a quick and easy enhancement, and likely to be of use to others.
Citrix mandatory profiles
Based on UPM template profiles (which have been available in previous UPM versions right the way back to UPM 2), Citrix mandatory profiles are very similar to Microsoft mandatory profiles. There are a couple of subtle differences:
- A Citrix mandatory profile can be changed within a session, though any changes will be discarded at the session end.
- A Citrix mandatory profile uses NTUSER.DAT (rather than NTUSER.MAN).
(There is some more detail in the comments section below)
ShareFile makes use of the same file system filter driver as the UPM Service – both features make use of it for catching reparse point I/O request packets (IRPs). UPM uses it for profile streaming (fetching files from the user store on demand) and ShareFile uses it to fetch files from the ShareFile cloud. We introduced the shared driver in the last hotfix rollup of UPM (Version 4.1.2) and the earliest supported ShareFile version is 2.1.
However, the setup has now been improved, and UPM 5.0 and later versions of ShareFile use DIFxApp to let them safely share the latest file system filter driver across upgrades.
If you’re using Microsoft redirected folders, you’ll see there have been some minor improvements in the profile handling of redirected folders, which no longer needs any policies to be set to manage it.
However, if you don’t want to use Microsoft redirected folders, there are new ADM policies that allow UPM to set up its own redirected folders.
Windows 8 support
UPM supports both Windows 8 and Windows Server 2012.
Windows XP and Windows Server 2003 support
Mainly as a consequence of the change to the file change notification mechanism, UPM 5.0 does not support Windows XP or Windows Server 2003. However, these platforms continue to be supported by UPM 4.x.
Profile delete delay
This is another feature to support provisioned environments. Broadly speaking, you either stream profiles and delete them at the end of a session, or you completely download profiles at first logon and keep them at logoff. Which approach you take depends on whether you have a personal or a shared environment, and on whether the environment offers persistent storage. The physical and Citrix Personal vDisk (PvD) cases first… – if you’re sharing (XA or RDS), you need to delete profiles, to prevent filling up your persistent storage; if the environment is dedicated (XD assigned or PvD) then you download them in full (that is, no streaming).
In the provisioned case, you always stream – sooner or later the machine will be switched off, so you only download what you need. The question is what to do at the end of session – you should delete the profiles a) to tidy up your storage and b) because the profile may be full of reparse points that’ll need deleting and re-creating. However, by waiting a while – leaving sufficient time for the machine to be switched off– you might save the cost of all those individual I/O operations. If the machine is not switched off (XD pooled, non-assigned and XA/RDS) after a certain time, then you can assume it’s OK to start deleting.
So if you’ve configured UPM to delete profiles on logoff, we’ve added a configurable delay. Setting the Delay before deleting cached profiles policy to (say) 60 seconds gives time for the VM to be shut down in accordance with power management or pool size policy. If the machine hasn’t shut down before that time, UPM will assume the machine is going to persist and delete the profile.
XenDesktop 7 changes
The remaining new features are only active in a XenDesktop 7 environment.
In addition to exposing perfmon counters (which are still supported), UPM also exposes a number of logon counters via WMI. Support for these depends on a Director plug-in architecture, but if this is active, the WMI metrics can be consumed by other WMI apps, or by PowerShell scripts.
UPM can be fully configured using the Policy Node in Studio. ADM or ADMX policies can still be used, as can the Policy node in Studio. Even the UPM .ini file can still be used. All are fully supported. Our advice is to only use one method to configure UPM.
Citrix (UPM) profiles (and Microsoft Roaming profiles) can be monitored through Director. You can even reset a profile using Director. Long-time users of UPM know that in general profiles don’t need to be reset, but if they do, the problem is most often an application issue. Without changing the app, a profile reset is unlikely to give more than temporary respite from problems.
Nevertheless, you can now reset a profile from Director. If you really, really, must.
As mentioned above, Studio is now aware of UPM and other profile types, and can be used to configure UPM (and other profile types). It can also configure UPM-based folder redirection as an alternative to Microsoft Folder Redirection. There’s also support for setting up a user store for UPM on an empty SMB share.
Extended synchronization has been retired. We recommend using PvD instead.
For more information, see:
… and of course the main UPM and XenDesktop 7 documentation.