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.

Meiner SCOM-Testmaschine wollte ich per ESX einen zweiten Prozessor spendieren, da sie nur sehr langsam reagierte und die Datenbank auf dem gleichen System läuft.

Die übliche und einfache Methode unter Gerätemanager und Computer von ACPI auf Multiprozessor ACPI umzuschalten funktioniert unter Windows 2003 R2 nicht mehr, um die zweite CPU nutzen zu können. Eine kurze Webrecherche hat zwar unzählige Möglichkeiten ergeben, aber die in meinen Augen einfachste und eleganteste habe ich im VMWare Forum gefunden:

Gerade gestartet und schon aktualisiert. WordPress läuft jetzt als Version 2.7. Diese Gelegenheit habe ich genutzt, die Vorschläge von Bren Ozar aus seinem Blog-Eintrag
How to Start a Technical Blog, Part 3: WordPress Plugins
umzusetzen. Ich habe jetzt ein paar sinnvolle Plugins hinzugefügt. OpenID finde ich mit das interessantest davon.

Gerade Windows Installation für Templates werden häufig mit kleinen Platten (ich verwende 10GB für das System) installiert. Dies reicht für den Großteil der Installationen aus, wenn man versucht größere Datenmengen auf extra Disks zu legen. Trotzdem kommt es immer wieder vor, dass der Platz nicht reicht. Seit ESX 3.5 (Update 2?) kann man Disks im laufenden Betrieb vergrößern.

Windows erkennt dies auch automatisch. Leider kann Windows 2003 nur NIcht-Systemplatten mit Boardmitteln vergrößern. Bevor jetzt ein ein Neustart mit einem Festplattenpartitionierungsprogramm gemacht wird möchte ich auf ein kleines aber sehr mächtiges Tools hinweisen: DriveSnapshot (www.drivesnapshot.de): Dieser Imagebackuptool kann viel mehr als die meisten wissen.

Heute wollte ich mal wieder ein paar Blade Systeme ins ESX Cluster aufnehmen. Da ich aber bei einem bereits in einem anderen Zusammenhang ein Problem hatte, waren vorher einige Lasttests angebracht.Da momentan noch kein standardisiertes Tool eingesetzt wird, habe ich etwas im Internet gesucht und bin zufällig über ein sehr interessantes Tool mit Namen Inquisitor gestolpert. Es bietet eine Linux Live CD mit Burn-In Tests. An sich noch nichts besonderes. Interessant wird es zusammen mit der Serverkomponente, mit der solche Tests auch zentral protokolliert und verglichen werden können.

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.

Ziele dieses Blogs:

Technische Informationen bereitstellen zu folgenden Bereichen:

• System Center Operations Manager (SCOM [meine Abkürzung])
• System Center Configuration Manager (SCCM)
• VMWare Virtual Center

Soweit es mir erlaubt ist, werde ich auch Programme und Quellcodes zu meinen aktuellen Projekten bei meiner Arbeit bereitstellen.