Why Sysvol and Netlogon Share are importance in Active Directory

By | August 31, 2016

Importance of Sysvol and Netlogon Share in Active Directory

What is sysvol and contents it includes

Sysvol is an important component of Active Directory. The Sysvol folder is shared on an NTFS volume on all the domain controllers in a particular domain. Sysvol is used to deliver the policy and logon scripts to domain members.

By default sysvol includes 2 folders

1.Policies – (Default location – C:\Windows\Sysvol\Sysvol\domain_name\Policies)
2.Scripts – (Default lcation – C:\Windows\Sysvol\Sysvol\domain_name\Scripts)

Note – We can go ahead and change these default locations.

Importance of Sysvol Share

Sysvol contains 2 folders namely Policies and Scripts.

Policies – Under Policies folder all the Group policies which are defined in a particular domain exist. Refer the screenshot

Note that you can see 3 GPT’s are available in above screenshot. When you create new group policy in your active directory then a set of folder are created under Policies folder.

For Eg – I am Creating a Policy called disable screen saver in my domain and linking that policy to my OU. When I hit create new policy button in GPMC, It will create one GUID Name folder under Policies folder which will be associated to Disable screen saver GPO.

To make this simple , Above screen shot has 3 GPT’s that mean 3 Group Policies are present in test.tld domain.
So when you make changes to particular Group policy objects that changes will be committed to Associated GUID name folder under Sysvol.


Importance of Sysvol folder is , it holds the GPT , and whenever an administrator makes any changes to any of the policies , that changes will be committed to associated GUID name folder and then they will be replicated to all Domain controllers.


Sysvol replication methods

Sysvol can be replicated to all the domain controllers using Distributed File System Replication (DFS-R) if the domain functional level This link is external to TechNet Wiki. It will open in a new window. is Windows Server 2008 or higher, or it is replicated using File Replication System (FRS).

For FRS, the SYSVOL schedule is an attribute associated with each NTFRS Replica Set object and with each NTDS Connection object. FRS replicates SYSVOL using the same intrasite connection objects and schedule built by the KCC for Active Directory replication. FRS uses two replication protocols for SYSVOL:

SYSVOL connection within a site. The connection is always considered to be on; any schedule is ignored and changed files are replicated immediately.

SYSVOL connection between sites. SYSVOL replication is initiated between two intersite members at the start of the 15-minute interval, assuming the schedule is open. The connection is treated as a trigger schedule. The upstream partner ignores its schedule and responds to any request by the downstream partner. When the schedule closes, the upstream partner unjoins the connection only after the current contents of the outbound log, at the time of join, have been sent and acknowledged.


Common sysvol error and problems

A . Sysvol and Netlogon shares are missing.

Take a senario , when you add a new domain controller to your domain and you see there is no sysvol and netlogon folder available on the domain controller

Note – Netlogon Share is not a Folder named Netlogon On Domain controller. In fact, it is a folder where, all the logon scripts are stored. So as mentioned above, Script folder under sysvol folder will act as Netlogon share (Location – %SystemRoot%\sysvol\sysvol\<domain DNS name>\scripts)

This mainly occurs if the sysvol replication broken. In some cases, after you added a new domain controller, sysvol replication may take some time. (Approximately you need to wait for some hours).

  1. Journal Wrap Error

FRS is a multi-master replication system that takes care of replicating the contents of Sysvol between all DC’s in the domain (it can also replicate normal data but we’re primarily interested in Sysvol replication in the blog entry).
With proper care and maintenance, Post-SP2 FRS on W2k3 is pretty stable and happily hums along as long as there isn’t an external condition such as a network outage or disk problems that cause it to break down (assuming the data you’re replicating isn’t completely unsuitable for replicating like .PST files, profile data or content that changes frequently).

The most frequent FRS issue is where a Journal Wrap occurs; let’s take a closer look at what happens during a Journal Wrap under the hood.

The way FRS works is that it has an internal database that contains all the files and folders it is replicating and each of these has a unique global ID (GUID). The database also contains a pointer to the last NTFS disk operation (in the USN Journal/NTFS Journal) that the FRS service processed.

If a user changes a file or folder on a disk, the following happens:

1) the operation is picked up by NTFS and an entry is made in the NTFS Journal.
2) FRS monitors the NTFS Journal for changes and notes that a change has been made to that file.
3) FRS keeps a record of the last NTFS Journal event that it processed and checks if it has processed it already.
4) If it hasn’t processed it already, it looks at whether it is a file that it should replicate.
5) If it should be replicated, the file goes into the normal process of staging, replicating, etc.
6) FRS increments the entry in its database about the NTFS Journal event that it has processed so it won’t consider it again.

Now…let’s simplify things a bit.

– Our disk contains one file and one folder (e:\Test and test.txt).
– Our NTFS journal has a size of 10 entries (default NTFS Journal size in RL is ~512 Mb depending on your OS/SP level).
– Our FRS database contains three entries
->a GUID for E:\test
->a GUID for E:\test\test.txt
->A referral to the last NTFS Journal entry we processed (let’s say #4)


Normal operations:

-> Someone makes a change to test.txt.
-> The NTFS Journal is updated to #5.
-> FRS notes that the NTFS journal says that a change has been made to test.txt and it sees that it hasn’t processed that change.
->Stage/Replicate and update the FRS database to reflect that we have processed that NTFS Journal entry.

Now, an Admin stops the FRS service for 30 minutes.

– Someone makes 10 changes to test.txt

o The NTFS Journal is updated 20 times and is now at #24 (remember we have a log size limit of the last 10 entries so therefore need to wrap around).

o FRS is stopped so it isn’t monitoring the NTFS Journal log.

At this point, we have changes on the disk which FRS isn’t aware of. FRS still knows the last NTFS Journal entry that it processed and it will compare this with the current NTFS Journal the next time it restarts.
The next time the FRS service starts, it sees that it has missed NTFS operations on the disk (it last processed NTFS operation #4 but the NTFS Journal is now at #24 and we only have a log that goes back 10 entries so we’re missing operations #5-#14 from the database.

This is when FRS complains it has reached a Journal Wrap state, the NTFS Journal log has wrapped around and it doesn’t know the current state of things on the disk.

The impact of this on an affected DC is that FRS will not set the IsSysvolReady registry key to indicate to the Netlogon service that all is well, Sysvol will therefore not be shared out and the DC will not be able to authenticate users fully until the Journal Wrap condition has been resolved.

Manually sharing out Sysvol or setting the IsSysvolReady registry key to 1 are not valid methods of resolving this issue and are not addressing the real problem.

For FRS to recover from a Journal wrap, you’ll basically have to start from scratch and reset the FRS database and start counting the NTFS Journal from the current values it has.

This means either:
– Replicating in data from an existing inbound partner (The d2 or non-authoritative FRS restore approach).

– Making your own data authoritative and let everyone else replicate from you (the d4 or authoritative FRS restore approach).

The d2 approach is fairly simple to perform, the requirements are however that you have a good network connection with the inbound replication partner and the time it will take is dependent on the amount of data to be replicated vs. the capacity of the link
On the other hand, this may not always be sufficient and you can find yourself being forced to go with the d4 option.

Above are most common errors when you consider sysvol in Active Directory.

Finally what are the steps we can follow when this Above errors are encountered.


Troubleshooting Sysvol Error messages

A . Sysvol and Netlogon shares are missing.

As I mentioned before it might be an issue with sysvol replication broken between Domain controllers.

How can I force the Sysvol replication in an active directory?

You can restart the FRS service to force the FRS replication

To restart the FRS service, launch services.msc from the Run option on the Start Menu
And restart the FRS service and you will get the Event ID 13516 on FRS event log this will ensure the FRS status is fine.


Sysvol replication through NTFRSUTL

If you want to force sysvol replication between two domain controllers in an active directory, then use the below procedure

NTFRSUTL FORCEREPL Command-Line Option to Force Replication

You can use the new ntfrsutl forcerepl command to enforce replication regardless of the predefined replication schedule. This is only implemented for the domain controller Sysvol replica set.

ntfrsutl forcerepl [Computer] /r [SetName] /p [DnsName]

This command forces FRS to start a replication cycle. You must specify the Computer, SetName and DnsName.

Note In this command, the following placeholders are used:

[Computer] = Connect with the NtFrs service on this machine.
[SetName] = The name of the replica set.
[DnsName] = The DNS name of the inbound partner to force replication from.

For example:

ntfrsutl.exe forcerepl DestinationDC /r “Domain System Volume (SYSVOL share)” /p SourceDC.domain.com

The quotation marks in this example are required when you use the /r option. If the quotation marks are not present, the command will not work.

If above does not help then,

Most popular method to resolve this is in below MS KB.


After you install Active Directory Domain Services on a new full or read-only Windows Server 2008-based domain controller in an existing domain, the SYSVOL share is present. However, the NETLOGON share is not present on the new domain controller.

Note This article does not apply if both NETLOGON and SYSVOL shares are missing.


This problem occurs when the Netlogon service reads the SysvolReady Flag in the registry very quickly. Then, the Netlogon service tries to share out the \Windows\SYSVOL\domain\scripts folder before the NT File Replication Service (NTFRS) creates this folder.


Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.

To work around this issue, set the SysvolReady Flag registry value to “0” and then back to “1” in the registry. To do this, follow these steps:

->Click Start, click Run, type regedit, and then click OK.

->Locate the following subkey in Registry Editor:

->In the details pane, right-click the SysvolReady flag, and then click Modify.

->In the Value data box, type 0, and then click OK.

->Again in the details pane, right-click the SysvolReady flag, and then click Modify.

->In the Value data box, type 1, and then click OK.

Note This will cause Netlogon to share out SYSVOL, and the scripts folder will be present.



The problem that is described in the “Symptoms” section occurs in the following scenario:

NTFRS first puts changes in the following location:

Then, NTFRS notifies Netlogon to share out SYSVOL by setting the SysvolReady Flag registry entry to “1.”
NTFRS then moves and renames files from the location that is mentioned in step 1 to the following folder:

However, if the Netlogon service reads the SysvolReady Flag entry in the registry very quickly, the Netlogon service tries to share out the \Windows\SYSVOL\domain\scripts folder before NTFRS creates this folder. Therefore, the NETLOGON share is not created.

  1. Journal Wrap ErrorIf Journal wrap error occurs , then we can set a blurflag value to D2 in the registry on a domain controller where Journal wrap error events are getting generated. By doing this Domain controller will dump the pre-existing folders and start replicating new content from one of its FRS replication partners.


We can set blurflag to D4 which does exactly opposite to above. That is, when you set D4 on a perticular domain controllers its data will act as Authorative , Result, all the domain controllers in your domain will replicate from the Domain controller where this blurflag is set to D4

Note – Setting BlurFlag to D4 is the last option, 90% cases will be resolved by setting up blurflag to D2.

One thought on “Why Sysvol and Netlogon Share are importance in Active Directory

Leave a Reply

Your email address will not be published. Required fields are marked *