Bei der Aktualisierung meiner SCOM 2007 R2 Umgebungen bin ich beim Upgrade des RMS auf die folgende Fehlermeldung gelaufen:

Das Problem besteht darin, dass die Operationsmanager Datenbank wie auch die Datwarehouse Datenbank auf einem extra SQL Server liegen:

Server1: RMS
Server2: Default SQL Instanz -> OpsMgrDB - Port 11433
Server2: SCOMDW Instanz -> OpsMgrDW - Port 12433

Leider gibt es keine Möglichkeit, dem Update diese Informationen mitzugeben.

Ein Lösung besteht darin, für die beiden Datenbanken eine ODBC Verbindung mit den notwendigen Client Einstellungen auf dem RMS anzulegen:

 Danach lief der Update auf 2012 RC ohne Probleme durch.

Im System Center Operations Manager 2012 gibt es eine kleine, aber sehr nützliche Verbesserung beim Erstellen von Overrides.

Jeder der sich schon mal mit Anpassungen im Operations Manager Umfeld befasst hat, weiss um die Bedeutung des "Default Management Packs". Es wird immer als Vorbelegung beim Erstellen von Overrides eingesetzt, obwohl es eine klare Empfehlung von Microsoft gibt, dieses Management Pack nicht zu benutzten.

Auch ein Umbennen in "DO NOT USE DEFAULT MANAGEMENT PACK" oder "HIER NICHTS REINSCHREIBEN" ändert an der Vorbelegung des DropDown Feldes nicht.

Und mal ehrlich: wer hat da nicht auch schon ganz schnell mal den OK Button gedrückt.

Mit dem Operations Manager 2012 hat Microsoft nun ein Einsehen und belegt das Feld, in dem der Benutzer das Management Pack angeben muss, nicht mehr mit einem Standardwert. Es steht nun der Hinweis, das ein Management Pack ausgewählt werden muss.

Der "OK" Button bleibt zusätzlich noch ausgegraut, bis der Benutzer sein gewünschtes Management Pack ausgewählt hat:

Damit sollte das versehentliche Speichern im ungeliebten Default Management Pack der Vergangenheit angehören.

Im SCOM 2012 gibt es eine Erweiterung bei Graystate-Problemen mit den Agenten. Und zwar gibt es unter Monitoring\Operations Manager\Agent Details\Agent Health State die Möglichkeit einen neuen Task auszuführen, der den Status der Konnektivität zum Agenten anzeigt und wenn der Agent im Graystate ist, wie lange er schon diesen Status hat. Der auszuführende Task lautet:

Show Gray Agent Connectivity Data

Wenn der Task ausgeführt wird erscheint nach Abarbeitung des Tasks folgende Ausgabe:

Mit der Installation eines SCOM 2012 Agenten wird auf einem System nun ebenfalls ein kleines grafisches Konfigurationstool installiert. Mit diesem Tool hat man die folgenden Möglichkeiten:

• den Agenten zu einer weiteren Management Gruppe hinzufügen
• den Agenten aus einer Management Gruppe entfernen
• die Active Directory Integration ein- bzw. auszuschalten
• den "Local Action Account" für den Agenten ändern

Zu finden ist das Tool nach einer Agenteninstallation unter "Systemsteuerung/System und Sicherheit" (bzw. "Control Panel/System and Security"):

Nach dem Start des erhält man eine Liste der Management Gruppen, mit denen der Agent verbunden ist:

Über Add / Remove kann eine weitere Management Gruppe hinzugefügt werden bzw. ein vorhandene gelöscht werden.

Wird eine Gruppe in der Liste markiert, so erhält man mit der Edit-Funktion einen Dialog, in dem der lokale Action Account eingestellt werden kann. Damit gibt es nun ein sehr schöne Möglichkeit für einen Systemadministrator, spezielle Benutzerdaten für den Agenten zu setzen, ohne auf die Hilfe der SCOM Administratoren angewiesen zu sein:

Zusammenfassend bleibt zu sagen, dass dieses kleine Tool ein weiterer postiver Schritt in Punkto Benutzerfreundlichkeit darstellt.

Neue Möglichkeiten mit dem SCOM 2012 RC Dashboard and Widget Wizard

Mit dem neuen Dashboards beim System Center Operations Manager 2012 RC ergeben sich ungeahnte Möglichkeiten.

• Erstellen von Dashboard mit verschiedenen Serversystemen
• Einstellen eines vordefinierten Zeitbereichs
• Positionierung der Widgets einfach anpassbar
• Freie Beschriftung der Widgets
• Filtern in den Widgets

