Bei der Prüfung von SCOM-Warnungen fiel mir diese hier besonders ins Auge:
![ADTime0 ADTime0](https://www.hertes.net/wp-content/uploads/2016/02/ADTime0_thumb.png)
![ADTime1 ADTime1](https://www.hertes.net/wp-content/uploads/2016/02/ADTime1_thumb.png)
Die Meldung “The Time Skew latency is above the configured threshold” besagt im Wesentlichen, dass die Zeitdifferenz zwischen einem “normalen” DC und dem PDC-Emulator zu hoch ist, in diesem Fall bei 267 Sekunden liegt und damit über der Warnungs-Schwelle von 5 Sekunden. Und tatsächlich, die Server haben eine sichtbare Zeitdifferenz:
![ADTime2 ADTime2](https://www.hertes.net/wp-content/uploads/2016/02/ADTime2_thumb.png)
Nun ist es ja so, dass alle Server einer Domäne die Uhrzeit beim PDC-Emulator abholen – oder es zumindest sollten. Dieser wiederum sollte so konfiguriert sein, dass er die Zeit von einer gültigen externen Zeitquelle empfängt. Das erreicht man recht einfach mit folgenden Aufrufen:
w32tm.exe /config /manualpeerlist:”0.de.pool.ntp.org 1.de.pool.ntp.org 2.de.pool.ntp.org 3.de.pool.ntp.org” /syncfromflags:manual /reliable:YES /update
w32tm.exe /config /update
PS: Restart-Service w32time
Im festen Glauben, dass dies auch in meiner Umgebung so ist, habe ich dies dennoch gegengeprüft:
Der Aufruf
netdom query fsmo
liefert die Verteilung der FSMO-Rollen, u.a. erfährt man eben auch, welcher DC aktuell der PDC-Emulator ist.
![ADTime3 ADTime3](https://www.hertes.net/wp-content/uploads/2016/02/ADTime3_thumb.png)
Nun kann man mit
w32tm /monitor
auf einem der DCs prüfen, welcher DC woher seine Zeit bekommt:
![ADTime4 ADTime4](https://www.hertes.net/wp-content/uploads/2016/02/ADTime4_thumb.png)
Und siehe da – die beiden DCs, die nicht PDC-Emulator sind bekommen ihre Zeit von irgend einem Server “frei im Internet”. Dies kann z.B. daran liegen, dass diese DCs früher mal PDC-Emulator waren und daher noch auf die Synchronisierung mit einer externen Quelle eingestellt sind. Dies lässt sich sehr leicht auf den betreffenden DCs (also denjenigen, die kein PDC-Emulator mehr sind) beheben. Dazu ist lediglich der Aufruf
w32tm /config /syncfromflags:domhier /update
net stop w32time
net start w32time
notwendig:
![ADTime5 ADTime5](https://www.hertes.net/wp-content/uploads/2016/02/ADTime5_thumb.png)
Nach kurzer Zeit sollte die Uhrzeit dann wieder passen. Zur Sicherheit kann man dies nun noch einmal mit
w32tm /monitor
überprüfen:
![ADTime6 ADTime6](https://www.hertes.net/wp-content/uploads/2016/02/ADTime6_thumb.png)
Jetzt sieht man, dass die beiden ersten DCs (beide kein PDC-Emulator) von HVSRV10 (dem PDC-Emulator) synchronisieren und dieser wiederum von einer externen Zeitquelle (stammt aus dem NTP-Pool).
Nun stimmen auch die Zeiten aller DCs wieder überein:
![ADTime7 ADTime7](https://www.hertes.net/wp-content/uploads/2016/02/ADTime7_thumb.png)