This works great for Windows/AD, but may (is) insufficient for many applicaiton server environments.
App servers often need tighter sync of time than what is provided by the native W32Time service. W32Time has an accuracy within a subnet of +/-2 seconds, compared to +/-0.002 seconds for (s)NTP.
Many enterprise environments employ a master time server (NOT the PDCe)that syncs to a trusted source (*.pool.ntp.org or GPS). This runs (s)ntp service, which the PDCe syncs to, along with at least two secondary NTP servers. BDCs sync with the PDCe, and workstations sync with DCs, all using W32Time. The app servers, however, (Windows, Unix, etc) utilize an NTP service and sync with the secondary NTP servers. The master time server is configured to "lie" about its sync condition - it always reports "in sync".
In this fashion, all AD DCs and clients remain in sync with no additional configuration and app servers remain in sync via the NTP servers. With all secondary (PDCe and NTP) time servers getting time from an internal master, your entire environment will stay in sync.
I worked at a place that did not employ the "always report synced" setting on their master server. When it lost connection to the external time source for a few hours, it reported "not synced", so the remaining systems chose not to trust it and switched to internal clocks. The resulting drift in 3 "real" hours caused a nearly 21 hour difference between two critical sysetms. What's worse, is that when the master server reconnected to the time source, it was only about 4 seconds out of sync. The massive time swings could have been avoided by using a single internal master time server that was configured to always be authoritative.
Glenn
_________________________
Actually I
am a Rocket Scientist!
