Troubleshooting Sysvol

If you run into me, ask me about why Sparta the dolphin needs a break. So after a well-deserved vacation to the Caribbean, I have decided to come back and write a blog posting that is one of the more common issues that we see weekly if not daily. The support request is usually worded something like – “We had a 2003 server, added a 2012 R2 domain controller, transferred the roles, turned off or demoted the 2003 DC and now nobody can log in”

The first step is of course to check for the presence of Sysvol and Netlogon shares on the new DC, if they are present, validate that they contain at least the following data structure.

How do I check for the shares?

From a command prompt run the following command “net share” should get something similar to:

Note: This command also tells you the physical paths to the actual resource, which if you follow that from explorer you will see a structure that looks like:

There are 2 policies that should be on every domain controller

  1. {31b2F340-016D-11D2-945F-00C04FB984F9} is the Default Domain Policy
  2. {6AC1786C-016F-11D2-945F-00C04FB984F9} is the Default Domain controllers policy

If all of the shares above are not present, then we need to find out if any other DC’s have the share.  If none seen, we could restore the missing data from backup.  Yet another option in my example at the beginning it to turn the 2003 DC back on and pull the data off of there.   Of course, that’s only applicable when you’re performing a migration.  If you do boot the old DC, you might check for the following error in the system event log on the old DC.

Event ID: 13561
Event Type: Error
Message Text: The File Replication Service has detected that the replica set “%1” is in JRNL_WRAP_ERROR. Replica set name is : “%1” Replica root path is : “%2” Replica root volume is : “%3” A Replica set hits JRNL_WRAP_ERROR when the record that it is trying to read from the NTFS USN journal is not found.

This would explain why sysvol never replicated to the new DC.  If the 13561 is present the easiest way to correct this would be to set the burflags on the 2003 server in journal wrap to D4 and on the new dc set as D2

What does all this D2/D4 mumbo jumbo mean? If set to D4 it basically tells the domain controller “Hey, you’re the boss – you have the best files”, while D2 tells the DC – “Your files aren’t right – get them from an authoritative server”
In the above situation, we are basically telling the 2003 (In Journal wrap) make your files authoritative – this will pull it out of journal wrap and allow the D2 server (2012) to replicate them. Note: you will have to stop the ntfrs server down on all DC’s when you do a D4.

The steps to perform this are:

  1. Stop NTFRS on all DC’s (“net stop ntfrs”)
  2. On the good DC set the registry value Burflags to D4 – HKLM\System\CurrentControlSet\Services\NTFRS\Parameters\Backup/Restore\Process at Startup
  3. On the bad DC(s) set the registry value Burflags to D2 – HKLM\System\CurrentControlSet\Services\NTFRS\Parameters\Backup/Restore\Process at Startup
  4. Start NTFRS on the good server (“net start ntfrs”)
  5. Start NTFRS on the bad server (“net start ntfrs”)
  6. Validate sysvol is replicating or has replicated by checking for Event 13565 and 13516 in the system log and running “net share” from the command prompt and validate the presence of NETLOGON and SYSVOL
  7. Rinse and Repeat steps 5 & 6 for each remaining DC

If you domain was created with 2008 or newer initially or you have migrated from utilizing FRS to DFS-R for sysvol then the process is a little different

If the above fails and you have another healthy DC you can also copy from the healthy DC to the not so happy dc using this process

So what happens if the old DC is no longer available, I do not have the shares available, and there is no backup? – Which will get you to DCGPOFix. This will recreate the default GPO’s, Let me restate that – THIS WILL REPLACE THESE TWO POLICIES WITH DEFAULT SETTINGS. This should be done as a last ditch effort to recover from a catastrophic failure.

So the above generally covers the failure of sysvol to replicate, but what about when you just need to restore from backup?

  1. System State Backup/Restore –
  2. Non-Authoritative restore: – Non-Authoritative restore of course assumes that there is another DC that is authoritative in the domain
  3. Authoritative Restore: – This link also describes the different types of backups and restores


Also in the same subject area – no conversation of backup/restore is complete without a brief statement about Tombstone Lifetime. The first thing to determine is what the tombstone lifetime value is:, and why that matters J

All of this goes into how to fix Sysvol errors, but it doesn’t really go into WHY this happens.

Here are some common issues that can cause these errors:

  1. Hardware errors and disk corruption, commonly on but not limited to aging hardware
  2. Power Issues: While it may not be immediately recognized as an issue, power outages and improper reboots can cause these. I have seen 2003 Single DC environments in journal wrap for years. It’s usually not until they add a brand new spanking server into the environment that the customer recognizes there is an issue.
  3. AV: This is my favorite one. Microsoft has published an article about exclusions that should be done on enterprise computers and a more exhaustive list but nobody tends to ever do them



Tagged with: , , ,
Posted in Active Directory

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: