-
-
High availability and disaster recovery with Profile Management
-
Scenario 1 - Basic setup of geographically adjacent user stores and failover clusters
-
-
FAQs about profiles on multiple platforms and Profile Management migration
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
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).
| 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 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.
Share
Share
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.