Haikos Blog Blog von Haiko Hertes zu allen Themen rund um Microsoft und Datacenter

15Feb/160

AD Domänen Controller: Zeitdifferenz / Time Skew zum PDC-Emulator

Bei der Prüfung von SCOM-Warnungen fiel mir diese hier besonders ins Auge:

ADTime0

ADTime1

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

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

Nun kann man mit

w32tm /monitor

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

ADTime4

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

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

w32tm /monitor

überprüfen:

ADTime6

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

15Mai/140

SCOM 2012 R2 – Auto-Defragmentierung

Wenn man den Operations Manager 2012 nutzt, dann wird man vermutlich auch schon einmal über eine Meldung gestolpert sein, die darauf hinweist, dass ein logisches Laufwerk zu stark fragmentiert ist ("Fragmentierungsgrad des logischen Datenträgers ist hoch" / "Logical Disk Fragmentation Level is High"). Wenn man viele Server überwacht, dann wird man diese Meldung auch sehr oft sehen - ganz speziell am Montag Morgen (das liegt daran, dass die Standardeinstellung dieses Monitor dafür sorgt, dass der Test immer Samstag 03:00 Uhr läuft).

Defrag1

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:

Defrag2

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.

16Dez/130

SCOM: Probleme beim Setup von SCOM 2012 R2 – hier: Reporting Server

Die Installation von SCOM (System Center Operations Manager) 2012 R2 ist eigentlich nicht sehr schwer – jedoch gibt es einige potentielle “Stolpersteine”, wenn man die Reporting-Komponente nutzen möchte. Selbst bei installiertem SSRS (SQL Server Reporting Service) können diverse Fehler auftreten, die ich hier mit samt ihrer Lösung vorstellen möchte.

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

scom2012ssrs1

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):

scom2012ssrs2

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

scom2012ssrs3

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

scom2012ssrs4

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:

scom2012ssrs6

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

scom2012ssrs7

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

scom2012ssrs8

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:

scom2012ssrs9

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

scom2012ssrs10

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

scom2012ssrs11

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.