Steps to rebuild the SYSVOL Tree when none exists in Active Directory
Knowing how to rebuild the SYSVOL tree from scratch isn't a skill that you'll use every day, but it's definitely one that you'll be glad you have.
Recently I talked to a Windows admin who had trouble promoting the second DC in a domain. It seems that AD replication was working and DNS was healthy, but FRS was not. No SYSVOL or Netlogon share, no SYSVOL tree on the second domain controller. The FRS event log was logging Event ID 13508 events but no 13509 events.
Tried forcing SYSVOL replication, using KB 290762 -- setting BURFLAGS value on the PDC to D4 and on the other DC to D2 -- but something went wrong and it wiped out the SYSVOL tree on the primary domain controller. It was as if it had replicated the empty SYSVOL to the PDC instead of the other way around. So we had no SYSVOL tree on either DC.
Yes, we could have started from scratch, but that would not have been a good political decision. And we really didn't have root cause to justify it.
The solution was to create the SYSVOL tree, including junction points and proper ACLs. Of course, we also had to create the default domain policy and the default domain controller policy.
There is a decent article on the Microsoft Help and Support site, KB 315457 How to rebuild the SYSVOL tree and its content in a domain, but like many articles of this nature, Microsoft tries to cover all the bases. At least for me, it was hard to follow at times.
In addition, the Microsoft's KB assumes you have a SYSVOL tree in the domain -- which we did not -- so we had to generate a new default domain policy and default domain controller policy. We ran into an additional problem with other policies that had objects in AD but did not exist in SYSVOL.
I would recommend referring to the KB for details, but this is how you solve the problem of no SYSVOL on any DCs.
Step 1: Stop the FRS service on both DCs and create the SYSVOL tree on the PDC. This is pretty basic. Use Windows Explorer or a command prompt. I used a good DC I had in a lab as a guide. The tree looked like this:
SYSVOL
Domain
DO_NOT_REMOVE_NtFrs_PreInstall_Directory
Policies
Scripts
Staging
Staging Area
SYSVOL
Corp.net
Step 2: Set the ACLs. We just left the default ACLs on all directories except the DO_NOT_REMOVE_NtFrs_PreInstall_Directory. Again, looking at my lab domain, we removed all users and groups except domain administrators and System I and defined both of them to have "Special Permissions" only. I also set the "DO_NOT_REMOVE" directory attributes to Hidden and Read.
Step 3: Create the junction points. Remember the junction points connect a "real" directory to a "mirrored" directory. The \SYSVOL\domain is the real (Source) directory connected to \SYSVOL\SYSVOL\corp.net, a junction point. \SYSVOL\Staging\Domain is the real (Source) directory connected to \SYSVOL\Staging Areas\Corp.net.
KB 315457 shows how to determine the actual source directory if you need that information, but here is what we did:
Using the linkd command,
linkd "%systemroot%\SYSVOL\SYSVOL\Corp.net" %SYSTEMROOT%\SYSVOL\DOMAIN
linkd "%systemroot%\Sysvol\staging Areas\Corp.net" %systemroot%\sysvol\Staging\Domain
Step 4: Rebuild default domain policies. Using the DCGPOFix tool, available from Microsoft's download site, this was pretty easy. Just run the tool and it asks if you want to create a new default domain policy (answer yes) and if you want to create a new default domain controllers policy (answer yes). At this point, we double-checked to make sure the SYSVOL tree and the policies were all correct.
Step 5: Replicate SYSVOL. We had already found that using KB 290762 wiped out SYSVOL on the PDC, so we didn't want to do that again. Because we only had two DCs and because the file replication service had been stopped, it seemed logical that starting the FRS -- first on the PDC and then the other DC -- would jump-start FRS. SYSVOL was replicated, and we had the SYSVOL share.
This next part isn't really a step. It's something we ran into that you should be aware of. After Step 5, SYSVOL was shared but not NETLOGON. When SYSVOL was deleted from the PDC, it also deleted two custom Group Policies. When SYSVOL was replicated after the rebuild, errors were logged in the event log complaining about these two policies. Using ADSIEdit, we went to Corp.net\system\Policies and deleted the objects for the two deleted policies. Soon, the Netlogon share appeared, and the 1704 event in the application log validated replication of policy.
After doing an operation like this, it's a good idea to check the event logs for related errors and create a sample GPO and see if it replicates.
Recently I talked to a Windows admin who had trouble promoting the second DC in a domain. It seems that AD replication was working and DNS was healthy, but FRS was not. No SYSVOL or Netlogon share, no SYSVOL tree on the second domain controller. The FRS event log was logging Event ID 13508 events but no 13509 events.
Tried forcing SYSVOL replication, using KB 290762 -- setting BURFLAGS value on the PDC to D4 and on the other DC to D2 -- but something went wrong and it wiped out the SYSVOL tree on the primary domain controller. It was as if it had replicated the empty SYSVOL to the PDC instead of the other way around. So we had no SYSVOL tree on either DC.
Yes, we could have started from scratch, but that would not have been a good political decision. And we really didn't have root cause to justify it.
The solution was to create the SYSVOL tree, including junction points and proper ACLs. Of course, we also had to create the default domain policy and the default domain controller policy.
There is a decent article on the Microsoft Help and Support site, KB 315457 How to rebuild the SYSVOL tree and its content in a domain, but like many articles of this nature, Microsoft tries to cover all the bases. At least for me, it was hard to follow at times.
In addition, the Microsoft's KB assumes you have a SYSVOL tree in the domain -- which we did not -- so we had to generate a new default domain policy and default domain controller policy. We ran into an additional problem with other policies that had objects in AD but did not exist in SYSVOL.
I would recommend referring to the KB for details, but this is how you solve the problem of no SYSVOL on any DCs.
Step 1: Stop the FRS service on both DCs and create the SYSVOL tree on the PDC. This is pretty basic. Use Windows Explorer or a command prompt. I used a good DC I had in a lab as a guide. The tree looked like this:
SYSVOL
Domain
DO_NOT_REMOVE_NtFrs_PreInstall_Directory
Policies
Scripts
Staging
Staging Area
SYSVOL
Corp.net
Step 2: Set the ACLs. We just left the default ACLs on all directories except the DO_NOT_REMOVE_NtFrs_PreInstall_Directory. Again, looking at my lab domain, we removed all users and groups except domain administrators and System I and defined both of them to have "Special Permissions" only. I also set the "DO_NOT_REMOVE" directory attributes to Hidden and Read.
Step 3: Create the junction points. Remember the junction points connect a "real" directory to a "mirrored" directory. The \SYSVOL\domain is the real (Source) directory connected to \SYSVOL\SYSVOL\corp.net, a junction point. \SYSVOL\Staging\Domain is the real (Source) directory connected to \SYSVOL\Staging Areas\Corp.net.
KB 315457 shows how to determine the actual source directory if you need that information, but here is what we did:
Using the linkd command,
linkd "%systemroot%\SYSVOL\SYSVOL\Corp.net" %SYSTEMROOT%\SYSVOL\DOMAIN
linkd "%systemroot%\Sysvol\staging Areas\Corp.net" %systemroot%\sysvol\Staging\Domain
Step 4: Rebuild default domain policies. Using the DCGPOFix tool, available from Microsoft's download site, this was pretty easy. Just run the tool and it asks if you want to create a new default domain policy (answer yes) and if you want to create a new default domain controllers policy (answer yes). At this point, we double-checked to make sure the SYSVOL tree and the policies were all correct.
Step 5: Replicate SYSVOL. We had already found that using KB 290762 wiped out SYSVOL on the PDC, so we didn't want to do that again. Because we only had two DCs and because the file replication service had been stopped, it seemed logical that starting the FRS -- first on the PDC and then the other DC -- would jump-start FRS. SYSVOL was replicated, and we had the SYSVOL share.
This next part isn't really a step. It's something we ran into that you should be aware of. After Step 5, SYSVOL was shared but not NETLOGON. When SYSVOL was deleted from the PDC, it also deleted two custom Group Policies. When SYSVOL was replicated after the rebuild, errors were logged in the event log complaining about these two policies. Using ADSIEdit, we went to Corp.net\system\Policies and deleted the objects for the two deleted policies. Soon, the Netlogon share appeared, and the 1704 event in the application log validated replication of policy.
After doing an operation like this, it's a good idea to check the event logs for related errors and create a sample GPO and see if it replicates.
Comments