GuidesAdvantages of SYSVOL Migration from FRS to DFSR

Advantages of SYSVOL Migration from FRS to DFSR

ServerWatch content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.




Windows Server 2008

The term Active Directory is most commonly equated with the NTDS.DIT database and its characteristics; however, its functionality is affected in a profound manner by content of the SYSVOL folder, residing by default, directly under the Windows directory (although its placement is customizable) and providing file system storage required to implement a wide range of Group Policies.

Open the SYSVOL folder from the Windows Server 2008 domain functional level and you can take advantage of Distributed File System Replication, which offers more robust capabilities than its File Replication Service predecessor.

Although both NTDS.DIT and SYSVOL get created as a direct result of domain controller promotion and their coherence is necessary to keep directory services fully operational, they are subject to different rules and processes. One of more prominent examples of this dissonance is the use of two distinct replication engines to synchronize their respective contents across distributed set of domain controllers. In particular, since the introduction of Active Directory with the release of Windows 2000 Server product line, SYSVOL relied on File Replication Service (FRS) to accomplish this goal (physically separate and conceptually different from NTDS.DIT replication). Although the same technology still remains available in Windows Server 2008 environment, once you switch to Windows Server 2008 domain functional level, you have an option to take advantage of considerably more robust, efficient, and scalable mechanism based on the Distributed File System Replication (DFS-R).

The purpose of this article is to describe its advantages over FRS and describe migration path between them.


Read More About Windows Server 2008

In principle, both File Replication Service and Distributed File System-based replication rely on the NTFS constructs (such as Update Sequence Number journal and internal jet database) to keep track of changes to the file system. The latter (which was introduced in Windows Server 2003 R2) offers a number of significant benefits over its predecessor. More specifically, it minimizes network usage by employing block-level (rather than file-level) replication, which means that partial changes to large files do not trigger their full transfer, as well as the Remote Differential Compression (RDC) algorithm, which can also be adjusted to arbitrary threshold or disabled altogether in environments with sufficient network bandwidth. It also has self-healing capabilities, handling more gracefully journal wrap conditions and database corruption.

The efficiency and reliability of DFS-R has been further improved in Windows Server 2008, bringing such features as support for RPC asynchronous pipes (boosting the volume of replication requests that can be serviced simultaneously and mitigating blocking behavior that might surface if one of the replication partners is slower or overloaded) and the ability to take advantage of unbuffered I/O, allowing for higher number of concurrent downloads. In addition, the new version of DFS-R is RODC (Read Only Domain Controller) aware, automatically rolling back any changes applied to local replica of SYSVOL (such functionality is missing from FRS maintained volumes, which increases chances for administrative error). Finally, for larger environments, it eliminates the recommended limit on 1200 domain controllers per domain, stipulated in the Windows Server 2003 Active Directory Branch Office Guide.

Another significant factor to note when contemplating DFS-R deployment concerns the method of transitioning from FRS. The process of migrating SYSVOL replication mechanism to DFS-R has been designed in the manner minimizing the impact on Active Directory availability as well as allowing for gradual, controlled, easy-to-track, and reversible (with the notable exception of the final stage) transition. From the administrative standpoint, the process is managed using a built-in DFS-R specific utility DFSRMig.exe (residing in the %SystemRoot%system32 folder), which triggers each individual migration step (by setting a global migration state, represented internally by a group of designated Active Directory objects and their attributes), automatically carried out across all domain controllers in the same domain. These steps are referred to (using DFS-R nomenclature) as transition states (total of 5), with each starting and ending in a clearly defined set of conditions labeled as stable states (total of 4). Each state gets associated with a unique integer value between 0 to 9, with the stable states occupying lower part of this range.

Get the Free Newsletter!

Subscribe to Daily Tech Insider for top news, trends & analysis

Latest Posts

Related Stories