Microsoft’s Support Statement Around Replicated User Profile Data

[Note from Ned: this article was created and vetted by the Microsoft development teams for DFS Replication, DFS Namespaces, Offline Files, Folder Redirection, Roaming User Profiles, and Home Folders. Due to some TechNet publishing timelines, it was decided to post here in the interim. This article will become part of the regular TechNet documentation tree at a later date. The primary author of this document is Mahesh Unnikrishnan, a Senior Program Manager who works on the DFSR, DFSN, and NFS product development teams. You can find other articles by Mahesh at the MS Storage Team blog: https://blogs.technet.com/b/filecab.

The purpose of this article is to clarify exactly which scenarios are supported for user data profiles when used with DFSR, DFSN, FR, CSC, RUP, and HF. It also provides explanation around why the unsupported scenarios should not be used. When you finish reading this article I recommend reviewing https://blogs.technet.com/b/askds/archive/2009/02/20/understanding-the-lack-of-distributed-file-locking-in-dfsr.aspx

Update 4/15/2011 - the DFSR development team created a matching KB for this - https://support.microsoft.com/kb/2533009]

Deployment scenario 1: Single file server, replicated to enable centralized backup

Consider the following illustrative scenario. Contoso Corporation has two offices – a main office in New York and a branch office in London. The London office is a smaller office and does not have dedicated IT staff on site. Therefore, data generated at the London office is replicated over the WAN link to the New York office for backup.

Contoso has deployed a file server in the London branch office. User profiles and redirected home folders are stored on shares exported by that file server. The contents of these shares are replicated to the central hub server in the New York office for centralized backup and data management. In this scenario, a DFS namespace is not configured. Therefore, users will not be automatically redirected to the central file server if the London file server is unavailable.

As illustrated by the diagram above, there is a file server hosting home folders and user profile data for all employees in Contoso’s London branch office. The home folder and user profile data is replicated using DFS Replication from the London file server to the central file server in the New York office. This data is backed up using backup software like Microsoft’s System Center Data Protection Manager (DPM) at the New York office.

Note that in this scenario, all user initiated modifications occur on the London file server. This holds true for both user profile data and the data stored in users’ home folders. The replica in the New York office is only for backup purposes and is not being actively modified or accessed by users.

There are a few variants of this deployment scenario, depending on whether a DFS Namespace is configured. Following sub-sections detail these deployment variants and specify which of these variants are supported.

Scenario 1A: DFS Namespace is not configured

[Supported Scenario]

Scenario highlights:

• A single file server is deployed per branch office. Home folders and roaming user profiles for users in that branch office are stored on the branch file server.
• This data is replicated using DFS Replication over the WAN from (multiple) branch file servers to a hub server for centralized backup (using DPM).
• DFS Namespace is not configured.

Specifics:

• In this scenario, in effect, only one copy of the data is modified by end-users, i.e. the data hosted on the branch office file server (London file server, in this example).
• The replica hosted by the file server in the hub site (New York file server, in this example) is only for backup purposes and users are not actively directed to that content.
• In this scenario, DFS Namespaces is not configured.
• Folder redirection may be configured for users in the branch office with data stored on a share hosted by the branch office file server.
• Roaming user profiles may be configured with user profile data stored on the branch office file server.
• Offline Files (Client Side Caching) may be configured, with the data stored on the branch office file server made available offline to users in the branch office.

Scenario 1B: DFS Namespace is configured – single link target

[Supported Scenario]

This is a variation of the above scenario, with the only difference being that DFS Namespaces is set up to create a unified namespace across all shares exported by the branch office file server. However, in this scenario, all namespace links must have only one target¹ - the share hosted by the branch office file server.

1 Deployment scenarios where namespace links have multiple targets are discussed later in this document.

Scenario highlights:

• A single file server is deployed per branch office. Home folders and roaming user profiles for users in that branch office are stored on the branch file server.
• This data is replicated using DFS Replication over the WAN from (multiple) branch file servers to a hub server for centralized backup (using DPM).
• A DFS Namespace is configured in order to create a unified namespace. However, namespace links do not have multiple targets – the share on the central file server is not added as a DFS-N link target.

Specifics:

• In this scenario, in effect, only one copy of the data is modified by end-users, i.e. the data hosted on the branch office file server (London file server, in this example).
• The replica hosted by the file server in the hub site (New York file server) is only for backup purposes and users are not actively directed to that content.
• In this scenario, a DFS Namespace may be configured, but multiple targets are not set up for links. In other words, none of the namespace links point to replicas of the share hosted on the branch office file server as well as the central file server. Namespace links point only to the share hosted by the branch office file server.
• Therefore, if the branch office file server were to fail, there will not be an automatic failover of clients to the central file server.
• Folder redirection may be configured for users in the branch office with data stored on a share hosted by the branch office file server.
• Roaming user profiles may be configured with user profile data stored on the branch office file server.
• Offline Files (Client Side Caching) may be configured, with the data stored on the branch office file server made available offline to users in the branch office.

Support Statement … (deployment scenario 1):

Both variants of this deployment scenario are supported. The key point to remember for this deployment scenario is that only one copy of the data is actively modified and used by client computers, thereby avoiding issues caused by replication latencies and users accessing potentially stale data from the file server in the main office (which may not be in sync).

The following use-cases will work in this deployment scenario:

• TS farm using the file server in the branch as backend store.
• Laptops in branch office with offline files configured against the branch file server.
• Regular desktops with folder redirection configured.

In this scenario, the following technologies are supported and will work:

• Folder redirection to the file server in the branch.
• Client side caching/Offline files.
• Roaming user profiles.

Designing for high availability

DFS Replication in Windows Server 2008 R2 includes the ability to add a failover cluster as a member of a replication group. To do so, refer to the TechNet article ‘Add a Failover Cluster to a Replication Group’. Offline files and Roaming User Profiles can also be configured against a share hosted on a Windows failover cluster.

For the above mentioned deployment scenarios, the branch office file server may be deployed on a failover cluster to increase availability. This ensures that the branch office file server is resilient to hardware and software related outages affecting individual cluster nodes and is able to provide highly available file services to users in the branch office.

Deployment scenario 2: Multiple (replica) file servers for geo-location

Consider the same scenario described above with a few differences. Contoso Corporation has two offices – a main office in New York and a branch office in London. Contoso has deployed a file server in the London branch office. User profiles and redirected home folders are stored on shares exported by that file server. The contents of these shares are replicated to the central hub server in the New York office for centralized backup and data management.

In this scenario, a DFS namespace is configured in order to enable users to be directed to the replica closest to their current location. Therefore, namespace links have multiple targets – the file server in the branch as well as the central file server. Optionally, the namespace may be configured to prefer issuing referrals to shares hosted by the branch office file server by ordering referrals based on target priority.

The replica in the central hub/main site may optionally be configured to be a read-only DFS replicated folder.

Scenario 2A: DFS Namespaces is configured – multiple link target configuration

[Unsupported Scenario]

Scenario highlights:

• A single file server is deployed per branch office. Home folders and roaming user profiles for users in that branch office are stored on the branch file server.
• This data is replicated using DFS Replication over the WAN from (multiple) branch file servers to a hub server for centralized backup (using DPM).
• A DFS Namespace is configured in order to create a unified namespace.
• Namespace links have multiple targets – the share on the central file server is added as a second DFS-N link target.
• The namespace may optionally be configured to prefer issuing referrals to the branch office file server. This may be done because administrators require that only when the branch file server is unavailable, should clients be redirected to the central file server.

Specifics:

• In this scenario, in effect, end-users may be directed to any of the available replicas of data. It is expected that in the normal course of events, users will modify the data hosted on the branch office file server.
• A DFS Namespace is configured and multiple targets are set up for namespace links. In other words, namespace links point to replicas of the share hosted on both the branch office file server as well as the central file server. The namespace may be configured to prefer issuing referrals to the share located on the branch office file server.
• If the branch office file server were to be unavailable, users would be redirected to the replica on the central hub server.
• Administrators may also require that roaming users be directed to the copy of their data or user profile that is located on a server closest to their physical location (eg. for users travelling to another site/branch office, this would be the replica in that office).

Scenario 2B: DFS Namespaces is configured – multiple link targets, read-only replica on central/hub server

[Unsupported Scenario]

Scenario highlights:

• In this scenario, the exact same configuration described above (scenario 2A) applies with only one difference - the replica on the central server is configured to be a read-only DFS Replicated folder.

Specifics:

• In this scenario, in effect, end-users may be directed to any of the available replicas of data. It is expected that in the normal course of events, users will modify the data hosted on the branch office file server.
• A DFS Namespace is configured and multiple targets are set up for namespace links. In other words, namespace links point to replicas of the share hosted on both the branch office file server as well as the central file server. The namespace may be configured to prefer issuing referrals to the share located on the branch office file server.
• The replica on the central file server has been configured to be a read-only replica.
• If the branch office file server were to be unavailable, users would be redirected to the replica on the central hub server. At this point however, the share becomes read-only for applications and the users, since this replica is a read-only replica.
• Administrators may also require that roaming users be directed to the copy of their data or user profile that is located on a server closest to their physical location (eg. for users travelling to another site/branch office, this would be the replica in that office).

What can go wrong?

 

• In the deployment scenarios listed above (2A, 2B), it is not guaranteed that replication of home folder data or user profiles data between the branch office file server and the central file server is always up to date. This is because many factors may influence replication status, such as the presence of large replication backlogs caused by many files changing frequently or files that weren’t replicated because file handles were not closed, heavy system load, bandwidth throttling, replication schedules etc.
• Since DFS Replication does not perform transactional replication of user profile data (i.e. replicating all the changes to a given profile, or nothing at all), it is possible that some files belonging to a user profile may have replicated, whilst some others may not have replicated by the time the user was failed over to the server at the central site.
• The DFS Namespace client component may fail over the client computer to the central file server if it notices transient network glitches or specific error codes when accessing data over SMB from the branch file server. This may not always happen only when the branch file server is down, since momentary glitches and some transient file access error codes may trigger a redirect.
• Therefore, there is a potential for users to be redirected to the central file server even if the namespace configuration was set to prefer referrals to the branch file server. If the replica data on the central file server is not in sync, users may be impacted in the following ways.

As a result of the behavior described above the following consequences may be observed:

• If the central file server is a read-write replica:  
  • Roaming user profiles: User profile data may get corrupted since all the changes made by the user in their last logon may not have replicated to the central server. Therefore, the user may end up modifying a stale or incomplete copy of the roaming profile during their next logon, thus resulting in potential profile corruption.
  • Offline Files (CSC)/Folder Redirection: Users may experience data loss or corruption, since the data on the central replica may be stale/out of sync with the data on the branch office file server. Therefore, users may experience data loss, where their latest modifications are not persisted and they are presented a stale/old copy of data.
  • Since DFS Replication is a multi-master replication engine with last-writer-wins conflict resolution semantics, the stale copy of data that was edited on the central file server will win replication conflicts and will overwrite the fresher copy of data that existed on the branch file server, but didn’t replicate out.
• If the central file server is a read-only replica:  
  • When a user is directed to a read-only replica located on the central file server (Scenario 2B), applications and users will not be able to modify files stored on that share. This leads to user confusion since a file that could be modified just a while earlier has suddenly become read-only.
  • Roaming user profiles: If the user is directed to the central file server (read-only replica), the profile may be in a corrupt state since all changes made by the user in their last logon may not yet have replicated to the central server. Additionally, the roaming user profiles infrastructure will be unable to write back any subsequent changes to the profile when the user is logged off, since the replica hosting the user profile data is read-only.
  • Offline Files (CSC)/Folder Redirection: Users may experience data loss or corruption, since the data on the central replica may be stale/out of sync with the data on the branch office file server. Therefore, users may experience data loss, where their latest modifications are not persisted and they are presented a stale/old copy of data. Additionally, users will notice sync errors or conflicts for files that have been modified on their computers. It will not be possible for users to resolve these conflicts, because the server copy is now read-only (since it is hosted on a read-only replicated folder).

What if one of the link targets is disabled?

Scenario highlights:

 

• In this scenario, the exact same configurations described above (scenario 2A or scenario 2B) apply, with one key difference – the link target that points to the share located on the central hub server is disabled during the normal course of operations.
• If the branch office file server were to be unavailable, the link target to the central hub server is manually enabled, thus causing client computers to fail over to the copy of the share on the central file server.

This deployment variant helps avoid the problems caused by DFS Namespaces failing over due to transient network glitches or when it encounters specific SMB error codes while accessing data. This is because the referral to the share hosted on the central file server is normally disabled.

However, the important thing to note is that the side-effects of replication latencies are still unavoidable. Therefore, if the data on the central file server is stale (i.e. replication has not yet completed), it is possible to encounter the same problems described in the ‘What can go wrong?’ section above. Before, enabling the referral to the central file server, the administrator may need to verify the status of replication to ensure that the adverse effects of data loss or roaming profile corruption are contained.

Support Statement:

Both variants of this deployment scenario (2A and 2B) are not supported. The following deployment use-cases will not work:

• TS farm using a DFS Namespace with either the file server in the branch or the central file server as backend store (link targets).
• Laptops in branch office with offline files configured against a DFS link with multiple targets.
• Regular desktops with folder redirection configured against a DFS link with multiple targets.

In this scenario, the following technologies are not supported and will not work as expected:

• Folder redirection against the namespace with multiple link targets.
• Client side caching/Offline files.
• Roaming user profiles.