Product Documentation

Scenario 1 - Basic setup of geographically adjacent user stores and failover clusters

Nov 30, 2012

“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, 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

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; this 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

Wagga Wagga

ANZ

Darwin

ANZ

Brisbane

ANZ

Auckland

ANZ

Seattle

NA

San Diego

NA

West Palm Beach

NA

Poughkeepsie, New York

NA

The following graphic shows one way of setting this up using DFS Namespaces.


Once this is set up, we configure the Path to user store setting as:

\\MyCorp\Profiles\#l#

The profiles of users belonging to the eight sites will be 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. This works well 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, because the #l# derives from the user's AD configuration rather than from machine configurations.

Option 2 - DFS Namespaces with failover clustering

Background reading

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, as domain-based namespaces do not support the use of failover clusters as namespace servers. Folder targets may 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, so it is possible that a failover at a critical point may result in profile corruption.