Houston, we have a (TS/RDS user profile storage) problem RRS feed

  • Question

  • I’m truly hoping that someone in this forum is able to provide some guidance to my user profile storage design issue.  Thanks for taking the time to read my post.


    First, a bit in the way of background:

    I work in a large terminal services environment (Citrix XenApp 5.0 over W2K3 R2 SP2 Ent) with approximately 350 servers in our production environment, 51,000 named users and anywhere from 10K-12K daily concurrent users.


    We use roaming terminal services profiles in a bit of a unique way: while we currently have W2K3 R2 SP2 Ent clusters with SAN-attached storage housing our profiles (this is the rather standard part), we use an alias to refer to the profile and home directory location in each user AD profile, rather than the cluster name itself.  Let’s call these tshome.net and tsprof.net.  We then use the hosts file on each server to redirect to the correct storage location; this allows us to change our storage locations without touching each AD account, and it also allows us to silo the storage location for sensitive apps.


    What I mean is this:

    ·         In the AD account:

    ·         Terminal Services Profile = tshome.net\home\%username%

    ·         Home directory = tsprof.net\profile\%username%

    ·         Physical location of the storage:

    ·         Home directories: \\ClusterA\Home at

    ·         Profiles: \\ClusterB\Profiles at

    ·         In the hosts file on the terminal servers:

    ·         tshome.net

    ·         tsprof.net


    These aliases are not in DNS, rather only in the hosts file on each TS.  These aliases are also used in our GPOs, as well as in a number of our (approximately 3000) TS hosted apps.  It should be noted here that we use group policy to redirect %APPDATA%, Start Menu, Desktop and My Documents to the home directory.


    The problem:

    Over the last several years, we’ve had intermittent issues with our TS profile and home directory storage clusters; and several deep dives by the various responsible teams (storage, network, server) has not revealed the root cause.  Furthermore, as our workforce becomes increasingly comfortable with accessing our Citrix environment remotely, we’ve seen a significant spike in the number of users working from home on inclement weather days (an increase in concurrency of 50% or more).


    We have a new NAS-based solution on the horizon, but we recognized that our current solution would not hold up in the face of the first major snow day, and are therefore in the midst of implementing a interim solution to get us through the winter months, as follows: Distribute both load and risk by creating breaking up the storage alphabetically into several clusters.  User profiles & home dirs A-E would now be housed in tshome1.net/tsprofile1.net, F-J in tshome2.net/tsprofile2.net., etc.  Unfortunately, this presents a problem that’s been confirmed in testing: we now have the one logical location in our GPOs and many application packages that must be resolved to one of several physical locations.  Hosts files now won’t work (we need to define per user, rather than per machine), nor will a DNS CNAME entry.


    Solutions Under Consideration:

    DFS: In my previous experience with DFS (server or domain), I’ve always used a single logical location to direct users to one of several identical physical locations.  In this case, I would need to direct users (as noted above) from a single logical location to only one of several physical linked locations:



    DFS_Link1: ClusterA – users A-E

    DFS_Link2: ClusterB – users F-J


    I’m hoping someone reading this post has an idea as to how I can use DFS in this manner – where users can be directed to a single location beneath the DFS root among several available links, each of which us unique and hosts only a fraction of the stored data.


    Application Compatibility Scripts: I’m considering using the app compat scripts on each server to convert the home directory and profile location into a variable that can be referenced in GPOs and AD accounts.  I still haven’t really gotten my head around how to resolve the one to many issue: either with new domain groups (using ifmember), or perhaps using the built-in %HOMEDIR% and %HOMEDRIVE% variables.  Any ideas would be appreciated.


    Thanks for reading my very lengthy post.  Once again, recommendations from anyone with experience in this area would be greatly appreciated.


    Monday, December 12, 2011 2:53 AM