SCORCH

Automatisierung mit System Center Service Manager und Orchestrator – Onboarding neuer Benutzer

Automatisierung mit System Center Service Manager und Orchestrator – Onboarding neuer Benutzer

Heute präsentiere ich Ihnen eine massgeschneiderte Lösung, die ich bei einem unserer wichtigsten Kunden implementiert habe. Diese basiert auf der Integration der beiden System Center Komponenten – Service Manager und Orchestrator.

System Center 2012 R2 Service Manager und Orchestrator sind an sich selbst mächtige Tools wenn es um „Service Management“ und „Automatisierung“ geht. Das volle Potential der beiden Komponenten wird aber erst dann erkennbar, wenn man diese miteinander, zwecks Automatisierung und Self-Service, integriert.

Die Aufgabe: Unser Kunde wollte den Prozess der Erfassung neuer Benutzer optimieren, weil man festgestellt hat, dass dieser so gestaltet ist, dass es sehr lange dauert bis das Benutzerkonto eines neuen Mitarbeiters erstellt wird und dass zu viele Leute des Personals involviert sind. Vor der Implementierung der Lösung sah der Prozess folgendermassen aus:

  • Der Personalverantwortliche jeder Abteilung musste alle Benutzerangaben (Namen, Adressen, Kontaktinfos, Position, etc.) erfassen und ein E-Mail an den entsprechenden Vorgesetzten schreiben.
  • Der Vorgesetzte und ein Mitarbeiter aus der Personalabteilung mussten die Anstellung des neuen Mitarbeiters bestätigen.
  • Die Personenangaben wurden an den IT-Support geschickt, so dass das Benutzerkonto in Active Directory mit den notwendigen Gruppenmitgliedschaften erstellt werden konnte. Je nachdem wie die neu angestellte Person mit Vor und Nachnamen hiess, musste dem Benutzer ein Laufwerk auf einem bestimmten Fileserver zugeordnet werden. Danach musste der IT-Supporter dem für den Bereich Exchange zuständigen IT-Spezialist ein E-Mail schicken, so dass die Exchange Mailbox erstellt werden konnte. Zusätzlich musste der Personalverantwortliche über das temporäre Kennwort des neuen Benutzers informiert werden.
  • Anschliessend musste die Abteilung „Infrastruktur“ über die Anstellung des neuen Mitarbeiters informiert werden, so dass diverse Hardware und andere Hilfsmittel zur Verfügung gestellt werden konnten.

Wie man sieht handelt es sich um einen Prozess, der in einer ähnlichen Form häufig in einer Unternehmensinformatik anzutreffen ist. Nun zu der Lösung. Diese beinhaltet ein Orchestrator Runbook, Service Manager Requests, Service Offerings und Service Request Vorlage mit diversen Review-Aktivitäten. Wichtige Voraussetzungen für die fehlerfreie Funktion dieser Lösung sind sowohl die Integration der involvierten System Center 2012 R2 Komponenten (SCSM und SCOrch) mit Active Directory, als auch ein funktionsfähiger Exchange Konnektor für Service Manager. Bevor ich Ihnen die einzelnen Schritte präsentiere, möchte ich nur vermerken, dass auch andere Methoden existieren, um mit SCSM und SCOrch diesen Prozess zu automatisieren. Eine Alternative wird in dem folgenden Microsoft Blog im Detail beschrieben:

System Center 2012 Service Manager and Orchestrator Integration Example Walkthrough Start-to-Finish – New Hire Provisioning Service Request
https://blogs.technet.com/b/antoni/archive/2014/04/09/system-center-2012-service-manager-and-orchestrator-integration-example-walkthrough-start-to-finish-new-hire-provisioning-service-request.aspx

