Active Directory Back to Basics - Sysvol

Introduction: What is SYSVOL

SYSVOL is simply a folder which resides on each and every domain controller within the domain. It contains the domains public files that need to be accessed by clients and kept synchronised between domain controllers. The default location for the SYSVOL is C:\Windows\SYSVOL although it can be moved to another location during the promotion of a domain controller. It’s possible but not recommended to relocate the SYSVOL after DC promotion as there is potential for error. The SYSVOL folder can be accessed through its share \domainname.com\sysvol or the local share name on the server \servername\sysvol.

What makes up SYSVOL?

The SYSVOL folder is made up of folders, files and junction points. In essence SYSVOL uses DFS to share the relevant folders to users and clients. Lets take a look at a default SYSVOL folder.

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb5.png

We see four folders: domain, staging, staging areas and SYSVOL. For now we will concentrate on the domain and SYSVOL folders.

Starting with the SYSVOL folder c:\windows\SYSVOL\SYSVOL we can see that this is the folder our clients access as it’s shared out as SYSVOL.

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb6.png

Going into the folder we see another folder by the name of our domain.

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb7.png

Looking at the folder we can see the shortcut arrow on the folder icon indicating that this is a link to another folder. If we run a DIR command from a command prompt it shows us that what we are actually seeing is a junction point rather than a directory. We also see the junction point is pointing to the C:\Windows\SYSVOL\domain folder.

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb8.png

Browsing into the domain folder we can see two key folders. Policies and Scripts. These are the folders we are really interested in when we refer to SYSVOL.

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb9.png

The scripts folder by default is empty. Its really the Netlogon share which is mainly used to hold scripts that need to be replicated around all your domain controllers. Whereas the policies folder should always contain at minimum two folders.

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb10.png

The long file names represent the GUIDS of two group policies. In any new domain environment we always get two default GPO’s, Default Domain Policy and Domain Controllers Policy. Any new additional group policies will get a folder created within the SYSVOL policies folder which contain all the files required for that group policy.

Replication

Now we have talked about what the SYSVOL consists of we need to discuss replication. The whole purpose of the SYSVOL folder is that is is replicated to all domain controllers throughout the domain. There are two replication technologies used to replicate the SYSVOL folder, File Replication Service and Distributed File System Replication Service. We are going to explore both these in more detail now:

File Replication Service – FRS

FRS is a multi-master, multi-threaded replication technology. This means that any server that is part of the replication set can make changes. It was first introduced in Windows 2000 to replace the previous LMREPL technology used in NT3.x and 4 days. Although FRS can still be used with Server 2008R2 and above It really isn’t recommended and you would most likely want to move towards using DFS-R – more about that shortly.

Lets start by explaining the steps involved to keep the SYSVOL synchronised between domain controllers using FRS replication. Active Directory replication is different from SYSVOL replication using FRS or DFSR, although both use the replication topology and schedule from AD. This diagram shows the high-level steps which we will go into more detail about.

http://www.windows-support.co.uk/press/wp-content/uploads/2014/04/image_thumb11.png

Whenever a file is written to disk on an NTFS volume the NTFS Change Journal is updated.This is also known as the USN journal and contains a log of changes made to files on the NTFS volume. The FRS service detects the change by monitoring the USN and applies a 3 second delay before creating an entry in its inbound log. This process, known as aging cache, is used to prevent replication when a file is undergoing rapid updates. We refer to to the inbound log, however this is actually a table within the NTFRS database. The log contains information about the file and the time it was changed, this is then used to build its change message. To ensure the file and all it’s attributes (i.e. permissions) are kept intact FRS calls the backup API which uses VSS technology to take a snapshot of the file and it’s attributes. This backup file is then compressed and stored in the staging area folder. At this point the outbound log is updated (again this is actually a table within the FRS database). This contains information about all the changes for a specified replication set. If in step 1 a file was deleted rather than created then we don’t create a staging file, but the outbound log reflects the deletion. FRS on DC1 then sends a change notification to its replication partner DC2. DC2 adds the information about the change into its inbound log and accepts the change then sends a change acknowledgment back to DC1. DC2 then copies the file from DC1 into its staging area. It then writes an entry to its outbound log to allow other partners to pickup the change. DC2 then calls the backup API to restore the file from the staging area into the SYSVOL folder. So there you have it, FRS replication. There is a very detailed and in-depth reference guide on TechNethere for further reference.

Distributed File System Replication – DFS-R

A brand new domain built upon Windows 2008 or higher will automatically use DFS-R to replicate its SYSVOL. However upgrading from 2003 to 2008 or above will not, the domain will still use FRS replication until it is transitioned to using DFS-R. If you are interested in migrating from FRS to DFS-R you should follow the steps here. Its a fairly painless exercise as long as you follow the guide correctly and don’t try and jump ahead and miss steps. DFS-R works in almost the same way as FRS, and Microsoft were kind enough to put some nice auto-healing functions in place to remedy some of the issues that FRS was prone to.

The main difference with FRS is that instead of replicating entire files we only replicate the chunks of data that have changed. This is achieved by creating an MD4 hash of the file. This makes it a much more efficient replication protocol compared to FRS. Also the use of inbound and outbound logs is not required as replication partners exchange version vectors to identify which files have to be replicated between them.

Summary

So we’ve covered what the SYSVOL is and what it consists of and how it’s replicated. The SYSVOL is a key function of Active Directory and an unhappy SYSVOL means an unhealthy AD. Don’t just rely upon the event logs to find errors, you should be proactively monitoring SYSVOL replication, there are plenty of free tools and utilities available to do so.