What you do before you start your migration It is better to prevent those issues by running some checks. Before you introduce another DC in your network always check your event log for ‘Journal Wrap’ conditions. If you have those the server was probably shutdown in a dirty state after an power outage. This is not really an issue if there is only the SBS involved. Here is how you fix those issues. Use the service manager to stop the File Replication Service, or NET STOP NTFRS. Use RegEdit to locate the following key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup Edit the BURFLAGS value and set to 0xD4 (= Authoratative Restore). This will cause the FRS service to rebuild its database from existing file content and become the authoritative sync partner - even though SBS is the only sync partner, this is still necessary. Use the service manager to start the File Replication Service (NET START NTFRS). When the FRS service is restarted, the following actions occur: The value for the BurFlags registry key is set back to 0. An event 13566 is logged to signal that an authoritative restore is started. Files in the reinitialized FRS replicated directories remain unchanged and become authoritative on direct replication. Additionally, the files become indirect replication partners through transitive replication. The FRS database is rebuilt based on current file inventory. When the process is complete, an event 13516 is logged to signal that FRS is operational. If the event is not logged, there is a problem with the FRS configuration A server reboot and a check of the event log after such a procedure is always a good. Suggested reading on this: Using the BurFlags registry key to reinitialize File Replication Service (This discusses the Burflag solution as described above and this is the preferred way of doing it) How to troubleshoot journal_wrap errors on Sysvol and DFS replica sets (This discusses an alternative way of fixing things. It sets 'Enable Journal Wrap Automatic Restore' but this does a nonauthoritative restore and I would not use that) What you do after you installed the new replica domain controller Once this is done you can introduce a new Domain Controller in your network and check replication and DNS. The first tool I would like to discuss is Repadmin . As soon as the new DC has been installed run Repadmin /showrepl and Repadmin /replsummary . Both commands will tell you what the state of your AD replication is. For those who fancy a GUI with the Repadmin tool there is Download Active Directory Replication Status Tool from Official Microsoft Download Center but I always use the Command line tool. C:\Windows\system32>Repadmin /showrepl C:\Windows\system32>Repadmin /replsummary The other check is done with DCDiag. The one test I always run shortly before I introduce a new DC and immediately after the new DC is implemented is DCDIAG /test:DNS /DNSALL /e /v and DCDIAG /test:RegisterInDNS /DNSDomain:adatum.local C:\Windows\system32>DCDIAG /test:DNS /DNSALL /e /v C:\Windows\system32>DCDIAG /test:RegisterInDNS /DNSDomain:adatum.local If you have replication issues between Domain Controllers in 9 out of 10 it is always DNS related. This tutorial will be repository for problems and the solutions regarding any replication issue so it will be updated regularly with new information. × On the new server type 'net share' from an elevated command prompt and make sure you see a SYSVOL share in the list. If it is not there you must check your FRS and DFSR event logs for errors. You can not continue your migration if you have no SYSVOL on your new server nor can you continue if you have DFSR errors. If you continue without SYSVOL share on your new server with demoting the old server you will loose your domain. Think twice!