Kurz nachdem ich begonnen habe, meine Lösung zu konzipieren, habe ich die folgenden Herausforderungen identifiziert:

  • Die Laufwerk- und Mailboxzuweisung erfolgt nach einer entsprechenden Logik, was Skripting mit PowerShell voraussetzte. Ich war nicht in der Lage die integrierten Orchestrator Aktivitäten „Create User“ (Active Directory Integration Pack) und „Create Mailbox“ (Exchange Integration Pack) zu benutzen. Eine kurze Recherche im Internet hat ergeben, dass es Integration Packs von Drittanbietern gibt, die ähnliche Funktionalitäten bieten, trotzdem habe ich mich in diesem spezifischen Fall für PowerShell entschieden.
  • Da ich in Orchestrator mit PowerShell Remote-Sitzungen zu den Domänencontrollern und dem Exchange-Server gearbeitet habe, musste ich auch eine Möglichkeit finden einige von den Variablen lokal auf dem Orchestrator Data Bus zu veröffentlichen, so dass diese in den nachfolgenden Aktivitäten wieder verwendet werden können. Im Normalfall bleiben die Daten innerhalb der jeweiligen PowerShell Remote-Sitzung verfügbar.
  • Die Anzahl an Parameter, die man in dem SCSM Self-Service Portal eingeben sollte, war so gross, dass die Anzahl an Parameter Mappings, die standardmässig in der „Runbook Automation Activity“ Vorlage in Service Manager zur Verfügung stehen, nicht ausreichend waren. Ich benötigte mindestens 5 zusätzliche Parameter vom Typ „String“ und noch einige vom Typ „Boolean“.
  • Ich sollte dem Benutzer, der das neue Konto auf dem Self-Service Portal erfasst, die Möglichkeit bieten den neuerstellten Benutzer zu unterschiedlichen Active Directory Gruppen hinzuzufügen, die auch diverse Rollen in der Umgebung des Kunden darstellen.

Wie sahen die einzelnen Schritte aus?

 

1. Orchestrator Runbook Vorbereiten

 

Capture

Das Orchestrator Runbook beinhaltet die folgenden Aktivitäten:

 

Initialize Data

Diese Aktivität beinhaltete alle Parameter, die man während der Benutzererfassung auf dem Self-Service Portal eintragen musste:

Capture1

Folgendes ist hierbei wichtig: Wenn man die Parameter in der „Initialize Data“ einmal definiert und mit dem Service Manager synchronisiert hat, darf man diese nicht mehr ändern. Sobald diese geändert werden, erscheint der entsprechende Runbook in der Service Manager Library, unter „Runbook“ mit dem Status „Invalid“, muss gelöscht und danach erneut synchronisiert werden.

 

Get Group Relationship, Get Group Object, get Parent SR Relationship, Get SR Object

Diese Aktivitäten sind Teil des “ System Center Integration Pack for System Center 2012 Service Manager“ und haben den Zweck die Beziehungen zwischen dem Service Request im Service Manager, der Active Directory Gruppe und der Runbook Automation Activity aufzudecken. Genau diese Beziehungen ermöglichen das automatische Hinzufügen des erstellten Kontos zu einer auf dem Portal ausgewählten Active Directory Gruppe. Da dies an sich ein grosses Thema ist, würde ich Ihnen empfehlen den ausgezeichneten Blogpost von Travis Wright zu lesen. Dieser erklärt ausführlich alle Details zu den o.g. Aktivitäten:

Working with Relationships in the SCSM Orchestrator Integration Pack
https://blogs.technet.com/b/servicemanager/archive/2012/05/22/working-with-relationships-in-the-scsm-orchestrator-integration-pack.aspx

Ein weiterer Artikel von Bob Roudebush beinhaltet sowohl eine ausführliche Anleitung in Bezug auf die Konfiguration der einzelnen Aktivitäten, als auch viele Details zu den Einstellungen der Request und Service Offerings:

Add User to Group Automated Request Offering Walkthrough
https://blogs.technet.com/b/servicemanager/archive/2012/06/25/add-user-to-group-automated-request-offering-walkthrough.aspx

 

Generate User Password

Diese Aktivität ist Teil des „Active Directory Integration Pack for System Center 2012 – Orchestrator” und damit kann man die Komplexität des Benutzerkennworts recht einfach bestimmen:

Capture2

 

Create and Enable the User

Diese „Run .Net Script“ (Typ: PowerShell) Aktivität ist „das Herz“ des Runbooks. Das Skript habe ich entwickelt um die folgenden Aufgaben zu erfüllen:

  • Der SamAccountName des Benutzers wird aus Vor- und Nachnamen erstellt. Es wird geprüft, ob dieser in der jeweiligen Domäne einmalig ist. Sollte bereits der SamAccountName vorhanden sein, werden Zahlen angehängt (Anforderung des Kunden). An der Stelle werden auch die Umlaut (falls eingegeben) durch die entsprechenden Buchstaben „a“, „o“, „u“ ersetzt.
  • Der Benutzer wird in einer Organisationseinheit in Active Directory erstellt, die durch das Eingabefeld (Portal) „Abteilung“ bestimmt wird.
  • Dem Benutzernamen entsprechend, wird ein Laufwerk zugeordnet.
  • Es werden weitere Attribute des Benutzerkontos gesetzt – Adresse, Telefon, Internetseite, Fax und viele mehr.
  • Das Kennwort aus der vorherigen Aktivität wird als temporäres Kennwort gesetzt. Der Benutzer wird aufgefordert, es bei der ersten Anmeldung zu ändern (ChangePasswordAtLogon:$true)

