While checking the syslog messages around the times of the Internet disruptions at customer site, I found that the timestamp recorded by the ISA server sometimes did not match the timestamp recorded by the border router. After some digging, I found that the clock on the ISA server was extremely slow, and would get off by five minutes in a matter of hours. Since five minutes is the magic number before domain authentication fails, this made me concerned. [more]
I found that the ISA is set to synchronize time with the VMhost, and that the VMhost’s clock had not been properly set. It had a date of January 26 (on February 17). VMware time synchronization is a little funny, in that if the guest is behind the host then the guest’s time just gets updated, but if the guest is ahead of the host then the host slows the guests clock until the time gets synchronized again. Thus, the ISA server’s clock was slow because of the VMware time synchronization, and the native Win32Time process was correcting the problem periodically.
Our current best practice is to a) synchronize the VMhosts to public time servers, b) synchronize virtualized domain controllers to the VMhosts, and c) utilize native Win32Time to synchronize domain members.