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.
- Click Start, and then click Run.
- In the Open box, type cmd and then press ENTER.
- In the Command box, type net stop ntfrs.
- Click Start, and then click Run.
- In the Open box, type regedit and then press ENTER.
- Locate the following subkey in the registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup - In the right pane, double click BurFlags.
- In the Edit DWORD Value dialog box, type D4 and then click OK.
- Quit Registry Editor, and then switch to the Command box.
- In the Command box, type net start ntfrs.
- Quit the Command box.
Then I ran the nonauthoritative restore process using the D2 flag on the SBS2008 server.
- Click Start, and then click Run.
- In the Open box, type cmd and then press ENTER.
- In the Command box, type net stop ntfrs.
- Click Start, and then click Run.
- In the Open box, type regedit and then press ENTER.
- Locate the following subkey in the registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup - In the right pane, double-click BurFlags.
- In the Edit DWORD Value dialog box, type D2 and then click OK.
- Quit Registry Editor, and then switch to the Command box.
- In the Command box, type net start ntfrs.
- Quit the Command box.
Bingo, the folders were recreated, and the shares appeared! An answer to a 3 year old question.