Da ich mit Variablen gearbeitet habe ($SamAccountName, $UPN, $Alias, $Identity), die standardmässig ausserhalb der PS- Remotesitzung nicht verfügbar sind, konnte ich sie in den weiteren Aktivitäten nicht verwenden. Ich musste also einen Weg finden, diese Variablen auf dem Orchestrator Datenbus zu veröffentlichen, so dass ich später mit deren Hilfe den Benutzer zu einer Gruppe hinzufügen kann und ihm die Mailbox zuweisen kann. Dieses Ziel konnte wie nachfolgend beschrieben erreichen.

Zuerst habe ich die Variablen innerhalb der Aktivität definiert:

Capture3

Danach musste ich diese im Rahmen des Skriptes so definieren, so dass sie ausserhalb der Sitzung verfügbar sind:

Invoke-Command -Session $PSSession -ScriptBlock{…} #PS-Remotesitzung
$SamAccountName = Invoke-Command -Session $PSSession -ScriptBlock { $SamAccountName }
$UPN = Invoke-Command -Session $PSSession -ScriptBlock { $UPN }
$Alias = Invoke-Command -Session $PSSession -ScriptBlock { $Alias }
$Identity2 = Invoke-Command -Session $PSSession -ScriptBlock { $Identity2 }

Im Anschluss konnte man mit dem Runbook Tester verfolgen, dass die o.g Variablen tatsächlich für die weiteren Aktivitäten (Assign a Mailbox to the User, Get User, Add User to Group, etc.) zur Verfügung gestellt wurden.

 

Assign a Mailbox to the User

Mit dieser “Run .Net Script” (PowerShell) Aktivität wird die Benutzermailbox nach einer bestimmten Logik erstellt (Je nachdem welches der erste Buchstabe des Nachnamens ist, sollte die Mailbox auf einer der drei unterschiedlichen Datenbanken erstellt werden).

 

Get AD Group

Diese Aktivität ist auch Teil des “Active Directory Integration Pack for System Center 2012 Service Manager“ und dient dazu die Gruppe zu liefern, zu der der Benutzer hinzugefügt werden soll. Diese Aktivität hat den folgenden Filter:

Capture4

Name: Sam Account Name
Relation: Equals
Value: {User Name from “Get Group Object”}

 

Get User

Diese Aktivität liefert den Benutzer, der als nächstes der Gruppe hinzugefügt wird. Für den Filter habe ich die mit der „Create and Enable the User“ Aktivität veröffentlichte Variable $SamAccountName benutzt:

Capture5

Name: Sam Account Name
Relation: Equals
Value: {SamAccountName from “Create and Enable the User”}

 

Add User to Group

Diese Aktivität ist Teil des „Active Directory Integration Pack for System Center 2012 – Orchestrator” und fügt den Benutzer der gewünschten Gruppe hinzu.

Capture6

 

Send Email

Diese Aktivität ist Teil des „Exchange Users Integration Pack for Orchestrator in System Center 2012“ und ist recht einfach zu konfigurieren. Ich habe in diesem Fall drei unterschiedliche Aktivitäten benutzt, da ich unterschiedliche Inhalte an unterschiedliche Empfänger versendet wollte:

Capture7

 

Fehlerbehandlung

Ich habe einen einfachen Mechanismus zur Fehlerbehandlung eingebaut, welcher dafür sorgt, dass die verantwortliche Person eine E-Mail bekommt, sollte eine der oben beschriebenen Aktivitäten fehlschlagen. Ich musste nur die Eigenschaften der Links (mit roter Farbe) anpassen, so dass die Mail dann versendet wird, wenn die Aktivität den Status „failed“ hat.

Capture_0

 

2. Runbook Automation Activity konfigurieren

 

