ProfessorI searched for this today because I found the above method is not sufficient. Why? Because the collector is required to be in the domain (generally) and with Windows, time flows through the domain from the PDC emulator. Does this check work? Yes, it tells you if the collector is skewed from the monitored server. Does it tell you if the time is correct? Nope. If the PDC emulator is not sync'ed, this check will happily tell you your offset is low/zero. What really is needed is a way to check time against an independent source. We ran into this yesterday when we were asked why a server showed skew. The answer was the target in this case was accurate and not in the domain, and the domain was skewed. I suppose a workaround would be to ensure the collector is getting time from NTP, not the domain, but this may not be feasible depending on group policy architecture.
Sorry, one more caveat -- forcing the collector to sync to NTP could break its domain membership since Kerberos will get wedged (or could). So really, this needs to be a different datasource that compares time not from the collector, but from one or more NTP sources.
