Abgelegt unter: Anleitungen | Tags: Alert, Connector, Konfiguration, SCOM, SCSM
Als erste Tat im neuen Jahr will ich nun den System Center Operations Manager an den Service Manager ankoppeln.
Notwendige Vorbereitungen
Einmal mehr hilft mir dabei ein Blogeintrag der belgischen System Center User Group. Sie weisen darauf hin, dass das benötigte Connector Account ein Domänenkonto sein muss, das Mitglied in der lokalen Gruppe „Users“ auf dem Service Management und zugleich ein Operations Manager Administrator sein müsse.
Ich erstelle deshalb zuerst einmal ein passendes Service Account im Active Directory, das ich sogleich zum Operations Manager Admin befördere und sogleich auch auf dem Service Manager Management Server in die Gruppe „Users“ aufnehme. Somit sollten die Prerequisites bereits erfüllt sein.
Erstellen des Connectors
Ich wechsle nun auf den Service Manager. In der Konsole navigiere ich unter „Administration“ zu „Connectors“ und klicke auf „Create Connector“ und wähle „Operations Manager Alert Connector“, worauf der entsprechende Wizard startet und mir seine Begrüssungsseite zeigt. Nach einem ersten Klick auf „Next“ werde ich nach einem Namen und einer Beschreibung gefragt, die ich passend angebe und dann wieder auf „Next“ klicke.
Nun werde ich nach dem Namen des Operations Manager Servers gefragt, den ich passend eintrage. Im Bereich „Credentials“ klicke ich wieder – wie beim SCCM Connector – beim „Run as Account“ auf „New…“, um das passende „Run As Account“ zu erstellen. Als „Display Name“ wähle ich „SCOM Connector Account“, trage eine passende Beschreibung ein und ergänze die entsprechenden Angaben zum AD-Konto. Ein Klick auf „OK“ und auch dieses Konto ist als „Run As“-Konto definiert. Es folgt der übliche Klick auf „Test Connection“, der mit der erfreulichen Meldung „The connection to the server was successful“ bestätigt wird.
Auf der nächsten Seite des Assistenten muss ich nun die „Alert Routing Rules“ definieren. Auch hier hilft mir der Blogeintrag der belgischen System Center User Group weiter: Sie schreiben, dass hier nur Einstellungen gemacht werden müssen, wenn man spezifische Templates für bestimmte Alerts haben will; ansonsten könne man hier die Liste leer lassen, dann würden alle Alarme das standardmässige „Operations Manager Incident Template“ benutzen. Das tönt doch schon mal gut; also ein Klick auf „Next“.
Die nächste Seite des Wizards widmet sich dem „Schedule“. Standardmässig wird vorgeschlagen, dass Alarmmeldungen alle 30 Sekunden abgeholt werden sollen. Da ich im Moment keinen Grund sehe, weshalb das eine völlig unpassende Voreinstellung sein sollte, übernehme ich diese mal direkt. Die beiden Checkboxen „Close alerts in Operations Manager when incidents are resolved or closed“ und „Resolve incidents automatically when the alerts in Operations Manager are closed“ hingegen finde ich noch sehr interessant. Da ich der Meinung bin, dass es jeweils im anderen System nachgeführt werden soll, wenn im einen System ein Problem als gelöst bezeichnet wird, aktiviere ich mal beide Checkboxen und klicke ein weiteres Mal auf „Next“.
Nun wird mir noch die Summary-Seite angezeigt; hier klicke ich sogleich auf „Create“. Mit der Bestätigung, dass der Wizard erfolgreich abgeschlossen wurde, ist der erste Teil der Erstellung des Connectors zu SCOM nun abgeschlossen.
Aktivierung der Subskription
Der nächste Teil muss nun mit der Operations Manager Konsole für den Root Management Server durchgeführt werden. Hier öffne ich den Abschnitt „Administration“ und navigiere zu „Product Connectors“, „Internal Connectors“. Hier finde ich in der Liste den soeben erstellten Connector. Ich wähle diesen aus und klicke ihn mit der rechten Maustaste an, um den Dialog „Properties“ zu öffnen.
Die Liste der Subscription ist noch leer, deshalb klicke ich auf „Add“, womit sich der „Product Connector Subscription Wizard“ öffnet. Dieser fragt zuerst mal nach einem Subscription-Namen und einer Beschreibung, die ich passend eintrage und dann auf „Next“ klicke. Im nächsten Dialogfenster kann ich wählen, für welche Operations Manager Gruppen die Alarme an den Service Manager übermittelt werden sollen. Ich wähle mal hier die Voreinstellung, dass ich alle Alarme übermittelt haben möchte. Im nächsten Schritt kann ich nun noch angeben, von welchen Targets die Alarme übermittelt werden sollen; auch hier wähle ich die Voreinstellungen, dass alle Alarme übermittelt werden sollen, auch diejenigen von Targets von Management Packs, welche erst in Zukunft importiert werden. Im letzten Schritt dieses Wizards können noch Kriterien definiert werden: Auch hier entscheide ich mich mal für die Vorgabewerte: Nur „Errors“, aber keine „Warnings“ oder „Informations“, nur die Prioritäten „High“ und „Medium“, aber nicht „Low“, sowie alle „Resolution States“ und alle Kategorien. Mit dem abschliessenden Klick auf „Create“ wird die Subskription erstellt.
Da die neu erstellte Subscription nun in der Liste erscheint, kann der „Properties“-Dialog wieder geschlossen werden, womit die notwendigen Konfigurationsarbeiten in der SCOM-Konsole abgeschlossen sind.
Überprüfung in der Service Manager Konsole
In der Service Manager Konsole navigiere ich nun zu „Work Items“, „Incident Management“, „All Open OM Incidents“. Die dortige Liste ist leer. Aber auch im Operations Manager sind keine Alarme zu finden.
Ich wage daher einen kurzen Test, für den ein Domänenkontroller herhalten muss, dessen DNS-Service nicht von unseren Clients her verwendet wird. Kurzerhand stoppe ich den DNS-Server-Dienst auf diesem Server, was wenige Sekunden später entsprechende SCOM-Alarme zur Folge hat. Gespannt schaue ich auf die Service Manager Konsole. Tatsächlich: nach wenigen Sekunden werden auch dort die entsprechenden Alarme aufgelistet.
Operations Manager Alarm in der SCSM-Konsole
Erfreut darüber, dass auch dies wunschgemäss funktioniert, starte ich den DNS-Server-Dienst auf dem Domänenkontroller wieder, worauf kurz darauf SCOM die entsprechenden Alarme schliesst. Kurze Zeit verschwinden auch im Service Manager die beiden Incidents aus der Ansicht „All Open OM Incidents“. Ich wechsle auf die Ansicht „All Incidents“; hier sind die beiden Incidents wieder zu sehen, allerdings mit dem Status „Resolved“. Wenn das kein gelungener Start ins neue Jahr ist…
Abgelegt unter: Anleitungen | Tags: Connector, Installation, SCCM, SCSM
Nachdem gestern die Anbindung des Service Manager an das Active Directory problemlos geklappt hat, ist heute nun der System Center Configuration Manager an der Reihe.
Im SCSM-Blog der belgischen System Center User Group finde ich den Hinweis, dass das dafür benötigte Connector Account Mitglied der „smsdbrole_extract“ und der „db_datareader“ Gruppen der SMS-Datenbank sein müsse. Das sagt mir im Moment mal leider gar nichts, denn ich kenne keine entsprechenden Einträge in der SCCM-Konsole. Ich schaue deshalb mal mit dem „SQL Server Management Studio“ in die Site-Datenbank rein und werde tatsächlich fündig: In der Site-Datenbank finde ich die beiden Bezeichnungen unter „Security“ -> „Roles“ -> „Database Roles“.
Ich erstelle deshalb im Active Directory ein passendes Service Account. Dieses kann ich nun als erstes dem SQL Server bekannt machen, indem ich unter der entsprechenden Datenbankinstanz -> „Security“ -> „Logins“ ein neues Login mit dem entsprechenden AD-Loginnamen vom Typ „Windows Authentication“ anlege. Unter „Server Roles“ ist bereits „public“ vorgegeben, unter „Status“ ist die Erlaubnis für das Verbinden zur Datenbank erteilt und das Login ist aktiviert.
Als nächstes kann ich nun bei der Site-Datenbank als User definieren, indem ich in der Site-Datenbank unter „Security“ -> „Users“ einen neuen Benutzer anlege. Hier kann ich nun beim Feld „Login Name“ nach dem betreffenden Benutzer suchen; als „User Name“ verwende ich wieder denselben Wert wie er nun beim „Login-Name steht. Unten in der Liste „Database Role Membership“ kann ich nun die beiden gewünschten Rollen „smsdbrole_extract“ und „db_datareader“ aktivieren.
Da nun die Prerequisites erfüllt sein sollten, wechsle ich nun auf unseren Service Manager. In der Konsole finde ich im Bereich „Administration“ unter „Getting started“ im Kasten „Create Connectors“ den Link „Create a Configuration Manager connector“, den ich nun mal anklicke. Damit wird der „System Center Configuration Manager Connector Wizard“ gestartet, der mir seine Willkommensseite präsentiert. Nach einem ersten Klick auf „Next“ werde ich nach einem Namen und einer Beschreibung gefragt, die ich passend angebe und dann wieder auf „Next“ klicke.
Nun werde ich nach einem Management Pack gefragt, wo dieser Connector gespeichert werden soll. Die einzige Auswahlmöglichkeit ist das Management Pack „System Center COnfiguration Manager Connector Configuration“, das ich mit einem Klick auf „Next“ übernehme.
Nun wird es spannend: Auf der nächsten Seite des Wizard sind nun die Angaben zur Datenbank notwendig. Als „Database Server Name“ trage ich unsere Named Instance in der Form „<Servername>\<Instancename>“ ein, als „Database Name“ das übliche „SMS_<Sitecode>“. Im Bereich „Credentials“ klicke ich nun beim „Run as Account“ auf „New…“ und erstelle damit ein neues „Run As Account“. Als „Display Name“ wähle ich „SCCM Connector Account“, trage eine passende Beschreibung ein und ergänze die entsprechenden Angaben zum AD-Konto. Ein Klick auf „OK“ und schon ist das neuerstellte Konto als „Run As“-Konto definiert. Erleichtert lese ich nach dem Klick auf „Test Connection“: „The connection to the server was successful.“
Auf der nächsten Seite des Assistenten kann ich nun die zu synchronisierende Collection wählen. Dabei werden mir alle Collections angezeigt, die mindestens ein Mitglied besitzen. Erfreut stelle ich mit einem kurzen Seitenblick zur SCCM-Konsole fest, dass die angezeigten Zahlen der enthaltenen Computer den Angaben im SCCM entsprechen: Wenn das kein gutes Omen ist! Nachdem ich „All Systems“ ausgewählt habe, klicke ich auf „Next“.
Nun muss ich noch den Schedule definieren, wann dieser Connector ausgeführt werden soll. Zur Auswahl wird mir „Every Day“ oder ein expliziter Wochentag angeboten, was einer wöchentlichen Synchronisierung entsprechen würde. Als Zeitpunkt kann ich jeweils eine volle Stunde wählen. Ich entscheide mich für täglich abends um 23 Uhr. So sollten die Veränderungen eines Tages im Configuration Manager am nächsten Tag im Service Manager nachgeführt sein.
Nach dem nächsten „Next“ wird mir nun noch das Summary präsentiert, worauf ich auf „Create“ klicke. Wenige Sekunden später erhalte ich die Meldung, dass ich den Wizard erfolgreich abgeschlossen hätte, den ich nun mit einem Klick auf „Close“ schliesse.
Zurück in der Konsole, nagiviere ich zu den „Connectors“ und sehe dort den neu erstellten Connector. Ich wähle diesen aus und klicke auf „Synchronize Now“. Dies wird sogleich bestätigt mit einer Meldung, dass der entsprechende Request abgesetzt worden sei. Der Status wird des Connectors wird nun als „Running“ angezeigt, zudem kann ich mitverfolgen, wie der Wert „Percentage“ langsam aber sicher steigt.
Etliche Zeit später – die Synchronisation grosser Produktionsumgebungen kann offenbar durchaus Stunden dauern – kann ich nun lesen: Status „Finished Success“, Percentage „100%“. Ich wechsle deshalb in den Abschnitt „Configuration Items“. Und siehe da: Nun sind zu den von SCCM verwalteten Computern detaillierte Informationen vorhanden.
Wenn doch bloss immer alles so einfach wäre und so reibungslos funktionieren würde…
Abgelegt unter: Anleitungen | Tags: AD, Connector, Konfiguration, SCSM
Heute will ich den System Center Service Manager ans Active Directory anbinden. Die Konsole ist geladen und zeigt mir an, was ich für das „Getting started“ noch alles tun sollte. Im Kasten „Import User Accounts“ sehe ich den Link „Import user accounts with the Active Directory Connector“, den ich nun mal anklicke. Der sog. „Active Directory Connector Wizard“ startet und zeigt mir seine Begrüssungsseite, die ich sogleich mit einem Klick auf „Next“ wieder verlasse.
Als erstes muss ich nun einen Namen und eine Beschreibung für den einzurichtenden Connektor eingeben; da das Häckchen bei „Enable this connector“ schon gesetzt ist, klicke ich anschliessend auf „Next“.
Auf der nächsten Seite „Select a domain or organizational unit“ schlägt mir der Wizard automatisch vor, die ganze Domäne, welcher der Service Manager Server angehört, anzubinden; ich hätte jedoch auch die Möglichkeit, eine andere Domäne oder auch nur eine einzelne Organisationseinheit zu wählen. Ebenso muss ich hier das Konto angeben, welches für den Zugriff auf das Active Directory verwendet werden soll. Die entsprechende Auswahl enthält bereits das „Operational System Account“ und das „Workflow Account“, der Knopf daneben bietet mir an, ein weiteres Konto für den Service Manager zu definieren. Ich wähle allerdings der Einfachheit halber das vorgeschlagene „Operational System Account“, über den Knopf „Test Connection“ kann ich sogleich überprüfen, ob der Zugriff ins Active Directory klappt: „The connection to the server was successful“, darf ich lesen; klappt perfekt!
Auf der nächsten Seite „Select Objects“ muss ich nun auswählen, ob ich alle Computer, Drucker, Benutzer und Benutzergruppen übernehmen will, oder ob ich gezielter auswählen möchte. Ich bin mit dem vorgeschlagenen „All…“ einverstanden und klicke wiederum auf „Next“.
Schon erhalte ich die Summary-Seite, die mir nochmals meine getätigten Angaben präsentiert. Sieht alles gut aus, also klicke ich auf „Create“. Wenige Sekunden später erhalte ich die Meldung, dass der Active Directory Connector erfolgreich erstellt worden sei und schliesse den Wizard mit „Close“.
Nun wechsle ich wieder zurück in die Service Manager Console in den Abschnitt „Administration“ und navigiere zu „Connectors“. Siehe da, einen Moment später kann ich bereits lesen, dass der Status „Finished Success“ sei.
Ich wechsle deshalb in den Abschnitt „Configuration Items“ und stöbere dort etwas herum. Tatsächlich: alle Userobjekte, alle Printqueues und alle Computerobjekte sind im Service Manager angekommen.
Nun habe ich mich noch gefragt, ob ich noch einen Zeitplan definieren muss, wie häufig dieser AD-Connector synchronisieren soll. Doch in einem Blog-Post des Service Manager Teams finde ich rasch die Information, dass ein aktivierter AD-Connector automatisch jede Stunde gestartet wird, um allfällige Änderungen an Objekten im AD zu übernehmen. Wird mal schneller eine Synchronisation benötigt, kann die jederzeit über „Synchronize now“ gestartet werden.
Das lief ja mal wieder wie am Schnürchen, also schaue ich mal noch gleich, was mir angeboten wird, wenn ich im Kasten „Import User Accounts“ auf der Administration-Seite auf den Link „Create and assign user roles“ klicke. Wie ich feststelle, navigiere ich damit zu „Administration“ -> „Security“ -> „User Roles“. Hier finde ich standardmässig angebotene Rollen wie „Authors“, „End Users“, „Problem Analysts“, „Incident Resolvers“ usw.
Also schaue ich mir diese Rollen mal kurz durch und finde bei den folgenden drei Rollen bereits Mitgliedschaften (alle übrigen Rollen enthalten noch keine Mitglieder):
- Mitglieder der Rolle „Administrators“ haben volle Zugriffsrechte auf alle Operationen und auf alle Objekte im System; als standardmässige Mitglieder finde ich hier mein Account, unter welchem ich den Service Manager installiert habe, das „Operational System Account“ sowie diejenige AD-Gruppe, die ich bei der Installation angegeben habe, als ich nach einer Gruppe gefragt wurde, welche Administrative Rechte für diese Management Gruppe erhalten soll. Passt!
- Mitglieder der Rolle „End Users“ dürfen laut Beschreibung auf das Self-Service-Portal zugreifen, Incidents anlegen, die Installation von Software verlangen, Announcements lesen und in der Knowledge Base suchen; standardmässig ist hier „Authenticated Users“ eingetragen, was meiner Meinung nach ebenfalls Sinn macht.
- In der Rolle „Workflow“ finde ich das „Workflow Account“ wieder. Workflows werden laut Beschreibung automatisch durch den Service Manager gestartet und können beliebige Configuration und/oder Work Items erstellen. Auch das macht Sinn.
Somit denke ich, dass die Aktivität „Import User Accounts“ für den Moment abgeschlossen ist und mache somit Schluss für heute.