I've never overridden the default behavior in a multi-site scenario and wouldn't generally recommend it...
Thanks, Brian Desmond br...@briandesmond.com c - 312.731.3132 Active Directory, 4th Ed - http://www.briandesmond.com/ad4/ Microsoft MVP - https://mvp.support.microsoft.com/profile/Brian -----Original Message----- From: Ben Scott [mailto:mailvor...@gmail.com] Sent: Friday, September 18, 2009 10:27 AM To: NT System Admin Issues Subject: Re: Why is Windows Time service crap? On Fri, Sep 18, 2009 at 10:36 AM, <richardmccl...@aspca.org> wrote: > 1. With multiple domain controllers, does one pick one of them, sync > to an outside time source, then somehow point the other DCs to this DC? As I recall: The DC holding the PDC emulator FSMO role should be the root time source for the entire AD forest. By default, all other DCs should automatically use that DC for time, and all members should automatically use to whatever DC they're using for everything else AD. If you've got multiple sites -- especially if you've got tiered sites -- you may want to override the default behavior. Have DCs at HQ use PDC emulator, DCs at second tier sites use HQ DCs, DCs at third tier sites feeding off second tier DCs, etc. You generally want a hierarchy within your organization, with a single master time source. You can manually maintain that master, or have it sync to outside time servers. I have found the Windows Time service to be somewhat easily perturbed. Our DC used to be set to sync directly to outside stratum two time servers. The time service would log errors and warnings all the time. I put an NTP Project ntpd server on our network, pointed the DC at that, pointed ntpd at the outside world, and all the DC trouble went away. The clients, pointing at the DC, still sometimes give warnings and errors. YMMV. (NTP Project is the reference implementation of NTP. http://www.ntp.org/ Free Software.) > 2. Why do servers and workstations drift off, time-wise? How to stop this? The most common causes are: (1) Failed or marginal battery for the Real Time Clock. When the system (re)boots, it gets system time from the RTC, so if the RTC is wacky you have trouble then. With practically every patch MSFT releases needing a reboot, even servers can expect to reboot often in Windows-land. (2) High interrupt load. Once booted, system time is advanced by interrupts generated by a hardware timer (the IRQ0 system timer by default). If the system is busy servicing other interrupts when the timer interrupt fires, it can miss clock ticks. Be aware that if time is out-of-tolerance by more than a certain amount (5 minutes? an hour? I forget), the time service won't adjust the system time. Radical changes in the system time tend to confuse lots of things (people and programs alike), so it leaves it up to you. -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
