I'm preparing to migrate the domain from using FRS to DFS replication for SYSVOL. In checking up on FRS health, I don't see any journal wrap errors (Event ID 13568), but I am getting regular daily events for ID 13567 in the File Replication Service log on the SBS 2011 box. My other 3 DCs are not having this issue. The description of that Event ID says:
"File Replication Service has detected and suppressed an average of 15 or more file updates every hour for the last 3 hours because the updates did not change the contents of the file. The tracking records in FRS debug logs will have the filename and event time for the suppressed updates. The tracking records have the date and time followed by :T: as their prefix.
"Updates that do not change the content of the file are suppressed to prevent unnecessary replication traffic. Following are common examples of updates that do not change the contents of the file.
"[1] Overwriting a file with a copy of the same file.
"[2] Setting the same ACLs on a file multiple times.
"[3] Restoring an identical copy of the file over an existing one."
I have looked into the FRS Debug logs but am not sure how to parse them to find what I'm looking for.
The basic problem as I understand it is that something is writing to files in SYSVOL repeatedly, but the writes change no data. AV programs and disk defragmenters are cited as the usual suspects for issues like this, but I do not have 3rd-party AV installed nor any disk defrag programs. I looked through the list of installed programs to see if anything else was likely to be doing something intense at the filesystem level, but nothing seemed like a likely source of trouble.
Will it be necessary to track down the source of the frequent writes (with no changed data) or whatever might be repeatedly setting ACLs on files in SYSVOL? Or can this issue be safely ignored since the server will be retired soon? Scrolling back through my event log, it's been operating like this for a very long time. Unless the DFSR engine will handle this scenario differently in any important ways, I'm inclined to think I can proceed with the migration from FRS to DFSR.
I don't think this warning event will necessarily prevent me from doing a successful FRS>DFSR migration, but I want to make sure I have healthy replication after the migration to DFSR.