Markus Bäker

I have uploaded a release of the Nagios Connector 1.3. You can read about the changes in this post:

http://www.mbaeker.de/2009/10/preinfo-nagios2scom-1-3/
I have only made some short and fast tests. So be cautious.

Download: SCOM2Nagios (107)

If you not only want to connect OpsMgr to Nagios with my connector but other management systems to OpsMgr than the OpenUMR can perhaps help you.

It does more than just creating  alerts in SCOM: it even creates the correct objects for the alerts.

More infos: http://openumr.codeplex.com/

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/2009/12/scom2nagios-1-3/

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…

The new version is released here: http://www.mbaeker.de/2009/12/scom2nagios-1-3/

Attached is the new version of the SCOM2Nagios Connector.

There is just one small thing changed:

You can now define the OK message in config file. So no more german status messages in you nagios

And thanks to Thomas Karatzoglou we now have an english installation instruction in the file.

Download Link: SCOM2Nagios (224)

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.

Für die Extraktion der Alert Informationen aus dem CCMS von SAP habe ich nur wenige Informationen gefunden. Das beste Dokument natürlich erst als dieser Teil schon fast abgeschlossen war: External Interface for Alert Management.

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!

Wie bereits in einem früheren Post erklärt musste man vor OpsMgr 2007 R2 bei einem Proxy Error (“Agent proxying needs to be enabled for a health service to submit discovery data about other computers.”) umständlich aus der angegebenen internen Rechner GUID den eigentlich gemeinten Agent herausfinden um ihm dann als Proxy Agent zu aktivieren.

R2 hat hier eine kleine aber wesentliche Verbesserung erfahren: In den Details  des Alarms wird jetzt die GUID direkt durch den DNS Namen ersetzt:

Details:Health service ( rechner.domain.local ) should not generate data about this managed type

Gerade solche Kleinigkeiten machen das Produkt immer besser!

Im DNS 2003 Version 6.0.6480.0 existiert ein Fehler.  In der Standardeinstellung wird ein Fehler bei der externen DNS Auflösung gemeldet (“DNS 2003 Server External Addresses Resolution Alert”).

Ursache ist ein fehlerhafte Zieladresse. Es wird versucht einen Namenservereintrag (NS) für www.microsoft.com zu ermitteln. Der  korrekte Nameserver wäre microsoft.com. www.microsoft.com ist nur ein Ressourcen Eintrag (A Record). Als Lösung sollte man somit den Alarm überschreiben und entweder den Typ auf A ändern oder die Adresse auf microsoft.com (oder irgend eine andere) und den Typ auf NS lassen.

Quelle: http://www.eggheadcafe.com/conversation.aspx?messageid=33863169&threadid=33863151