Microsoft’s Support Statement Around Replicated User Profile Data

Microsoft’s Support Statement Around Replicated User Profile Data

  • Comments 19
  • Likes

[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: http://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 http://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 - http://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).
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.
  • Great article! Thanks!

  • Agreed, great article!  Although this focuses on "User Profile Data" the same should be said for any multi-user edited documents that don't have a file lock in play (hence Ned's link).  Especially those that only write their changes on file exit, like Microsoft Access MDB files for example.

    Out of curiosity what is the Microsoft view or suggestion to create server failover for a DR scenario in these cases?  For other DFS configurations, we do have a global high/low priority setup for our links.  Is there any suggested way to acomplish a DR configuration for DFS-N, without manually needing to change links or use a 3rd party?

    Thanks!

  • I typically find that the planning around DR site 'failover' times are unreasonably aggressive. I.e. customers want to have a DR site come online instantly if their main office servers were all destroyed in a fell swoop.

    Except that generally speaking a disaster of that magnitude:

    1. Is likely to have destroyed most users entry point into the DR site as well.

    2. Is likely to have destroyed most of the users own access points (main corporate network).

    The above means that instant failover is unlikely and that the business will not mind a little downtime if the entire datacenter suffered a meteor strike. Which by the way killed all your IT staff, as they are always colocated, so your DR site isn't going to be managed.

    So when you gear down to a more common "not disaster" - such as a branch site who's main file server has gone offline due to hardware failure - a few seconds or minutes for an admin to enable a disabled DFS link target or to switch an existing one to another target is usually pretty acceptable.

    If data is mostly static and users are never going to have a reason to access a DFSN link target you might accept the aupportability risk and simply have a secondary link online that is extremely high site costed and and unlikely to be hit. But we have a few cases every day of customers accessing the wrong DFSN link targets due to many factors outside their control, such as network conditions and 3rd party WAN appliance issues. You get back into all the risks described in the article at that point.

  • @Ned

    Thanks for the feedback, and that is pretty much what I assumed was the case.  Just wanted to make sure there wasn't some automated "Hey, this File Server is no longer reachable, quick switch any links that point to it" magical hidden feature.  :)  

    In all seriousness some native Microsoft way to script/automate that would be much appreciated.  Even if it does still take a few seconds to minutes.  There are time admins with proper knowledge and rights aren't always available after all.  I'm thinking along the lines of PowerShell cmdlets, but I imagine you guys are already (hopefully) working on such things.

    As always, appreciate all the great information you guys put together here!

    Thanks again...

  • On second thought... I imagine that "native Microsoft" way will be directed towards SCOM?

  • 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...

  • 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...

  • This is the very sort of the doc I wanted to have, for many years... But I need a solution of a variant of 2A.

    I plan to have TWO local fileserver, plus one in central site for tape backup, all configured as DFS target (but the central site one is disabled). We can assume reasonably high-speed connection between the two local fileservers (on the same subnet, same physical switch, 1Gbps connection). I understand we still cannot guranantee 100% sync between those two fileservers, but I guess it should work... Can you comment on this, please?

    Also, what happens if I disable DFS target of one of the local fileserver (leaving one local fileserver as Enabled, while the other local one and the central office one are disabled) and manually switch Enable/Disable between the two local servers in case of server failure. Is this supported?

  • 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.

  • 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 :)

  • 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 - \\Domain\Namespace\Profile

    • 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.

  • 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.

  • 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

  • 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!

  • 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.