Markus Bäker

Im Rahmen meiner beruflichen Tätigkeit sind diverse Management Packs für den Operations Manager (SCOM) angefallen.

Diese stehen jetzt kostenlos zum Download bereit: http://www.its-technidata.de/de/im_focus/microsoftsystemcenter/Seiten/KostenloserDownloadSCOM.aspx

Darunter sind (einfache) MPs für:

• BlackBerry Email Router Monitoring
• Microsoft CRM Email Router
• Datacore Storage Server
• FileZilla FTP Server Monitoring
• Kiwi Syslog Server Monitoring
• SAP MaxDB Monitoring
• Oracle Database Server Monitoring
• Basic SAP Monitoring auf Windows Servern
• WAMP Monitoring

Fragen und Anregungen dürfen auch gerne an diesen Post als Diskussion angehängt werden!

Sometimes the acs forwarder doesn’t connects successfully to the acs server and states in the operations manager event log, that you have to activate debugging to see more details.

You can activate it by following this instruction:

1. Browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AdtAgent\Parameters
2. Create DWORD value = TraceFlags
3. Edit the TraceFlags entry and enter decimal value 524420
4. Restart the AdtAgent service

(Source: http://helpmemanage.blogspot.com/2007/05/enable-detailed-logging-for-acs.html)

You can find the log under c:\windows\temp

One cause can be that the acs cannot operate over forest borders or from a workgroup (kerberos authentication – some reason for the scom agent).

The workaround is a little bit mor complicated that a simple certificate exchange.

A good and working explanation can be found here:

http://www.directtechnology.com/BlogEngine/post/2010/08/17/Problems-with-non-trusted-computers-reporting-to-ACS-%28Audit-Collection-Services%29.aspx

Seit dem 1. Oktober steht das CU3 für den SCOM bereit. Es beinhaltet nicht viele Neuerungen dafür aber einige Fehlerbehebungen. Eine Installation lohnt sich somit! Integriert ist darüber hinaus das Cross Pattform Update 3.

Bei der Installation bitte folgendes beachten: Es reicht nicht aus einfach das Update zu installieren, sondern es müssen noch ein paar manuelle Schritte durchgeführt werdden. Dazu zählt hauptsächlich das Ausführen von SQL Statements. Details findet ihr auf der Knowledge Base Seite unter dem Abschnitt:

Manual operations that must be performed after you update the Root Management Server and Data Warehouse

Hier der Link zum Update: http://support.microsoft.com/kb/2251525/en-us

Und wenn man schon am Updaten ist, dann kann man auch das Cross Platform Cumulative Update 3 for Systems Center Operations Manager 2007 R2 mit installieren. Es beinhaltet das oben erwähnte CU2, so dass man seine Linux Agents nur einmal aktualisieren muss.

Cross Plattform CU3 Version (z.B. Management Pack): 6.1.7000.277

Cross Plattform CU3 Agent Version: 1.0.4-265

FB_Addon_TelNo{ height:15px !important; white-space: nowrap !important; background-color: #0ff0ff;}

Vor Kurzem hat Microsoft das OpsMgr Authoring Resource Kit unter  http://www.microsoft.com/downloads/details.aspx?FamilyID=9104af8b-ff87-45a1-81cd-b73e6f6b51f0&displaylang=en bereitgestellt.

Es beinhaltet neben der bereits auf der R2 CD enthaltenen Authoring Console folgende Punkte:

• Management Pack Best Practice Analyzer
• Management Pack Spell Checker
• Management Pack Visio Generator
• Management Pack Diff
• Management Pack Cookdown Analyzer
• All References Add-in
• Workflow Analyzer
• Workflow Simulator

Also ein paar interessante Ergänzungen!

The new version is released here: http://www.mbaeker.de/category/tools/scom2nagios/

The next release will address two feature requests:

1. Possibility to change the hostname (you don’t use fqdn host names in nagios…)
2. Possibility to use more than one service in nagios (you want to separate the alerts for dns and acitve directory)

I will try to solve both by using “processing instructions”. This instructions will use the scom alert as an input filter and the nagios alert as the object to manipulate.

This instructions are defined in a xml file:

<?xml version=’1.0′ encoding=’ISO-8859-1′?>
<instructions>

<!–
field:
scom: path (of monitoringobject), fullname (of monitoringobject), severity, state, name (of alert), description
nagios: text, host, service, state

compare:
contains, containsIgnoreCase, equals, equalIgnoreCase

–>

<instruction>

<input field=”path” compare=”contains”>DNS</input>
<output field=”service”>DNS</output>
</instruction>

<instruction>
<input field=”state” compare=”equals”>255</input>
<output field=”text”>Everything is OK </output>
</instruction>

</instructions>

What do you think about this feature?

The main code is ready. It even compiles without problems… Next step is testing – but currently I have no operations manager test system with a connected nagios…

FB_Addon_TelNo{ height:15px !important; white-space: nowrap !important; background-color: #0ff0ff;}

FB_Addon_TelNo{ height:15px !important; white-space: nowrap !important; background-color: #0ff0ff;}

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 http://www.mbaeker.de/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.

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:

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.

Dies ist natürlich auch beim Entwickeln neuer Skript sehr nutzlich!

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