Configuring the Windows Time Service for Windows Server

Configuring the time service on the PDC Emulator FSMO role holder

Ace Fekay, MVP, MCT, MCTIP EA, MCTS Windows 2008 & Exchange 2007, MCSE & MCSA 2000/2003, MCSA Messaging
Microsoft Certified Trainer
Microsoft MVP: Directory Services

Original Compilation 9/12/2009

Edit: 9/23/09: Added additional links (indicated in the Related Links section).
Edit: 10/10/2009: - Added additional section called "Client To DC Time Sync"
Edit: 2/11/2010:  - Added info about finding out which DC is the time source by using the w32tm /monitor command
Edit: 8/9/2010 - Added additional info in the troubleshooting section

---

Time Service Background

Kerberos is the authentication method in an Active Directory infrastructure. There are three parts of the the authentication method between members in an AD infrastructure: 1) Client, 2) Server, and 3) the trusted third party, which is Kerberos. Kerberos uses time as a "salt" to insure that the authentication sequence cannot be used in a "replay" scenario by a prospective attacker. One of the basis of preventing a "replay" is that Kerberos has a five (5) minute time skew, meaning that if the client and server (whatever two machines are authenticating, whether DC to DC, member server to DC or client, or client to DC), if the clocks are off more than five (5) minutes, the authentication sequence fails. To insure that all clients' clocks are within the five (5) minute skew, the time service must be synched across the infrastructure.

Clients get their time source from the DC that logged them on. That DC will get it's time synched from the PDC Emulator in its domain. If its in a child, that PDC Emulator will get its time synched from the PDC Emulator in the forest root, which should be configured to an external time source. This simply works out-of-the-box other than configuring the PDC Emulator in the forest root domain to sync with an external time source. No other action is truly necessary. To alter the time registry settings, is inviting trouble and should only be done under guidance by Microsoft Support.

To find the DC that logged a client on, run the following. This is also the client's time server.
echo %logonserver%

In a multi-site scenario, as long as AD Sites have been configured properly with their respective subnet objects assigned to the site, and the servers have been moved to their respective sites, the client machine's logonserver will always be the time source. 

This all assumes that none of the DCs are not multihomed (or it may become part of more than one site which will cause an error, besides other issues), the AD DNS domain name is not a single label name ("domain" vs domain.something), and using only the internal DNS servers in ipconfig, otherwise it's guaranteed to expect other problems to occur.


Time Convergence Hierarchy

This section was quoted from:

Basic Operation of the Windows Time Service
http://support.microsoft.com/kb/224799

All client desktops select an authenticating domain controller (the domain controller returned by DSGetDCName()) as their time source. If this domain controller becomes unavailable, the client re-issues its request for a domain controller.

All member servers follow the same process.

All domain controllers in a domain make 3 queries for a DC:
1. A reliable time service (preferred) in the parent domain,
2. A reliable time service (required) in the current domain,
3. The PDC of the current domain. It will select one of these returned DCs as a time source.


The PDC Emulator FSMO role holder at the root of the forest is authoritative, and can be manually set to synchronize with an outside time source (such as the United States Naval Observatory).

 

Client to DC Time Sync

(Added 10/10/2009, 12:21AM)

How to configure an authoritative time server in Windows Server 2003
http://support.microsoft.com/kb/816042

The points below were quoted from the above link:

All client desktop computers nominate the authenticating domain controller as their in-bound time partner.
All member servers follow the same process that client desktop computers follow.
All domain controllers in a domain nominate the primary domain controller (PDC) operations master as their in-bound time partner.
All PDC operations masters follow the hierarchy of domains in the selection of their in-bound time partner. In this hierarchy, the PDC operations master at the root of the forest becomes authoritative for the organization

The following quote is on the time  algorithm in Windows 2000, which I haven't seen any evidence that it has changed:
http://www.windowsnetworking.com/articles_tutorials/Configuring-Windows-Time-Service.html
http://windowsitpro.com/article/articleid/8383/windows-time-synchronization-service.html

"When a client workstation (i.e., a Windows 2000 Professional—Win2K Pro—machine) boots, it contacts a domain controller for authentication. When the two computers exchange authentication packets, the client adjusts its local time based on the target (i.e., the domain controller's) time. If the target time is ahead of local (i.e., the client's) time by less than 2 minutes, the client immediately adjusts its time to match the target time. If the target time is behind the local time by less than 2 minutes, the client slows its clock over a period of 20 minutes until the two times are in synch. If the local time is off by more than 2 minutes, the client immediately sets its time to match the target time. . . . "

