0

We have a 2008 R2 domain spread over many sites around the world and have been using the built in w32tm service for quite some time. We have found that the times are inaccurate in the order of seconds between devices in the domain.
More importantly we have some devices (Cisco switches) mark the DCs time servers as insane and do not sync their time at all. Cisco states that insane is used rejects NTP servers with large offsets - however we , and others on the web have found that this is also done for the SNTP server in Windows 2xxx.

So we have begun experimenting with replacing the W32TM service with a real NTP service as this article from Microsoft implies this is allowed. I say implied as it doesn't specifically mention DCs but its an article on how the whole hierarchy works.

The Windows Time service (W32Time) can be completely disabled. If you choose to implement a third-party time synchronization product that uses NTP...

This avoids the need to re-point our clients

However we now get errors from DCdiag - Some we can probably say are false positive type results for example "A Time Service could not be located" and an expected result for this message "the 32Time service is disabled" However we also get in the Locator checks the message "The server holding the PDC Role is down"

So my questions are - has anyone done this sort of replacement , does anyone know if the PDC emulator actually relies on the W32Tm . Alternatively is there a better way to do this The alternative seems to me is to run a separate NTP hierarchy which has the problem of where do I put it and I then have two known different clock sources in the domain and have to re-point our clients, or wait to upgrade to 2016.

4
  • We have found that the times are inaccurate in the order of seconds between devices in the domain. - Yeah, the Windows time service isn't meant to be accurate withing a matter of seconds. Why is this an issue? More importantly we have some devices mark the DCs time servers as insane and do not sync their time at all. - What? What does that mean exactly?
    – joeqwerty
    May 15, 2017 at 4:22
  • Thats what the NTP client say - "Insane" -
    – Ross
    May 15, 2017 at 4:23
  • Yes it is clear that W32Tm is not meant to provide that accuracy and Microsoft agree and say you can replace it which is why I'm asking . The issue is some of end devices require more accurate time for what they do and so I'm trying to fix the Domain NTP hierarchy rather than create a new one. I'll clarify the insance as an edit
    – Ross
    May 15, 2017 at 4:30
  • Well I'll just add - if you replace it on the DCs it appears w32Time must be replaced everywhere. As w32Time cannot find a DC to sync with - ... seems obvious in retrospect
    – Ross
    May 15, 2017 at 23:15

3 Answers 3

1

I have some experience with this software. It is a porting of GNU NTP to Windows. It has successfully substituted the W32Time service of a windows server. Linux boxes and PCs with W32time are configured to take its sync source from that server without problems (I had a lot of them when linux boxes had to synchronize with the server with W32Time).

Substituing the native service with the new one is as easy as enable GNU NTP and disable W32Time

2
  • That is the software we were using - and your statement is correct it can be done - but you have to do them all - we have 500 machines all windows - so we decided changing the build on everyone was too onerous to maintain.
    – Ross
    Apr 30, 2020 at 22:00
  • We have about 500 Windows clients that use its own W32Time service, and about 200 Linux servers with GNU NTP. You "only" have to install the NTP build in the NTP servers (a hundred in our case) May 2, 2020 at 9:10
1

This is listed as a Known Cisco bug CSCed13703

http://www.cisco.com/c/en/us/support/docs/ip/network-time-protocol-ntp/108076-ntp-troubleshoot.html

Common Issues

Sync to W32 based time service (Most Windows Implimentations)

W32Time uses Simple Network Time Protocol (SNTP a subnet of NTP) for time synchronization. SNTP and NTP use the same network-packet format. The main difference between SNTP and NTP is that SNTP doesn't provide the error-check and filtering functions that NTP provides. Cisco router and switches use NTP and allow for all error-checking and filtering functions provided by NTP v3.

Known bug: CSCed13703 - NTP will not sync, flags server as insane, invalid

An IOS system may be unable to synchronize to an NTP server despite being able to transmit to and receive packets from the server. This may be seen with a Windows system running the w32time service.

"show ntp associations detail" will show that the server is flagged as "insane, invalid". The "root dispersion" value will be seen as being in excess of 1000 ms, which will cause the IOS NTP implementation to reject the association.

Workaround: Instead of running the w32time service on the Windows system, use NTP 4.x - refer http://www.eecis.udel.edu/~mills/ntp/html/hints/winnt.html

Note: The bug is Junked because the behavior is normal and actually cant be "resolved" as such. Another workaround can be use of SNTP since it's not concerned with root dispersion value, it is not recommended however.

http://www.cisco.com/c/en/us/support/docs/ip/network-time-protocol-ntp/108076-ntp-troubleshoot.html

Windows W32Time shows that it is an SNTP implementation inside (rather claiming itself NTP). Cisco IOS-NTP, which tries to sync with W32Time, gets its own root-dispersion value that it sends to the W32Time and this proves costly for Cisco IOS-NTP to synchronize. Because the root-dispersion value of Cisco IOS-NTP goes higher than 1000 ms, it unsynchronizes itself (clock-select procedure). Since the Cisco IOS based routers run the full RFC implementation of NTP they do not sync to an SNTP server. In this case the output of the show ntp associations detail command shows that the server is flagged as insane, invalid. The root dispersion value is in excess of 1000 ms, which causes the Cisco IOS NTP implementation to reject the association. Routers that run Cisco IOS can be unable to synchronize to an NTP server if it is a Windows system that runs the W32Time service. If the server is not synchronized, the routers are not able to transmit to and receive packets from the server.

In order to workaround this issue and sync a Cisco IOS based router, use an authoritative NTP server on the Internet, a UNIX box that runs NTPD or a GPS on certain platforms. As an alternative, you can choose not to run the W32Time service on the Windows system. Instead, you can use NTP 4.x. All versions of Windows 2000 and later can serve as an NTP server. Other machines on the network can then use the NTP server to synchronize their time.

I would suggest to configure the Cisco devices to sync with time.windows.com rather than implementing alternative NTP for the Windows domain in order to keep the switches happy...

1
  • Well no I can't - I don't want my 400 switches on three continents all being allowed out to the internet - through maybe 5 different internet gateways ... even if it is "just" for time. Still thanks for the link I knew I had read it - but google just would not put it in the top 2 answers.
    – Ross
    May 28, 2017 at 1:34
0

Replacing W32Tm on domain controllers means the domain looses the presence of 32TM servers advertising themselves as available - DCDiag will report errors and at least some of these errors are real so it is not possible to simply replace W32TM with a standards compliant NTP server.

Also all member servers must be reconfigured, this does wok but was onerous - I did not investigate manually simulating the advertisements to remove the need of configuring each client nor do we use DHCP so that was also not investigated, but is probably possible.

The alternative we have used is to deploy a parallel NTP time system - We reconfigured the domain controllers to use ALL clock sources (DOMHEIR and NTO) and added the local NTP systems with a flag of 8 to say use client mode.

The Domain controllers selects the local NTP sources rather than the domain as its time source and the measured jitter of the DCs has dropped from 500ms to 10ms.

initially we used a NTP hierarchy using orphan mode to handle disconnections then swapped to a set of hardware clocks. The behavior of the Windows domain was unchanged, although the long term jitter for the domain when using hardware clocks is yet to be verified.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .