Windows doesn't do NTP out-of-the-box (Microsoft assertions to the contrary notwithstanding). You can build a reasonably working standard daemon, however don't expect time to be very accurate. Windows out-of-the-box can keep time +/- 10 minutes or so using the Microsoft lets-pretend-NTP.
You can build the current standard NTPD distribution on Windows. You can also spend lots of time to make it "work as well as possible" (once you manage to get it to compile, that is). Even so, when you have configured it to the optimality of accuracy, this is what you can expect:
remote refid st t when poll reach delay offset jitter
Probably because they realize that in a Windows domain, their domain
controllers already provide a SNTP service with the Windows NT PDC
Emulator providing authoritative time for windows time service, and
all those windows servers can be enabled as a NTP server with a small
configuration change, and Windows Domain clients are required to
be synchronized with this using the Windows time service, as a
condition for Kerberos authentication and domain logon, for the
configuration to be a supported one.
So, given you already have those capabilities and those constraints...
how do you justify deploying another server for providing a separate
time service, running a new OS, instead of just using the same one
for all hosts?
In many cases it's not "Why use a windows time server" that has to
be justified;
the burden of proof is to answer the question "What can you say that
indicates you should definitely not use a windows time server for the
application?"
Many folks have more than just windows desktop PCs syncing their time.
If your application requires sub-5 second accuracy, (such as end of a
banking day), then Windows NTP is unsuitable for the purpose.
If your only objective is to sync the times on a bunch of user laptops so
they can get Kerbeos tickets within the 5 minute tolerance, it works fine.
For me, even a few seconds apart can be frustrating for comparing log files
between busy devices.
Your reason would be whether or not you fall inside or outside the
Microsoft guidelines below:
From Microsoft:
We do not guarantee and we do not support the accuracy of the W32Time
service between nodes on a network. The W32Time service is not a
full-featured NTP solution that meets time-sensitive application needs. The
W32Time service is primarily designed to do the following:
- Make the Kerberos version 5 authentication protocol work.
- Provide loose sync time for client computers.
The W32Time service cannot reliably maintain sync time to the range of 1 to
2 seconds. Such tolerances are outside the design specification of the
W32Time service.
That i've seen, Windows NTP in physical environments with a hardware
system clock not having issues consistently provides accuracy better
than +/- 0.5 against the time source it's synced with, but in
virtual environments, which have incompatibilities with high
sub-second RTC accuracy in the first place, neither Windows nor Unix
NTP services are able to provide that consistently without much
tinkering.
If it's absolutely critical that you have sub-5 second accuracy,
even Unix NTP is not to be considered good enough, you need highly
accurate hardware time source, something more accurate than the usual
system clock you find in a PC or server. Unix NTP can only do so much
to correct for a broken system clock; although it does do a very
good job disciplining PC real-time clocks that consistently run a bit
too fast or too slow, ultimately the
personal computer clocks can at times be unreliable....
If they were perfect, you wouldn't need time sync in the first place;
just set them once,
and correct the annual 0.01 seconds worth of error once a year....
