Importance of Sysvol and netlogon share in Active DirectoryTechieBird

Home | Windows | Network | Interview Questions | Database |

Virtualization | Knowledge Base | Contact Us
Quick Links
Windows 2003 KB
Windows 2008 KB
Windows 2012 KB
Network KB
MS Cluster FAQ's
Knowledge Base Home
Virtualization
Command reference
Exchange Q&A
DNS FAQ's
DHCP FAQ's
Active Directory FAQ's
AD History
Configuring New Domain
Deleted Object Recovery in AD
Global Catalog Server
NetDom Command
Replmon Command
NTDS Utility Guide
FSMO Guide
FSMO Failure
Network Interview Questions
SQL Interview Questions
Active Directory Trust
Group Policy Guide
IIS 6.0
RAID Levels
RPC Guide
Domain & Forest Functional Levels
SQL Failover Cluster
Sysvol and netlogon share importance 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 %SystemRoot%\Sysvol\Sysvol\domain_name\Policies)
2.Scripts - (Default lcation %SystemRoot%\Sysvol\Sysvol\domain_name\Scripts)
Note - We can go ahead and change these default locations.
> Imprtance of Sysvol Share.
Sysvol contains 2 folders namely Policies and Scripts.
Policies - Under Policies folder all the Group policies which are
defined in a particluar 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 Assocaited GUID name folder under
Sysvol.
Conclusion
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 assocated 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 borken. In some cases
after you added a new domain controller , sysvol replication may
take some time.( Approximately you need to wait for some hours).
B.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 dababase 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
encoutered.
> 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
Your 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.
SYMPTOMS:
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.
CAUSE:
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.

WORKAROUND:
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:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parame
ters
->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.
MORE INFORMATION:
The problem that is described in the "Symptoms" section occurs in
the following scenario:
NTFRS first puts changes in the following location:
\Windows\SYSVOL\domain\DO_NOT_REMOVE_NtFrs_PreInstall_Directory
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:
\Windows\SYSVOL\domain
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.
B . Journal Wrap Error
If 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.
Or
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.
AD ArticlesWindows FAQ's
Comments
Enter your comment here
by Html Comment Box No one has commented yet. Be the first!
Home | Windows | Network | Interview Questions | Database| Knowledge
Base | Contact Us
Designed by TechieBird