To keep your Windows XP computers synchronized with the domain controllers, Windows uses a service called the Windows Time Service.
But have you ever noticed that the time on any two given XP systems tends to be completely out of sync, even though the two systems are joined into the same domain?
Of course, you made sure each PC's CMOS battery was good, you unregistered/reregistered the w32time service to try and correct it, you verified that the workstations can connect to a Domain Controller (DC) and that they can sync using the commands: w32tm /resync or NET TIME /SET.
Doing any of all of these may have gotten the time to sync that one time, but after a while your systems still tend to fall out of synchronization with one another. And this really irritates you, because you went through all the work in getting your DC (PDC emulator) to synch with an external time source (firewall UDP port 123 open, Group Policy is configured correctly so your client PCs call to your DCs for their time, you can ping the external Network Time Protocol (NTP) server and you know that it allows client requests) so everyone has "atomic clock" synchronized time.
Here is a little disappointing history on the Windows Time Service (W32time):
- W32Time meets the requirements specified by the Kerberos authentication protocol to provide clock values that are "loosely synchronized" across a network. According to a Microsoft white paper, the
- Windows Time Service "is not designed for use by applications that require greater precision."
- Software such as anti-virus, power management, screen savers and apparently any program that can cause the system to delay can cause time loss issues. On average, you can expect to lose upwards of 30 seconds to a full minute per week.
- If that is not shocking enough, wait to you see the default synchronization time strategy Microsoft employed with XP, which from what I gather is using roughly the same Basic Operation as it did with Windows 2000.
To summarize, in a domain:
- The client boots and pulls time from its BIOS.
- The client syncs time with the domain controller.
- The client attempts to synch successfully every 45 minutes, for three consecutive times. If it is successful, the client changes the sync period to every eight hours!
Now here's the kicker: In Windows 2000 you could at least change the above sequence somewhat so that the client polls the time more often. But it seems that Microsoft has removed that functionality from XP's version of w32tm.
Sure, you have options. You could:
- set up a scheduled job (with local admin privileges) on all the PCs to perform the following
command to resync with the domain controller:
net stop w32time && net start w32time && w32tm /resync /rediscover
- set up all your XP clients to get their time from an internal or external NTP time source that you set up manually (using a manual peer list) and then set up a SpecialPollInterval with how often you wish to sync.
- purchase a third-party time sync utility, such as this one from Beaglesoft, to install on all of your computers.
- purchase an NTP hardware clock, install it on your network and configure all your systems to connect to it for time.
But wouldn't it be nice if Microsoft decided that its Advanced Operating System could be configured either via group policy or a GUI to keep the time more in sync when your systems are apart of a domain? Rather than forcing you to work around the issue using Registry hacks and manual peer lists, NTP hardware, third-party utilities, etc.? Or how about not losing time when your system is working harder than normal? I guess this is just too much to ask. However, it's still worth your while to read what Microsoft has to say about configuring Windows Time Service.
But if anyone has a hack for this, or if I'm off base, please let me know! I hate paying money to correct a feature within Windows. And I am now officially off my soapbox.
Addendum to tip
After this tip appeared, SearchWinComputing member Kevin K. emailed me to suggest another option: setting a special polling interval via Group Policy. Here are the settings you'll need to apply this GPO to your users' desktop computers:
- Client Computer GPO
- System/Windows Time Service/Time Providers -Policy Setting -Configure Windows NTP Client: Enabled -NtpServer time.windows.com,0x1
- Type: NTP (default is NT5DS for default domain synch)
- CrossSiteSyncFlags: 1 (ignored since type is set to NTP)
- ResolvePeerBackoffMinutes: 10 (Specifies the initial interval to wait, in minutes, before attempting to locate a peer to synchronize with.)
- ResolvePeerBackoffMaxTimes: 7 (Specifies the maximum number of times to double the wait interval when repeated attempts fail to locate a peer to synchronize with.)
- SpecialPollInterval: 2400 (Specifies the special poll interval in seconds for peers that have been configured manually.)
- EventLogFlags: 0
Then, for Policy Setting, you'll need to select Enable Windows NTP Client Enabled.
About the author: Tim Fenner(MCSE, MCSA: Messaging, Network+ and A+) is a senior systems administrator who oversees a Microsoft Windows, Exchange and Office environment, as well as an independent consultant who specializes in the design, implementation and management of Windows networks.
More information on this topic:
- Tip: Can
users log on to a domain when a system clock is desynchronized?
- Topics: Windows
- RSS: Sign up for our RSS feed to receive expert advice every day.
This was first published in November 2006