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:

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.

Nun kann man mit

w32tm /monitor

auf einem der DCs prüfen, welcher DC woher seine Zeit bekommt:

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:

Nach kurzer Zeit sollte die Uhrzeit dann wieder passen. Zur Sicherheit kann man dies nun noch einmal mit

w32tm /monitor

überprüfen:

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:

Sie kann entweder über die MSDN…

…oder das Microsoft Evaluation Center

heruntergeladen werden.

Das Evaluation Center ist hier zu finden: https://technet.microsoft.com/de-de/evalcenter/bb291020.aspx 

Viel Spaß damit!

Nun hat man im Wesentlichen 3 Optionen:

1. Meldung hinnehmen und von Hand auflösen – bedeutet u.U. sehr viel Aufwand
2. Meldung ignorieren oder gar mittels Override deaktivieren – löst aber nicht die Ursache auf
3. Meldung nutzen, um nicht nur die Meldung selbst (=Wirkung), sondern auch den Zustand (=Ursache) selbst aufzulösen

Die Möglichkeit, die Defragmentierung zu automatisieren ist auch im Wissensdantenbank-Artikel des Monitors erwähnt:

Wie das genau geht, hat Cameron Fuller, MVP für SCOM, in seinem Blogartikel beschrieben:

http://tinyurl.com/OMAutodefrag

Ein großartiger Artikel!

Update: Es gibt auch einen etwas einfacheren Weg – man kann das selbe Ziel auch mit einem einfachen Override erreichen, somit ist auch kein weiteres MP nötig… Wie genau das funktioniert, werde ich zeitnah nachreichen.

Zunächst einmal kann folgende Fehlermeldung auftauchen, die verschiedene Gründe haben könnte:

Mögliche Fehler:

• SSRS sind nicht installiert (trivial)
• Reporting Services Webdienst-URL ist nicht konfiguriert (Durchaus denkbar, direkt nach dem Setup)
• Keine SSRS-Datenbank angelegt (kann nach dem Setup auch gut möglich sein)
• Keine Berichts-Manager-URL konfiguriert (vor allem wenn noch keine Webdienst-URL gesetzt wurde normal)

Ob einer der Fehler vorliegt lässt sich recht einfach mit Hilfe des “Konfigurations-Manager für Reporting Services” prüfen:

Hier ist beispielsweise keine Webdienst-URL gesetzt (zweiter Fall):

Das Ganze sollte so aussehen (wenn dies erst gerade geschehen ist, sollte die rot markierte Meldung zu sehen sein):

Dritter Fall: Keine Datenbank. Das sieht dann so aus:

Durch einen Klick auf “Datenbank ändern” kann man mit Hilfe von “Neue Berichtsserver-Datenbank erstellen” und der Standardwerte eine neue DB samt TempDB anlegen. Das sollte am Ende so aussehen:

Vierter Fall: Berichts-Manager-URL ist noch nicht konfiguriert; sieht so aus:

Durch “Anwenden” lässt sich dies korrigieren und sieht danach so aus:

Zurück im Setup das SCOM2012R2 kann man nun erneut sein Glück versuchen, jedoch könnte nun folgender Fehler auftauchen, dessen Meldung man nur sieht, wenn man mit dem Mauszeiger über das rote Kreuz fährt:

Die Meldung ist zum Glück sehr aussagekräftig, so dass ein Blick in services.msc (Dienste) recht schnell Klarheit bringt:

Der SQL Agent Dienst sollte auf Autostart stehen und muss zum Zeitpunkt der Installation laufen, also so:

Das sind nun also die häufigsten Fehler und ihre eigentlich recht einfache Lösung; ich hoffe, das Ganze ist für die Problemlösung hilfreich.