Scenario 2 - Multiple folder targets and replication 编辑

“If my local NUS is not available, I want my users to be able to get their profile data from a backup location somewhere else on the corporate network. If they make changes, those changes need to get back to their preferred NUS when it is available again.”

The basic requirement in this scenario is to provide alternative locations for profiles on the network. The use case includes the partial failure of the network infrastructure or the complete unavailability of a folder target such as a failover cluster.

Options you need consider are the use of multiple folder targets and the use of DFS replication.

Option 1 - Referrals to multiple folder targets

Background reading

For information about tuning DFS namespaces, see https://docs.microsoft.com/en-us/windows-server/storage/dfs-namespaces/tuning-dfs-namespaces
.

About this option

A referral is an ordered list of targets that are tried in turn by a user device. It is designed for scenarios where the targets are read-only, such as software libraries. There is no linkage between targets, so using this technique with profiles might create multiple profiles that cannot be synchronized.

However, it is possible to define both an ordering method and a target priority for targets in referrals. Choosing a suitable ordering method appears to result in a consistent choice of target by all user sessions. But in practice, even when all of a user’s devices are within the same site, intra-site routing problems can still result in different targets being chosen by different sessions. This problem can be compounded when devices cache referrals.

Important: This option is not suitable for Profile Management deployments and is not supported. However, file replication has been used in some specialized deployments in which only a single session can be guaranteed andActive write back is disabled. For information on these special cases, contact Citrix Consulting.

Option 2 - Distributed file system replication

Background reading

• For an overview of Distributed File System Replication (DFSR), see https://docs.microsoft.com/en-us/windows-server/storage/dfs-replication/dfsr-overview
  .
• For a statement of support about replicated user profile data, see https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/microsoft-8217-s-support-statement-around-replicated-user/ba-p/398230
  .
• To understand why DFSR does not support distributed file locking, see https://blogs.technet.com/b/askds/archive/2009/02/20/understanding-the-lack-of-distributed-file-locking-in-dfsr.aspx
  .

Implementing this option

DFS Replication provides folder synchronization across limited bandwidth network connections. This option appears to solve the problems in Option 1 because it synchronizes multiple folder targets that a single namespace folder definition refers to. Indeed, when folders are added as targets to a folder definition, they can be specified as belonging to a replication group.

There are two forms of replication to consider:

• One-way replication (also known as active-passive replication) is designed for backing up critical data to a safe repository. This replication makes it suitable for maintaining a disaster recovery site, for example. It can be made to work with Profile Management so long as the passive targets are disabled for referrals, and are only invoked when the disaster recovery plan is activated.
• Two-way replication (also known as active-active replication) is intended to provide local read-write access to global shared data. Instantaneous replication is not necessarily a requirement here. The shared data might be modified infrequently. Important: Active-active DFSR is not supported.

A schedule defines the frequency with which data is replicated. A frequent schedule is more intensive on both CPU and bandwidth, but does not guarantee instantaneous updates.

At various points in its operation, Profile Management requires certain files to be locked in the NUS to coordinate updates to the (shared) user store. Typically these updates take place when a session starts and ends, and in the middle of a session if active write-back is enabled. Since distributed file locking is not supported by DFS Replication, Profile Management can only select one target as an NUS. This set effectively eliminates any value of two-way replication (active-active replication), which is therefore not suitable for Profile Management and is not supported. One-way replication (active-passive replication) is suitable for Profile Management only as part of a disaster recovery system. Other uses are not supported.