Freigeben über

Friendly Reminder: Get off FRS now!

  • Artikel

As mentioned in my last post, the need for environments to move away from FRS replicating SYSVOL is getting more and more pressing. This article serves as a friendly reminder to:

1. Check if you've moved to using DFSR for SYSVOL replication

2. Migrate to DFSR if you haven't yet!

First, some backstory.

In the beginning, there was FRS 

When designing Active Directory for Windows 2000, there was a requirement for a common "system volume" (SYSVOL) that clients could connect to regardless of their location. Although Active Directory was conceived as a directory database, there are (and were) a number of scenarios that required files (as apposed to database objects) - login scripts, Group Policy setting files, etc. Due to Active Directory database replication being multimaster, we needed a multimaster file replication service to go along with it, to facilitate the hosting of a writable copy of SYSVOL on every domain controller in the domain. There was the existing LMREPL (LanMan replication) service, but this was not multimaster and was not going to cut it.

Enter FRS. FRS was designed to be perfect for this purpose, and it was integrated tightly into the promotion and subsequent operation of domain controllers. The rest is history.

Almost.

FRS, for all it's virtues, also has a number of flaws, and many inefficiencies. The most famous of these is the dreaded FRS Journal Wrap which you may have been lucky enough to experience for yourself. Effectively, you can put many of these issues down to the fact that we're talking about a 15+ year old file replication technology, and a lot has changed since.

Then came DFSR

DFSR was developed as a replacement for FRS, addressing a number of limitations. Features such as automatic journal wrap recovery, remote differential compression, and greater scalability meant it was superior to FRS in every way. Introduced in Windows Server 2003 R2, DFSR was originally only able to be used to replicate normal folders (so not SYSVOL). In Windows Server 2008, support was added for DFSR for SYSVOL replication, and the status quo has continued since. All subsequent released versions of Windows Server have included support for using either FRS for DFSR for SYSVOL replication.

The reason for the continued support for FRS is mostly due to backwards compatibility - being able to have legacy domain controllers (eg, 2003) present in the environment was important to facilitate domain migrations. While there is a tool to assist you in migrating from FRS to DFSR, it required you to at least be running 2008 Domain Functional Level (DFL) as all DCs needed to at least be 2008 to support the replication of SYSVOL using DFSR.

Against the odds, it's getting worse

You might be inclined to think "sure, FRS is bad - but it hasn't fallen over yet, so there's no rush, right?" - wrong!

Your risk of running with FRS for SYSVOL replication is actually increasing for a few reasons:

  • More data is probably being added to SYSVOL increasing the likelihood of something bad happening
  • As no further investment in FRS is occurring, issues and updates are not being discovered or fixed
  • FRS is being removed from future versions of Windows Server, potentially blocking your Active Directory upgrade
  • Newer operating systems (such as Windows 8 or Server 2012) are designed under the assumption of having a highly performing SYSVOL replication engine

The last point is actually the most interesting of the four - the way that edits are handled by the PowerShell CMDlets and GPMC/GPEdit has changed slightly so that the system is more robust - but actually causes more problems when combined with FRS.

Effectively, edits/restorations of policy now invoke a series of successive changes that involve files getting renamed and copied around - the problem is that with FRS this can cause access violations that are handled poorly, potentially resulting in data loss. When there's a KB published for this, I'll put the link in here. In the meantime, the strong recommendation is not to edit group policy from Windows 8 or 2012 or later against a domain that replicates SYSVOL with FRS.

Migrate now

Migrating the DFSR is pretty simple. Rather than retyping the instructions here, check out the following page about using the DFSRMig utility to do this:

https://technet.microsoft.com/en-us/library/dd640019(v=ws.10).aspx

Happy hunting of FRS in your environment!