Scenario 1 - Basic setup of geographically adjacent user stores and failover clusters
“I want my users to always use a geographically adjacent, preferred networked user store (NUS) for their profiles.” Options 1 and 2 apply in this case.
“I want my NUS to be on a failover cluster, to give me high availability.” Option 2 applies in this case.
The following graphic illustrates this scenario. Users in North America (NA) want to use the NUS in New York rather than the NUS in Brisbane. The aim is to reduce latency and to minimize the traffic sent over the intercontinental link to Australia or New Zealand (ANZ).
Option 1 – DFS Namespaces
- For an overview of the Microsoft DFS Namespaces technology, see http://technet.microsoft.com/en-us/library/cc730736(WS.10).aspx.
- For advice on load balancing user stores, see the Citrix blog at https://www.citrix.com/blogs/2009/07/21/profile-management-load-balancing-user-stores/.
Implementing this option
DFS Namespaces can resolve some of the issues presented in the blog article.
Let us set up a namespace for the NUS called \\MyCorp\Profiles. It is the namespace root. We set up namespace servers in New York and Brisbane (and any of the other sites). Each namespace server has folders corresponding to each Active Directory location, which in turn have targets on a server in New York or Brisbane.
We might have the following locations configured in Active Directory (part of the user records).
|AD Location Attribute (#l#)||Geographic Location|
|West Palm Beach||NA|
|Poughkeepsie, New York||NA|
The following graphic shows one way of setting this up using DFS Namespaces.
Once it is set up, we configure the Path to user store setting as:
The profiles of users belonging to the eight sites are distributed to just two servers, meeting the geographical constraints required of the scenario.
You can order namespace targets and use the ordering rules as follows. When DFS Namespaces resolves which target to use, it is possible to specify that only targets in the local site are chosen. It works so long as you are sure that, for any given user, every desktop and server is guaranteed to belong to the same site.
This technique fails if, say, a user normally based at Poughkeepsie visits Wagga Wagga. Their laptop profile may come from Brisbane, but the profile used by their published applications may come from New York.
The recommended technique, using AD attributes, ensures that the same DFS Namespace choices are made for every session that the user initiates. The reason is that the #l# derives from the user’s AD configuration rather than from machine configurations.
Option 2 - DFS Namespaces with failover clustering
- For a step-by-step guide to configuring a two-node file server failover cluster, see http://technet.microsoft.com/en-us/library/cc731844(WS.10).aspx.
- For information about choosing a namespace type, see http://technet.microsoft.com/en-us/library/cc770287(WS.10).aspx.
Implementing this option
Adding failover clustering allows you to provide basic high availability.
The key point in this option is to turn the file servers into failover clusters, so that folder targets are hosted on a failover cluster rather than a single server.
If you require the namespace server itself to have high availability, you must choose a standalone namespace. Domain-based namespaces do not support the use of failover clusters as namespace servers. Folder targets might be hosted on failover clusters, regardless of the type of namespace server.
Important: The state of file locks may not be preserved if a server in a failover cluster fails. Profile Management takes out file locks on the NUS at certain points during profile processing. It is possible that a failover at a critical point might result in profile corruption.