I previously wrote a blog article on properly configuring Citrix Profile Management and Folder Redirection. If you have not yet read it, then I would suggest you read it first.  All of the articles in this series apply to non-persistent virtual desktops or XenApp published desktops. You can find Part 1 at the link below:


After I wrote the first article I received a lot of requests to provide guidelines on how to properly scale file services to support Citrix Profile Management as well as Folder Redirection.  Specifically, I received the following types of questions:

  • How do I distribute users across multiple different file servers or NAS devices?
  • How many IOPS will typically be required for UPM and Folder Redirection?
  • How many users can I get on a single file server or NAS device?
  • How much bandwidth do I need for the file server or NAS device?

I finally decided to write some follow-up articles to answer the above questions and help provide some guidelines on how to scale your file services infrastructure to accommodate large environments.  In this article, I will address the first question on how to distribute users across different file clusters or NAS devices.

Before we begin, if you have less than 5,000 concurrent XenApp sessions or less than 5,000 concurrent VDI users, then architecting your environment should not be too difficult as a single file cluster or NAS device with enough drives, plenty of RAM and multiple LACP bonded 1 Gb NICs or preferably 10 Gb NICs should be able do the trick as long as you configure Citrix Profile Management and Folder Redirection correctly per my blog.  When you start getting into larger environments where you need to support 10K, 20K, 30K or more users, then it becomes a little more complex as a single file cluster or NAS device might not be enough.

Company ABC – 20,000 Non-persistent Windows 7 Desktops

To illustrate how to properly scale a large environment let’s use a fictitious company that needs to deploy 20,000 non-persistent Windows 7 virtual desktops from a single data center located in New York City.  We will walk through how one could design the Citrix Profile Management and Folder Redirection for this environment.

First, let’s define a few assumptions for our fictitious company:

  1. All 20,000 virtual desktops are non-persistent and delivered via Provisioning Services.
  2. All desktops will be hosted in a single data center.
  3. All servers are virtual and all hypervisors and file services are connected at 10Gb.
  4. All 20,000 users will use the same gold PVS image with some apps loaded in the base OS and others delivered via XenApp Streaming to the virtual desktop or delivered via XenApp hosted.
  5. We want to limit each file cluster or NAS target to no more than 5,000 users.
  6. All file services used for Profile Management and Folder Redirection will be co-located in the same data center and highly connected to our virtual desktops.

Method #1: Creating Separate Desktop Groups or XenDesktop Sites

Since Citrix Profile Management and Folder Redirection are configured through Group Policy, the quickest and easiest thing that first comes to mind is to divide the 20,000 users into four groups each containing 5,000 users.  You could create four XenDesktop group assignments and have the desktops for each group reside in a separate OU.  Since a unique OU is used, a different GPO for folder redirection and Citrix Profile management could be assigned.  The screen shot below illustrates what this would look like in the Desktop Studio Console.

A user would only be assigned to one of the desktop groups and each desktop group would be in a unique OU that has GPOs specifying different file servers for Profile Management and Folder Redirection.

The screen shot below illustrates what this would look like in the Group Policy Management Console.

Using this method, you could easily distribute the users across different file clusters or NAS devices. Also, this method could be used with multiple XenDesktop sites instead of multiple desktop groups within a single XenDesktop site.  You might be asking yourself, “Why would I ever have more than one XenDesktop site instead multiple desktop groups in the same site?” The answer is that for really large or critically important environments, you need multiple XenDesktop sites to address scalability and reliability concerns.  However, I will save that topic for another blog, so stay tuned!

Personally, I am not a fan of this method of load distribution across file servers for the following reason; remember that all 20,000 desktops are in the same data center and using the same gold image delivered from Provisioning Services.  Should it matter which desktop group or which desktop a user connects to?  No, it should not matter!  If the catalogs or hypervisors serving Group 1 go down, those users should be able to connect to Group 2, Group 3 or Group 4, as long as there are desktops available.  Since all 20,000 desktops are identical, I should be able to send users to any group or any XenDesktop site.  However, using this architecture, if Group 1 becomes unavailable or runs out of desktops, and I send Group 1 users to desktops in Group 2, the Group1 users will no longer have access to their profile and redirected folders.  The users would end up getting new profiles and new redirected folders on the file servers assigned via the Group 2 Group Policy.  This is not desirable.  Ideally, I should be able to treat the identical desktops groups within a single XenDesktop site, or multiple XenDesktop sites as one logical unit.  As long as a desktop is up and available, the user should be able to connect and have their profile and redirected folders available.  In order for us to be able to send the user to any desktop group or XenDesktop site that has available desktops, we need a more intelligent way to distribute the file services load, which bring us to the next method of load distribution.

