One of the most eye-opening moments for me as Development Manager of UPM was a meeting I attended of the UK Citrix Users Group a couple of years ago.  I wasn’t there to promote UPM; I had gone with my team to listen and learn what Citrix users were doing with profiles.

But in the pub, after the meeting, and with a pint of Fuller’s in my hand, I asked the question ‘why do people not choose UPM?’

Some did use UPM – they said it just installed and worked and they didn’t ever have to bother with it again (slight exaggeration, I admit) – but the ones who didn’t mostly told me it was too hard to configure.

Drilling down, it turned out that there were actually quite a lot of configuration policies that weren’t well explained – why would you configure a certain policy one way or a different way?  And that was just too off-putting for some people to invest time in UPM – they’d just stick with local or roaming profiles, or pay for one of the several excellent high-end profile management solutions to sort it all out.

So that led to a minor revolution in our docs, as what we called internally the “Sixfold Way” was born – six questions you needed to ask about your UPM deployment, that would guide your choices for the vast majority of policies.  That section appeared in the UPM v4.0 eDocs and was retrofitted to the UPM v3 eDocs too.  See


It turns out that most of those questions are about the environment (XenApp or XenDesktop?  Provisioned or Permanent?  ), and those questions can be checked programmatically.  Another (Mobile/Laptop versus Static) you can make a good stab at by looking for features that most laptops have, such as a battery, or type of system enclosure.

That means that – in theory – you can offload a lot of that work to software.  In the ideal case, you would just point UPM at a File Share or a DFS Namespace, and it would work out the rest.

We’re not there yet, and may never get there, because the question of what applications you’ve got, and which application settings are important to keep requires a) deep and broad product knowledge  and b) an understanding of what the business regards as important settings, mutable settings, etc.

What we can do, however, is to examine the environment, mostly using WMI queries, and compare the detected settings to those which – in our opinion – are recommended for that environment.  We’ve wrapped that up in a PowerShell script that you can run on your pilot (or production) environment, which will point out any mismatches.

From that, you, as an administrator, can go back to our eDocs “Sixfold way” section, and read up on the reasons why we recommend a particular setting in a particular environment, and decide if that makes sense for you.

Additionally, we were able to look at forum posts on UPM, and pick up on other issues that might arise, such as whether there were trailing spaces in folder names that might cause unexpected effects, or whether the cookie handling was set up correctly, or whether 8.3 filename support was enabled on XP and Windows 2003, or … whatever.

That’s where we are today with this UPM Configuration Check tool.

Because it’s not part of the product, and supplied as-is, we can change it quickly, if (say) a new hypervisor version is released that isn’t recognised by our existing checks.  Or if a new environment or configuration pitfall emerges through the forum, we can put in a check for that.

Because it’s not part of UPM, it can have a User Interface, and you can capture the output, and submit it along with any problem reports.  In some situations it may be easier than running an RSoP report, or capturing the UPMSettings.ini file.

And we can build in awareness of new Citrix products as they’re released (such as PVD), which might invalidate previous recommendations.

The Future

As I said above, we could in theory bake all this environmental awareness into UPM itself, and we could remove large swathes of the configuration.  Which might be fine for 80% of you, but there would be pitfalls:

  • What if a new OS patch changes the results of the WMI queries?  UPM might decide that it wasn’t running on a hypervisor anymore and change its operation.  (We’ve seen some recent version-specific differences in Hyper-V, for example.)
  • What if a new Citrix component appears that alters our recommendation?  PVD is a good example, where we suggest that Profile Streaming is actually better disabled.
  • There might be perfectly good reasons why our recommended configuration isn’t actually going to be optimal.  For example, you may know that for a XenApp server serving a small department, it’s preferable to keep the UPM profiles cached locally.

So we’ll be very cautious about moving any of this environment awareness into the core of UPM.  Where we do, we’ll make sure that you can override UPM decisions, by only letting UPM decide what to do if you’ve configured a policy as “default”.

The script itself is “read-only” – it doesn’t make changes, just reports on  divergences.  Future enhancements might address checking NTFS permissions and ACLs on the user store, and even writing test files to the store, and updating ACLs.  Again, because it would be our script, writing to your system, that’s not a change we’d make lightly.


We hope this tool is going to help new users of UPM overcome their fear of configuration, and help all users understand why certain policies might need to be set in a particular environment.

So we encourage you to try out the tool.  You’ll find it at .  Let us know if it’s useful, and let us know what enhancements you’d like to see.