--- SOLVED SEE EDIT 5 ---
My w2k3 pdc is configured as an authoritative time server. Other servers on the domain are able to sync with it if I manually specify it in the peer list. By if I try to sync from flags 'domhier', it wont resync; I get the error message
The computer did not resync because no time data was available.
I can only think that it is not querying the pdc. I also tried setting the registry as shown here (http://support.microsoft.com/kb/193825). But no luck (I have not restarted the server, I am hoping I wont have to since it is the pdc)
If you would like any further information on my config, please let me know.
Edit 1:
I have set the w32time service config AnnouceFlags to 0x05 as documented here www.krr.org/microsoft/authoritative_time_servers.php and a number of other places. The PDC syncs to an external time source (ntp).
I can get the stripchart on the client from the pdc no problems.
The loginserver for the host I am trying to configure is shown as the pdc.
Edit 2:
The packet capture has revealed something interesting. The client is contacting the correct server, and getting a valid response but I still get the same error message.
Here is the NTP excerpt from the client to the server
Flags:
11.. .... = Leap Indicator: alarm condition (clock not synchronized) (3)
..01 1... = Version number: NTP Version 3 (3)
.... .011 = Mode: client (3)
Peer Clock Stratum: unspecified or unavailable (0)
Peer Polling Interval: 10 (1024 sec)
Peer Clock Precision: 0.015625 sec
Root Delay: 0.0000 sec
Root Dispersion: 1.0156 sec
Reference Clock ID: NULL
Reference Clock Update Time: Sep 1, 2010 05:29:39.8170 UTC
Originate Time Stamp: NULL
Receive Time Stamp: NULL
Transmit Time Stamp: Nov 8, 2010 01:44:44.1450 UTC
Key ID: DC080000
Here is the reply NTP excerpt from the server to the client
Flags: 0x1c
00.. .... = Leap Indicator: no warning (0)
..01 1... = Version number: NTP Version 3 (3)
.... .100 = Mode: server (4)
Peer Clock Stratum: secondary reference (3)
Peer Polling Interval: 10 (1024 sec)
Peer Clock Precision: 0.00001 sec
Root Delay: 0.1484 sec
Root Dispersion: 0.1060 sec
Reference Clock ID: 192.189.54.17
Reference Clock Update Time: Nov 8,2010 01:18:04.6223 UTC
Originate Time Stamp: Nov 8, 2010 01:44:44.1450 UTC
Receive Time Stamp: Nov 8, 2010 01:46:44.1975 UTC
Transmit Time Stamp: Nov 8, 2010 01:46:44.1975 UTC
Key ID: 00000000
Edit 3:
dumpreg for paramters on pdc
Value Name Value Type Value Data
------------------------------------------------------------------------
ServiceMain REG_SZ SvchostEntry_W32Time
ServiceDll REG_EXPAND_SZ C:\WINDOWS\system32\w32time.dll
NtpServer REG_SZ bhvmmgt01.domain.com,0x1
Type REG_SZ AllSync
and config
Value Name Value Type Value Data
--------------------------------------------------------------------------
LastClockRate REG_DWORD 156249
MinClockRate REG_DWORD 155860
MaxClockRate REG_DWORD 156640
FrequencyCorrectRate REG_DWORD 4
PollAdjustFactor REG_DWORD 5
LargePhaseOffset REG_DWORD 50000000
SpikeWatchPeriod REG_DWORD 900
HoldPeriod REG_DWORD 5
LocalClockDispersion REG_DWORD 10
EventLogFlags REG_DWORD 2
PhaseCorrectRate REG_DWORD 7
MinPollInterval REG_DWORD 6
MaxPollInterval REG_DWORD 10
UpdateInterval REG_DWORD 100
MaxNegPhaseCorrection REG_DWORD -1
MaxPosPhaseCorrection REG_DWORD -1
AnnounceFlags REG_DWORD 5
MaxAllowedPhaseOffset REG_DWORD 300
FileLogSize REG_DWORD 10000000
FileLogName REG_SZ C:\Windows\Temp\w32time.log
FileLogEntries REG_SZ 0-300
Edit 4:
Here are some notables from the ntp log file on the pdc.
ReadConfig: failed. Use default one 'TimeJumpAuditOffset'=0x00007080
DomainHierachy: we are now the domain root.
ClockDispln: we're a reliable time service with no time source: LS: 0, TN: 864000000000, WAIT: 86400000
Edit 5:
F&^%ING SOLVED! Ok so I was reading about people with similar problems, some mentioned w32time server settings applied by GPO, but I tested this early on and there were no settings applied to this service by gpo. Others said that the reporting software may not be picking up some old gpo settings applied. So I searched the registry for all w32time instaces. I came across an interesting key that indicated there may be some other ntp software running on the server. Sure enough, I look through the installed software list and there the little F*&%ER is. Uninstalled and now working like a dream.
FFFFFFFUUUUUUUUUUUU
I always follow this setup, never had any issues.
On the PDC for the Domain:
w32tm /config /manualpeerlist: "peers" /syncfromflags:manual /reliable:yes /updateGet peers from here.
On all the servers and in login scripts (or you can use Group Policy):
w32tm /config /syncfromflags:domhier /updateNet Stop w32tmNet Start w32tmReference:
Configure w32tm on PDC: Microsoft Technet
Configure w32tm on computers: Microsoft Technet
Check that your PDC has a valid external time source. If not, it may be flagging itself as 'unreliable' and clients may back off.
Also check that you can run w32tm /stripchard /computer:yourdcnamehere from a client and receive a valid response.
Lastly, the domain time sync heirachy isn't consistently documented by microsoft, but I believe your clients will checking in with their logon server for time sync. That may or may not be the PDC depending on your topology. So verify on the clients that doing a echo %logonserver% returns the PDC's name.
BTW, as of 2003 and XP, you're dealing with a full NTP implementation rather than the stripped-down 2000-and-earlier SNTP. net time is deprecated and w32tm should be used for configuration. Again, this isn't clearly documented IMO.
Ok so I was reading about people with similar problems, some mentioned w32time server settings applied by GPO, but I tested this early on and there were no settings applied to this service by gpo. Others said that the reporting software may not be picking up some old gpo settings applied. So I searched the registry for all w32time instaces. I came across an interesting key that indicated there may be some other ntp software running on the server. Sure enough, I look through the installed software list and there the little F*&%ER is. Uninstalled and now working like a dream.