Method #2: Intelligent Load Distribution based on Group Membership and Active Directory

Citrix Profile Management

While both Citrix Profile Management paths and Folder Redirection paths are assigned via Group Policy, Profile Management is assigned through a Computer Setting and Folder Redirection is assigned through a User Setting.  This means that we cannot use Active Directory Groups for setting the path to the Citrix Profile Management store.  Since the virtual desktop or XenApp server can only have one path set via Computer policy, this one path must be used by all users that logon to the desktop or XenApp server.

So how do we give each user a unique path could resolve to a different file server? The answer is DFS-N and unique Active Directory attributes from the user’s account.  We already have two great blog articles written by Bill Powell as well as details on how to accomplish this in our Citrix eDocs.  I will not waste time rewriting it here, so please check out the following links:




The great thing about using DFS-N as a namespace solution is that it is highly available due to integration with Active Directory, and it also works with non-Windows NAS devices.  Personally, I am a big fan of NetApp and their CIFS filer technology which is fully supported and compatible as a target within the DFS namespace.  However, other non-Windows NAS devices are also supported as DFS leaf targets, including EMC.  The benefit to using the CIFS capabilities built into your SAN/NAS is that you not only get robust and scalable performance, but you also get other great features for high availability such as block level storage replication to other appliances.  For large virtual environments you are going to need to partner with a top-tier storage vendor anyway, so I would recommend you leverage them for your CIFS requirements as well.

So back to our design for 20,000 virtual desktops in a single data center, let’s assume that we are using NAS appliances called NYC-NAS1, NYC-NAS2, NYC-NAS3 and NYC-NAS4.  We have four separate appliances that we want to distribute our load across, so we create the following Active Directory DFS namespace:


Each of our four NAS appliances will have a CIFS share called UserData created and they will be added as leaf node targets as follows:

\\ABC.corp\NYCDataCenter\NYC-NAS1 (points to \\NYC-NAS1\UserData)

\\ABC.corp\NYCDataCenter\NYC-NAS2 (points to \\NYC-NAS2\UserData)

\\ABC.corp\NYCDataCenter\NYC-NAS3 (points to \\NYC-NAS3\UserData)

\\ABC.corp\NYCDataCenter\NYC-NAS4 (points to \\NYC-NAS4\UserData)

We will split our 20,000 users across the four NAS servers by assigning each user to a specific NAS by populating the UID attribute on each user’s Active Directory account.  We will populate the UID attribute with a value of NYC-NAS1, NYC-NAS2, NYC-NAS3 or NYC-NAS4.  The trickiest thing about deciding which AD attribute to select is picking one that is not already in use or likely to be used.  You can use ADSI Edit to view the full list of available attributes.  There are plenty of attributes that can be used that are not typically in use such as #UID# or #InternationalISDNNumber#.  For a complete list of all attributes see the following links:




So the path that we assign to our user store for Profile Management will be as follows:


Folder Redirection

Now that we know how to have a single UPM path that can be assigned to all 20,000 desktops that spreads users across multiple file servers, how do we distribute Redirected Folders across multiple file servers?  The answer is AD Group Membership.  When defining Folder Redirection via Microsoft Group Policy, you can specify a different path based on user group membership.

So in our example for ABC Company and their 20,000 users, we will create four Active Directory Groups and divide the users up evenly between the groups.  We will name each group after the data center and NAS appliance; NYC-NAS1, NYC-NAS2, NCY-NAS3, NYC-NAS4.  Each user should only be added to one of the groups.  Additionally, whatever group a user is placed into should match the value that was placed on their Active Directory account attribute for Citrix Profile Management.  So, in our example, if a user is placed into the NYC-NAS3 group, then NYC-NAS3 should be written to the Active Directory account attribute.

