I have Windows 2003 server (SP1) standard edition running on my domain controller. At the moment, all the domain clients synchronize their local times with this PDC with no problems. The time on the domain controller, however, is not accurate. I am trying to get it to synchronize with an external time server: time.nist.gov.

I started off following the instructions in this article:
http://support.microsoft.com/kb/816042
They don't work.

When you run the command: w32tm /resync, you receive the error: "The computer did not resync because no time data was available." A warning is also posted to the event log: "Time Provider NtpClient: This machine is configured to use the domain hierarchy to determine its time source, but it is the PDC emulator..."

Digging on the web, I found only more and more articles either repeating the steps from the Microsoft article or stating similar problems, with no solutions, to mine.

Firstly, let me declare the obvious: port 123 (SNTP) was forwarded to my domain controllers IP, both TCP and UDP, on my ADSL router. (NAT)

I tried my silver-bullet: unregister w32time and start again. I created the following batch script:

net stop w32time

w32tm /unregister
w32tm /register

w32tm /config /manualpeerlist:192.43.244.18 /syncfromflags:MANUAL /reliable:YES

net start w32time

w32tm /config /update

w32tm /resync /rediscover

The first line stops the NT service. You then unregister it and re-register it, recreating all the registry keys with default values, giving you a standard starting point. After that, I configure it, specifying an NTP server's ip address as a peer (this IP is time.nist.gov) and that it should synch from the manual peer list. I also mark this server as a reliable time server. I then start the service again, tell it to update its configuration, just in case, and then resync.

You guessed it, same error in the command line ("no time data was available") and same warning in the system event log! Argh!

I have to ask the question: Does w32time actually work on windows 2003?

Has anyone got any insight into this problem? There must be a solution, I am sure that the vast majority of admins would like their network to have accurate time!

Thanks,
Stephen Martindale

Try these commands:


If that does't work, try time.windows.com to see if you get a different result: 207.46.130.100

If it continues to have a problem, I would take a network trace on the DC and capture the traffic while it tries a resync and see what requests & responses are on the wire.


Edit:
Checked this last night - set up a Windows 2003 R2 Server, configured as a DC in a new forest, saw the complaints about w32tm not being configured and ran the 3 commands above - w32tm is now happily getting time from time.nist.gov.

You have to be very sure you followed the instructions for using an external time source correctly. I've used these instructions on many a 2K3 server without issue, so to recap:

1. Change Windows to use the NTP protocol for time synchronization:
Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\Type
Value: Type
Data: NTP

2. Configure the AnnounceFlags value:
Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config\AnnounceFlags
Value: AnnounceFlags
Data: 5

3. Enable the NTP server value:
Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer
Value: Enabled
Data: 1

4. Specify the NTP server to use:
Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\NtpServer
Value: NtpServer
Data: time.nist.gov,0x1

5. Select the NTP polling interval:
Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient\SpecialPollInterval
Value: SpecialPollInterval
Data: 900

6. Configure the time correction settings:
Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config\MaxPosPhaseCorrection
Value: MaxPosPhaseCorrection
Radix: Decimal
Data: 3600

Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config\MaxNegPhaseCorrection
Value: MaxNegPhaseCorrection
Radix: Decimal
Data: 3600


After this, stopping and restarting the NTP service should get you working. If it does not, check the value configured in step 4 - this being misconfigured is the only time I've seen errors in the Windows Time service like the ones you've posted, so it's possible this is incorrect in your registry. I would also suggest using a time server OTHER than time.nist.gov, as it is a VERY busy time server and you are likely to miss one or two time syncs to it before you get a good one. I would suggest using another time server, preferrably a stratum-2 NTP server closer to you. You can find these listed here:
http://www.eecis.udel.edu/~mills/ntp/clock2a.html

One other obvious one you didn't mention... have you added a policy allowing port 123 to ISA/other firewall software (if you are running any... )??

I had to do it on my 2k3 SBS server (ISA firewall) to get it working.

Thanks for the replies, but nothing is working so far.

Firstly, I tried Snrub's suggestion. With time.nist.gov, ntp2a.mcc.ac.uk and ntp2b.mcc.ac.uk. No joy. (I had tried this before too) (I can ping all domains with no problems)

I also tried cluberti's suggestion, with all three domains above.

I checked on my router, UDP port 123 is forwarded to the correct IP. I don't run any other firewall or proxy software anywhere.

I even tried installing an NTP server daemon on my linux box. The linux server gets NTP data perfectly, and runs the NTP daemon perfectly. Configuring my Windows 2003 server to use that as the time server fails. Once again, "The computer did not resync because no time data was available"

I am clearly not the only one experiencing this unsolveable problem. Here is a URL to what looks like a e-mail conversation with Microsoft support with the identical problem. No solution was reached.

http://www.eggheadcafe.com/ng/microsoft.pu.../post358908.asp

This is really pathetic. SNTP is supposed to be Simple - i.e. it just works. It does 'just work' on my Linux server, and non-domain Windows XP workstations, but not my Windows 2003 Domain controller. I have spent HOURS searching and found nothing so far!

My DC is running Windows 2003 SP1, NOT R2.

Please HELP!

What's the version of %systemroot%\system32\drivers\tcpip.sys on the DC?

(Just to rule out an MS05-019 v1 / KB898060 issue.)

Did you take a network trace while trying a /resync?

Hello,

I am resurecting this post because it seams to be the closest anyone has been to a resolution for this problem.



tcpip.sys is version 5.2.3790.2709

As my trouble is to the letter the same as the first post, I would like to pick up where Charlie left off and do a trace but I am not sure how to do that; can someone explain?

The output of w32tm /monitor from a client machine seems to show that all of my "BDC's" are synced to the PDC but the PDC is synced to its own internal clock:

C:\>w32tm /monitor
dc4.mydomain.com [172.16.2.5]:
ICMP: 8ms delay.
NTP: +0.0033296s offset from dc1.mydomain.com
RefID: dc1.mydomain.com [10.1.1.1]
dc3.mydomain.com [10.1.1.17]:
ICMP: 0ms delay.
NTP: -0.0384710s offset from dc1.mydomain.com
RefID: dc1.mydomain.com [10.1.1.1]
dc2.mydomain.com [10.1.1.23]:
ICMP: 0ms delay.
NTP: -0.0175720s offset from dc1.mydomain.com
RefID: dc1.mydomain.com [10.1.1.1]
dc1.mydomain.com *** PDC *** [10.1.1.1]:
ICMP: 0ms delay.
NTP: +0.0000000s offset from dc1.mydomain.com
RefID: 'LOCL' [76.79.67.76] <-- shouldn't this be the IP of my time server time.mydomain.com [10.1.1.67]

Thanks in advance for suggestions.

First, time.nist.gov is not a great place to sync your time unless you are required to do so - it's slow when not busy, and when it is the time server is sometimes inaccessible due to the fact that it's one of the only well-known internet time servers out there. Consider using pool.ntp.org instead - it'll use a local time server, and theoretically they are load-balanced and you will use a relatively responsive and underused one every time you check. I've found time on all of the AD domains I've been a part of has been much better and more reliable since switching from random time servers to the pool:

http://www.pool.ntp.org

Also, I've rarely run into the problems you appear to be seeing after making the previously mentioned registry changes and restarting the time service (although sometimes rebooting can clear it up on a finnicky server). Make absolutely certain that the machine you're on is indeed the PDCE!

Ok I will schedule the reboot Monday and see if that helps, I need a good laugh so I sure hope this works LOL. Thanks for the reply and have a good weekend.

Well, call me lazy or whatever, I personally use the free SymmTime utility, mostly because it can also show the local, UTC, Tokyo, and NY times simultaneously (needed for stock market, you know).

Seems like this topic is going for a while. I found it by looking for problem/solution that I am having. I have read the various articles, each helped a little, but not all the way. A great piece of info can come from the w32time logging facility. This can be turned on by setting a few registry entries then restarting the service. This document talks alot about the service and at the end shows how to turn it on. I am going to try the utility it has a link to in case it might help.

My main problem is that I have a hardware clock on on our local network that has a GPS input, but the GPS hardware isn't connected yet, only the internal clock is set. Right now, the PDC seems to get the NTP response, but doesn't like it.. Here's the packet from the log file:


The next lines are:


I noticed that the Leap Indicator is 3, which is "not syncronized", which could cause the problem..

Just putting this info out in case it helps others, and if others have seen my problem. Also does anybody know what the NTP response field "LiVnMode: 0xDC" means? Doesn't show up in docs that I 've seen for NTP packet definitions

"LiVnMode: 0xDC" -- that's the 8-bit representative of the first line:

0xDC = 11 011 100
- 11 = Leap Indicator (3)
- 011 = Version (3)
- 100 = Mode (4)

Or, syntactically, LiVnMode:
- Li = Leap Indicator
- Vn = Version Number
- Mode = Mode



Edit: I think test 6 & 8 failures may be caused by too much a difference between the NTP client time with the NTP server time.

Edit2: @lamphax, I also get the same result:

For those who run into this issue...

My problem was solved by reading the diagnostic steps in the article referenced by Charlow:

http://www.mmmug.co.uk/files/216/download.aspx

Step Number 15 on Page 13:

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”.


Sure enough, the first two entries where set to "Enabled" and after setting them to "Not Configured" and restarting the time service all was well and time was synced.

Thank you very much to all who responded to this thread.

Lamphax

You are awesome! I have been banging my head against the wall for MONTHS - i've poured over the registry and verified the settigns were correct at least 50 times, I thought I was crazy!

Sure enough, I too had settings enabled in group policy, i removed them, did a gpupdate and literally it started right up. It synced correctly to my sources.

Why is it human nature to always overlook the simple obvious things?

Thank you again!

this is fantastic, group policy was my issue as well and fixed it right away. You don't need to explicitly open up your firewall for port 123 since most firewalls are smart enough to let in traffic that have been sent out on the originating port. All my reg settings were right except that they did not take precedence since group policy was enforcing something different.

thanks to all that helped.

-Isaac

Thank you so much! I too have spent months trying to find the solution to this problem. I too have been through all of the registry settings dozens of times. I caught a lot of grief for the time becoming 'off'.

I was especially confused because I even tried using 'atomic clock' programs and they returned the same error as the Windows Time Service. I knew it couldn't be that UDP port 123 was blocked because other DC's and workstations were able to run the atomic.exe program with no problems. It was a real head scratcher.

Most of my policy setting were correct, but one was wrong. I changed it and rebooted my PDC. I went back through all of the registry and w32tm settings one more time just to make sure they were correct. Everything works now.

Thanks for sticking with this problem and finding a solution. I really appreciate your help!

Conic

Neutron ,http://keir.net/ is a time sync file for W2K,XP,98SE,Vista includes atomic time sync too.*Another is Atomictime.exe, <http://worldtimeserver.com/>

=cool program too!!!