imageteam - Fotolia

Tip

How to rebuild the SYSVOL tree using DFSR

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.
domain controller shares
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.

SYSVOL folder contents
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.

Create a folder for the backups:

New-Item -ItemType Directory -Path C:\ -Name GPObackup

Use the date to create a subfolder name and create the subfolder for the current backup:

$date = (Get-Date -Format 'yyyyMMdd').ToString()

New-Item -ItemType Directory -Path C:\GPObackup\ -Name $date

Run the backup:

Backup-GPO -All -Path (Join-Path -Path C:\GPObackup -ChildPath $date)

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 * |

Set-ADObject -Replace @{'msDFSR-Enabled'=$false; 'msDFSR-options'=1}

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.

New-Item -Path C:\Stest\SYSVOL\domain\scripts -ItemType Directory

New-Item -Path C:\Stest\SYSVOL\domain\policies -ItemType Directory

New-Item -Path C:\Stest\SYSVOL\staging\domain -ItemType Directory

New-Item -Path C:\Stest\SYSVOL\'staging areas' -ItemType Directory

New-Item -Path C:\Stest\SYSVOL\sysvol -ItemType Directory

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:

C:\Windows>mklink /J C:\stest\SYSVOL\SYSVOL\sphinx.org C:\stest\SYSVOL\domain

Junction created for C:\stest\SYSVOL\SYSVOL\sphinx.org <<===>> C:\stest\SYSVOL\domain

C:\Windows>mklink /J "C:\stest\SYSVOL\staging areas\sphinx.org" C:\stest\sysvol\Staging\domain

Junction created for C:\stest\SYSVOL\staging areas\sphinx.org <<===>> C:\stest\sysvol\Staging\domain

Set the following permissions on the SYSVOL folder:

NT AUTHORITY\Authenticated Users                           ReadAndExecute, Synchronize

NT AUTHORITY\SYSTEM                                                        FullControl

BUILTIN\Administrators           Modify, ChangePermissions, TakeOwnership, Synchronize

BUILTIN\Server Operators                                   ReadAndExecute, Synchronize

Inheritance should be blocked.

If you don't have a backup of the GPOs, re-create the default GPOs with the DCGPOFIX utility, and then re-create your other GPOs.

You may need to re-create the SYSVOL share (See Figure 1). Set the share permissions to the following:

Everyone: Read

Authenticated Users: Full control

Administrators group: Full control

Set the share comment (description) to Logon server share.

Check that the NETLOGON share is available. It remained available during my testing process, but you may need to re-create it. 

Share permissions for NETLOGON are the following:

Everyone: Read

Administrators: Full control

You should be able to restart replication.

How to restart Active Directory replication

Start the DFSR service and reenable DFSR on the authoritative server:

Start-Service  -Name DFSR

Get-ADObject -Identity "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=TTSDC01,OU=Domain Controllers,DC=Sphinx,DC=org" -Properties * | Set-ADObject -Replace @{'msDFSR-Enabled'=$true}

Run the following command to initialize SYSVOL:

DFSRDIAG POLLAD

If you don't have the DFS management tools installed, run this command from a Windows PowerShell 5.1 console:

Install-WindowsFeature RSAT-DFS-Mgmt-Con

The ServerManager module cannot load into PowerShell Core at this time.

Start DFSR service on other domain controllers:

Start-Service -Name DFSR

Enable DFSR on the nonauthoritative domain controllers. Check that replication has occurred.

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'=$true}

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

Cloud Computing
Enterprise Desktop
Virtual Desktop
Close