In a large scale computing environment accurate time becomes a constant battle. Systems across multiple data centers must interact with each other, and often those systems rely on each servers time interpretation for transactions. Accurate time is a must, and unfortunately in Windows environment accurate time is not an easy task.
In Microsoft’s flawed NTP implementation administrators rely on time sync within their Active Directory domains. Each Active Directory forest contains a PDC Emulator, which amongst other things serves as a source of accurate time for the forest. PDC emulators in other domains within the forest will sync to the root domain’s PDC emulator. Domain members then sync their own clock every 8 hours. Often this set it and forget it mentality works, but often enough it doesn’t. The reason for this is that Microsoft in their infinite wisdom did not implement the full network time protocol (NTP), but instead implemented a subset of the full standard which they call Windows Time (aka W32TM).
W32TM works well in small-scale single data center environments, but it fails to scale out to large multi-site environments, while still retaining the necessary accuracy applications often demand. W32TM was designed to keep system clocks accurate enough for Kerberos to function within an Active Directory forest, but was never built for truly accurate time. For Kerberos to function in Active Directory the time of systems only has to be within 5 minutes of the Domain Controller, which is far from accurate, thus why they can get away with an every 8 hour sync. The problem is so bad that Microsoft actually admits in a MSDN article that W32TM shouldn’t be used if true time accuracy is needed:
“The W32Time service is not a full-featured NTP solution that meets time-sensitive application needs and is not supported by Microsoft as such”
W32TM is prone to inaccuracy when used across high latency network links and fails to function accurately when the individual systems become heavily taxed. The use of a single AD Forest PDC system as the time source for an organization is perhaps the largest flaw within the system. With systems spanning across multiple data centers, all time requests must travel over WAN links to the PDC emulator. Whether they be ISDN or 10GB Ethernet these links introduce significant latency that Windows Time was not designed to compensate for.
For those that require accurate time on their Windows systems it is possible to run a fully compliant NTP client on Windows system. Meinburg, a German company that develops hardware for highly accurate time keeping, has developed a simple yet effective NTP client for Windows. It runs as a service and doesn’t have any odd prerequisites like you might find in applications that make it from the *nix world to the Windows world.
Meinburg NTP can either be installed via the GUI installer or in a more automated fashion with an installer config file and the command line. I’ve used the command line configuration to add Windows NTP support to the Opscode Chef NTP recipe. I’m putting the finishing touches on this Chef recipe and hopefully it will make it into the upstream NTP cookbook release soon. For those of you that want to automate the installation either via PowerShell or via your WDS deployment processes here’s how to setup a simple command line install:
1) Download the client Meinburg NTP client from http://www.meinberg.de/english/sw/ntp.htm
2) Create a ntp.conf file for your clients. This is the same format as NTP conf files in *nix so you can simply copy this from one of your *nix systems. Here’s my sample config
server ntp.datacenter1.dmz iburst
server ntp.datacenter2.dmz iburst
server ntp.datacenter3.dmz iburst
server ntp.datacenter4.dmz iburst
restrict default nomodify notrap noquery
3) Create a file called ntp.ini. This is what you will pass the installer to define your installation. Here’s my sample config:
Keep in mind that I have enabled AllowBigInitialTimestep so if the system is off by a day the clock is going to jump all at once. I’m ok with this, but it might not be acceptable in your environment. Use caution.
4) Pass the ntp.ini file to the installer to silently install: email@example.com /USEFILE=\\SERVER\path\to\config\ntp.ini
5) Confirm the the installation and NTP status by running C:\NTP\bin\ntpstatus.bat