Nachdem das Runbook fertig war, habe ich die Synchronisation über den Orchestrator Konnektor erzwungen und sichergestellt, dass das Runbook im Service Manager, unter Library ->Runbooks mit dem Status „Active“ verfügbar ist. Hieraus habe ich eine neue „Runbook Automation Activity“ Vorlage erstellt und diese in einem selbst erstellten, unversiegelten Management Pack gespeichert. Die somit erstellte Vorlage ist auf dem Service Manager, unter Library->Templates, unter dem angegebenen Namen zu finden.

Die Konfigurationsfelder unter der Karte „General“ kann man beliebig ausfüllen. In diesem Fall ist es sehr wichtig, dass man das Kästchen mit der Option „Is Ready for Automation“ aktiviert. Tut man das nicht, wird die Runbook Automation Activity innerhalb des Service Requests das Runbook nicht starten:

Capture8

Der nächste Schritt wäre, unter der Karte „Runbook“, die Parameter Mappings zuzuteilen:

Capture9

Hier kam die nächste Herausforderung: Es existierten keine ausreichenden Mappings (Edit Mapping->Runbook Automation Activity), so dass ich alle im Runbook vordefiniertem Parameter unterbringen konnte. Der Service Manager bietet standardmässig 10 „Text“ (Text 1-10) und 5 „Long Text“ (Long Text1-5) Mappings zur Auswahl. Zu Hilfe kam das Service Manager Authoring Tool, mit dem man spezifische Anpassungen im SCSM vornehmen kann. Damit konnte ich schnell und einfach die Klasse „Runbook Automation Activity class“ erweitern und neue Properties vom Datentyp „String“ (Text 11, Text 12 – 20, Long Text 6-10) hinzufügen. Das hat dazu geführt, dass mir in der Runbook Automation Activity Vorlage die neuen Properties zur Auswahl standen und ich somit in der Lage war alle Runbook Parameter (Initialize Data) abzubilden.

Capture10

Wichtig ist hier die entsprechenden Mappings (z.B Vorname -> Text1, Nachname -> Text2 usw.) aufzuschreiben, weil diese danach nochmals im Rahmen des Request Offerings genauso abgebildet werden müssen.

 

3. Service Request Vorlage erstellen

 

Nachdem die Runbook Automation Activity angepasst war, kam die Service Request Vorlage an der Reihe. Aus dieser Vorlage werden jedes Mal separate Service Requests im Service Manager erstellt, wenn man die Benutzerinformationen im Self-Service Portal eingibt und die Anfrage einreicht. Sie beinhaltet auch die Schritte zur Genehmigung des entsprechenden Service Requests – Genehmigung seitens des Personalverantwortlichens, Genehmigung seitens der Personalabteilung, des IT-Supports und als letzten Schritt – die oben beschriebene Runbook Activity.

Capture11

Wie bei der Runbook Automation Activity kann man die Felder „Urgency“, „Priority“, „Source“, „Area“ unter der Karte „General“ beliebig konfigurieren.

Die interessanteste Aktivität ist die „PVA Review Activity“, weil hier die Option „Line Manager Should Review“ aktiviert ist. Diese Option setzt eine funktionierende Synchronisation der Konfigurationselemente (Benutzer, Computer, Drucker, etc…) mit Active Directory voraus und sorgt dafür, dass die Genehmigung dem Abteilungsleiter zugestellt wird. Hierbei wird das Attribut „manager“ des Active Directory Kontos der Person ausgelesen, die den neuen Benutzer im Self-Service Portal erfasst.

Capture12

Im Gegenteil zu dieser Review Activity, haben die anderen beiden Aktivitäten (Org Personal Review Activity, IT Support Review Activity) in dem Feld „Reviewers“ statische Einträge für die Benutzer/Gruppen, die für die Genehmigung verantwortlich sind.

Erst nachdem alle drei Instanzen zugestimmt haben, darf das Runbook im Orchestrator über die „Provision New User Activity“ gestartet werden.

 

4. Request Offering vorbereiten und veröffentlichen

 

Zuerst ganz kurz zu der Definition von Request Offerings (Quelle Microsoft Technet): „Requestangebote sind Katalogobjekte, durch die Objekte, Hilfe oder Aktionen beschrieben werden, die dem Endbenutzer im Dienstkatalog von System Center 2012 – Service Manager zur Verfügung stehen. Sie werden in der Regel in logische Gruppen in Form von Dienstangeboten zusammengefasst. Dienstangebote und zugehörige Requestangebote werden für Self-Service-Portal-Benutzer verfügbar, wenn ihr Status „Veröffentlicht“ lautet und Endbenutzer der entsprechenden Service Manager-Benutzerrolle zugewiesen wurden.“

Also definiert das Request Offering welche Informationen von dem Portalbenutzer angefordert werden und welche zurückgegeben werden. Ich werde die trivialen Eingaben (Title, Description, usw.) überspringen und mehr zu den Besonderheiten bei der Konfiguration der einzelnen Feldern sagen (die s.g. Prompts), die der Benutzer auf dem Portal zwingend ausfüllen muss. Zuerst definiert man die Felder (Vorname, Nachname, Abteilung, …) und auch den entsprechenden Typ des Prompts (Text, Simple List, Date, True/False, Query Results) und danach hat man die Möglichkeit je nach Typ diese einzeln zu konfigurieren.

Capture13

So sieht beispielsweise die Konfiguration eines Strings aus:

Capture14

Wenn man detaillierte Informationen bezüglich der zahlrechen Konfigurationsmöglichkeiten benötigt, würde ich den folgenden Microsoft Blogpost von Neil Lydickg empfehlen:

Request Offering Wizard Overview
https://blogs.technet.com/b/servicemanager/archive/2011/11/08/request-offering-wizard-overview.aspx

Am Interessantesten in unserem Fall ist die Konfiguration der Gruppenmitgliedschaft (Role) vom Typ „Query Result“, die dazu dient, die Active Directory Gruppe abzufragen, zu der der Benutzer hinzugefügt wird. Wenn man das Feld „Role (Gruppenmitgliedschaft)“ markiert und dann auf „Configure“ klickt, startet der Wizzard, in dem ich Folgendes konfiguriert habe:

 

  • Karte „Select Class“

Hier habe ich die Klasse „Domain User or Group“ ausgewählt, so dass mir das Portal nur solche Treffer anzeigen kann:

Capture15

 

  • Karte „Configure Criteria (optional)“

Hier habe ich die Liste der Gruppen weiter limitiert, in dem ich nur Gruppen anzeigen lasse, deren Name das Schlüsselwort „ROLE“ beinhaltet (Alle Active Directory Gruppen, die pro Abteilung erstellt wurden, beinhalteten dieses Wort).

Capture16

 

  • Karte „Display Columns“

Hier kann man definieren mit welchen Eigenschaften die Gruppe im Portal angezeigt wird. Als Minimum hat man den Anzeigenamen, ich habe mich jedoch für das Format Domänenname\Gruppenname entschieden.

Capture17

 

  • Karte „Options“

Hier ist es wichtig die Gruppe als „related item“ zu der Service Request Vorlage und als „configuration item“ zu der Runbook Automation Activity hinzuzufügen. Tut man das nicht, hat das Runbook keine Möglichkeit über die „Get Relationship“ Aktivitäten die genaue Gruppe aus der entsprechenden Vorlage zu bestimmen und den Benutzer zu dieser hinzuzufügen.

Capture18

Der nächste wichtige Schritt bei der Konfiguration des Request Offerings wäre die Mappings, die man vorher aufgeschrieben hat, auf die im Portal angezeigten Felder abzubilden.

Capture19

Anschliessend kann man einen Knowledge Artikel hinzufügen und den Status des Request Offerings auf „Published“ setzen (Ein Request Offering mit dem Status „Draft“ wird auf dem Portal nicht erscheinen).

 

5. Service Offering veröffentlichen

 

Wie bereits erwähnt hilft das Service Offering vorhandene Request Offerings logisch auf dem Portal zu gruppieren. Wie beim Request Offering muss der Status des Service Offerings auf „Published“ gesetzt werden, so dass das Dienstleistungsangebot auf dem Portal zu sehen ist.

Capture20

Nachdem das Service Offering auf „Published“ gesetzt und mit „OK“ bestätigt wird, erscheint es auf dem Portal. Beim Klick darauf sieht man, dass das Request Offering auch zur Auswahl steht.

Capture21

Im Anschluss muss man nur alle Felder auszufüllen, die Anfrage einreichen und auf die Genehmigung der involvierten Instanzen warten. Der Rest wird fleissig vom Service Manager und Orchestrator erledigt.

Die Automatisierung dieses Onboarding-Prozesses hat für den Kunden nicht nur einen wirtschaftlichen, sondern auch einen technischen (funktionellen) Mehrwert. Neben der Zeit- und Kostenersparnis sorgt die Lösung auch dafür, dass die Erstellung des neuen Benutzers jedesmal genau gleich verläuft und manuelle Fehleingaben verhindert werden.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.