Microsoft's official enterprise support blog for AD DS and more
[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]
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.
[Supported Scenario]
Scenario highlights:
Specifics:
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.
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:
In this scenario, the following technologies are supported and will work:
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.
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.
[Unsupported Scenario]
What can go wrong?
As a result of the behavior described above the following consequences may be observed:
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.
Both variants of this deployment scenario (2A and 2B) are not supported. The following deployment use-cases will not work:
In this scenario, the following technologies are not supported and will not work as expected:
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.
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.
Hi Ned,
indeed what happens is the following: SiteA and SiteB have the same configurations and they are managed through a balancer, which decides where to direct user1, depending on several factors, e.g., server load.
Under this hypothesis, user1 can be directed to either SiteA or SiteB, but at different times and in different sessions. It's not possible that user1 is connected to SiteA and at the same time to SiteB.
Of course, if user1 connects to SiteA and then logoff, next time the balancer could direct him to SiteB.
Is the replication latency a critical problem in this scenario? Consider that servers in SiteA and SiteB are kind of kiosks, so users can only customise application settings.
Thanks.
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.