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.

clip_image002

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 target1 - 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).

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.

Comments

  • Anonymous
    September 01, 2010
    Great article! Thanks!

  • Anonymous
    September 02, 2010
    The comment has been removed

  • Anonymous
    September 02, 2010
    The comment has been removed

  • Anonymous
    September 02, 2010
    The comment has been removed

  • Anonymous
    September 02, 2010
    On second thought... I imagine that "native Microsoft" way will be directed towards SCOM?

  • Anonymous
    September 02, 2010
    That's a very interesting notion. It would be quite scriptable with DFSUTIL and DFSCMD. And you could use SCOM 2007 as well as a trigger. Or some other product, or trigger mechanism. Very intersting, I shall dwell on this as a potential blog post...

  • Anonymous
    September 24, 2010
    Bummer. Scenario 2A is exactly what I had wanted to do.  I'm glad I read this article and I guess I will have to come up with something different...

  • Anonymous
    September 28, 2010
    The comment has been removed

  • Anonymous
    September 30, 2010
    What about if you made the two local servers into one cluster, Ikono? Then you get all the advantages and none of the disadvantages (plus you could save money of disk,as you would need half the space of two full DFSR servers). For your second question, yes that would work and be supportable.

  • Anonymous
    September 30, 2010
    Thank you, NedPyle.  Mainly due to the cost associated to shared disk (iSCSI, etc) I preferred not to go for a clustering.  But I am glad to learn  the second one is supportable, as I can start testing right now and implement very soon :)

  • Anonymous
    October 19, 2010
    What are your thoughts about this scenario (Variant Scenario 2A)? • Central Site Server is hosting ONLY the (Not the entire profile) redirected profile subfolders: ○ Documents, Desktop, Favorites, Downloads • The Redirected folders are located in the users H: drive (Home Path) mapped to - \DomainNamespaceProfile • The data is replicated using DFS Replication over the WAN between a single branch office and Central Site • Namespace link has multiple targets (Active) - Central Site and Branch Office (Sites and Services is configured) • Third party solution 'AppSense' is controlling Profile/Settings Roaming across the environment I understand that in a failover the user may not have the latest copy of their data, but "critical" data is stored in separate department shares which are replicated, (Namespace link has multiple targets) but is only active (enabled) to one.

  • Anonymous
    October 19, 2010
    Since you're using a third party profile tool here, I have no way to comment on this anymore. I can't tell what it might do or want or need. But from I read here, no this is not supported and contradicts our recommendations around multiple access points to the same data by the same user.

  • Anonymous
    October 19, 2010
    The scenario indicates you have multiple links, but only one link is active.  That part fits into the prescribed scenarios. However, you indicated you’re using AppSense.  I can’t comment on what AppSense does and does not support. Microsoft does not support AppSense. Mike Stephens

  • Anonymous
    October 21, 2010
    Thanks for the useful info!  Hopefully you can help me with a question... It makes sense to me that there could be corruption problems with a profile because there are several files that may be modified concurrently and an incomplete replication would leave them in an inconsistent state.  However, if CSC is not used, I don't understand why a redirected folder (such as a user's home folder) with multiple targets is at any greater risk than any other replicated folder with multiple targets. Are you saying that replicated folders with multiple targets are also not supported?  I assume that is not true because it would render DFSR useless.  Can you clarify as to why folder redirection against a namespace with multiple link targets is different from any other scenario using multiple targets? Thanks!

  • Anonymous
    October 21, 2010
    The risks with folder redirection against a namespace with multiple targets backing the share are due to replication latencies and due to the switch between targets in case of transient network glitches. It may be disconcerting to a user to find that a document he recently worked on/saved is unavailable when he was redirected to another replica. If you've configure replication schedules (say off hours replication), this may be an expected outcome. Another problem that can arise is that of replication conflicts since you now have a scenario where the user may be modifying the file on two different replicas. Since DFSR has last-writer-wins replication conflict resolution, you'd find that a previously modified version of the file is moved to the ConflictsAndDeleted directory. It just becomes a lot more difficult for an administrator to support since you have to be ready to restore files from the ConflictAndDeleted folder in case users complain of files going missing.

  • Anonymous
    December 03, 2010
    This article is great :-) Thank you. Can I ask you a question about a different scenario and if it is supported? I have two branches, SiteA and SiteB, each hosting a Remote Desktop Session Host (TS) Farm deploying RemoteApps and remote desktops. Each site can be accessed by all users, through a balancer grating access to the least loaded farm. I would like to use roaming profiles (and if possible, folder redirection) so that users always have their docs and settings, regardless of the farm they connect to. For example: user1 connects to SiteA farm, personalise settings and applications and logoff; after some time (minutes, hours, days, ...) user1 connects to SiteB farm and he should find exactly the same customisations. Is this scenario possible with DFS-R? My idea was to:  - create a file server on SiteA, serving SiteA users;  - create a file server on SiteB, serving SiteB users;  - establish replica (DFS-R) between SiteA file server and SiteB file server. Will it work? Is it supported? Any problems should I add a third (disaster recovery) file server, connected to the same replica group? Thank you in advance, hope having been clear. Mauro.

  • Anonymous
    December 03, 2010
    Hi Flxmra, Why would user1 be connecting to multiple sites? That would be the main problem with this design: it effectively is like scenario 2, where an end user could easily (due to replication latency) end up accessing a stale profile. If the main design was that user1 always contacted siteA, and the only time they could ever use SiteB was due to a disaster and you specifically making them access SiteB, then it would probably be ok.

  • Anonymous
    December 03, 2010
    The comment has been removed

  • Anonymous
    December 03, 2010
    It depends - for instance, let's say I customize my application settings on a TS in SiteA. Then I log into SiteB (which has not yet replicated) and all my settings are gone. So I reset them again. Then I log into SiteA again, and make a few more changes. And then I go back to B and those changes are gone again. What happens if I am allowed to logon to both sites simultaneously? What about where the settings are store - in the user registry? There is only one file for that, NTUSER.DAT, so if I use a few different applications then I could be wiping out each version depending on which server I go to each time. The customer experience could be very confusing. Or it could confusing only once and never again. It's up to you to decide if it's going to work or not for your user base.

  • Anonymous
    October 24, 2014
    Microsoft’s Support Statement Around Replicated User Profile Data - Ask the Directory Services Team - Site Home - TechNet Blogs