FRS Problem when Virtualising a Domain Controller

I recently had to assist someone who had virtualised a single Windows 2003 Domain Controller from physical hardware to a virtualised Virtual Guest file using a third party (Non Microsoft) utility (not that I am saying this issue would be any different using a Microsoft utility). This is not an advised\recommended practice for Domain Controllers, but in this instance they had no choice and the DC concerned was in fact a single DC (once again; Bad Practice, I know, but we work with what we have sometimes) in a test environment. Ignoring the list of bad practices, the resulting DC was producing Event ID 13559 errors in the NTFRS log (see description below)

The File Replication Service has detected that the replica root path has changed from "x:\windows\sysvol\domain" to "x:\windows\sysvol\domain". 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 5 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.

Indeed the description is also discussed in this KB article https://support.microsoft.com/kb/887440 and it would appear that the disk signatures for the volumes that host the SYSVOL folder structure are changed during the conversion of the system from physical to virtual. Following the procedures detailed in the error event and in the article did in fact remedy the situation and the NTFRS event logs showed this fact by logging 13560, 13553 and 13516 (which effectively proves the DC is functioning correctly from and FRS\SYSVOL perspective) over a period of time.

This issue has also been seen during the Restore of a Domain Controller from backup or during a failed attempt to move SYSVOL to another volume as per this article https://support.microsoft.com/kb/842162