Windows Time and the W32TM service Contents

Windows Time and the W32TM service.............................................................................1 Contents...............................................................................................................................1 Introduction..........................................................................................................................2 Time Sync Principles...........................................................................................................3 Why time sync:................................................................................................................3 What is Network Time Protocol......................................................................................3 What are we configuring within Windows......................................................................3 Time Protocol Interoperability.........................................................................................4 Time Sync Hierarchy and Stratum:..................................................................................4 Reliable Time Source Configuration...............................................................................5 Windows 2000 Time Sync...................................................................................................6 Windows 2003 uses W32TM not NET TIME.....................................................................7 Locating Time Servers:........................................................................................................9 Best Practise:......................................................................................................................10 Preventing Large Time Changes....................................................................................10 Troubleshooting Time Sync...............................................................................................12 My Troubleshooting steps:............................................................................................12 Other useful w32tm commands:....................................................................................14 How to turn on debug logging:......................................................................................14 References..........................................................................................................................16

Introduction
In the last few days this issue of time sync in Windows domains has come up a few times both at work and on the Minasi forum of which I am a member (http://web2.minasi.com/forums). Each time there has been confusion as to exactly how time sync occurs in a Windows domain. Therefore, I decided that I would put this article together in order to try to provide a decent answer as to what is going on and how to troubleshoot any issues that arise. The first thing about Time Sync in Windows is to realise that it is a little different between Windows 2000 machines and Windows XP/2003 machines. This is because in Windows 2000 the Simple Network Time Protocol (SNTP) was used and was configured with the NET TIME command. Now, with XP and 2003, Network Time Protocol (NTP) is used which give benefits such as more reliable time due to better correction methods. This is configured using the new W32TM commands which we will look at later on. To start with, however, I will look at the principles that remain the same for both Windows 2000, 2003 and XP computers/domains.

Time Sync Principles

Why time sync:
The first question that we need to ask ourselves is why do we need time synchronisation? Well, in an Active Directory domain, it is very important for all clocks to be within 5 minutes of each other (by default) due to the implementation of the Kerberos protocol for authentication which relies on time stamped packets to prevent amongst other things, man-in-the-middle attacks. Another reason time sync is important for is because now Active Directory uses multi-master domain controllers (DCs) it is important that changes made at a later actual time on one DC dont get overwritten by similar changes on another DC whose time is set wrong thus making it look like the most recent change!

What is Network Time Protocol

Network Time Protocol (NTP) is the default time synchronization protocol used by the Windows Time Service (WTS) in Windows Server 2003 and Windows XP. It should be noted that this is different from Window 2000. As I will mention in the Windows 2000 specific section later on, Windows 2000 used the Simple Network Time Protocol (SNTP) to do time sync. However, for now we will talk about NTP as is contains all the functionality of SNTP and more! NTP time synchronization takes place over a period of time and involves the transfer of NTP packets over a network. NTP packets contain time stamps that include a time sample from both the client and the server participating in time synchronization. NTP relies on a reference clock to define the most accurate time to be used and synchronizes all clocks on a network to that reference clock. NTP uses Coordinated Universal Time (UTC) as the universal standard for current time. UTC is independent of time zones and enables NTP to be used anywhere in the world regardless of time zone settings.

What are we configuring within Windows

The Windows Time Service (WTS), thats what! As you can tell from the name, this is a service that runs on Windows machines and understands and implements network time sync using NTP. To enable the WTS to be flexible, it works by using plug in time providers. This allows it to support both hardware and Internet based time sources. The NTP provider is the standard time provider included with Windows Server 2003. The NTP provider follows the standards specified by NTP version 3 for a client and server, and can interact with SNTP clients and servers for backward compatibility with Windows 2000 and other SNTP clients. The NTP provider in the Windows Time service consists of the following two parts: NtpServer output provider. This is a time server that responds to client time requests on the network.

NtpClient input provider. This is a time client that obtains time information from another source, either a hardware device or an NTP server, and can return time samples that are useful for synchronizing the local clock. The Windows Time service is implemented in a dynamic link library called W32Time.dll. W32Time.dll is installed by default in the Systemroot\System32 folder during Windows Server 2003 setup and installation.

Time Protocol Interoperability

As is often the case with developments in the Windows environment, the new technology can still talk to the old. In this case, this means that the Windows Time service can operate in a mixed environment of computers running Windows 2000, Windows XP, and Windows Server 2003, because the SNTP protocol used in Windows 2000 is interoperable with the NTP protocol in Windows XP and Windows Server 2003.

Time Sync Hierarchy and Stratum:

The degree to which a computers time is accurate is called a stratum. The most accurate time source on a network (such as a hardware clock) occupies the lowest stratum level, or stratum one. This accurate time source is called a reference clock. An NTP server that gets its time directly from a reference clock becomes part of a stratum that is one level higher than that of the reference clock. Resources that get time from the NTP server are two steps away from the reference clock, and therefore are part of a stratum that is two higher than the most accurate time source, and so on. As a computers stratum number increases, the time on its system clock may become less accurate. Therefore, the stratum level of any computer is an indicator of how closely that computer is synchronized with the most accurate time source. Windows 2000/3/XP ensures time is synchronised correctly within a domain by setting up a time sync hierarchy which follows the model above. The Primary Domain Controller emulator (PDCe) of the forest root is the Master Time Server (effectively stratum 1 for the network, although you could see this as stratum 2 as the PDCe also syncs with a more accurate clock). Other DCs then sync with the PDCe and clients and member servers sync with their authenticating DC. Therefore you have one point of Reliable Time in the enterprise, the root PDCe. So you might now be asking; what should I sync the root PDCe to? Well, there are several choices; you dont have to sync the box at all! So long as all the machines within your network share the same time, it doesnt matter what time it is (unless you use time for other purposes). However, since you are likely to want the correct time on all your machines the other options are, either to sync the root PDCe with a hardware clock or to sync it with a public time server on the Internet. Once you have setup the PDCe to sync with an external time source then what happens? Well, it tries to sync every 45 minutes until it achieves its first sync. Then after that, it syncs again every 45 minutes until it has done three successful syncs in a row. After that it syncs once every 8 hours.

You should also note that if the time is more than 3 minutes out then the w32time service will use a process of gradual adjustment to bring things into line rather than simply changing the clock immediately.

Reliable Time Source Configuration

If a domain controller is configured to be a reliable time source, in other words, it syncs with an external time source, the NetLogon service announces that domain controller as a reliable time source when it logs on to the network. When other domain controllers look for a time source to synchronize with, they choose a reliable source first if one is available. When a DC is intended to be a reliable time source you should ensure that the following registry key has a value of 5 if not then the default value 10 should be left in place. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Ti me\Config\AnnounceFlags

Windows 2000 Time Sync

I am now going to look at how you setup your Windows 2000 machine to sync over the Internet and what protocol Windows 2000 uses to do this. As mentioned briefly above, this is one of the differences between Windows 2003/XP and 2000. The protocol used for Windows 2000, is called Simple Network Time Protocol or SNTP. It is a simple version of NTP and lacks some of the more complex algorithms which provide more accurate and stable time for NTP clients. The way you set this up is to use the command line to enter the following: NET TIME /SETSNTP:dnsnameofserver For example, you could use the following: NET TIME /SETSNTP:time.window.com If you what to find out which server you setup a machine to sync to you can use the following command: NET TIME /QUERYSNTP

Windows 2003 uses W32TM not NET TIME

As I mentioned above, Windows Server 2003 and Windows XP now use NTP instead of SNTP. Alongside that they now have a new way of configuring the WTS. The command that now does everything regarding WTS is: w32tm So how do we use it? Well, the first thing to look at is the /config parameter. This does a few things. It allows you to use /computer to specify which computer you are setting up. The default setting is the local machine but it is nice that you can administrate time on remote computers too! It also allows you to tell the WTS that its config has changed and that it should apply the changes by using the /update switch. However, the two most important parameters are: /syncfromflags:MANUALorDOMHIER /manualpeerlist:PEERS These parameters tell the computer whether or not to look for a time server within an Active Directory hierarchy or whether it should sync from and external source and then, if so, what that source is! What these parameters actually do is control a registry entry called "Type" in: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters This key is either set to "NT5DS" if you're in an AD, or "NTP" if you're either not an AD member, or if you're the root domain's PDCe. Actually, this key could also be set to NoSync to prevent any time sync taking place. To tell a system's W32Time service to get its time from the Active Directory, type w32tm /config /syncfromflags:domhier /update This does two things. First, it sets that Type value to "NT5DS." Second, it notifies the w32time service that settings have changed. If the system is not a member of and AD or is the root PDCe then change two things. First, the value of the /syncfromflags option changes from "domhier" to "manual" which changes the Type value from "NT5DS" to "NTP". Second, add the /manualpeerlist: option, to tell it where to sync from. Adding the /manualpeerlist: actually adds the entry specified to another key under the location above. The key is called NTPServer. For example, to tell your system that it should do its own time sync from time.windows.com, type:

w32tm /configure /manualpeerlist:time.windows.com,0x1 /syncfromflags:manual /update Note: if using a DNS name for the time server then it is important to add the 0x1 to the end. If using and IP address this can be omitted. After making any changes to the w32time service configuration you should restart the W32TIME service. This can be done from a command prompt as follows: net stop w32time && net start w23time After issuing either of these commands, you should tell your system to update its time with the following command: w32tm /resync /rediscover So that gets you the basics setup for a Windows Server 2003 or Windows XP machines. To see a list of all the commands you can use with w32tm, type: W32tm /?

Locating Time Servers:

By the way, if you are wondering where to find time servers to sync with I would recommend that you look into the NTP pool project which in its own works does the following: The pool.ntp.org project is a big virtual cluster of timeservers striving to provide reliable easy to use NTP service for millions of clients without putting a strain on the big popular timeservers. For more info see http://www.pool.ntp.org One tip that may be useful to someone during the search for a timeserver is this; if you think that a machine is running a time server then try the utility ntpquery.exe found at the following link: http://www.bytefusion.com/products/fs/ntpquery/ntpquery.html Point it at either a DNS name or IP address and if it returns box like the one in the screenshot below, then you have found a time server!

Another way to verify whether a machine is a time server is to use the w32tm /monitor command. This can be used as follows: W23tm /monitor /computers:uk.pool.ntp.org w32tm /monitor /computers:uk.pool.ntp.org uk.pool.ntp.org [82.71.9.63]: ICMP: error IP_REQ_TIMED_OUT - no response in 1000ms NTP: -4.9009063s offset from local clock RefID: utserv.mcc.ac.uk [130.88.200.6] You should get output similar to the above. In particular the NTP: line which shows that my clock is 4 seconds behind the online time server.

Best Practise:
Preventing Large Time Changes
As I have already stated, it is highly recommended to setup your root PDCe to sync with an external time source of some sort. However, having done this, you are then open to a possible problem caused by an error with the clock you sync to. If something were to go wrong and the time were to change dramatically on your external clock your root PDCe would by default follow this time change and apply it. This would then filter all through you domain which obviously would be a bad thing! To prevent this you should configure the MaxPosPhaseCorrection and MaxNegPhaseCorrection registry entries. From Microsoft sources on the Internet, it would appear that the recommended value is 900 seconds (15 mins). I would suggest that having a 15 minute time change occur on your network is likely unacceptable. I would therefore recommend setting this interval for 300 seconds so that the time change internally is never greater than 5 minutes. This should help to prevent problems if a large change was received which then prevented Kerberos authentication working as some

machines would have a time difference of greater than 5 minutes before full time sync could occur. If you are particularly worried about this type of problem then you could also set the values for your internal systems as well as for your root PDCe. For a little more info about these keys, including where to find them, look in the table below: Obviously the above also means that if your clock were to get a long way out then correction wouldnt be automatic. In this case you should monitor the time of your network fairly regularly and also set the value of the MaxPollInterval registry entry to 10 or less, or that you set value of the SpecialPollInterval registry entry to 3600 (1 hour) or less to enable frequent time checks. As with all these setting changes for more information have a browse of the Windows Time Service Technical Reference which can be found through the link below: http://technet2.microsoft.com/WindowsServer/en/library/b43a025f-cce2-4c82b3ea-3b95d482db3a1033.mspx?mfr=true

Troubleshooting Time Sync

The first thing to note about troubleshooting is that in Windows 2000, there is not much logged to the event log. However, this is changed with 2003 so your first step would be to check out the messages logged there. In order to really see what is going on, you should then look to make use of w32tm and investigate the relevant registry keys mentioned above. Finally you can also enable debug logging for the w32time service. Whilst this can be useful, it does output a large amount of information of which lots may be unintelligible. It is for this reason that it is often useful only when working with MS PSS to solve your problem.

My Troubleshooting steps:
Here are the steps I take when troubleshooting Time Sync issues on a PDCe box. 1. First I will investigate the forest structure looking at how many domains and DCs exist. Then on one of the DCs I will install the Windows 2003 support tools and type netdom query fsmo 2. This will locate the holders of the FSMO roles and allow me to find the server holder the PDCe role. 3. I will then verify with replmon that good replication is occurring within the forest. 4. I will next use the NTPQuery utility mentioned above to verify that the time.windows.com time server can be accessed from the machine. This will verify that the relevant ports are open. Another way of doing this would be to use portqry as shown below which should return a Listening or Filtered output portqry n time.windows.com e 123 p UDP 5. Next I will open up regedit and locate the registry key below. Once there I will check that the desired time server is configured and that if a DNS name is used the ,0x1 suffix is used: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ W32Time\Parameters\NtpServer 6. I will next attempt to ping the server that is referred to. Although this is not always possible due to settings at either end, it does provide a clear indication that the server is available. Another way to get this verification would be to use the portqry command above.

7. Open Registry Editor (regedit.exe) and configure the following registry entries so that it is set to NTP not NT5DS: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\ Type 8. Whilst in the registry ensure that the registry key below has a value of 5. HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config\Ann ounceFlags 9. Now stop and restart the Windows Time service using the following command: net stop w32time && net start w32time 10. Next re-sync the w32time service using the following command: w32tm /resync /rediscover 11. Next check in the system event log to see if errors are still logged. If the above has fixed the problem then you should now receive an event ID of 35 logged by the w32time service. 12. If you still have errors then reboot the server. 13. Then in the registry point the time server to the same time source as above but use the 0x8 flag instead of the 0x1 flag to force W32time to send normal client requests. 14. Restart the w32time service as shown above and check the event log. If errors continue carry on as follows. 15. Check the Default Domain Controllers group policy and the Default Domain group policy and any others that could affect the PDCe or other DCs. Check the following areas: Computer configuration/Administrative Templates /System/Windows Time service/Time Providers Ensure that all three settings listed are set to not configured. 16. Now stop and restart the Windows Time service using the following commands: net stop w32time && net start w32time 17. At this point check the system event logs and you should see event id 35

18. If you are still having problems then as a final attempt, you can un-register and reregister the w32time service. This will clear out all configurations and let you start again from scratch. The details of how to do this are in the next section titled Other useful w32tm commands.

Other useful w32tm commands:

A couple of other w32tm commands that may well be useful in your troubleshooting are as follows: W32tm /unregister W32tm /register W23tm /dumpreg The first command will remove all w32time service registry keys and settings and unregister the w32time service. This effectively wipes all configuration from the machine. The second command will register the service and set it up with default settings ready for your configuration. The third command is useful for both documentation and reporting to PSS as it enables you to export the contents of the w32time registry key. To be honest though, I find it easier to use regedit to do this.

A final tip is that after any changes you should restart the w32time service

How to turn on debug logging:

In order to turn on debug logging you must create a location for the log. I would use c:\w32tmlog. Next open up regedit and make the following changes: Locate and then click the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Confi g On the Edit menu, click New Value, and then add the following registry values: Value Name: FileLogSize Data Type: DWORD Value data: 10000000 This registry value specifies the size of the log file in bytes.

Value name: FileLogName Data Type: String Value data: C:\w32tmlog\w32time.log This registry value specifies the location of the log file. The path is not fixed. You can

use a different path.

Value name: FileLogEntries Data Type: String Value: 0-116 This registry value specifies the level of detail of the information in the debug log. If you must have more detailed logging information, contact a Microsoft Support Professional. Note The Data Type value must be of type REG_SZ (String). You must type the value exactly as shown (that is, type 0-116). The highest possible value is 0-300 for most detailed logging. The meaning of this value is: Log all entries within the range of 0 and 116.

The information above has been taken from the following MS KB article: http://support.microsoft.com/kb/816043/

References
Below are some links to pages I found useful when researching this article. The http://technet2.microsoft.com/WindowsServer/en/library/a0fcd250-e5f7-41b3-b0e8240f8236e2101033.mspx?mfr=true How to configure the Windows Time Service against a large time offset: http://support.microsoft.com/kb/884776/ Registry entries for the W32Time Service: http://support.microsoft.com/kb/q223184/ How to configure Debug logging: http://support.microsoft.com/kb/816043/ How to configure and authoritative time server in Windows Server 2003: http://support.microsoft.com/kb/816042 http://labmice.techtarget.com/windows2000/timesynch.htm http://www.pool.ntp.org/