a blog about nothing

If a light bulb has stopped glowing, you wouldn’t start with tearing down the wall to check the cables. You’d probably check if pressing the light switch will help you get the light back. If that didn’t work, you’ll move on to replace the light bulb. Still no luck? You’ll move on to check the fuse.

If the fuse is ok, is it just this room that is affected? You might look out the window to see if your neighbours have some lights on.

If you can’t figure it out, you will maybe call en electrician. You’d tell him all the things (steps) you have checked. Maybe the electrician have some additional steps he/she ask you to check…

Why would you follow these steps?

A wise man once said “if you know how a system works, then you’d be able to troubleshoot the system” (at least I think he said it:)

This rule applies to almost all efficient troubleshooting. If you’re going to troubleshoot slow logon issues, then it’s not as easy as the light bulb example. The cause can be hundreds of things. So where should I start looking?

Instead of re-inventing the wheel, here is my four favorite MS team blogs regarding the issue. If you take your time and read them, you will have a very good chance to find the culprit.

1. Ask the Perf team

2. Ask the DS team part#1

3. Ask the DS team part#2

4. Troubleshooting AD by Instan

Applies to Server 2003/2008. Not for Windows 2000.

Time is crucial in an Active Directory domain. If there are i.e. more than 5 minutes offset between a DC and a client computer, the Kerberos protocol used for authentication will fail.

You may also see problems with AD replication if two DCs are out of time sync, since attributes that are changed are time stamped when the change occurred. The time stamp is one of three functions to prevent replication/attribute conflicts.

When a user logs on to his/her workstation and authenticates, the computer will synchronize its time with the authenticating DC.

This DC, if it’s not the PDC role holder, synchronizes its time with the domain’s PDCe role holder.

The PDCe holder should synchronize its time with a reliable time source. You could find a NTP server close to you HER.
If the DC holding the PDC dies, the role is transferred or siezed you have to configure the time source on the new PDCe.
Configuring the external time source can be a mess, and maintaining it might be even more messy

The MS DS team made a blog entry about this some time ago and I must say it’s a really elegant approach!!

In short terms they create a GPO, sets an external time source, configures a WMI filter so the GPO only applies to the domains PDCe role holder, and link the GPO to the Domain Controller container.

Open the GPMC and create a new WMI filter:

 

 

 

 

 

 

 

 

 

Query: Select * from Win32_ComputerSystem where DomainRole = 5

Create a new GPO and set the external time source:

Computer Configuration/Administrative Templates/System/Windows Time Service/Time Providers/Configure Windows NTP Client

You set the NtpServer you prefer and change the type to NTP.

 

 

 

 

 

 

 

 

 

Activate the WMI filter to this GPO:

 

 

 

 

 

 

 

 

 

 

and link the GPO to the Domain Controllers container:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

To see how the DCs is synchronizing their time, run: w32tm / monitor

 

 

 

Here dc01test.spurs.local (the PDCe holder) uses its HW clock while dc4test.spurs.local is synchronizing with dc01test.

Restart the time service (net stop w32time && net start w32time) and force a Group Policy update (gpupdate /force or wait 5 minutes)

Now the newly created GPO is applied and now dc01test is synchronizing with the external time source.

 

 

 

 

You can also see this in the System Event log:

 

 

 

 

 

 

 

 

So what happens if I transfer the PDCe role from dc01test to dc4test?

I wait for 5 minutes (and run w32tm /monitor just to check):

 

 

 

 

As you can see dc4test is now synchronizing with the external time source, while dc01test is synchronizing with dc4test.

You don’t have to think of configure the time source if your PDCe is transferred.
You even don’t have to clean the old PDCe holder as the registry don’t gets tattooed by this!!!
If you configure the time with a GPO, the registry settings will be located here:

HKLM/Software/Policies/Microsoft/Windows/W32time

If you don’t use a GPO, the settings will be set here:

HKLM/System/CurrentControlSet/Services/W32time

The first one takes precedence over the second one.

References:

http://www.pool.ntp.org/en/

http://support.microsoft.com/kb/816042

http://blogs.technet.com/b/askds/archive/2008/11/13/configuring-an-authoritative-time-server-with-group-policy-using-wmi-filtering.aspx

Environment:

– Windows 2000/2003/2008 domain controllers using FRS (not DFSR).
– More than one Domain Controller
– Atleast one DC with a healthy SYSVOL

Why do Journal Wraps occur?

Instan at the AD Troubleshooting blog made an excellent blog entry about:

“What happens in a Journal Wrap?”

You should give it a read to understand what is going on under the hood.

