[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

[Sponsor]

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

This post has been edited by Mr Snrub: 08 February 2006 - 04:21 AM

[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]

Quote

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.eggheadca.../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.

Quote

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]

This post has been edited by pepoluan: 27 November 2006 - 09:34 PM

[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....6/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

Attached File(s)

•  Windows_Time_and_the_W32TM_service.doc (133.5K)
  Number of downloads: 10

This post has been edited by lamphax: 28 December 2006 - 07:02 PM

[gabrielpc]

lamphax, on Dec 28 2006, 02:56 PM, said:

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

[conic123]

lamphax, on Dec 28 2006, 07:56 PM, said:

For those who run into this issue...

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

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

...

Lamphax

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

[thydreamwalker]

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!!!

This post has been edited by thydreamwalker: 27 September 2008 - 02:50 AM

[anneb2]

All the above solutions still did not work for me. The policies were all set to "not configured". I tried to set them to "disabled", rebooted the machine, reset them to "not configured", rebooted, but to no avail.

Finally I found that policies get stored in the registry as well.

After renaming the following keys in :
\HKEY_LOCAL_MACHINE\SOFTWARE\POLICIES\MICROSOFT\W32TIME\

CONFIG to _CONFIG
PARAMETERS to _PARAMETERS
TIMEPROVIDERS to _TIMEPROVIDERS

and restarting w32time,

at last w32tm started reading the normal - documented - registry settings and this solved the problem for me as well.

( 8 hours wasted thanks to policy settings that do not appear in the policy editor or did I look in the wrong place?)

[tropolite]

I had to become a member of this forum - just to say a big THANKS to all that participated on this thread...

My problem was my PDCe continually bouncing back "The computer did not resync because no time data was available."

I spent literally hours scouring the web for solutions, finding great amounts of valuable information but this particular thread, I believe is the most helpful! My problem came down to the solution that annab2, so THANK YOU VERY MUCH - I sincerely appreciate everyone's time spent (no pun intended).

I have one question to add if I may... Our secondary DC is returning a NTP: error ERROR_TIMEOUT - no response from server in xxxxms. I have checked the registry settings to ensure that those pesky GPO inherited registry settings are removed, and checked that the DC is set in its default state, so it supposedly will sync automatically with the PDCe.

Running a w32tm /monitor command returns

C:\>w32tm /monitor
cde01.domainname.local *** PDC *** [xx.x.2.1]:
	ICMP: 589ms delay.
	NTP: +0.0000000s offset from cde01.domainname.local
		RefID: reptile.digitalriver.com.au [121.54.129.52]
abc01.domainname.local [xx.x.1.4]:
	ICMP: 0ms delay.
	NTP: error ERROR_TIMEOUT - no response from server in 1000ms

Appreciate any help on this related subject... thanks.

Cheers
tropolite

[tropolite]

Fortunately with a bit of persistance I was able to resolve the NTP: error ERROR_TIMEOUT - no response from server in 1000ms problem.

My solution -
On the secondary DC that was returning the error I;
- made sure that W32time service was running
- reset HKLM\System\CurrentControlSet\Services\W32Time\Parameters\NTPServer to time.windows.com,0x1
- reset HKLM\System\CurrentControlSet\Services\W32Time\Parameters\Type to NT5DS
- reset HKLM\System\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer\ Enabled is set to 1
- closed Regedit and in the command prompt ran - net stop w32time && net start w32time
- and lastly ran - w32tm /monitor which will confirm the PDCe and DC/s running (hopefully) correctly.

C:\>w32tm /monitor
cde01.domainname.local *** PDC ***[xx.x.2.1:123]:
	ICMP: 582ms delay
	NTP: +0.0000000s offset from cde01.domainname.local
		RefID: reptile.digitalriver.com.au [121.54.129.52]
		Stratum: 3
abc01.domainname.local *** PDC ***[xx.x.1.19:123]:
	ICMP: 0ms delay
	NTP: -0.0044411s offset from cde01.domainname.local
		RefID: cde01.domainname.local [xx.x.2.1]
		Stratum: 4

I hope this is somewhat helpful to others having similar issues...

Cheers
tropolite