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

Background reading

• For an overview of the Microsoft DFS Namespaces technology, see DFS Namespaces overview
  .
• 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).

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:

\\MyCorp\Profiles\#l#

The profiles of users belonging to the eight sites are distributed to just two servers, meeting the geographical constraints required of the scenario.

Alternatives

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 are guaranteed to belong to the same site.

This technique fails if, say, a user normally based at Poughkeepsie visits Wagga Wagga. Their laptop profile might come from Brisbane, but the profile used by their published applications might 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

Background reading

• For a step-by-step guide to configuring a two-node file server failover cluster, see Deploying a two-node clustered file server
  .
• For information about choosing a namespace type, see https://docs.microsoft.com/en-us/windows-server/storage/dfs-namespaces/choose-a-namespace-type
  .

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 might 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.