When you’re setting up a User Store for Profile Management, you configure the location in the GPMC under “Path to user store” (as described in http://support.citrix.com/article/CTX118944 ), and in the simple case, that’s a single location, such as \\server1\profiles .

(Actually, you’d also include the username and probably the userdomain variables as well, and a system environment variable to indicate the profile version or platform e.g. \\server\profiles \ %USERNAME%.%USERDOMAIN% \ %ProfVer . However, it all gets very verbose, and I’ll assume you can add these bits yourselves in the discussion below.)

Anyway, we’ve had a couple of requests recently on how to load-balance User Stores for Profile Management across multiple servers, and we came up with a couple of approaches which might be helpful generally.

A couple of reasons for load-balancing came to light:

  • simply to balance the load across several servers
  • where an organisation operates several datacenters, each serving one or more geos.

The customers didn’t want to use DFS, because they recognised that replication would take place of all profiles between all DFS servers, which would waste bandwidth. I seem to recall that Microsoft doesn’t recommend DFS for storing profiles, anyway.

One administrator asked if he could use %homeshare% on the assumption that %homeshare% ought to reference a local server.  No, because %homeshare% is a user environment variable, and Profile Management can’t see user environment variables … but AD does have a property #homeDirectory# which holds the same information.  So if you’re OK to put profiles on the same share as the users’ HOME directories, configure the “Path to user store” as #homeDirectory#\profiles

The other approach is more general, and may require some AD configuration and/or some DNS hackery.

If you can find an AD attribute, such as #c# (country) or #l# (location – that’s #L# but lower case), then the job may be easy – just set the “Path to user store” to \\FileServ#c#\profiles (say) – this should expand to \\FileServUS\profiles or whatever your country happens to be.  Similarly #l# could be used, but if your office is in “Ashby de la Zouch” or “Llanfairpwllgwyn…” (you know the place I mean, in Wales) that may cause grief when used as part of a server name!

So if there are spaces or just a very long name, you’ll have to get your AD admins to create and populate a new attribute, such as #geo#

What if you’ve got a #l# attribute, short, with no spaces, but you want to map several different values to the same server?  In Citrix, for example, we have several geographically close offices sharing a single datacenter, and some offices which have had different names in their history, e.g.

Chalfont (CHF), High Wycombe (HW), Gerrards Cross (GX) and even London (LON) all actually refer to the same office, so \\FileServ#l#\profiles will expand to

\\FileServCHF\profiles or \\FileServHW\profiles etc…

The trick here is to configure multiple names in DNS with the same IP address, so that, regardless of what’s configured in #l#, it all maps to the same physical server.