If you’re still using an older file and folder replication solution, it’s high time you moved over to the Distributed File System.
The Distributed File System (DFS) has been around since the days of Windows NT. It comes in a variety of configurations and options and is available in standalone and domain configurations. DFS is a popular and effective technology that provides redundant file and folder replication between remote servers. You can organize them under a common namespace to let users connect without needing the name of the server on which the DFS share is hosted.
Unfortunately, there has never been a comprehensive DFS best practices document. Here’s a summary of all the best practices used, learned and recommended over the years. New information is always posted to the Microsoft Web site, so check here for updates.
The terms DFS and Distributed File System refer to the legacy namespace product available in Windows 2000, Windows 2003 and Windows 2003 R2, and as a legacy product in Windows 2008. DFS used the problematic File Replication Service (FRS) for the replication engine.
With Windows 2003 R2, Microsoft introduced a new DFS namespace product along with a much-improved replication engine. Here the term “legacy DFS” refers to the legacy DFS in Windows Server 2000, Windows Server 2003 and Windows Server 2008. The new DFS namespace is called DFS-N, and the new replication engine is called DFS-Replication (DFS-R).
The legacy DFS in Windows 2000 and Windows 2003 used a cumbersome and confusing administrator’s console and terminology. The FRS was also problematic. Windows 2003 attempted to mitigate some of those issues, but was unable to actually fix them. So Microsoft delivered a completely new replication engine, DFS-R, for Windows 2003 R2 and Windows 2008.
With Windows 2003 now out of mainstream support by Microsoft, you really need to migrate to the new DFS/DFS-R available in Windows 2003 R2 and Windows 2008, if you haven’t already. Here are some potential problems and best practices associated with the legacy DFS and FRS.
FRS detects changes via the New Technology File System (NTFS) journal. This is modified when a change is made to a file or folder in the file system. Unfortunately, FRS can’t detect whether or not that change requires replication.
Applications that scan files—like antivirus and disk defragmentation tools—typically modify the security descriptor of the files. This triggers a change in NTFS journal, which in turn triggers FRS to replicate the files even though no changes were made. Updates made to FRS in Windows 2003 minimized those problems, but did not fix them. They included:
The best practices for managing and using legacy DFS/FRS revolve around the central concept that keeping dynamically changing data on DFS shares is inherently a bad idea. FRS is easily overwhelmed with large numbers of files. It also has a hard time replicating frequently changing data. For example, you shouldn’t use it to house My Documents for user profiles.
Other best practices for handling legacy DFS/FRS include:
FRS replicates the entire file, even if only a few bytes have changed. There’s an approximate limit of 65GB per share that DFS/FRS can effectively replicate. Exceeding this limit will result in inconsistency and poor performance. Other noted limitations include:
For multiple-domain DFS configurations:
For further reference, see the DFS FAQ.
The new DFS-N and DFS-R in Windows 2003 R2, Windows Server 2008 and Windows Server 2008 R2 have significant improvements over the legacy DFS and FRS products. DFS-R replicates on a block-level basis, only replicating changes made to a file, rather than the whole file.
For example, if you changed a title on a PowerPoint slide and the file is 3MB, FRS would replicate the entire 3MB file for the old legacy DFS. DFS-R only replicates a few bytes. This makes a huge difference for both network and disk performance. It also helps with user-perceived performance of getting changes replicated. DFS-R can handle large amounts of data, and dynamically and efficiently change that data.
DFS-R is available only in Windows Server 2003 R2 and Windows Server 2008. You can only use it to replicate DFS data in Windows Server 2003 R2, but you can replicate DFS and SYSVOL data in Windows Server 2008 and Windows Server 2008 R2. To use DFS-R for replication, only your DFS servers must be running Windows Server 2003 R2, Windows Server 2008 or Windows Server 2008 R2. You won’t have to upgrade the DCs.
Installing the new DFS/DFS-R in a Windows Server 2003 domain will require a schema change (see the list of DFS-R FAQs for more details):
Apply the 972105, 969688, 978326, 959114, 978994 hotfixes prior to SYSVOL migration to DFS-R. Then proceed as follows:
DFS-R provides more robust and efficient replication and handles dynamic data quite well, but it’s important to understand the scalability limitations for DFS-R when planning a DFS infrastructure. You can define replication groups independently of DFS namespace configuration—one is not dependent on the other. You will be, however, subject to the following limitations:
For more details, see the Microsoft TechCenter page on this issue. There’s also an excellent list of FAQs.
Overall, the recommendation is simple: Get off of FRS—seriously. It’s old technology that Microsoft threw in the dumpster years ago. Bite the bullet and migrate all DFS shares (Windows Server 2003 R2 and newer) and SYSVOL replicas (Windows Server 2008 and newer) to DFS-R.
Take advantage of the robust performance improvements and spend your time doing more productive things. With the deprecation of legacy DFS and FRS in Windows Server 2008 R2, Microsoft is sending a message that it’s time to move to better technology. There are really no downsides.