Active Directory is the key component in many organizations to keep tabs on access and identity. If the SYSVOL directory disappears, these steps can get the system fixed.
Active Directory has a number of different components to keep track of user and resource information in an organization. If one piece starts to fail and a recovery effort falters, it could mean it's time for a rebuilding process.
The system volume (SYSVOL) is a shared folder found on domain controllers in an Active Directory domain that distributes the logon and policy scripts to users on the domain. Creating the first domain controller also produces SYSVOL and its initial contents. As you build domain controllers, the SYSVOL structure is created, and the contents are replicated from another domain controller. If this replication fails, it could leave the organization in a vulnerable position until it is corrected.
User access to SYSVOL is essential for the logon process in an Active Directory domain. User logon scripts and GPO data reside in SYSVOL; if user access to SYSVOL falters, then the logon procedure or the user configuration process might fail. If the latter happens, then users might not have access to essential data and applications, or they might gain access to prohibited data and applications.
How the SYSVOL directory is organized
SYSVOL contains the following items:
group policy data;
logon scripts;
staging folders used to synchronize data and files between domain controllers; and
file system junctions.
Figure 1: Use the Get-SmbShare cmdlet to show the SYSVOL and NETLOGON shares on an Active Directory domain controller.
The Distributed File System Replication (DFSR) service replicates SYSVOL data on Windows 2008 and above when the domain functional level is Windows 2008 and above.
Figure 2. The SYSVOL folder contains four folders: domain, staging, staging areas and sysvol.
The position of SYSVOL on disk is set when you promote a server to a domain controller. The default location is C:\Windows\SYSVOL\sysvol, as shown in Figure 1.
For this tutorial, we will use PowerShell Core v7 preview 3, because it fixes the .NET Core bug related to displaying certain properties, such as ProtectedFromAccidentalDeletion.
SYSVOL contains a number of folders, as shown in Figure 2.
How to protect SYSVOL before trouble strikes
As the administrator in charge of Active Directory, you need to consider how you'll protect the data in SYSVOL to protect the system in case of corruption or user error.
Windows backs up SYSVOL as part of the system state, but you should not restore from system state, as it might not result in a proper restoration of SYSVOL. If you're working with the relative identifier master flexible server master operations holder, you definitely don't want to restore system state and risk having multiple objects with the same security identifier. You need a file-level backup of the SYSVOL area. Don't forget you can use Windows Server backup to protect SYSVOL on a domain controller if you can't use your regular backup approach.
If you can't use a backup, then login scripts can be copied to a backup folder. Keep the backup folder on the same volume so the permissions aren't altered. You can back up group policy objects (GPOs) with PowerShell:
Import-Module GroupPolicy -SkipEditionCheck
The SkipEditionCheck parameter is required, because the GroupPolicy module hasn't had CompatiblePSEditions in the module manifest set to include Core.
If you still use login scripts, rather doing everything through GPOs, the system stores your scripts in the NETLOGON share in the C:\Windows\SYSVOL\domain\scripts folder.
Restore the SYSVOL folder
SYSVOL replication through DFSR usually works. However, as with any system, it's possible for something to go wrong. There are two scenarios that should be covered:
Loss of SYSVOL information on a single domain controller. The risk is the change that removed the data from SYSVOL has replicated across the domain.
Loss of SYSVOL on all domain controllers, which requires a compete rebuild.
The second case involving a complete rebuild of SYSVOL is somewhat more complicated, with the first case being a subset of the second. The following steps explain how to recover from a complete loss of SYSVOL, with added explainers to perform an authoritative replication of a lost file.
Preparing for a SYSVOL restore
To prepare to rebuild the SYSVOL tree, stop the DFSR service on all domain controllers:
Stop-Service DFSR
On domain controllers where you can't perform a restore, you'll need to rebuild the SYSVOL tree folder structure and share structure.
On the domain controller with the SYSVOL you want to fix -- or the one with the data you need to replicate -- disable DFSR and make the server authoritative.
Get-ADObject -Identity "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=TTSDC01,OU=Domain Controllers,DC=Sphinx,DC=org" -Properties * |
Disable DFSR on the other domain controllers in the domain. The difference in the commands is you're not setting the msDFSR-options property.
Get-ADObject -Identity "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=TTSDC02,OU=Domain Controllers,DC=Sphinx,DC=org" -Properties * |
Set-ADObject -Replace @{'msDFSR-Enabled'=$false}
Rebuild the SYSVOL tree data
The next step is to restore the data. You can skip this if you're just forcing replication of lost data.
On domain controllers where you can't perform a restore, you'll need to rebuild the SYSVOL tree folder structure and share structure. This tutorial assumes you've created SYSVOL in the default location with the following folder structure:
C:\Windows\SYSVOL
C:\Windows\SYSVOL\domain
C:\Windows\SYSVOL\domain\policies
C:\Windows\SYSVOL\domain\scripts
C:\Windows\SYSVOL\staging
C:\Windows\SYSVOL\staging\domain
C:\Windows\SYSVOL\staging areas
C:\Windows\SYSVOL\sysvol
You can use the following PowerShell commands to re-create the folders in the minimum number of steps. Be sure to change the nondefault location of the Stest folder used below to match your requirements.
Re-create the directory junction points. Map SYSVOL\domain (source folder) to SYSVOL\SYSVOL\<domain name> and SYSVOL\staging\domain (source folder) to SYSVOL\staging areas\<domain name>.
You need to run mklink as administrator from a command prompt, rather than PowerShell:
Run DFSRDIAG on the nonauthoritative domain controllers:
DFSRDIAG POLLAD
The results might not be immediate, but replication should restart, and then SYSVOL should be available.
The process to rebuilding the SYSVOL tree is not something that occurs every day. With any luck, you won't have to do it ever, but it's a skill worth developing to ensure you can protect and recover your Active Directory domain.
Dig Deeper on Microsoft messaging and collaboration
