First of all, there was obviously a reason (probably many reasons) why Microsoft released DFSR, so there should be some level of trust that newer is better. I don't pretend to be an expert on FRS or DFSR, but I can relay to you the issues I have experienced when working with customers who are still using FRS.
Yes, I do mean even today as we have just started rolling out Windows Server 2019, that there are still companies out there utilizing FRS in their networks. And the biggest problem with this is that they probably have no idea. We'll talk a little bit more about that in the Which one am I running section of this chapter.
FRS is like a magician who only ever learned half of a trick. He's great at making things disappear (watch the crowd ooh and aah over the disappearing data), but not always so great at bringing it back. From what I have experienced, if a domain environment is still running all older Domain Controllers (Server 2008-ish), and you only ever make GPO changes on these older DCs, you'll probably never experience the cool new feature called disappearing data (maybe this is a weird cousin to data deduplication...?). The trouble with FRS comes into play once you start manipulating Group Policy from newer systems inside the FRS-replication environment. They don't necessarily even have to be Domain Controller systems.
More specifically, the trouble shows up when you start making changes or updates to Group Policy data from an operating system newer than Server 2008R2. This might be from the first Server 2012 Domain Controller you install, or it might be from some other Server 2012 or newer box where you happen to have the Group Policy Management tools installed. When you use this new platform to open up a GPO and make some changes to it, there is the possibility that all of the settings inside that GPO might disappear.
Yikes. I'm not making this up; I have helped numerous customers out of this boat after losing GPO settings. Not only is there the potential that when you, with your own hands, make a change to a GPO that the GPO might be deleted, there is also potential that the GPOs might be deleted without you directly touching the GPO. This is because the newer Server Manager starting in Server 2012 does so much for us. There are some management consoles now where you only ever interact with a GUI interface, but what that GUI is really doing is throwing PowerShell commands at Active Directory in the background. You click on a setting, and PowerShell issues the relevant command to the closest Domain Controller to make that change happen. While this is really cool and is the core reason that today's Server Manager is hundreds of times more powerful than the Server Manager of old, it also means that your GPOs are sometimes being updated without you ever touching GPMC.
If this all seems a little confusing and far-reaching, let me give you a real example. When configuring Microsoft DirectAccess (remote access technology) inside an environment, we are introducing a Server 2012 (or newer) system to the environment. Chances are that this new server is not the first Server 2012 box that the customer is running, but it could be the case that this is the first Server 2012 or newer that is going to be doing automated manipulation of Group Policy. After prepping the server and installing the role, we head into the DirectAccess configuration wizards. At the end of the wizards, after selecting all of our options, the wizard then reaches into Group Policy and creates some new GPOs for us. Those GPOs are then filled with settings, GPO links are established, and even Security Filtering is populated based on the information that we plugged in during the wizard. All of these things are done inside Group Policy without us ever having to touch a Domain Controller or GPMC in any way.
Sometimes even this initial rollout of the GPOs goes sideways, but let's pretend that it went smoothly and DirectAccess is up and running. Now it's a couple of days later, and we realize that something needs to be tweaked in our configuration. We simply re launch the DirectAccess configuration wizards, make the changes, and click the Apply button. This tiny little change is pushed into our GPOs, and from there it rolls down to the client computers, right? Except that, when FRS is still being used for replication, what often happens is that DirectAccess completely breaks for everybody. When we look a little closer at what happened, we find that the GPOs related to DirectAccess are completely empty. All of the settings have been cleared out of them! The GPOs still exist, their links still exist, and they are still filtered appropriately, but all settings have been forgotten.
DirectAccess is not the only technology where this happens, but it's one that I deploy a lot, so it's the best example I have. The point is that FRS is no longer a reliable mechanism for replicating Group Policy data! The only way to fix this behavior is to update your Domain Controllers to replicate using DFSR instead.