I have had a crazy week so far. One of the issues that has bugged me this week was missing SYSVOL and NETLOGON shares and missing domain data after a new domain controller was added to the domain during migrations.

I first ran into this problem 3 years ago, when I was performing one of my first Swing migrations. I had shut down a server too soon, and as a result, the replica sets were incorrecty synchronized. In that case, I didn’t know what hit me. After I swung the DC back to the target new server, the entire AD crashed. There was no recovery, and I had to restore the server to it’s original state. When I reworked the Swing Migration weeks later, this error did not occur. I made a note on my Swing Migration worksheet, and did not come across this issue again . . . until Monday.

In the first case, I was trying to salvage the AD for a SBS2000 server which had lost the RAID and was barely functional. Just enough to get started. I quickly fixed up a Win2003 server and joined it to domain with the purpose of giving some backup to the AD in preparation for a Swing Migration.

Everything went according to plan, and the AD appeared to have transfered across. I did one last check according to my notes, which I have compiled over the past 4 years, and hit a snag which I had not seen for about 3 years. The SYSVOL and NETLOGON shares were not present on the new DC. Looking further, C:\WINDOWS\SYSVOL\sysvol\domain.name was empty. It should have 2 very important folders – Policies and Scripts. Without this, the AD would crash if the main DC were no longer operational.

In this instance, time was short, and I had to let this one go. We had to rebuild a new domain and reset all the workstations and data.

Today, as I was preparing a new SBS2008 server for migration, I found the same situation. The SBS2008 installation had completed and this new server was fully operational. Being paranoid, I checked, and there was the problem again!

After some searching, I finally found an old Microsoft Knowledge Base article KB290762 (http://support.microsoft.com/kb/290762/) – Using the BurFlags registry key to reinitialize File Replication Service replica sets.

I ran the Authoritative FRS restore procedure using the D4 flag on the old server.

1. Click Start, and then click Run.
2. In the Open box, type cmd and then press ENTER.
3. In the Command box, type net stop ntfrs.
4. Click Start, and then click Run.
5. In the Open box, type regedit and then press ENTER.
6. Locate the following subkey in the registry:
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
7. In the right pane, double click BurFlags.
8. In the Edit DWORD Value dialog box, type D4 and then click OK.
9. Quit Registry Editor, and then switch to the Command box.
10. In the Command box, type net start ntfrs.
11. Quit the Command box.

Then I ran the nonauthoritative restore process using the D2 flag on the SBS2008 server.

1. Click Start, and then click Run.
2. In the Open box, type cmd and then press ENTER.
3. In the Command box, type net stop ntfrs.
4. Click Start, and then click Run.
5. In the Open box, type regedit and then press ENTER.
6. Locate the following subkey in the registry:
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
7. In the right pane, double-click BurFlags.
8. In the Edit DWORD Value dialog box, type D2 and then click OK.
9. Quit Registry Editor, and then switch to the Command box.
10. In the Command box, type net start ntfrs.
11. Quit the Command box.

Bingo, the folders were recreated, and the shares appeared! An answer to a 3 year old question.