NtFrs Error 13559 OR When in Doubt, Read the Error

One of our IT support customers was complaining that their “sysvol” share on their Windows Server 2003 R2 domain controllers was not replicating content (updated group policies, login scripts, etc.). Upon initial examination, I ran across this error in the event logs:

Event Type: Error
Event Source: NtFrs
Event Category: None
Event ID: 13559
Date: 5/18/2009
Time: 6:53:52 AM
User: N/A
Computer: DC2
Description:
The File Replication Service has detected that the replica root path has changed from "c:windowssysvoldomain" to "c:windowssysvoldomain". If this is an intentional move then a file with the name NTFRS_CMD_FILE_MOVE_ROOT needs to be created under the new root path.
This was detected for the following replica set:
"DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"

Changing the replica root path is a two step process which is triggered by the creation of the NTFRS_CMD_FILE_MOVE_ROOT file.

[1] At the first poll which will occur in 60 minutes this computer will be deleted from the replica set.
[2] At the poll following the deletion this computer will be re-added to the replica set with the new root path. This re-addition will trigger a full tree sync for the replica set. At the end of the sync all the files will be at the new location. The files may or may not be deleted from the old location depending on whether they are needed or not.

Having had previous experience with troubleshooting journal_wrap errors (resulting from drive corruption, power outages, improper cloning/restores, low disk space) and performing nonauthoritative restores, I proceeded to ignore the information from the error above and began to troubleshoot the issue from the ground up. All of my diagnostics (frsdiag, sonar, etc) confirmed the obvious: FRS was not synchronizing on one of the domain controllers.

Installing the Windows Server 2003 Resource Kit tools, I proceeded to check the junction links using the “linkd” utility. Everything appeared to be ok, except for a strange musical note appended to the end of the “sysvolsysvolfqdn” output. Other than just being weird, no problem there.

Still looking for the ‘smoking gun’, I decided to go back to the initial error above and ran across this extremely appropriate article (even though it was directed for Windows Server 2000). Rereading the error above, more slowly this time, it all made perfect sense. I actually needed to create a file named “NTFRS_CMD_FILE_MOVE_ROOT” and copy it to the “C:WINDOWSSYSVOLdomain” folder, restart the FRS service, sit back and let Active Directory do the rest. Duh!

Originally posted at: http://blog.xiquest.com/?p=32