Screenshot SCOM 2012 RC Dashboard:

Wenn ein System Center Operations Manager Agent sich im Gray-State befindet gibt es verschiedene Möglichkeiten die Funktion wiederherzustellen.

1. Analyse des Operations Manager Logs auf dem fehlerhaften System durchführen.
2. Wenn keine Fehler ersichtlich kann ein zurücksetzen des Agenten die Funktion wiederherstellen. Dazu unter Monitoring/Operations Manager/ Agent / Agent Health State im Fenster Agent Sate den Agenten auswählen und mit der Aktion Flush Health Service State and Cache den Agenten zurücksetzen. Der Task meldet keinen Sucess zurück, da auch dieser Task im Agent gelöscht wrd.
3. Sollten im Log Lesefehler des Agenten angezeigt werden, kann durch umbenennen des Ordners "Health Sevice State" auf dem betroffenen System und des Neustart des Health Service(System Center Management Health Service) eine Erneuerung des Ordners und deren Inhalt erzwungen werden. Alle Management Packs und die Konfiguration werden neu geladen.

Tim McFadden von Microsoft hat erneut ein kleines aber feines Tool geschrieben, welches das Leben im Umgang mit Management Packs erleichtert.

MP2XMLPRO ist ein mit einer Benutzeroberfläche ausgestattetes Programm, mit dem man MP Dateien in XML Dateien umwandeln kann.

Dabei stehen 3 verschiedene Varianten zur Verfügung:

1. Eine einzelnen MP Datei in eine XML Datei umwandeln
2. Alle MP Dateien in einem Verzeichnis in XML Dateien umwandeln
3. Alle "gesealten" Management Packs über eine Verbindung direkt zum Root Management Server in ein lokales Verzeichnis als XML Datei exportieren

Damit entfällt die Benutzung des weit verbreiteten Powershell Skriptes MP2XML.ps1.

Das Tool findet man unter folgendem Link: MP2XMLPRO

Manchmal kommt es vor, dass man nicht alle Applikationen/Services auf einzelnen Systemen überwachen möchte. Um nicht alle Regeln und Monitore dieser Applikation per Override deaktivieren zu müssen, sollte man das Discovery auf diesen Systemen deaktivieren.

Zunächst muss man das Objekt Discovery der enstprechenden Applikation für das Zielobjekt  (oder einer Gruppe von Zielobjekten) per disable Override deaktivieren.

Was mache ich aber, wenn das Zielobjekt bereits discovered wurde?

In diesem Fall kann man per Powershell über das remove_disabledmonitoringobject Kommando die Objekte, für die das Discovery deaktiviert wurde, wieder löschen.

Syntax des Kommandos
http://technet.microsoft.com/en-us/library/gg132269.aspx

Um dieses Problem zu beheben ist eine Abfrage auf die OperationsManagerDB auszuführen. Diese Abfrage gibt als Ergebnis die Agenten aus, die in der Spalte "isManuallyInstalled" als Wert "true" haben. Folgende Abfrage wird im SQL-Management Studio ausgeführt:

select b.displayname, h.isAgent, h.IsManuallyInstalled,h.basemanagedentityid  from
mt_healthservice h inner join BaseManagedEntity b on h.basemanagedentityid = b.basemanagedentityid
where h.isAgent = 'True'
 
Das Aktivieren besteht nun darin, den Wert in der Spalte „isManuallyInstalled“ auf „False“ zu setzen.

update mt_healthservice
set isManuallyInstalled = 'False'
where basemanagedentityid = ''

Wenn der Wert jetzt wieder auf "false" sollte in der Operations Manager Konsole beim Agenten wieder die Funktionen Change MS, Repair, Uninstall verfügbar sein.

Um in Demo-Umgebungen den Netzwerk-Monitoring Part des SCOM darzustellen ist es nicht immer möglich einen Switch bereitzustellen und genau diese Lücke schliesst das Tool von Jalasoft. Mit diesem SNMP-Device Simulator ist es möglich über eine Windows-VM verschiedene Netzwerkkomponenten darzustellen. Folgende Produkte können simuliert werden:

• Cisco Switches
• Cisco Router
• Cisco Firewalls
• Cisco VPN Concentrators
• Cisco Wireless devices
• 3Com Switches
• HP Procurve Switches
• F5 BigIp
• Nortel
• APC UPS

Produkte ist unter folgendem Link verfügbar : http://www.jalasoft.com/Web/Product/Product.aspx?id=49