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.