Due to this 2 minute conversion, an authorative time server on the domain (PDC Emulator), acts a time client to an external time source, therefore you may see a lag between the time source's time and the time on the server.

 

Note: The PDC master must not be configured to synchronize with itself.

This important section was quoted from:

How to configure an authoritative time server in Windows Server
http://support.microsoft.com/kb/816042

For more information about why the PDC master must not be configured to synchronize with itself, visit the following Web site to view Request For Comment (RFC) 1305:
http://www.rfc-editor.org/ (http://www.rfc-editor.org/)

If the PDC master is configured to synchronize with itself, the following events are logged in the System log:

Event Type: Information
Event Source: W32Time
Event Category: None
Event ID: 38
Computer: ComputerName
Description: The time provider NtpClient cannot reach or is currently receiving invalid time data from NTP_server_IP_Address. For more information, see Help and Support Center at http://support.microsoft.com.

Event Type: Warning
Event Source: W32Time
Event Category: None
Event ID: 47
Computer: ComputerName
Description: Time Provider NtpClient: No valid response has been received from manually configured peer NTP_server_IP_Address after 8 attempts to contact it. This peer will be discarded as a time source and NtpClient will attempt to discover a new peer with this DNS name. For more information, see Help and Support Center at http://support.microsoft.com.

Event Type: Error
Event Source: W32Time
Event Category: None
Event ID: 29
Computer: ComputerName
Description: The time provider NtpClient is configured to acquire time from one or more time sources, however none of the sources are currently accessible. No attempt to contact a source will be made for 15 minutes. NtpClient has no source of accurate time. For more information, see Help and Support Center at http://support.microsoft.com.

 

To set the time service in an existing Windows 2003 domain

On the DC holding the PDCEmulator FSMO Role:

w32tm /config /manualpeerlist:192.5.41.41 /syncfromflags:manual /reliable:yes /update
net stop w32time
net start w32time

On other DCs (that are not the PDC Emulator):
w32tm /config /syncfromflags:domhier /update
net stop w32time
net start w32time


Transferring the PDC Emulator Role

If you have moved the Windows 2003 PDC Emulator role to another DC, or if you seized the role to another DC because the original PDC Emulator is no longer available, reset the time source and hierarchy:

On the new PDCEmulator (where 'peers' is an Internet time source such as 192.5.41.41):
w32tm /config /manualpeerlist:peers /syncfromflags:manual /reliable:yes /update

On the old PDCEmulator:
w32tm /config /syncfromflags:domhier /update

After that run the following on both DCs:
net stop w32time
net start w32time

