Problem: Synchronizing Time on 2k3 PDC with External Source

[Charlie.]

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

[Mr Snrub]

Try these commands:

w32tm /config /manualpeerlist:192.43.244.18,0x8 /syncfromflags:MANUAL
net stop w32time & net start w32time
w32tm /resync

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.

Edited February 8, 2006 by Mr Snrub

[cluberti]

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

Value: Type

Data: NTP

2. Configure the AnnounceFlags value:

Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config

Value: AnnounceFlags

Data: 5

3. Enable the NTP server value:

Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient

Value: Enabled

Data: 1

4. Specify the NTP server to use:

Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters

Value: NtpServer

Data: us.pool.ntp.org,0x1

5. Select the NTP polling interval:

Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient

Value: SpecialPollInterval

Data: 900

6. Configure the time correction settings:

Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config

Value: MaxPosPhaseCorrection

Radix: Decimal

Data: 3600

Key: HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Config

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.ude...tp/clock2a.html

[markajm]

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)

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.

[Charlie.]

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!

[Mr Snrub]

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?

[lamphax]

Hello,

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

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?

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.

[cluberti]

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!

[lamphax]

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.

[pepoluan]

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

[charlow]

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:

148251 03:17:37.5781250s - /-- NTP Packet:
148251 03:17:37.5781250s - | LeapIndicator: 3 - not synchronized;  VersionNumber: 3;  Mode: 4 - Server;  LiVnMode: 0xDC
148251 03:17:37.5781250s - | Stratum: 1 - primary reference (syncd by radio clock)
148251 03:17:37.5781250s - | Poll Interval: 4 - 16s;  Precision: -19 - 1.90735æs per tick
148251 03:17:37.5781250s - | RootDelay: 0x0000.0000s - unspecified;  RootDispersion: 0x0246.365Fs - 582.212s
148251 03:17:37.5781250s - | ReferenceClockIdentifier: 0x49524947 - source name: "IRIG"
148251 03:17:37.5781250s - | ReferenceTimestamp:   0x83AA7E8000000000148251 03:17:37.5781250s -  - 11644473600000000000ns - 134774 00:00:00.0000000s
148251 03:17:37.5781250s - | OriginateTimestamp:   0xC912345194000000148251 03:17:37.5781250s -  - 12808898257578125000ns - 148251 03:17:37.5781250s
148251 03:17:37.5781250s - | ReceiveTimestamp:	 0xC91234C472F86A09148251 03:17:37.5781250s -  - 12808898372449103000ns - 148251 03:19:32.4491030s
148251 03:17:37.5781250s - | TransmitTimestamp:	0xC91234C4732BB73D148251 03:17:37.5781250s -  - 12808898372449885800ns - 148251 03:19:32.4498858s
148251 03:17:37.5781250s - >-- Non-packet info:
148251 03:17:37.5781250s - | DestinationTimestamp: 148251 03:17:37.5781250s - 0xC912345194000000148251 03:17:37.5781250s -  - 12808898257578125000ns148251 03:17:37.5781250s -  - 148251 03:17:37.5781250s
148251 03:17:37.5781250s - | RoundtripDelay: -782800ns (0s)
148251 03:17:37.5781250s - | LocalClockOffset: 114871369400ns - 1:54.871369400s
148251 03:17:37.5781250s - \--

The next lines are:

148251 03:17:37.5781250s - Packet test 6 failed (not syncd or bad interval since last sync).
148251 03:17:37.5781250s - Packet test 8 failed (bad value for root delay or root dispersion).
148251 03:17:37.5781250s - Ignoring packet that failed tests from 10.13.3.30 (ntp.m|0x8|10.13.2.70:123->10.13.3.30:123).

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

[pepoluan]

"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:

adelie.eqlx.local *** PDC *** [192.168.6.1]:
	ICMP: 0ms delay.
	NTP: +0.0000000s offset from adelie.eqlx.local
		RefID: 'LOCL' [76.79.67.76]

Edited November 28, 2006 by pepoluan

[lamphax]

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

Windows_Time_and_the_W32TM_service.doc

Edited December 29, 2006 by lamphax

[gabrielpc]

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!

[youngi]

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