Windows 2008 R2 Domain Controller Promotion Guidance

Excessively Large Sysvol

The first issue I want to discuss is an issue I faced with an excessively large SYSVOL. As we all know, the SYSVOL is replicated to all domain controllers within the domain. So, as soon as you place a file in the SYSVOL, it will be triggered by the File Replication Service (FRS or NTFrs) or DFRS (with Windows Server 2008 domain functional levels). The typical contents of the SYSVOL include your scripts (logon, logoff, startup, and shutdown) and your Group Policy Objects (the Group Policy Template portion anyway). The Group Policy Objects are located under the Policies subfolder and the scripts under the Scripts folder. An example of these can be seen in Figure 1.

Figure 1: Scripts and Policies subfolders under the SYSVOL on domain controllers.

Even with a large number of Group Policy Objects and/or a large number of scripts, this volume of data is not extremely large. Thus, when a new domain controller is introduced into the domain, the time to copy and converge the folders and data is reasonable, especially on a well connected network.

However, if other data is placed in the SYSVOL, which is voluminous in size, the time to copy and converge the data can be very long. How long? Well, it all depends on the network speed, bandwidth availability, hardware on each domain controller, and overall “voluminosity” of the data. In one instance it took over 10 hours to copy and converge the data for a new domain controller.

Why is this important? Well, the SYSVOL and NETLOGON shares will not be created until the contents of each are 100% copied and converged! This means that your domain controller will not be available until this occurs.

My suggestion is to keep a close eye on the SYSVOL contents and ensure that everything is copied and converged, before you attempt to “solve” this problem. Patience is the key here. If you attempt to assist or alter the behavior, you could very well corrupt the process, extend the overall process, or even cause the domain controllers to fail to create the SYSVOL and NETLOGON shares.

Sysvol Being Ready

During the promotion of a server to a domain controller, the operating system is constantly checking for indicators that the server is truly a domain controller. Like anything else, there might be a time when the computer has completed the promotion, rebooted, and even some of the services (DNS, DHCP, etc) are functioning, but the computer does not register that it is a domain controller.

If this occurs, the SYSVOL will not be registered as “ready” so there will not be any replication of the SYSVOL between the existing domain controllers and the new domain controller. There will also not be a NETLOGON share, as the SYSVOL being ready flag was missing or in error, thus causing the NETLOGON to fail to be created. There may or may not be an error message in the Event Viewer, depending on which aspect of the computer the system feels is not yet a domain controller.

I have found that everything is ready, running, and functional, and there are no events registered in any log. However, the SYSVOL is not replicating! In this instance, there is a Registry value you can add/modify to ensure that the domain controller is seen as complete and the SYSVOL is ready for replication.

The Registry path to this value is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters and the value is SysvolReady. If the value is set to 0, that indicates that the system is not ready. If you move this to a value of 1, that should cause the NETLOGON share to be created and replication to begin to occur.

For more information on this entry and value, please refer to http://support.microsoft.com/kb/947022.

Re-replication of Sysvol

There might be other instances where a domain controller fails to replicate SYSVOL and the contents correctly or completely. In this instance you will need to restore or reinitialize the domain controller SYSVOL information, due to it being incomplete or inconsistent. In rare instances you might need to rebuild the entire replica set from scratch, but that is extremely rare.

For our scenario, and what I have found most often, you can simply set the failing domain controller Registry entry such that it is seen as a non-authoritative replica and it will then cause the replication to occur from one of its replication partners.

The Registry path to this value is HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup and the value is BurFlags. This is a DWORD value and it has two
primary configurations. D2 will indicate that the SYSVOL is a non-authoritative replica partner and D4 indicates an authoritative partner. Before you edit this value to D2 (non-authoritative in our example) be sure to stop the ntfrs service. After you set the value to D2, go ahead and start the ntfrs service. The BurFlags value will be set back to 0 automatically.

For more information on this Registry entry, go to http://support.microsoft.com/kb/290762.

Summary

SYSVOL and NETLOGON are essential aspects of any domain controller. When you are performing a promotion of a server to become a domain controller, different issues might occur. The best thing you can do at first is be patient and keep checking the SYSVOL and associated files for changes. If the files are slowly replicating just be patient. Be sure you know how much information you have in the SYSVOL before you promote your server, so you have an idea as to how long the process might take. In some cases it might take up to 12 hours for the SYSVOL to replicate if you have roaming profiles or other large files located in SYSVOL. If the replication process fails to start, then double check the SysvolReady value, as this might not have triggered the domain controller to create the NETLOGON share or the SYSVOL share. If all else fails and you feel that your domain controller is ready for action, but nothing is occurring, go ahead and trigger your domain controller for a non-authoritative restore of the SYSVOL using the BurFlags Registry entry. After performing one or more of these actions, your domain controller should replicate and start authenticating correctly.