The "peers" can be a text file, or direct input, allowing you to set the time source, either DNS name such as (time.windows.com, or an ip address for a reliable time source. I normally use 192.5.41.41.

On your edge firewall, make sure UDP port 123 traffic is allowed inbound from the time source.

Fi you need a reliable external time source, read the following link for a complete list of them around the internet:

The pool.ntp.org project is a big virtual cluster of timeservers striving to provide reliable and easy to use NTP service for millions of clients without putting  strain on the big popular timeservers.
http://www.pool.ntp.org

 

If some domain machines have problems

w32tm /config /syncfromflags:domhier /update

After that run:
net stop w32time
net start w32time



To set the Time Service on Windows 2000 DCs

On the PDC Emulator, run the following three commands:

C:\>net time /setsntp:192.5.41.41
The command completed successfully.

C:\>net stop w32time
The Windows Time service is stopping.
The Windows Time service was stopped successfully.

C:\>w32tm -once
(W32time performs numerous commands to set the time)

C:\>net start w32time
The Windows Time service is starting.
The Windows Time service was started successfully.

 

To set the Time Service in Windows 2008

Please follow the registry entries instructions in the following Microsoft article on how to configure the Time Service in Windows 2008:

How to configure an authoritative time server in Windows Server (2003 & 2008)
http://support.microsoft.com/kb/816042



The Net Time Command is Weak and Inaccurate with Certain Functions

CO NOT USE the "net time" command. It will create confusion with the time service. This command was meant for use with stand alone machines, and basically is a DOS command, and is pretty much useless in an AD environment.

The net time command is weak. It is a foreground application and is not reliable. It does not query what the local machine's time service is set to use with the domain hierarchy. The net time command is similar to the nslookup command, where it uses its own query methods independent of the local machine.

For example, the following was quoted from:

Overview\Windows Time Service Issues Information
http://www.greyware.com/software/DomainTime/Product/w32time.asp

"When you run NET TIME without the /domain option, the workstation will iterate through the list of time sources on the network, and contact the first one encountered. By default on an NT or 2000 network, only the PDC is a time source.

However, if Domain Time Server is installed on any machine, that machine also becomes a time source. Notice that the NET TIME client won't use the nearest time source -- it will use the first one found in the browser list. It also will not move on to the next source if the first one fails."

Read more on the net time command and its limitations, in the following link. Scroll down to the heading "Problems with NET TIME"

Overview\Windows Time Service Issues Information
http://www.greyware.com/software/DomainTime/Product/w32time.asp



Time Service skew: The Windows W32Time service is not as accurate or reliable as one thinks

Yes, this is true, and this statement is according to Microsoft (KB939322). The reason is the Windows time service is not reliable to synch time down to 1 or 2 seconds and such tolerances are beyond the design of the Windows time service. . It was primarily designed for loose synchronization to support Active Directory's use of the Kerberos v5 protocol for authentication, which uses and relies on a maximum time skew of 5 minutes for it authentication 'salt.' However the Windows Time services is sufficient for this reason, however if you have apps that require sensitive transactional processing with timing down to the second (possibly SEC, banking, or other reasons), it is suggested to use a third party time service.

The Windows 2000 and 2003 time service skew and algorithm is pretty much the same.

The following is quoted from page 9 in the following Microsoft document.
The Windows 2000 Time Service
http://download.microsoft.com/download/2/0/f/20f61625-7b2a-4531-b007-1c714f1e51b7/wintimeserv.doc

"When the local clock offset has been determined, the following algorithm is
used to adjust the time:
 
If the local clock time of the client is behind the current time received from the server, W32Time will change the local clock time immediately.

If the local clock time of the client is more than three minutes ahead of the time on the server, W32Time will change the local clock time immediately.

If the local clock time of the client is less than three minutes ahead of the time on the server, W32Time will quarter or halve the clock frequency for long enough to bring the clocks into sync. If the client is less that 15 seconds ahead, it will halve the frequency; otherwise, it will quarter the frequency. The amount of time the clock spends running at an unusual frequency depends on the size of the offset that is being corrected. "

Read more on this in the following links.

Overview\Windows Time Service Issues Information
http://www.greyware.com/software/DomainTime/Product/w32time.asp

Support boundary to configure the Windows Time service for high accuracy environments
http://support.microsoft.com/kb/939322

 

Which server is my time source?

On a non-DC, you can run the following to see which DC logged you in. That DC wll be YOUR time source.

To confirm which server is being used as a time source, you can also run the following command:

w32tm /monitor

For example, I ran this on a non-PDC emulator DC, dc02.domain.local, in a domain with two DCs. You can see that it grabbed time from the PDC Emulator, which in this case is dc01.domain.local. It also states that dc01.domain.local got it's time source from 192.5.41.41. You can see the offset between the two DCs is 0.0000651s (seconds), so no sync is required since it is under the 2 minute time sync tolerance.

c:\Documents and Settings\administrator>w32tm /monitor
dc01.domain.local *** PDC *** [192.168.80.10]:
    ICMP: 0ms delay.
    NTP: +0.0000000s offset from dc01.domain.local
        RefID: ntp1.usno.navy.mil [192.5.41.41]
dc02.domain.local [192.168.80.11]:
    ICMP: 0ms delay.
    NTP: +0.0000651s offset from dc01.domain.local
        RefID: dc01.domain.local [192.168.80.10]

 

Time Service Troubleshooting

Basic support issues I've seen usually regard if you've moved the PDC Emulator role in the forest root domain to another DC, possibly due to retiring an old DC or DC failure. In this case, all you really have to do is reset the time service on the new PDC Emulator so it is authorative for the domain/forest.

Other than that, the numerous other time service tech support issues I've seen are due to the administrators changing registry settings to tweak the service, however they've found that something is amiss, and now begin back tracking, asking what the registry entries do and their results if set to this setting or that setting, etc. IMHO, I don't believe this is necessary. Basically the Time service works out-of-the-box. The PDC Emulator in the forest root domain is the ultimate time server source for the whole forest, and all other DCs, whether in the forest root or in child domains, or additional trees in the forest, will follow the hierarchy to sync time. Why does it work out-of-the-box? Because  the time services is extremely important for Kerberos. If the time clocks between a machine and a DC are skewed beyond the 5 minute tolerance, the authentication fails, so Microsoft made sure to make the time service work without any changes required. All you have to do is configure the PDC Emulator in the forest root domain to an outside time source, and you are DONE. That's it. Altering the time service registry, unless directed by Microsoft support, are not required.

To reset the Time Service to use the new PDC Emulator

By default, all DCs that are not PDC Emulators, should be syncing time from the PDC Emulator.  If that isn't the case then reset time on the DC in question using the following steps (which applies to workstations, as well).

In a command prompt. I know I said not to use this command, but this is the ONLY exception to run this command on a machine to reset the time service on a machine:

"net time /setsntp: "   (Note the blank space prior to the end ")
Tells the client (whether a DC or workstation) to delete the current registry settings for time and use default settings.

Then run the following:
net stop w32time && net start w32time

Client should now be part of the time domain heirarchy

If the dc is already pointing at the PDCe the PDCe should be getting its time externally (Although this won't cause your problem).  You can run debug logging to track down the error.  All DCs other than the PDC Emulator should be getting time from its domain's PDC Emulator.

Run a Fsmo Query  -  To find which DCs hold which FSMO roles and to determine which DC is the PDC Emulator
netdom query fsmo

You can query the registry keys with the following method:

c:\>reg query hklm\system\currentcontrolset\services\w32time\parameters
C:\> w32tm /dumpreg /subkey:parameters

To resync the service on a client machine:

 w32tm /resync
 w32tm /resync /rediscover

Related Troubleshooting links:

Ensure that the PDC Emulator Time Service is setup as described in KB816042:
How to configure an authoritative time server in Windows Server
http://support.microsoft.com/kb/816042

To Assist in troubleshooting time service issues on the PDC Emulator and other machines, use the following link:
Troubleshooting Windows Time Service Problems
http://technet.microsoft.com/en-us/library/bb727060.aspx

How to turn on debug logging in the Windows Time Service
http://support.microsoft.com/kb/816043/en-us

 

Windows Time Service Related General Links

Support boundary to configure the Windows Time service for high accuracy environments
http://support.micorosoft.com/kb/939322

Basic Operation of the Windows Time Service
http://support.microsoft.com/kb/224799

Time Service:
http://support.microsoft.com/kb/216734

How to configure an authoritative time server in Windows Server (2003 & 2008)
http://support.microsoft.com/kb/816042

How to Configure an Authoritative Time Server in Windows Server 2008 (This article is based on Microsoft KB8164042, link provided above.)
http://www.articlesbase.com/operating-systems-articles/how-to-configure-an-authoritative-time-server-in-windows-server-2008-461336.html

Change the Windows Time service configuration on the previous PDC emulator
http://technet.microsoft.com/en-us/library/cc738042.aspx

A comprehensive list of the Simple Network Time Protocol (SNTP) time servers:
http://support.microsoft.com/kb/262680

Windows Time Service Tools and Settings (including w32time service, w32time registry entries), and how to use the w32tm commands)
http://technet.microsoft.com/en-us/library/cc773263(WS.10).aspx

How Windows Time Service Works. This article provides a good overall graphical and explanation of the Time Service in Windows
http://technet.microsoft.com/en-us/library/cc773013(WS.10).aspx

Network Time is off, not sure how to fix it
http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/652e8200-fc4b-40c7-b579-a88d934df04d/

The Windows 2000 and 2003 time service skew and algorithm is pretty much the same.
The following is quoted from page 9 in the following Microsoft document. The Windows 2000 Time Service
http://download.microsoft.com/download/2/0/f/20f61625-7b2a-4531-b007-1c714f1e51b7/wintimeserv.doc

==================================================================

Ace Fekay

Comments

acefekay said:

Interesting to hear that, considering I am not a woman.

# November 12, 2009 6:25 PM
Leave a Comment

(required) 

(required) 

(optional)

(required) 

If you can't read this number refresh your screen
Enter the numbers above: