Freigeben über

The Case for Migrating SYSVOL to DFSR

  • Artikel

Hello folks, Ned here again. Recently I was asked to provide a technical assessment of the risks of continuing to use the File Replication Service (FRS) and the benefits of migrating to DFSR, all regarding SYSVOL on domain controllers. I thought I’d find a decent set of documentation on TechNet, polish it up and send it along – I was wrong; I had to spend several hours coming up with a complete list.

Now you can reap the benefits. Hopefully this helps you convince yourself or your management that the time has come to cut the cord on FRS, especially if you have already deployed your Windows Server 2008 DC’s.

I sure hope you like bullet points!

The risks and downsides of FRS and SYSVOL

  • FRS code is in maintenance mode, where Microsoft does not accept design change requests or bug fixes except when related to security.The last FRS bug fix update was released in KB939667. It was for Win2003 and nearly 3 years ago; Win2008 has never gotten an FRS bug fix update in its history.
  • Additionally, the FRS component began deprecation starting in Windows Server 2003 R2:
    • The Microsoft product team stopped investing in FRS in Windows Server 2003 R2, when it was decided to build DFSR and have that replace FRS even for SYSVOL replication
    • DFSGUI.MSC FRS management tool was removed in Win2008
    • FRS component no longer installable in Win2008 R2 except for SYSVOL replication on DC’s
    • FRS component automatically uninstalled during in-place upgrade of Win2008 R2 non-DC’s
  • FRS scalability and performance are significantly lower than DFSR, especially with frequently modified files, larger data sets, larger files, and slow wide area networks. FRS always replicates an entire file regardless of modification type (i.e. a security change, data change, attribute change, or file name change each replicate the entire file)
  • FRS does not include a public development interface (API or WMI) for monitoring, and it’s interface for management is limited
  • FRS does not have a native, supported health reporting mechanism.
  • FRS does not have a native, supported monitoring solution from Microsoft System Center. Only has legacy unsupported tools like Sonar, Ultrasound, CONNSTAT, etc. with limited MOM 2005 integration
  • FRS has limited performance monitoring counters through PERFMON/ETW
  • FRS does not have a working self-healing system for problems like database corruption,  journal wraps, and morphed folders
  • FRS does not fully support RODC SYSVOL replicas and allows data to become unsynchronized without chance of automatic resynchronization
  • FRS does not support the inter-site change notification flag, leading to artificially slow replication between DC’s in different AD logical sites
  • FRS does not have significant built-in instrumentation (debug logs, event logs) for troubleshooting and debugging

The improvements and upsides to DFSR and SYSVOL

  • DFSR code is in active development with full product DCR and QFE support. Hotfixes for feature improvements as well as bug fixes are regularly released and also integrated into new Service Packs.
  • DFSR scalability and performance are designed to be superior to FRS. This includes:
    • Ability to replicate partial file changes using RDC (block-level delta replication) rather than entire files
    • Support for cross-file RDC that can construct new files from similar files, rather than replicating the new file over the wire (when using Enterprise edition)
    • A more efficient file compression on staged files
    • The number of files that can be replicated inbound and outbound simultaneously is significantly increased
    • Support for unstable and slow networks with asynchronous RPC
    • Support for more efficient OS kernel mechanisms introduced in Win2008 like unbuffered I/O, low priority I/O, and asynchronous I/O’s
    • No staging of smaller files (<=64KB by default)
    • Staging compression can be controlled on a per-file type basis
    • Scalable to a supported (not hard) limit of 10 terabytes of data. Although if you have 10TB in SYSVOL, you are doing it wrong buddy.
  • DFSR has a public interface (using WMI/DCOM) managing and monitoring all aspects of DFSR, including backlog (and files currently on the wire in Win2008 R2).  It also includes command-line tools that give feature parity with the GUI management tools
  • DFSR has a native, supported health reporting mechanism that is available through the GUI or command-line and generates HTML/XML outputs
  • DFSR has several releases of native, supported monitoring solutions from Microsoft System Center via management packs. The new Win2008 R2 File Services MP is also in final stages of beta
  • DFSR has more complete performance monitoring counters through PERFMON/ETW
  • DFSR has a self-healing system for problems like database corruption or journal wraps. Due to improved replication performance and the ability to enable content freshness protection, it is also very unlikely to ever see a journal wrap in the first place. DFSR also does not create morphed folders like FRS and instead uses a conflict resolution algorithm
  • DFSR supports RODC SYSVOL replicas and does not allow SYSVOL’s to remain out of sync in Win2008. In Win2008 R2 originating I/O in SYSVOL is completely blocked with a filter driver on RODC’s
  • DFSR  - while it does not directly support the AD DS inter-site change notification flag – always replicates SYSVOL immediately and continuously with its own internal change notification as long as the schedule is open; these scheduled windows are in 15 minute blocks and are assigned on the AD DS connection objects. If the current time matches an open block, you replicate continuously (as fast as possible, sending DFSR change notifications) until that block closes. If the next block is closed, you wait for 15 minutes, sending no updates at all. If that next block had also been open, you continue replicating at max speed.
  • DFSR has significant built-in instrumentation for troubleshooting and debugging, including considerable event logging and a large number of highly verbose debug logs (1000 debug logs maintained under compression by default in Win2008 R2, at the second to highest level of verbosity by default)

A table

Here’s a different way of looking at it, as I know executives love their matrices:

Description

FRS

DFSR

Reliable, fast, scalable, and continually improving

No

Yes

Is deader than fried chicken

Yes

No

Now go migrate. For most customers it will be a few hours of work. Your manager may not even have time to buy you lunch on a Saturday.

Stay tuned for another article about the benefits of using FRS. Its title will be “the shortest blog post ever written” and will contain only a picture of my dogs eating their toys. Here’s a preview.

image

A special thanks to Mahesh from the DFSR product team for his timely review and contributions to this write up. You rock dude.

Until next time,

Ned “nom nom nom” Pyle

Comments

  • Anonymous
    April 22, 2010
    How can we achieve "Staging compression can be controlled on a per-file type basis?"

  • Anonymous
    April 22, 2010
    I got it whey you say "Staging compression can be controlled on a per-file type basis" you are referring to your kb 951003 (msDFSR-DefaultCompressionExclusionFilter   ) I did not catch the per-file TYPE basis and interpreted as per-file basis. Thanks and Regards.

  • Anonymous
    April 23, 2010
    WOW..This is Excellent information...Great Work

  • Anonymous
    April 23, 2010
    I'm pretty shocked that 9 months after server 2008 R2 release that MS hasn't released the SCOM MP for file replication. Whatever happened to MS shipping SCOM MPs with the product or within 60 days of launch? Product teams don't seem to put a priority on creating MPs in a timely fashion for customers. I'm seriously reconsidering the enterprise use of SCOM because product groups like this take forever to release native MPs. Get with the program and provide timely MPs or don't release the product at all.

  • Anonymous
    April 24, 2010
    The comment has been removed

  • Anonymous
    January 04, 2014
    Hi there! I have noticed the following at many customers who had upgraded their Active Directory from

  • Anonymous
    June 24, 2014
    The comment has been removed

  • Anonymous
    June 25, 2014
    The comment has been removed