Momentan bin ich daran einen einfachen SAP2SCOM Connector zu entwickeln. Leider stellt sich die Informationsrecherche im SAP Umfeld für mich als relativ schwierig dar. Daher: Falls jemand ebenfalls mal in diesem Umfeld etwas machen darf, hier zwei relevante Links:

Für Visual Studio 2003 gibt es einen SAP .NET Connector um auf BAPI und Webservices von SAP  zuzugreifen. Für neuere Versionen gibt es diesen nicht mehr. Trotzdem mach dieses Add-On die Entwicklung einfacher, da es die komplette Komplexität kapselt. Möchte man dies also heute noch nutzen, dann gibt es unter  http://www.codeproject.com/KB/dotnet/Connect_SAP_from_VS2008.aspx eine Anleitung dazu.

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

Anbei die Version 1.1 des Nagios Connectors. Er beinhaltet nur geringe Änderungen:

• Ausgabe der Versionsnummer in der Logdatei
• Detailliertere Logausgaben
• Fehler beim zweiten Nagios Server: er wurde in jedem Fall aufgerufen

Download: SCOM2Nagios_1.1

Liebe Microsoftler,

meistens bin ich ja auf eurer Seite. Aber mache Dinge muss man nicht verstehen, oder?

Das ist kein gemeinsamer Dienst der System Center Familie (soweit ist die Integration wirklich noch nicht), sondern der Operations Manager Dienst (System Center Operations Manager 2007 R2). Gemeinsame Identitäten schaffen ist gut. Alle Familienmitglieder nur mit dem Nachnamen anzusprechen ist aber zu viel des Guten.  Bitte nennt den Dienst doch mindestens System Center Operations Agent oder so ähnlich!

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.

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<br />
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.

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.

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: