Im DNS 2003 Version 6.0.6480.0 existiert ein Fehler. In der Standardeinstellung wird ein Fehler bei der externen DNS Auflösung gemeldet (“DNS 2003 Server External Addresses Resolution Alert”).
Ursache ist ein fehlerhafte Zieladresse. Es wird versucht einen Namenservereintrag (NS) für www.microsoft.com zu ermitteln. Der korrekte Nameserver wäre microsoft.com. www.microsoft.com ist nur ein Ressourcen Eintrag (A Record). Als Lösung sollte man somit den Alarm überschreiben und entweder den Typ auf A ändern oder die Adresse auf microsoft.com (oder irgend eine andere) und den Typ auf NS lassen.
Does anyone need an english version of the instruction? Then just post a comment.
In Absprache mit meinem früheren Chef habe ich den bereits vor längerer Zeit versprochenen SCOM2Nagios Connector aufgeräumt und in eine releasefähige Version verpackt.
Ich stelle ihn hiermit unter die GPL. Lizenzinformationen sind mit im Zip File enthalten.
Ein Wort der Warnung: Obwohl diese Version des Programms bei meinem früheren Arbeitgeber bereits im produktiven Umfeld lief, sollte er natürlich vorher ausgiebig in einer Testumgebung ausprobiert werden.
Die aktuell vorliegende Dokumentation ist sehr rudimentär und beschreibt hauptsächlich die (relative komplexe) Installation. Voraussetzung ist ein aktuelles .Net Framework, dass auch für den OpsMgr notwendig ist. Detailiertere Informationen müssen momentan noch aus dem mitgelieferten Quellcode entnommen werden.
Bei Rückfragen stehe ich natürlich über diese Webseite zur Verfügung (ohne Anspruch auf eine schnelle Reaktion).
Die Zip-Datei mit allen Informationen ist unter scc-scom2nagios_v10 zu finden.
Zeitweise stieg die Datenbankgröße des OpsMgr extrem schnell an. Um herauszufinden, woher dieses ungewöhnliche Verhalten kam, wollte ich ein Liste aller Alerts mit deren Summe des Auftretens erstellen. Früher wäre ich dafür direkt in die Datenbank gegangen. Heute gibt es dafür Powershell. Das ist einfacher und supported.
Die Liste lässt sich mit folgendem Einzeiler erstellen:
get-alert | group-object -property Name | sort-object count
Der Aufbau ist recht einfach: Zuerst alle Alerts ausgeben (inklusiv der bereits geschlossenen). Diese Liste gruppieren nach der Eigenschaft Name. Als letztes die Ausgabe nach der Anzahl des Auftretens sortieren.
Die Ausgabe sieht dann gekürzt so aus: [...]
158 SMTP Message Pending R... {SMTP Message Pending Routing is outside calcu...
790 Pool Non Pages Bytes i... {Pool Non Pages Bytes is outside the calculate...
4861 DB Chaining Flag {DB Chaining Flag, DB Chaining Flag, DB Chaini...
10754 Disk % Free Space low ... {Disk % Free Space low - Yellow(<15%)., Disk %...
Bei zirka 200 Agenten sind 11000 Disk Free Alerts innerhalb von sieben Tagen sehr ungewöhnlich.
Also schauen wir uns das mal genauer an:
get-alert -criteria 'Name Like ''Disk%''' | group-object -property NetbiosComputerName | ft *
Also alle Alerts ausgeben, die mit Disk beginnen. Das Ergebnis nach dem Computernamen, auf dem der Alarm aufgetreten ist sortieren. Zum Schluss das Ergebnis als Tabelle ausgeben:
Values Count Group Name
------ ----- ----- ----
{Rechner1} 10784 {Disk % Free Spa... Rechner1
{Rechner2} 89 {Disk transfer (... Rechner2
{Rechner3} 2 {Disk not respon... Rechner3
Laut dieser Ausgabe sind alle Alerts auf nur einem Rechner entstanden. Der Übertäter ist somit erkannt. Jetzt sollte man ihn genauer untersuchen, um die Ursache zu ermitteln.
Im Rahmen einer Supportanfrage bei MS wurde ich auf eine einfache Möglichkeit hingewiesen, wie man aufzeichnen kann, wann welches Skript durch den OpsMgr Agent ausgeführt wird:
Zusammenfassend werden die Filter im Process Monitor von Sysinternals (jetzt Microsoft) so gesetzt, dass der Start und das Ende von cscript.exe Prozessen aufgezeichnet werden. Da dabei auch die Parameter mit protokolliert werden, ist so einfach zu sehen ob und wann ein Skript mit welchen Eigenschaften aufgerufen wurde. Beim Prozessende erkennt man auch eventuelle fehlerhafte Exitcodes.
Dies ist natürlich auch beim Entwickeln neuer Skript sehr nutzlich!
msiexec.exe /i “%~dp0MOMAgent.msi” /qn USE_SETTINGS_FROM_AD=1 MANAGEMENT_GROUP=<hier name dermanagement group> MANAGEMENT_SERVER_DNS=<hier dns name des scom servers oder gateways> ACTIONS_USE_COMPUTER_ACCOUNT=1 /m scom07 /l* “%systemroot%scomx86.log” REBOOT=REALLYSUPPRESS
Diese Batchdatei als Programm (jeweils für x86 und x64) hinterlegen. Als Collection in SCCM verwende ich im allgemeinen eine Sammelcollection, die die alle Zielsysteme hineinkommen. Darunter lege ich eine Filtercollection an, die aus den Zielsystemen nur die herausfiltert, die den Agent noch benötigen. Hier bietet sich eine Subselection als Query an, die alle Systeme ausschließt die den Dienst bereits haben. Eine Hardwareinventur (HW) wird im Allgemeinen häufiger gemacht als eine Softwareinventur (SW). Daher erhält man die Infos über Dienst (HW) schneller zurück als Dateiinformationen aus der SW-Inventur.
Eine Query könnte so aussehen:
select SMS_R_System.ResourceID,SMS_R_System.ResourceType, SMS_R_System.Name,SMS_R_System.SMSUniqueIdentifier, SMS_R_System.ResourceDomainORWorkgroup, SMS_R_System.Client from SMS_R_System inner join SMS_G_System_SERVICE on SMS_G_System_SERVICE.ResourceID = SMS_R_System.ResourceId where SMS_R_System.ResourceId not in (select SMS_R_System.ResourceId from SMS_R_System inner join SMS_G_System_SERVICE on SMS_G_System_SERVICE.ResourceID = SMS_R_System.ResourceId where SMS_G_System_SERVICE.Name = “HealthService”)
Als Collectionlimit die übergeordnete Sammelcollection eintragen. Die Ankündigung läuft dann auf der Filtercollection.
Heute konnte ich mir endlich die Zeit nehmen einen Alert im SCOM genauer zu betrachten. Obwohl über 2GB auf der NTDS Platte des DCs frei waren und die Subdomäne nur eine Datenbankgröße von 512MB hat, meldete SCOM regelmäßig, dass die Platte zu voll sei.
In diesem Fall sieht die Berechnung folgendermaßen aus:
Name der Regel im MP: AD Database Drive Free Collection
Aktuelle Größen:
ntds.dit: 454672 kbytes
ntds.logs: 10240 kbytes (das MP Skript betrachtet nur das edb.log File)
Folgende Defaultparameter werden an das Skript übergeben (sind überschreibbar): <Threshold_DIT>0.2</Threshold_DIT> (also 20%)
<Boundary_DIT>500000</Boundary_DIT>
<Boundary_LOG>200000</Boundary_LOG>
<Threshold_LOG>0.05</Threshold_LOG>
Die Berechnung sieht so aus (aus dem Skript kopiert):
lReserveLog = lSizeDB * CDbl(LOG_THRESHOLD)
If (lReserveLog < LOG_BOUNDARY) Then
lReserveLog = LOG_BOUNDARY
End If
lReserveDB = lSizeDB * CDbl(DIT_THRESHOLD)
If (lReserveDB < DIT_BOUNDARY) Then
lReserveDB = DIT_BOUNDARY
End If
Die Berechnung der Logfilegröße basiert auf der ADDS Datenbankgröße (DIT)
Die Logdateien und die DB liegen auf der gleichen Partition. Daher gilt:
If (lFreeSpaceDB < (lReserveDB + lReserveLog)) Then
bSuccess = False
strMessage = “Free space (” & lFreeSpaceDB & “KB) on drive ” & UCase(Left(strPathDB, 2)) & ” is lower than the required reserved space for AD Database and Log file. It should be at least ” & (lReserveLog + lReserveDB) & ” KBytes.”
Somit muss der freie Platz größer als 700MByte sein. Was in diesem Beispiel zutrifft.
Trotzdem erscheint im Eventlog und im SCOM die Fehlermeldung:
AD Database and Log : Free space (2614404KB) on drive D: is lower than the required reserved space for AD Database and Log file.
It should be at least 3182704 KBytes.
Wenn man 3182704 durch die DB Größe (454672) teilt erhält man exakt 7. Die entspricht 2+5, d.h. es gibt ein Problem mit dem Komma-Trenner (, in deutsch, . in english)
Ich habe dies überprüft, in dem ich das Skript angepasst habe, damit es die erhaltenen Parameter auch in die Registry speichert (setData..):
Die Boundary Werte sind korrekt, aber Threshold Werte sind auf 5 (log) und 2 (dit) !
Lösung:
Override auf deutschen DCs mit 0,05 und 0,2
Test:
Die Datenbankplatte wurde etwas gefüllt. Kurz darauf wurde folgende korrekte Meldung generiert:
AD Database and Log : Free space (225996KB) on drive D: is lower than the required reserved space for AD Database and Log file. It should be at least 700000 KBytes
Natürlich könnte man als Alternativen Workaround immer die 7fache Größe der Datenbank als freien Speicherplatz bereitstellen, aber gerade wenn man Domänencontroller virtualisiert und die Platten vollständig reserviert, ist dies kein gangbarer Weg. Microsoft sollte hier wie üblich auf die Ländereinstellungen achten! (Oder Nachkommastellen vermeiden. Die Prozentwerte könnten auch als 5% angegeben werden, anstatt 0.05)
Das Sharepoint 2007 (MOSS) Management Pack erzeigt leider einige Skriptfehler auf allen nicht Sharepoint Systemen.
Es gibt verschiedene Lösungen im Web dazu. Die meisten beschreiben ein Override, dass die Zielgruppe auf nur Sharepoint Systeme einschränkt. Dies ist in meinen Augen eine schlechte Lösung, da gerade der Charm an SCOM das automatische Discovery ist.
Daher gibt es noch eine weitere Lösung, die leider etwas versteckt ist: Chris Fox hat ein Management Pack entwickelt, dass durch einige geschickte Gruppen den Fehler korrigiert ohne die Dynamik zu verlieren: Für uns bedeutet das ein einfaches Import des MPs in SCOM. Zu finden ist es auf der OpsManJam Seite.
