Replicating User Profiles Between Sites (With or Without DFS) – Why it Should be Avoided
This article is part of Helge’s Profile Toolkit, a set of posts explaining the knowledge and tools required to tame Windows user profiles.
Roaming user profiles seems like such a good idea at first, but it causes a myriad of problems in practice. One of these problems stems from the fact that the master copy of each profile is stored on a central file share. That file share needs to be accessible over a fast connection from all machines a user is logging on to, or logons tend to become very slow. This proximity requirement is easy to meet if only one site is involved, but what if users roam between different locations, or if terminal servers are distributed across several data centers? Unfortunately, there is no easy answer to this question.
Can DFS Replication be the Answer?
It looks like replication is the obvious solution. If you have users alternately working in multiple sites, replicate their profiles between those sites and – bingo – the problem is solved. No matter where they log on from, there will always be a copy of their profile nearby.
Put differently, why not simply copy the profiles to all sites users are working in? Windows has a very nice technology included called DFS-R (distributed file system – replication), that looks ideally suited for the task. Alas, it is not.
The basic problem is that replication takes time. What happens if user Ben changes his profile in site A and logs off, only to immediately log on to some machine in site B and make some changes there, too? In such a scenario you have two differing “master” copies of one profile, a situation no known replication software can deal with efficiently. DFS-R, if used here, would merge both versions of the profile, since it is a two-way replication system by design. It is unlikely that Ben would be happy with the resulting merged version of his profiles.
DFS-R is not the right technology for the task of multi-master user profile replication. Microsoft is well aware of this “limitation” (which really is none since DFS was not designed for replicating profiles, as far as I know) and describes it in a document on its Technet site. Or so I remember from a while back. Interestingly, I cannot find that reference any more, not even with Bing. So either I remember incorrectly (I do not think so), the document was removed (maybe) or I am too stupid to dig it up (possible). Whatever the reason, I found out the following: there is no single (findable) document on the internet that states with credible authority if you can or cannot use DFS-R to replicate user profiles between sites. Why? I have no clue. But, if you can extend even the slightest amount of trust towards this blog, then do not do it, unless you can get Microsoft to guarantee support for your setup.
What Can You Do With DFS-R and User Profiles?
Not much. First you would have to ensure that each profile is only accessed from a single location at a time. That alone is difficult with DFS-R, since it is by nature a two-way mechanism. Then the latency problem would arise. Before a profile earlier used in site A can be used in site B (instead!), replication of that profile from site A to site B must have completed. It would not do to have only half the updates from site A in site B when a user logs on in site B. To my knowledge, DFS-R offers no mechanism whatsoever to guarantee atomicity at a (profile) folder level, so that either everything has replicated (which you need) or nothing (which you do not want).
What About Other Replication Technologies?
Every large storage vendor has a replication solution that either synchronously or asynchronously (but with low latency) replicates between storage systems or even data centers. The main benefit of such systems (example: Hitachi TrueCopy) with regards to user profiles is the negligible or even non-existent latency. But even with such highly priced technologies you are stuck with the problems of guaranteeing there only ever is a single master copy of each profile, and ensuring atomicity at a profile level. These constrains make even high-end replication mechanisms unsuitable for the replication of user profiles between multiple alternately or concurrently used sites.
Disaster Recovery, Anyone?
Most larger companies are very concerned about potential disasters involving entire data centers and how to quickly recover from such events. Disaster recovery is the only application of replication I know of that makes sense (again, this applies to user profiles only). In order to have a readily available backup copy of your profiles, use a low-latency replication system (not DFS-R) to continuously synchronize the profiles from the primary to a secondary data center. In the event of a major failure in the primary data center, switch everything over to the secondary data center. From then on, only use the secondary systems. Once the primary data center is operational again, demote the former primary site to a secondary site and synchronize the other way round. Or synchronize from secondary to primary and then switch back over to the main site.
Centralized Backup it is
According to an article in Microsoft’s “Ask the Directory Services Team” blog and KB2533009 that appeared after I wrote this article, replicating user profiles with DFS-R is supported in one scenario only: bringing in user profiles from branch offices to the headquarter for backup. That is about the only sensible use case I can think of, too. Please note that in this scenario the profiles are never used in the headquarter. Remember: One profile may be used in one location only.
Thanks to commenter Michael for bringing up this topic.
Hi Helge – I went down this path with a customer a couple years ago that wanted to use DFS-R for roaming profiles w/ folder redirection (2 data center scenario)…needless to say, it failed miserably and MS told us it wasn’t supported or recommended. That’s when they added this statement to their DFS-R FAQ (I believe that’s what you’re looking for):
Also look at the question 4 items below it that says “when NOT to use DFS-R”…bottom line – you are right…if you have 2 data centers and are considering using DFS-R, don’t. Just trust me – I’m a Consultant. :)
thanks for posting the URL, that was exactly what I remebered!
For small companies DFS-R just fits perfectly.
Consider the following situation:
1 Headquarter, few offices maybe 100 to 250 km away.
Backup is done centrally in headquarter.
the offices have no backup on their own, but common shares and profiles.
if there is a meeting in the head quarter, replication of the profile is finished before you reach your car (usually).
it\’s not just a so bad idea. comes to relations.
and for an onboard solutions, it\’s very reliable.
when you need it for backup only, replication time doesn\’t matter at all.
I have a question I cannot find the answer and thought I would ask here.
I get that using the replication part of DFS is a bad idea for user profiles but wanted to know what you thought about using DFS namespace to point profiles to a non replicated space. My thought process is that it could be useful when migrating to a new server to use DFS replication over a weekend to move the profiles to the new server then turn off DFS replication.
DFS namespaces are certainly a good thing to have. They are often used in conjunction with user profiles and home directories.
Do not use DFS replication for migrations, though. Use robocopy. Far more robust.
Thanks for the reply.
Love your blog. I thought I remembered you writing that you could use DFS-R with roaming profile, but use DFS-N and disable one of the server targets so that clients only ever point to one server. If the one server goes down, adjust the DFS-N to point to the second server. Not a truly seamless solution, but easy to do even remotely.
However in trying to implement this I have a problem, when one server is “downed” the other is no longer able to access the settings for the namespace, it’s strange. I thought the whole point of multiple namespace servers is to prevent this issue.
I do not think I ever advocated using DFS-R with profiles. In fact I recommend the opposite.
Assume the following scenario:
Server1 and Server2. DFS-R replication with roaming profile folders in the replication group. Both servers acting as DFS-N nameservers. Namespaces pointing to both server folders, but with Server2 target disabled. (Replication still occurs, of course.)
Clients always are referred to Server1 since the Server2 target is disabled. Now one day Server1 fails for some reason. Disable target to Server1, enable to Server2, users go back online.
Acceptable scenario? The Technet white paper seems to indicate you can. (Of course it isn’t 100% seamless, but it’s pretty fast.)
I’m trying to create such a scenario, but I’m having the namespace problem I described earlier.
Off the top of my head I would say: don’t do it. A more detailed answer would require a bit of testing.
I have a Server 2008 R2 Citrix TS Farm, and in the same Data Center and Subnet, three other Server 2008 R2 Servers that I want to use as robust Roaming Profile/Home Servers. The nature of the Ctirx Farm: almost exlusivly OS Profile Data, other than application temp files and logs, Users do not have Desktop or store data, no Email/Office data. I could do the redirection directly to one of the servers without DFS. However, I want to be able to do maintenance or support an outage of the “main” profile Server, even if manually. Any ideas of a good infrastructure to support this? Thank you!
This is very interesting have you tried using Storage Replica in place of DFS-R? Also, when using Storage Replica what happens if UserA logs into Site A and B?