Question Locked

Major Win32Time Issue - Time Sync

0 helpful
5 replies
Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

Hey all,

I'm a frequent reader and just recently started an account. I'm a new Sys. Admin for a startup company and it appears that some major windows time service issues are occurring. I've done about 6 hours worth of googling and searching on this forum and others. I have found several possible solutions but none seem to fix my problem.

I have a PDC whose time seems to offset itself by one day. This is obviously a problem because all the computers on the domain are now off by one day. I receive the following in the event log of the PDC:

Event Type: Warning
Event Source: w32time
Event Category: None
Event ID: 11
Date: 10/2/2007
Time: 8:02:34 PM
User: N/A
Computer:
Description:
The NTP server didn't respond
Data:
0000: 49 27 00 00 I'..

------

The message seems self explanatory. However, I have even tried to make the necessary registry settings to only allow the PDC to get its time from its internal hardware clock....and I still receive the error. I've also tried opening UDP port 123 on the firewall with no luck. I've also tried several well known external time sources.

Another interesting thing that I noticed is that 'net time' when run on the PDC is returning a value from another DC on the network. Is this expected? I would think that 'net time' should lookup the time from the PDC.

Please let me know of anything that I can provide to help troubleshoot this issue. I'm in a bit of a bind.

Thanks much guys!

5 replies

by sburk

PDC and DC are both Windows 2000.

I'm receiving this error in the event log occasionally on the DC(not PDC).

Event Type: Error
Event Source: w32time
Event Category: None
Event ID: 49
Date: 10/1/2007
Time: 1:02:13 PM
User: N/A
Computer:
Description:
An unexpected error occured while trying to start the server. The port may already be in use.
Data:
0000: 00 00 00 00 ....

----------------

Also, some other information that would be helpful to me would be the default registry settings for the PDC and the DC. Windows 2000.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Enum
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Security

by churdoo

Since the net time command returned the time from another DC on the network, I think THE OTHER DC is where the problem is. For whatever reason, and admittedly I'm not clear on what criteria determines which DC will be the SNTP server on a windows network, but clearly it's this other DC that has been elected the SNTP server for your AD, and therefore is where the problem lies.

Go to the other DC and check its timezone setting, logs for net time errors, Windows Time service, etc.

Then check
net time /querysntp
and set to a known good public source with
net time /setsntp:

make sure your firewall allows outbound port 123 (NTP) traffic.

by cg it

in a domain environment you can specify which DC will be the authoritative server for time that all other servers and clients sync with. Typically a server that has the PDC emulator role.

Here's a Technet article

http://technet2.microsoft.com/WindowsServer/en/library/71e76587-28f4-4272-a3d7-7f44ca50c0181033.mspx?mfr=true

There is a Windows Time Service white paper available that spells out the Windows Time Service service and what CLI commands to use.

Also see see this Help and Support article on how to configure an authoriative time server in Windows 2003 Server.

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

by sburk

Thanks guys. I ended up setting a couple of registry settings that seemed to clear up the issue. On the PDC:
LocalNTP=1
ReliableTimeSource=1. MaxAllowedClockErrInSecs=900 (15 minutes) Period=24.

I also specified four NTPServers to back eachother up. Be sure to specify by IP address otherwise windows 2000 will only go after the first NTP server listed.

Thanks for the help!

This discussion is closed to new replies.