Post to Twitter |
Comments (6) |
Views (6242) |
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.
Comments (6)
Jul 22, 2009
Ryan Benigno says:
I know MS doesn't support DFS with replication for profile storage, but I hadn't...I know MS doesn't support DFS with replication for profile storage, but I hadn't seen the recommendation for regular old DFS. Can you please post a link?
Thanks.
Jul 22, 2009
Bill Powell says:
It was DFS with replication that I had in mind when I made the comment. "r...It was DFS with replication that I had in mind when I made the comment. "regular old DFS" is something I haven't looked at. What sort of deployment did you have in mind? (It'll help us plan the testing of the next release of Profile Management.)
Jul 23, 2009
Bill Powell says:
After a little investigation, I have to say that using DFS with Profile Manageme...After a little investigation, I have to say that using DFS with Profile Management is looking like a really deep topic; one which really needs a blog post of its own, or a chapter in a Profile Management Best Practice Guide (if there's demand for such a document). Right now, we can see that there are some DFS configurations that will work, but there are others where more investigation is needed before we can make a recommendation.
Jul 23, 2009
Edward Maule says:
We have our XenApp5 on Win2k8 64bit pre-rollout environment setup. It's been run...We have our XenApp5 on Win2k8 64bit pre-rollout environment setup. It's been running for a few months now. Profile Management is by far my favorite feature of XenApp5.
I setup a Win2k8 active-active file cluster with DFS. One cluster node hosts miscellaneous shared directories and the other hosts XenApp profiles. We are not using DFS replication. I'm not even sure you can when you run DFS on a cluster, but I could be mistaken. I can provide additional info on how our DFS is setup if you'd like.
We have several thousand users and a sample TS profile path in AD for Pres4 looks like this.
\\Server\PresProfiles\M\username
We have 26 folders in the share, one for each letter of the alphabet, and if your last name begins with M, your profile is saved in the M folder.
I'd like to do the same thing with XenApp, but I cannot figure out how since the GP setting in User Profile Manager will override anything we put in the TS profile path in AD.
Do you know if this is possible?
For XenApp, my GP profile setting in UPM is
\\company.com\Profiles\DFSCoreProfiles#cn#
From the blog post it seems I need to try something like this?
\\company.com\Profiles\DFSCoreProfiles#X##cn#
Where #X# = some kind of AD attribute I can populate with the first letter of a user's last name.
(There's supposed to be slashes between DFSCoreProfiles and #X# and #cn#, but it's not showing up in my post).
Jul 24, 2009
Bill Powell says:
Yes, that's exactly what I was getting at in my blog post. I guess it shou...Yes, that's exactly what I was getting at in my blog post. I guess it should be possible to create a new AD attribute and populate it automatically in a script which looks at #sn# and sets #X# to the first letter of #sn#.
Sadly there's no feature within Profile Management to do this sort of transformation dynamically. If this turns out to be a common scenario, though...
So let me know if this works, and I'd welcome feedback from other folks too on whether this is an area we should be developing further.
Jul 24, 2009
Bill Powell says:
One other (general) comment is that Edward's proposal uses #cn#. I assume ...One other (general) comment is that Edward's proposal uses #cn#. I assume he's only using a single domain and so #cn# is probably unique in a single domain, but we'd generally recommend using #sAMAccountName# for a single domain, or %USERNAME%.%USERDOMAIN% in a multi-domain environment to be sure it's unique.
Hope that's not "teaching grandma to suck eggs"
Add Comment