Product Documentation

Scenario 2 - Multiple folder targets and replication

Aug 14, 2017

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

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 may 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 generally not supported. However, file replication has been used in some specialized deployments in which only a single session can be guaranteed and Active write back is disabled. For information on these special cases, contact Citrix Consulting.

Option 2 - Distributed file system replication

Background reading

Implementing this option

DFS Replication provides folder synchronization across limited bandwidth network connections. This 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 makes it suitable for maintaining a disaster recovery site, for example. This 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 may 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 will 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 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.