SCSM 2012 – Connector Framework, Zusammenspiel der System Center Familie (Teil 2)

In Teil 1 dieser Blogreihe habe ich Ihnen kurz gezeigt was der Service Manager 2012 ist und worin seine Aufgabe besteht. Dieser Beitrag soll Ihnen das Connector Framework des Service Managers vorstellen und aufzeigen welche Möglichkeiten es bietet.

Die System Center Familie bietet die Möglichkeit der Vernetzung. Dadurch können Kommunikationskanäle aufgebaut werden, die einen kontinuierlichen Informationsfluss ermöglichen. Im Mittelpunkt steht der Service Manager, er bekommt so alle notwendigen Informationen zugespielt.

Diese Informationen erweitern die CMDB (Configuration Management Database) des Service Managers, erstellen automatisch Tickets, führen automatisiert Aufgaben durch oder erweitern den Funktionsumfang des E-Mail-Systems.

Schauen wir uns die Connectoren und ihre Aufgaben im Einzelnen an. Da die Einrichtung relativ selbsterklärend ist, wird darauf nicht näher eingegangen:

Zunächst zu den Connectoren, die sogenannte Configuration Items (CI) mitbringen und damit die CMDB füllen.

Der Active Directory connector verknüpft den Service Manager mit dem AD. Hieraus können Informationen über Benutzer und Gruppen sowie Computer-Objekte und Drucker (sofern diese im AD veröffentlicht sind) erworben werden. Dazu wird im Connector definiert welche Objekte bezogen werden sollen. Es lässt sich entweder auf Domänen- bzw. OU-Ebene einsteigen, oder per LDAP ein entsprechender Filter definieren. Vom AD Connector können theoretisch beliebig viele erstellt werden, Erfahrungen haben aber gezeigt, dass zu viele davon zu einer sehr hohen Auslastung führen.

Der Configuration Manager connector liefert, wie der AD Connector auch, Informationen über Computer Objekte. Der Clou, die Objekte werden nicht parallel angelegt, sondern Informationen von bereits bestehenden Objekten ergänzt. Dazu gehören beispielsweise die Informationen aus der Software Discovery, Betriebssystem Version etc. Darüber hinaus wird Software selbst auch als CI angelegt und kann entsprechend verwaltet werden.

Der Operations Manager CI connector ist einer von zwei SCOM Connectoren, er liefert ebenfalls Informationen zu Computer Objekten. Auch in diesem Fall werden die Informationen bereits bestehender Objekte nur ergänzt. Sind die entsprechenden Management Packs vorhanden können sogar Distributed Applications in den Service Manager übernommen werden. Diese werden dort als sogenannte Business Services gehandelt. Damit werden bestimmte Server- und Systemgruppen als Einheit betrachtet und nicht mehr nur als Individual Objekte. Es ist also Möglich beispielsweise den Service „Messaging“ mit allen seinen Komponenten (Server, Datenbanken, Dienste, …) zusammenzufassen.

Der Virtual Machine Manager connector bedient den Service Manager mit Informationen aus der Virtualisierung. Also beispielsweise VM Templates, Storage, etc. Auch diese werden mit in die CMDB aufgenommen.

Abschließend zu den CI Connectoren noch einer, der eigentlich kein wirklicher Connector ist, aber dennoch sehr Hilfreich ist – CSV Import. Er ermöglicht den Import von CIs mittels CSV. Gerade bei Migrationen von CIs aus Drittsystemen, die über die anderen Connectoren nicht geliefert werden (Mobilgeräte, Handhelds, evtl. Kassensysteme …), ist dies eine Option. Für den CSV-Import werden zwei Dateien und ein wenig XML Kenntnis benötigt. Die beiden Dateien sind einmal die CSV-Datei mit den zu importierenden Objekten und eine XML-Datei mit der Objekt-Definition. Beispiel:

Es sollen die Incidents aus dem alten System importiert werden. Damit wir wissen wie die Klasse für Incidents aufgebaut ist, verwenden wir das Get-SCSMClass Cmdlet der Service Manager Shell:

Und weil die Klasse Incident von weiteren Klassen Eigenschaften erbt, hier der Vollständigkeit wegen die Eigenschaften der Basisklassen:

Jetzt da wir wissen welche Eigenschaften die Klasse hat, können wir die XML-Definition entsprechend aufbauen:

Die Reihenfolge der Properties in der XML Datei ist entscheidend für die Anordnung der CSV-Datei. Also am besten ziehen Sie sich eine CSV aus Ihrem Alt-System und ordnen der CSV-Datei entsprechend die XML-Properties an.

Die erste Spalte IR{0} bildet später die ID im System. Der Platzhalter {0} wird durch die nächste anstehende ID ersetzt.

Das Ergebnis sieht wie folgt aus:

Die übrigen Connectoren die nicht unter den Typ CI Connector fallen sollen im Folgenden vorgestellt werden:

Darunter der SCOM Alert connector. Er dient der automatischen Ticketgenerierung wenn SCOM ein Ereignis einer zuvor definierten Klassifizierung entdeckt. Zum Beispiel Kritische Ereignisse oder Warnungen. Diese Alarme werden über den SCOM connector an den Service Manager weiter gegeben und entsprechend in Tickets umgewandelt. Im Connector selbst können Regeln definiert werden, wie bestimmte Ereignisse im Service Manager behandelt werden sollen. Entsprechend dieser Regeln können Incident Templates mit vorausgefüllten Informationen hinterlegt werden (zu Templates mehr in Teil 3). Von SCOM erstellte Tickets können außerdem, sofern diese Einstellung gesetzt ist, von automatisch SCOM auch wieder geschlossen/erledigt werden, wenn das Problem behoben ist.

Der Orchestrator connector dient der Integration von Runbooks in den Service Manager. Runbooks enthalten automatisierte Arbeitsabläufe (Workflows). Dies ermöglicht eine Automatisierung von z.B. Offerings aus dem Service Catalog, wie das Anlegen von AD Usern oder das Zurücksetzen von Passwörtern. Genaueres dazu wird in den Teilen 4 und 8 behandelt.

Abschließend soll der Exchange connector vorgestellt werden. Er ist für Service Manager 2012 allerdings noch Release Candidate und somit noch nicht supported. Weitere Informationen dazu können Sie dem folgenden Link entnehmen:

http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=29423

Ich hoffe ich konnte Ihnen das Prinzip der Connectoren etwas näher bringen. Im nächsten Teil der Serie befassen wir uns mit Incidents und Changes.

Weitere Beiträge dieser Serie:

• SCSM 2012 – System Center Service Manager 2012 – Einführung (Teil 1)
  
• SCSM 2012 – Connector Framework, Zusammenspiel der System Center Familie (Teil 2)
  
• SCSM 2012 – Incident und Change Management (Teil 3)
  
• SCSM 2012 – Service und Request Offerings, User Management (Teil 4)
  
• SCSM 2012 – Service Manager Authoring Tool (Teil 5)
  
• SCSM 2012 – Erstellen eigener Configuration Items (Teil 6)
  
• SCSM 2012 – Standard Incidents erweitern (Teil 7)
  
• SCSM 2012 – Automatisierung mit dem SCOrch (Teil 8)