Time Sync Best (and Better, and Good) Practices

Don’t do these

  • Sync all your workstations, network devices and servers directly with a single public NTP server
    • This is an especially big problem for NIST and USNO
  • Sync hundreds of devices directly to the public NTP Pool - it’s run by volunteers at their own expense

Sourcing Good Time

If you’ve got the budget and need really excellent time and reliability, buy a couple GPS / CDMA time sources from Meinburg, etc. and use those for your time source. If you don’t need anything too fancy, find 2-3 physical boxes that can run a full-blown NTP implementation (not SNTP) like Juniper gear, Linux Box, Windows with the Meinburg NTP software or VMWare ESXi can sync to the NTP Pool.
Don’t source your time on a Virtual Machine, it will drift and be generally crazy
Disable any alternative time sync systems, like the one built into VMWare and run NTP/SNTP everywhere you can. This will get you the most consistent time with the fewest headaches.

Syncing Time

Sync all of your network equipment and domain controllers directly to the good time sources (if you have a physical DC, it’s fine for it to also be a good time source). Let your workstations and Windows servers sync to the domain controllers.

2 Likes

I have found that a lot of people don’t actually know how to configure DCs for time syncing from reliable sources. I have created a general guideline that will work from any Windows system in either CMD or PS, when run as administrator.

FIND TIME SERVERS

The best time servers that I’ve found (mentioned by @codatory) are members of pool.ntp.org. Go here to see the NA time servers, and browse around to find others for different areas or check out the propaganda.
http://www.pool.ntp.org/zone/north-america

If you’re in the US, specifically, this may be a better link: http://www.pool.ntp.org/zone/us

Those time servers (or more specific ones) will go inside the quotes below (eg. 0.us.pool.ntp.org,0x1…etc)

USING TIME SERVERS

I really don’t have as much of a problem using the time syncing in virtualization hosts as @codatory. I believe that as long as the hosts themselves are configured well, time syncing for guests is generally reliable. That being said, DCs should not sync with hosts if virtualized, and turning time syncing of VMs off in a domain environment may help avoid problems later (if the host can’t fetch time and starts to drift, it might not be the first thing on your mind when trying to figure out why a few clocks are different). Just note that there are certain guest situations when, as long as the host is set up to get time from a reliable source, I don’t think syncing to the guest is a bad thing at all.

DC CONFIG

w32tm /config /manualpeerlist:"0.us.pool.ntp.org,0x1 1.us.pool.ntp.org,0x1 2.us.pool.ntp.org,0x1 3.us.pool.ntp.org,0x1" /syncfromflags:MANUAL /reliable:YES
w32tm /config /update
net stop w32time
net start w32time
w32tm /resync /rediscover

DOMAIN JOINED DEVICE CONFIG

w32tm /config /syncfromflags:DOMHIER
w32tm /config /update
net stop w32time
net start w32time
w32tm /resync /rediscover

ESXi TIME CONFIG

After logging into the ESXi Server, go here:

From there, ensure this option is set:

And finally, make sure the pool servers are correct and up to date:

HYPER-V TIME CONFIG

If you run the following commands on the Hyper-V host (ASSUMING IT IS NOT RUNNING AD), your host will manually sync time, and not be vulnerable to any drift the domain may see (for whatever reason). Additionally, you could run this on your home PC. From an elevated CMD or PS window, run:

w32tm /config /manualpeerlist:"0.us.pool.ntp.org,0x1 1.us.pool.ntp.org,0x1 2.us.pool.ntp.org,0x1 3.us.pool.ntp.org,0x1" /syncfromflags:MANUAL /reliable:NO
w32tm /config /update
net stop w32time
net start w32time
w32tm /resync /rediscover

OTHER PLATFORMS

If you’d like something Debian/Cisco/whatever based, let me know. Remember, switches, phones, routers, HVAC, and everything else all like reliable and good time sources too!

FINAL THOUGHTS

GPS based time sources that run on your LAN are highly reliable, and can be set as primary with a failback to internet time. The larger concern is that, generally, the devices on your network share the same time. If it’s two seconds off from the absolute correct time, that’s fine.

A good time policy should be very ‘set it and forget it’ in nature. Don’t get too caught up and, generally speaking, be okay with a small amount of drift.

2 Likes