Symptoms that might occur:

• Event ID 13568 is logged in the NtFrs event log
• A generic Event ID 1058 may be logged
• You make changes to a logon script but not all users got the change
• Changing a GPO or creating a new GPO is not applied to all users or computers
• Missing SYSVOL share
• A RSoP or gpresult report that data or policy object is missing or corrupt

If you take a look at the 13568 event you’ll see that there is a “solution” to this problem:

Set the “Enable Journal Wrap Automatic Restore” registry parameter to 1

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters”

Restart ntfrs service.

This is not a good solution for post-Server 2000 SP3.
I don’t know why Microsoft still have this “how-to-fix” in event 13568, but they say in KB 290762:

Important: Microsoft does not recommend that you use this registry setting, and it should not be used post-Windows 2000 SP3. Appropriate options to reduce journal wrap errors include…

Update: I had to ask around about this since it was nagging me:

The event was never changed because the product group didn’t want to pay for the localization cost, nor admit that this registry setting caused more problems than it fixed. It actually came down to ego – the developer of FRS was a real piece of work. So instead the public docs were updated to state not to use that autorecovery registry setting.

Instead you should go for the Burflags method. This will kick start your SYSVOL up and running. Most often a “non-authoritative” (D2) approach will fix you up.

The “D2” key can be set two places in registry:

Global re-initialization:

HKLM\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup

or

Replica set specific re-initialization:

HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets\GUID

If you’re using DFS replica sets that holds a large amount of data that is healthy, go for the “Replica set specific re-initialization”. If you set the Global Burflags, FRS will re-initialize all replica sets, including the DFS namespace the member holds. If they hold a large amount of data… that might take some time.

To find the GUID of SYSVOL, look for the “Replica Set Name” named “Domain System Volume (SYSVOL SHARE)” under the subkey “HKLM\..\..\Replica Sets”:

This screenshot have only one GUID since I don’t use DFS in my lab.

Change the value of Burflags to D2 (hex).
If you don’t uses DFS you could just set the Global Burflags to D2. It will not make any difference under what subkey you set it. This will re-initialize all replica sets the member holds (in this case the SYSVOL).

After you have set the Burflags key to D2, you have to restart the NTFRS service on the affected DC.

Overview of what happens:

1. The Burflags is set to 0
2. Event ID 13565 is logged. non-authoritative restore has started
3. The content of SYSVOL are moved to the pre-existing folder
4. Event ID 13520 is logged
5. The local FRS database is rebuilt
6. It re-join (vvjoin) the replica set
7.  The “bad DC” will compare all files (file ID and MD5 sum) it has in the Pre-existing folder with the files from an upstream partner.
8. If a match is found, it will copy the file from the Pre-Existing folder to the original location. If they don’t match, it will pull the file from the upstream partner.
9. Event ID 13553 is logged
10. FRS notifies (SysvolReady reg.key = 1) the Netlogon service that SYSVOL is ready and can be shared.
11. The Netlogon service will share SYSVOL and Netlogon.
12. Event ID 13516 is logged (finished)

 

When you have verified that SYSVOL is shared and in sync, you can delete the content in the Pre-Existing folder to free up space.

Authoritative restore (D4):

If your SYSVOL is all messed up on every DC’s, you might have to do an “authoritative restore” using both the D4 and D2 values.

By the way you should never, ever use the D4 flag on more than one DC as you will have a lot of collisions and morphed folders. The D4 flag should only be set like Microsoft says, as a last resort.

Quick overview:

1. Stop the NtFrs service on every DC
2. Set the D4 flag on one DC that will be authoritative for the replica set(s). The SYSVOL content will not be moved to the pre-existing folder on the authoritative member.
3. Set the D2 flag on the other DC’s (non-authoritative)
4. Start the NtFrs service on the “D4” DC.
5. Check that Event ID 13553 and 13516 is logged.
6. If step 5 is ok, start NtFrs on the “D2” DC’s.

For detailed steps, see “How to rebuild the SYSVOL tree and its content in a domain”

References:

FRS event codes: http://support.microsoft.com/kb/308406

What happens in a Journal Wrap?
http://blogs.technet.com/instan/archive/2009/07/14/what-happens-in-a-journal-wrap.aspx

How to rebuild the SYSVOL tree and its content in a domain
http://support.microsoft.com/kb/315457

Using the BurFlags registry key to reinitialize File Replication Service replica sets
http://support.microsoft.com/kb/290762

Backing Up and Restoring an FRS-Replicated SYSVOL Folder
http://msdn.microsoft.com/en-us/library/cc507518(VS.85).aspx