Here is a screen shot from the GPO containing the Folder Redirection policy that will be applied to all 20,000 virtual desktops for ABC Company.

So in this example of redirecting the AppData folder, we would specify the path for each group.  So, if a user was in the NYC-NAS1 group, then the path to the user’s AppData folder would be as follows:


Each folder name should be explicitly called out at the end of the path.  As another example, for a user in the NYC-NAS1 group, their Desktop folder would be redirected in the Group Policy as follows:


There are a few things to consider when architecting your file services infrastructure for Citrix Profile Management and Folder Redirection. First, you want to make sure that your file services are in the same data center and are highly connected to the virtual desktops; this means plugged into the same core switching infrastructure and networking backbone.  The only possible exception is the location of the user’s home directory or documents folder.  While it would be most desire bale and still highly recommended that the user’s home directory be co-located in the same data center, there are instances where that may not be possible.  For these situations, you still want to specify local file services in the same data center as the virtual desktops for hosting of the Citrix profile Management share and all other redirected folders.  The only folders that could ever possibly be redirected to another data center are key personal folders (Documents, Pictures, Music, and Videos).  The reason these are the only exceptions is that the native Folder Redirection engine allows you to specify that these folders follow the user’s home directory.

The second thing to consider is that you want to make sure that any user who accesses a desktop group using this architecture has a group assigned and defined in the Folder Redirection policy and that they have their AD account attribute properly set for Citrix Profile Management.  The easiest way to do this is to only publish the desktop assignments to the Active Directory groups created and defined in the Folder Redirection policy.  Using our ABC Company example, in Desktop Studio we would select NYC-NAS1, NYC-NAS2, NYC-NAS3 and NYC-NAS4 as the only groups permitted to launch the virtual desktops.  That way, we could be sure that the user would get the proper Folder Redirection policy.  Additionally, we could easily create an ADSI script that ensures that the user’s AD account attribute matches their group assignment for folder redirection.  The script can easily be programmed to do the following:

  1. Query a list of groups and get a list of all the users. For our example it would be NYC-NAS1, NYC-NAS2, NYC-NAS3, and NYC-NAS4.
  2. Compare the list of each group and make sure that the user only belongs to one group, if a user is in more than one group, then take action or send an alert.
  3. For each user in the group, write the name of the group to the Active Directory attribute if it does not already match. For our example, if Jane Doe is in the NYC-NAS1 group, then we would write NYC-NAS1 to the #uid# attribute on the account of Jane Doe.

Whenever a user needs to be granted access, they must be added to the proper group and their AD attribute for Profile Management needs to be set.  A script like the one above could be periodically run at a set interval to make sure that this has properly taken place.

The final thing to note is that I used the same root path for both Citrix Profile Management and Folder Redirection, but I made each a separate top-level folder in the path so that the Profile Management folder is a parallel sibling to the Folder Redirection and vice-versa.  It is important to do this correctly as you never want the Profile to be a child of the Redirected Folder location or a child of the home directory.  It should always be in its own top-level path.  Additionally, you never want redirected folders to be a child in the path of Profile Management.  Using the same base-level path as a starting point is a good idea as it allows us to use a single share and have a single directory containing all of the user’s data, but it must be done so that it keeps the paths from ever having a parent-child relationship to each other.  So, in our example for ABC Company, the two unique paths for Jane Doe assigned to NYC-NAS1 would be as follows:



If Jane Doe’s home directory was assigned to the same NAS device, then her home directory path would be as follows:


For the example of Jane’s home directory, it is important that the home directory be mapped directly to the Home folder and not to the JaneDoe.ABC folder.  Assuming Jane’s home directory was drive H:, then her H: drive should be mapped at the Home folder level, so that Jane cannot see or browse her UPM or FolderRedir folders under the H: drive.

By following this design for distributing load across file servers for Profile Management and Folder Redirection you can easily scale to support tens of thousands of users and most importantly, you can have any user access any desktop group or XenDesktop site in your data center and the user will always get the correct profile and redirected folders!

I hope you find this useful and I encourage you to check out my next article in this series on determining the IOPS and bandwidth requirements for Citrix Profile Management and Folder Redirection!  You can find part 3 at the link below:



Dan Allen