Achtung: Neue Version /2009/07/scom2nagios-version-1-1/

**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.

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:

http://blogs.technet.com/jeevanbisht/archive/2008/12/09/OpsMgr-2007-How-to-identify-what-script-is-running-on-the-agents-_2F00_-frequency-_2F00_-parameters.aspx

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.

Während einer OS Installation über SCCM (MDT) ist die Installation der aktuellen HP Treiber durch das passende Support Pack sehr einfach möglich. Firmware Updates fand ich bis jetzt schon schwieriger.

Eine sehr einfache Möglichkeit ermöglicht die Firmware Update CD:
Die CD (ISO File) einfach entpacken (z.B. mit 7Zip) und als Paket im SCCM einbinden. Im Root des Paketes eine Batch Datei mit folgendem Inhalt anlegen:

"%~dp0FW840.2009_0209.17compaqswpackageshpsum.exe" /s /romonly /use_location "%~dp0FW840.2009_0209.17compaqswpackages"

Treibermanagement in SCCM ist recht einfach gestaltet, trotzdem sollte man eine gewisse Organisation und Vorsicht walten lassen. Daher mal diesmal ein paar Basics:

Eindeutiges Zeichen für einen Fehler ist folgender Bluescreen (0xc000035a):

Schaut man sich die Boot Image Treiber genauer an, so erkennt man schnell einen Intel Storage Treiber.  Unter Drivers kann man ebenfalls erkennen, dass der Treiber folgende Plattformen vorgesehen ist: “All x64 Windows Server 2003 (Non R2), All x64 Windows Server 2003 R2, All x64 Windows Server 2008, All x64 Windows Vista, All x64 Windows XP Professional […]”.

Wenn bereits eine existierende SCCM Infrastruktur auf den Servern exisitert, dann macht es eventuell Sinn, den SCOM Client damit zu verteilen.

Dafür einfach ein Paket mit den Quelldateien aus dem AgentManagement Ordner vom SCOM Server erstellen.

Darin im x86 und x64 Ordner folgende Batchdatei install.cmd hinterlegen:

rem Sicherheitshalber msxml6 installieren (Voraussetzung)

msiexec.exe /i “%~dp0MSXML6.msi” /qn /m scom07 /l* “%systemroot%msxml6.log” REBOOT=REALLYSUPPRESS

msiexec.exe /i “%~dp0MOMAgent.msi” /qn USE_SETTINGS_FROM_AD=1 MANAGEMENT_GROUP= MANAGEMENT_SERVER_DNS= ACTIONS_USE_COMPUTER_ACCOUNT=1 /m scom07 /l* “%systemroot%scomx86.log” REBOOT=REALLYSUPPRESS

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)

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.

Aktuell runde ich den produktiven SCCM ab. Dabei hatte ich wieder den Fall, dass die WinPE trotz installierter HP Netzwerktreibern nicht die Netzwerkkarten finden konnte (DL385G2, Onboard Nics). Ursache war vom Pilotsystem schon bekannt.

Die verbauten Broadcom Karten (NetXtreme II) haben ein etwas komplizierteres Treibermodel: Zuerst wird ein “Grundtreiber” geladen. Dieser stellt aber nur die Basis für den eigentlichen Netzwerktreiber dar. Diese zweite Schicht hat aber als PCI-ID ein Dummy ID, die erst von dem Grundtreiber zur Verfügung gestellt wird. Dieser doppelte Treiber wird momentan von einer WinPE CD nicht sauber unterstützt (da beim Booten nur ein Plug-and-Play Lauf gemacht wird).

Find the newest version on top of: /category/tools/scom2nagios/

In meinem Umfeld ist Nagios als oberster Überwachungspunkt definiert worden. Daher hat sich bereits eine on mir betreute Diplomarbeit u.a. mit der Anbindung von SCOM an Nagios beschäftigt. Daraus hat sich ergeben, dass sich SCOM am Besten mittels send_ncsa anbinden lässt, da dieses Tool (das auch für Windows existiert) die Übertragung verschlüsseln kann und nicht auf Email (Verzögerung und was ist wenn man damit die Emailumgebung überwachen will?) bzw. snmp (wird von einigen als unsicher angesehen…) setzt.