Testumgebung

Der Umgang mit PowerShell in der Administration sowie die Anwendung als Automatisierungssprache ist inzwischen weit verbreitet. Dennoch bestehen große Unsicherheiten bzgl. einer zentralen Verwaltung von Scripten, Richtlinien zur Ausführung von Scripten, Rechten und Sicherheit, Nachvollziehbarkeit, Delegationsmöglichkeiten und vielem mehr. Alles Gründe, um ScriptRunner im eigenen Umfeld zu testen. Dieser Leitfaden hilft Ihnen dabei.

Für einen ersten Eignungstest bedarf es nur weniger Systeme in Ihrer Infrastruktur. Im einzelnen werden benötigt:

  • Active Directory zur Anlage von wenigen Sicherheitsgruppen
  • virtuelle Maschine für den ScriptRunner Server in einer Windows Domäne mit administrativen Zugriff
  • virtuelle Maschine als Zielsystem in einer Windows Domäne zum entfernten Ausführen von PowerShell-Testscripten
  • Client mit einem Web-Browser (IE11, Edge, Chrome, Firefox oder Opera)

Um die erweiterten Test Cases mit Exchange, Office 356, File- und Print Servern sowie mit Hyper-V oder VMware ausführen zu können, benötigen Sie Zugang zu den entsprechenden Systemen.

Ja Nicht Änderung vorschlagen

Vorbereitungen für den Test

Gruppen und Benutzer im Active Directory

Für die ordnungsgemäße Funktion der Rollen in ScriptRunner werden mindestens zwei Sicherheitsgruppen im Active Directory sowie ein administrativer Benutzer-Account und ein Standardbenutzer-Account benötigt.

  • Administrativer Benutzer-Account: Dieser sollte auch Administratorrechte auf der benötigten Test-VM haben. Wir empfehlen, Ihren persönlichen Admin-Account zu verwenden, sofern dieser über ausreichende Rechte verfügt.
  • Standardbenutzer-Account: Dieser benötigt keine administrativen Rechte. Wir empfehlen, Ihren persönlichen Standardbenutzer-Account zu verwenden.
  • Sicherheitsgruppe für ScriptRunner Haupt-Administratoren: Legen Sie eine Sicherheitsgruppe an. Diese kann sich an Ihren Namenskonventionen ausrichten, z.B. „SR-Main-Admins“. Nehmen Sie Ihren und ggfs. weitere administrative Benutzer-Accounts in diese Gruppe auf.
  • Sicherheitsgruppe für ScriptRunner Service Desk Anwender: Legen Sie eine Sicherheitsgruppe an. Diese kann sich an Ihren Namenskonventionen ausrichten, z.B. „SR-ServiceDesk“. Nehmen Sie Ihren und ggfs. weitere Standardbenutzer-Accounts in diese Gruppe auf. Es können auch bereits bestehende Sicherheitsgruppen verwendet werden.

Für Endanwender Self Services:

  • Optional: Sicherheitsgruppe für ScriptRunner Self-Service Endanwender. Legen Sie eine Sicherheitsgruppe an. Diese kann sich an Ihren Namenskonventionen ausrichten, z.B. „SR-SelfService-User“. Nehmen Sie Ihren und ggfs. weitere Standardbenutzer-Accounts in diese Gruppe auf. Es können auch bereits bestehende Sicherheitsgruppen verwendet werden.

Für Multi-Team und Multi-Mandanten-Betrieb:

  • Optional: Sicherheitsgruppe für ScriptRunner Administratoren (Team oder Mandant). Legen Sie eine Sicherheitsgruppe an. Diese kann sich an Ihren Namenskonventionen ausrichten, z.B. „SR-AD-Team“ oder SR-Kundenname. Nehmen Sie die entsprechenden Admin-Accounts in diese Gruppe auf. Es können auch bereits bestehende Sicherheitsgruppen verwendet werden.

Für die ordnungsgemäße Funktion der PowerShell Richtlinien in ScriptRunner werden Credentials mit administrativen Rechten benötigt. Sie können hierfür separate technische Service-Accounts anlegen, bestehende technische Service Accounts verwenden oder ausschließlich für Testzwecke ihren persönlichen administrativen Account verwenden.

Virtuelle Maschine für ScriptRunner Server

Es wird empfohlen, die Installation von ScriptRunner Server auf einer virtuellen Maschine vorzunehmen. Die virtuelle Maschine benötigt folgende Grundeinstellungen:

  • Windows Server 2019, Windows Server 2016 oder Windows Server 2012R2 als Member Server in einer Domäne
  • CPU: min. 2 Cores, produktiv min. 4
  • Speicher: min. 8 GB RAM und 64 GB Disk (SSD o.ä. bevorzugt)
  • .NET Framework 4.6 oder höher
  • Management Framework 5 mit PowerShell 5.1
  • WinRM Service ist aktiv
  • PowerShell Execution Policy und PowerShell Remoting ist eingeschaltet inkl. der Firewall Rules
  • Internet Explorer 11 mit gültiger eingetragener „local intranet zone“ und deaktivierter enhanced security (im Server Manager)

Zusätzlich sollten Sie mittels Server Manager das Feature „Active Directory PowerShell Module“ aus der Featuregruppe Remoteserver Verwaltungstools -> Rollenverwaltungstools -> AD und DS Tools installieren.

Einrichten der Web Server Rolle auf dem Server

Die ScriptRunner Web Apps sind JavaScript-Anwendungen und lauffähig in Edge, Chrome, Firefox, Opera und Internet Explorer 11. Für die Verteilung der Web Apps an die Clients wird ein Web Server genutzt. Verwenden Sie zum Testen den IIS auf dem ScriptRunner Server. Installieren Sie über den Server Manager die Rolle „WebServer (IIS)“ mit den Verwaltungsprogrammen ohne weitere Zusatzfeatures. Für den Test verwenden Sie den IIS und die ScriptRunner Web Apps über HTTP. Vor einer späteren produktiven Nutzung können Sie den IIS und den Web Service auf dem ScriptRunner Server einfach auf HTTPS rekonfigurieren.

Hinweis

Internet Explorer 11 verwendet eine veraltete Rendering Engine zur Darstellung von Webseiten. Das kann zu Darstellungs- und Performanceproblemen in den ScriptRunner Apps führen.

Zweiter Server für den Test mit PowerShell Remoting

Für die Ausführung von PowerShell-Scripten über PowerShell Remoting wird eine entsprechende zweite Testmaschine benötigt. Sie können dafür auch eine bereits vorhandene Testmaschine verwenden. Es werden in einem ersten Funktionstests nur PowerShell-Scripte ausgeführt, welche keine Veränderungen am System vornehmen. Die virtuelle Maschine und der Zugriff durch ScriptRunner benötigen folgende Grundeinstellungen:

  • Windows Server 2019, Windows Server 2016 oder Windows Server 2012R2 als Member Server in einer Domäne
  • WinRM Service auf der zweiten Maschine ist aktiv
  • PowerShell Execution Policy und PowerShell Remoting ist eingeschaltet inkl. der Firewall Rules
  • technischer Service-Account oder administrativer Account, welcher für die Ausführung von PowerShell-Scripten auf dieser Maschine berechtigt ist

Öffnen Sie die PowerShell als Administrator und verwenden Sie folgende Befehle:

> Get-ExecutionPolicy -List
>
> Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope LocalMachine -Force -Verbose
>
> Enable-PSRemoting -Force

Prüfen Sie, ob die PowerShell Einstellungen auf beiden virtuellen Maschinen mittels GPO gesteuert werden! Zur Konfiguration der PowerShell-Einstellungen können Sie auch die PowerShellConfigWizard.EXE  aus unserem Setup Paket verwenden.

Wenn Sie mit Firewalls oder Proxies arbeiten

Stellen Sie sicher, dass die beiden Test-VMs von Ihrem Client mittels Browser über HTTP erreichbar sind. Neben Port 80 wird auch der Port 8091 für die REST-Kommunikation mit dem ScriptRunner Web Service Interface benötigt. Für die Kommunikation zwischen dem ScriptRunner Server und dem zweiten Server über PowerShell Remoting wird der Standard Port 5985 für WinRM/PowerShell verwendet.  Dieser sollte sowohl auf der lokalen Firewall als auch in einer ggfs. dazwischenliegenden Firewall freigeschaltet sein. Bei Aktivierung der PowerShell Execution Policy und Remote Powershell werden alle notwendigen Einstellungen an der lokalen Windows Server Firewall automatisch vorgenommen. Hier erfahren Sie mehr über die verwendeten Protokolle und Ports im Detail.

Ja Nicht Änderung vorschlagen

Schnelle Installation

Verwenden Sie zum Durchführen der Installation ausschließlich die aktuellen ScriptRunner Setup-Dateien. Diese können Sie über unsere Support Seite anfordern. Ein Link auf den Download der Setup-Dateien wurde Ihnen bereits in der gleichen E-Mail mit dem Link auf diesen Leitfaden zugesendet.

  1. Erstellen Sie einen Snapshot der ScriptRunner Server VM vor der Installation.
  2. Entpacken Sie die ZIP-Datei mit den Setup-Dateien auf der ScriptRunner Server VM
  3. Führen Sie zuerst SetupScriptRunnerService_version.EXE aus

Es werden der zentrale ScriptRunner Dienst und alle Funktionen des ScriptRunner Servers sowie ein Set an Windows Performance-Countern installiert.

Wichtiger Hinweis

Ändern Sie die Gruppe für die ScriptRunner Haupt-Administratoren auf der entsprechenden Setup-Page. Geben Sie dazu den Gruppennamen der von Ihnen dafür angelegten Sicherheitsgruppe ein und drücken Sie Verifizieren. Anschließend wird Ihnen der Security-Claim dieser Gruppe angezeigt. Sollte ein Fehler auftreten, so ist die Verbindung des ScriptRunner Servers zum Active Directory gestört.

Kontrollieren Sie den neu installierten „ScriptRunner Service“. Dieser muss gestartet sein. Treten Fehler bei der Installation auf, so prüfen Sie das Setup-Log in Drive:\Program Files\ScriptRunner\ScriptRunnerService

Führen Sie anschließend SetupScriptRunnerWebApps_version.EXE  mit der Option Deploy to IIS aus. Geben Sie auf der entsprechenden Setup-Page den vollständigen FQDN des ScriptRunner Servers an und verwenden den Standard-Port 8091. Lassen Sie die SSL inaktiv!

Tipp

Bei der Installation prüft das Setup, ob der ScriptRunner Web Service unter der angegebenen URI per HTTP (oder HTTPS) erreichbar ist.

Wenn Sie auf Ihren Admin und DevOps Clients die ScriptRunner ISE App verwenden wollen, so führen Sie SetupScriptRunnerTeamApps_version.EXE  dort jeweils aus und wählen die Option „ISE Plugin“ aus und die beiden anderen Apps ab. Wenn Sie das ISE PlugIn nutzen wollen, muss Ihr Client-Anmelde-Account Mitglied in der Sicherheitsgruppe für ScriptRunner Haupt-Administratoren bzw. ScriptRunner Administratoren sein.

Ja Nicht Änderung vorschlagen

Einfache Erstkonfiguration

Für die einmaligen Einstellungen am ScriptRunner Server wird das PowerShell Modul ScriptRunnerSettings verwendet. Öffnen Sie die PowerShell als Administrator. Geben Sie folgende Befehle ein:

> get-asrlicense # Ausgeben der Lizenzinformationen
> 
> get-asrservice # Ausgeben des Status des ScriptRunner Dienstes
>
> test-asruri    # Ausgeben des Status des Web Service Endpoint

Zur Konfiguration der E-Mail-Notification-Funktionen zum Versenden von Benachrichtigungen über SMTP verwenden Sie folgende Befehle:

> # Anzeigen der Standardeinstellungen am Connector
> Get-ASREmailNotificationConnector -Verbose
>
> # Einstellungen am Connector vornehmen
> Set-ASREmailNotificationConnector -ON -Host 'MyHostName' -Port pnr -UseTLS yes/no -Sender scriptrunner@mydomain -Restart -Verbose
>
> # Test-E-Mail versenden
> Test-ASREmailNotificationConnector -Receipient Empfaenger@MyDomain

Hinweis

Für den authentifizierten Versand von E-Mails verwenden Sie die weiteren Optionen des Set-Cmdlets. Bei Fehlern beim Versenden der Test-E-Mail werden SMTP-Fehlercodes angezeigt. Schauen Sie zur Fehlersuche in den Logs Ihres Mailservers nach.

Ja Nicht Änderung vorschlagen

Erster Funktionstest

Melden Sie sich mit Ihrem administrativen Account an einem Client an und starten Sie einen Web-Browser. Geben Sie folgende URL ein:

  • http://FQDN_of_ScriptRunner_Server/scriptrunner/admin -> die Admin Web App wird geladen
  • Wählen Sie den grünen Button „Testen“ auf dem Startbildschirm.
  • Sie können optional die Sprache in der App umschalten. Dazu wählen Sie die Sprache rechts oben in der Top Bar der Anwendung aus.

Hinweis

Wenn Sie den Internet Explorer verwenden, muss die Domainkennung aus dem FQDN des ScriptRunner Servers in den Security Settings der Local Intranet Zone eingetragen sein. Unter Umständen werden diese Einstellungen per GPO für den Browser gesetzt und die Domain des ScriptRunner Servers ist nicht aufgeführt!

Optional können Sie die Admin App im Internet Explorer auf dem ScriptRunner Server direkt starten. Schalten Sie dazu die enhanced security options für den IE mit dem Server Manager aus. Verwenden Sie auch auf dem Server den vollständigen FQDN in der URL.

ScriptRunner Admin App with Dashboard, top menu, main menu on the left and Action bar on bottom line

ScriptRunner Admin App with Dashboard, top menu, main menu on the left and Action bar on bottom line

Um die Funktionstüchtigkeit der Scriptausführung zu testen, führen Sie folgendes aus:

  1. Klicken Sie in der Admin Web App im Hauptmenü auf der linken Seite den Punkt Actions/Aktionen.
  2. Markieren Sie in der Listenansicht die Aktion mit dem Namen „Local: Add two values“.
  3. Starten Sie die Aktion mit dem Button Run/Ausführen in der kontextorientierten Action Bar am unteren Rand der Applikation. Es erscheint der Action Wizard im RUN Mode mit einer Eingabemaske für die PowerShell Parameter mit zwei vorausgefüllten Feldern.
  4. Klicken Sie nun den Ok-Button am unteren Rand des Wizards. Nun wird das PowerShell-Script ausgeführt, welches zwei Zahlen addiert.
  5. Nach der Ausführung des Scriptes erscheint ein grüner Balken in der Zeile der Aktion. Klicken Sie auf den Balken und lassen Sie sich den Report anzeigen.
  6. Wiederholen Sie die Ausführung der Aktion und wählen Sie dabei andere Möglichkeiten aus. Beachten Sie, dass Zahlen und Strings nicht gemischt addiert werden können.
  7. Wechseln Sie nun über das Hauptmenü in das Dashboard. Dort können Sie sowohl einzelne Reports anklicken als auch verschiedene Darstellungsoptionen nutzen.
  8. Klicken Sie im Dashboard den Button Reports in der Action Bar unten. In der Reportdarstellung können Sie nun die einzelnen Reports durchblättern und die verschiedenen Darstellungsoptionen rechts oben im Reportfenster verwenden.

 

Contextual Action bar with help button

Contextual Action bar with help button

Ja Nicht Änderung vorschlagen

Einrichten & Testen einer Delegation

Konfigurieren Sie nun zuerst eine Gruppe in der Rolle Service Desk User. Anwender mit dieser Rolle dürfen die ScriptRunner Delegate Web App nutzen und vorkonfigurierte PowerShell Aktionen starten, ohne dass sie dafür administrative Berechtigungen auf die Zielsysteme benötigen. Dazu führen Sie folgendes aus:

  1. Wechseln Sie in das Hauptmenü Delegation.
  2. Klicken Sie auf den Button Create/Erstellen. Der Wizard zum Anlegen von Gruppen und Accounts öffnet sich.
  3. Wählen Sie zuerst die Rolle Service Desk User aus und klicken Sie Next.
  4. Vergeben Sie anschließend einen Anzeigenamen für die Gruppe und wechseln Sie auf die nächste Wizardseite.
  5. Geben Sie den Namen der Sicherheitsgruppe im Active Directory für die Service Desk User ein und drücken den Button zum Verifizieren. Im Feld Claim Typ erscheint ein String mit group-sid am Ende.
  6. Wechseln Sie in die Zuweisungsseite und klicken Sie die Aktion „Local: Add two values“ aus der Liste an. Eine Mehrfachauswahl kann mit CTRL-Maustaste erfolgen.
  7. Schließen Sie die Anlage und Zuweisung mit OK ab.
  8. Wechseln Sie in das Hauptmenü Actions/Aktionen und wählen Sie die Aktion aus.
  9. Klicken Sie in der Action Bar unten den Button Delegate/Delegieren. Der Action Wizard öffnet sich im EDIT Mode und stellt die Konfigurationsseite für die Delegation für diese Aktion dar.
  10. Geben Sie einen Tab-Bezeichner „MeinRegister“ ohne Leerzeichen ein und drücken die Tab-Taste. Wählen Sie eine Farbe für die Aktionskachel in der Delegate App aus. Optional können Sie den User verpflichten, vor dem Starten der Aktionen das Ursachenfeld auszufüllen.
  11. Schließen Sie mit OK ab.
Delegate App, ScriptRunner, Listview and Tileview

ScriptRunner Delegate App – List view (left) and Tiles view (right)

Melden Sie sich nun an einem Client mit Ihrem Standardbenutzer-Account an und starten einen Web-Browser. Geben Sie folgende URL ein:

  1. http://FQDN_ScriptRunner_Server/scriptrunner/delegate -> die Delegate Web App wird geladen.
  2. Wählen Sie nun das Register Alle und anschließend das Register MeinRegister.
  3. Klicken Sie die Kachel „Local: Add two values“ an. Es erscheint eine Eingabemaske für die PowerShell Parameter mit den beiden vorausgefüllten Feldern.
  4. Geben Sie in das Feld „Reason/Ursache“ einen Kommentar zur Aktion ein, z.B. einen Bezug zu einer Ticketnummer.
  5. Starten Sie die Aktion durch Drücken des Ausführen/RUN Buttons in der Action Bar am unteren Rand.
  6. Warten Sie die Ausführung ab.
  7. Klicken Sie im modalen Anzeigefenster den Link Report oder in der Action Bar den Button Reports.
  8. Wiederholen Sie die Ausführung der Aktion und wählen Sie dabei andere Möglichkeiten aus. Beachten Sie, dass Zahlen und Strings nicht gemischt addiert werden können.

Wechseln Sie nun in die Admin App auf das Hauptmenü Actions/Aktionen und wählen Sie die Aktion „Local: Add two values aus“. Klicken Sie nun auf den Button Reports in der Action Bar unten. Anschließend können Sie alle Reports durchblättern etc. Achten Sie dabei auf die unterschiedlichen Informationen im Meta-Datenblock oben.

Ja Nicht Änderung vorschlagen

Erstes PowerShell Remoting

Nach einem erfolgreichen ersten Funktionstest wird nun das System zum Testen des Remote Managements mit PowerShell in ScriptRunner eingebunden und eine Aktion so konfiguriert, dass ein Script auf einer entfernten Maschine ausgeführt werden kann. Die eingebauten Assistenten unterstützen Sie bei der Einrichtung. Neben der Hilfe/? in der Action Bar sind auf jeder Assistenten-Page ?-Helpboxen mit zusätzlichen Informationen vorhanden.

 

ScriptRunner Infobox on each wizard page

ScriptRunner Infobox on each wizard page

 

Dazu gehen Sie für zum Einrichten einer Aktion für PowerShell Remoting zum zweiten Server wie folgt vor:

  1. Wechseln Sie in der Admin Web App auf das Hauptmenü Credentials/Administrative Konten und klicken den Button Create/Erstellen.
  2. Erfassen Sie einen administrativen Service-Account, welcher berechtigt ist, PowerShell-Scripte auf dem zweiten Server (Remote System) auszuführen.Tipp: Erstellen Sie Domänen-Service-Accounts in der Schreibweise domain\account. Schließen Sie den Vorgang mit OK ab.
  3. Wechseln Sie nun in den Hauptmenüpunkt Targets/Zielsysteme und markieren das Target mit dem Namen „Sample Target“.
  4. Klicken Sie den Button Edit/Editieren in der Action Bar unten. Der Konfigurations-Wizard öffnet sich im EDIT Mode.
  5. Ändern Sie den Displaynamen – empfohlen Windows Computername – und den eingetragenen FQDN auf den tatsächlichen FQDN des zweiten Servers (Remote System).
  6. Wählen Sie das unter 2) erstellte PS Remoting Credential aus.
  7. Schließen Sie mit OK ab.

Nachdem der zweite Server (Remote System) in ScriptRunner bekannt ist und mit dem eingerichteten Credential verknüpft wurde, wird nun eine PowerShell Script Policy erstellt. Um den Vorgang zu vereinfachen, gehen Sie wie folgt vor:

  1. Wechseln Sie in der Admin Web App auf das Hauptmenü Actions/Aktionen und markieren „Local: Add two values“.
  2. Klicken Sie nun den Button Copy/Erstellen in der Action Bar unten. Es wird eine Kopie der Aktion erstellt und in der Liste mit der Endung „- Copy“ angezeigt.
  3. Markieren Sie in der Liste die Kopie und klicken Sie Edit/Editieren in der Action Bar unten. Der Wizard öffnet sich im EDIT Mode.
  4. Wechseln Sie durch anklicken auf die erste Wizard Page Action Properties und ändern Sie den Namen der Aktion, z.B. auf „Mein erster Remote Test“.
  5. Wechseln Sie durch anklicken auf die zweite Wizard Page Select Targets und wählen Sie den von Ihnen konfigurierte zweiten Server (Remote System) aus.
  6. Überspringen Sie die dritte Wizard Page.
  7. Wechseln Sie durch anklicken auf die vierte Wizard Page Assign Parameter Values/Skript-Parameter vorbelegen und wählen in beiden Dropdown-Menus den Wert „Select a value“ aus.
  8. Wechseln Sie durch anklicken auf die fünfte Wizard Page Set Result Options & Notifications. Markieren Sie E-Mail Notifications, wählen Sie die Option „Always“ und tragen Sie Ihre E-Mail-Adresse ein.Tipp: Für die ordnungsgemäße Funktionsweise muss der E-Mail Notification Connector, wie oben beschrieben, eingerichtet sein.
  9. Schließen Sie mit OK ab.

Nun ist die erste PowerShell-Script Policy für einen Test mit PowerShell Remoting eingerichtet. Zum Testen mit der Admin Web App und der Delegate Web App absolvieren Sie mit der Aktion „Mein erster Remote Test“ die Schritte wie oben im Abschnitt Erster Funktionstest und Einrichten und Testen einer Delegation beschrieben.

Hinweis

Sollten bei der Ausführung Fehler auftreten, so lesen Sie die PowerShell Fehlermeldungen im Report sorgfältig durch und überprüfen Sie bitte folgende Einstellungen:

  • auf dem zweiten Server (Remote System):
    • WinRM Service muss aktiv sein.
    • PowerShell Execution Policy muss eingeschalten und auf „Remote Signed“ konfiguriert sein.
    • PowerShell Remoting muss aktiviert sein.
    • Der unter Credentials eingetragene und für das Remoting verwendete Account muss Rechte zum Ausführen von PowerShell-Scripten haben.
    • Tipp: Eine domainweite PowerShell GPO kann andere Einstellungen wirksam werden lassen!
  • auf dem ScriptRunner Server in der Admin Web App:
    • Prüfen Sie an an den Zielsystem-Einstellungen, ob der FQDN korrekt ist und das richtige Credential zugewiesen wurde.
    • Prüfen Sie an den Aktionseinstellungen, ob das richtige Zielsystem ausgewählt wurde.
    • Falls ein Fehler in der Authentifikationsmethode aufgetreten ist, können Sie diese auf der Wizard Page „PS Remoting Session Setting“ unter der Option „use a non-default PS Remoting authentication method“ ändern, z.B. auf Kerberos.
    • Geben Sie für das Credential den Account und das Passwort korrekt ein.
Ja Nicht Änderung vorschlagen

Erweiterte Test Cases

Um schnell Ergebnisse mit den erweiterten Test Cases erzielen zu können, sind bereits im Setup entsprechende Scripte und Konfigurationen enthalten, welche nach der Installation sofort zur Verfügung stehen.

Die erweiterten Test Cases demonstrieren ausgewählte Fähigkeiten und Funktionen von ScriptRunner in Zusammenarbeit mit folgenden Systemen:

  • Multi-Team und Multi-Mandanten Betrieb
  • Self-Service für Endanwender
  • Active Directory
  • Microsoft Exchange
  • Office365
  • Azure

In diesem Zusammenhang stehen folgende Features von ScriptRunner im Mittelpunkt der Tests:

  • Abbilden des selben Use Cases unter Verwendung von lokaler und remote PowerShell
  • Erhöhte Interaktivität durch Abfragen auf das Active Directory und Listen
  • Erhöhte Interaktivität durch gescriptete Abfragen auf unterschiedliche Systeme
  • Einsatz von PowerShell Modulen lokal und remote
  • Einsatz von Library Scripten

Zusätzlich können Team-Szenarien für unterschiedliche Zuständigkeiten ausprobiert werden.

Ja Nicht Änderung vorschlagen

Multi-Team & Multi-Tenant

Weitere Gruppen im Active Directory

Für die ordnungsgemäße Funktion im Multi-Team und Multi-Mandanten-Betrieb in ScriptRunner werden zwei weitere Sicherheitsgruppen im Active Directory mit entsprechenden Benutzer-Accounts benötigt.

  • Sicherheitsgruppen für ScriptRunner Administratoren (Team oder Mandant). Legen Sie zwei weitere Sicherheitsgruppen an. Diese können sich an Ihren Namenskonventionen ausrichten, z.B. „SR-AD-Team“ oder SR-Kundenname. Nehmen Sie die entsprechenden Admin-Accounts in diese Gruppe auf. Es können auch bereits bestehende Sicherheitsgruppen verwendet werden.

Starten Sie die ScriptRunner Admin App im Browser als Haupt-Administrator. Wählen Sie anschließend das Hauptmenu Delegation aus. Klicken Sie in der Action Bar auf Create. Wählen Sie die Rolle Administratoren (Team) aus und folgen Sie dem Assistenten. Für die zweite Gruppe verfahren Sie analog.

Add a group in ScriptRunner

Arbeiten als Administrator im Team oder Mandanten

Melden Sie sich nun mit einem administrativen Account in der Rolle Administratoren (Teams) an einem Client an und starten Sie einen Web-Browser. Geben Sie folgende URL ein:

  • http://FQDN_of_ScriptRunner_Server/scriptrunner/admin -> die Admin Web App wird im Kontext eines Administrators oder Mandanten gestartet
  • Wählen Sie den grünen Button „Testen“ auf dem Startbildschirm.
  • Sie können optional die Sprache in der App umschalten. Dazu wählen Sie die Sprache rechts oben in der Top Bar der Anwendung aus.

 

ScriptRunner Multi-Team Multi-Tenant

Admin groups for multi-team and multi-tenant operations

Wechseln Sie in eines der anderen Hauptmenus und erstellen Sie jeweils mit Erstellen/Create jeweils ein neues Credential und danach ein neues Target/Zielsystem vom Typ PowerShell Remoting.  Weisen Sie dem Zielsystem im Assistenten das erstellte Credential zu.

Eigentümerschaft bei Richtlinien-Elementen

ScriptRunner Aktionen bestehen aus verschiedenen Richtlinien-Elementen: Scripte, administrative Konten, Zielsysteme und Queries. Sowohl Aktionen als auch andere Elemente können nun von der Einstellung PRIVATE USE oder PUBLIC USE sein.

PRIVATE USE symbolisiert die Zuordnung zu einem bestimmten Admin-Team bzw. Mandanten. Alle Elemente und Aktionen, welche zugewiesen wurden, können nur von diesem Admin-Team bzw. diesem Mandanten verwendet werden.

PUBLIC USE implementiert die gemeinsame Verwendung von einzelnen Elementen und Aktionen.

PRIVATE USE schlägt PUBLIC USE. Das bedeutet, dass Elemente, welche einem Admin-Team bzw. Mandanten zugeordnet worden sind, nicht in übergeordneten Elementen und Aktionen verwendet werden können, welche PUBLIC USE sind. Umgekehrt können PUBLIC USE Elemente immer als untergeordnete Elemente in PRIVATE USE Elementen verwendet werden.

DELETE GROUP führt zu PUBLIC USE. Wird die Gruppe eines Admin-Team bzw. Mandanten in ScriptRunner gelöscht, werden alle mit dieser Gruppe verbundenen Elemente auf PUBLIC USE zurückgesetzt. Das Löschen einer solchen Gruppe ist nur durch einen Haupt-Administrator möglich.

Ja Nicht Änderung vorschlagen

Self-Service für Endanwender

Konfigurieren Sie nun zuerst eine Gruppe in der Rolle Self-Service Endanwender. Anwender mit dieser Rolle dürfen die ScriptRunner Self-Service Web App nutzen und vorkonfigurierte PowerShell Aktionen starten, ohne dass sie dafür administrative Berechtigungen auf die Zielsysteme benötigen. Dazu führen Sie folgendes aus:

  1. Starten Sie die Admin App in der Rolle als Haupt-Administrator.
  2. Wechseln Sie in das Hauptmenü Delegation.
  3. Klicken Sie auf den Button Create/Erstellen. Der Wizard zum Anlegen von Gruppen und Accounts Accounts öffnet sich.
  4. Wählen Sie zuerst die Rolle Self-Service Endanwender aus und klicken Sie Next.
  5. Vergeben Sie anschließend einen Anzeigenamen für die Gruppe und wechseln Sie auf die nächste Wizardseite.
  6. Geben Sie den Namen der Sicherheitsgruppe im AD für die Self-Service Endanwender ein und drücken den Button zum Verifizieren. Im Feld Claim Typ erscheint ein String mit group-sid am Ende.
  7. Wechseln Sie auf die Zuweisungsseite und klicken Sie die Aktion „Local: Add two values“ aus der Liste an. Eine Mehrfachauswahl kann mit CTRL-Maustaste erfolgen.
  8. Schließen Sie die Anlage und Zuweisung mit OK ab.
  9. Wechseln Sie in das Hauptmenü Actions/Aktionen und wählen Sie die Aktion aus.
  10. Klicken Sie in der Action Bar unten den Button Details. In der Detailsansicht werden unten die Delegationen für diese Aktion aufgeführt.
  11. Wechseln Sie durch erneutes Klicken von Details auf die Hauptübersicht.
Self-Service App, ScriptRunner

Self-Service App to delegate task to the end users

 

Melden Sie sich nun an einem Client mit Ihrem Standardbenutzer-Account an und starten einen Web-Browser. Geben Sie folgende URL ein:

  1. http://FQDN_ScriptRunner_Server/scriptrunner/selfservice-> die Self-Service Web App wird geladen.
  2. Klicken Sie die Kachel „Local: Add two values“ an. Es erscheint eine Eingabemaske für die PowerShell Parameter mit den beiden vorausgefüllten Feldern.
  3. Starten Sie die Aktion durch Drücken des Ausführen/RUN Buttons in der Action Bar am unteren Rand.
  4. Warten Sie die Beendigung der Ausführung ab.
Ja Nicht Änderung vorschlagen

Active Directory Test Case

Vorbereitungen

Für diesen Testcase benötigen Sie Zugang zum Active Directory unter Verwendung von:

  • installiertem Active Directory PowerShell Module auf dem ScriptRunner Server. Das Modul können Sie mithilfe des Server Mangers installieren. Zur Kommunikation mit dem Active Directory verwendet das Modul die Protokolle LDAP und ADWS.
  • PowerShell Remoting auf einen ausgewählten Active Directory Controller. Auf dem Controller muss WinRM und PowerShell Remoting aktiviert sein. Zur Kommunikation mit dem Active Directory Controller wird das WinRM/PowerShell-Remoting Protokoll verwendet.

Hinweis

Es werden für diesen Test Case nur Scripte mit Get-Cmdlets verwendet.

Erläuterungen zur lokalen und entfernten Arbeitsweise mit PowerShell

Bei Verwendung des Active Directory Moduls auf dem ScriptRunner Server nutzen Sie den lokalen Ausführungsmodus von PowerShell Scripten. Das Starten einer Aktion in ScriptRunner führt vereinfacht zu folgenden Schritten:

  1. Es wird ein lokaler PowerShell-Prozess erzeugt. Diesen erkennen Sie im Windows Taskmanager als SRXPSHost.exe.
  2. An diesen Prozess werden alle notwendigen Informationen, Scripte, Credential-Referenzen etc. übergeben.
  3. Das Script wird gestartet und die Cmdlets im lokalen Active Directory Modul werden aufgerufen.
  4. Das lokale Active Directory Modul baut eine Verbindung zum primären Active Directory Controller auf. Diesen können Sie auch mit dem Kommando Get-ADRootDSE auf der PowerShell Konsole des ScriptRunner Servers überprüfen.
  5. Die Befehle des PowerShell Scriptes werden vom Active Directory Modul in LDAP-Aufrufe und ADWS-Kommunikation transformiert.
  6. Die Ergebnisse der Aufrufe werden vom Active Directory Modul in PowerShell Rückgabewerte re-transformiert und an den lokalen PowerShell Prozess auf dem ScriptRunner Server übergeben.
  7. Nach Beenden des Scriptes wird der lokale PowerShell Prozess beendet.
  8. Der PowerShell Report in ScriptRunner wird abgeschlossen.

Aus der lokalen Arbeitsweise ergeben sich einige Konsequenzen, welche Sie bei der Planung von Use Cases mit ScriptRunner berücksichtigen sollten:

  • PowerShell-Module, welche von lokal auszuführenden Scripten benötigt werden, müssen auf ScriptRunner Server installiert sein.
  • Es werden andere Kommunikationsprotokolle als WinRM/PowerShell-Remoting verwendet. Das betrifft sowohl die lokale Firewall von ScriptRunner Server und Zielsystem als auch dazwischen geschaltete Firewalls und Proxies.
  • Die Steuer- und die Verarbeitungslast zur Ausführung der Scripte sind auf dem ScriptRunner Server konzentriert. Das entfernte System, hier das Active Directory, ist von der PowerShell-Verarbeitung entlastet.
  • eine hohe Konzentration von Verarbeitungs- und Steuerlast auf dem ScriptRunner Server erfordert dort ein entsprechendes Sizing.
  • Das Laden des Scriptes und der Module sowie das Ausführen im lokalen PowerShell Prozess ist schneller als unter Verwendung von PowerShell Remoting.

Hinweis

Nicht immer sollten Scripte lokal auf dem ScriptRunner Server ausgeführt werden. Maßgeblich dafür ist die Funktionalität des Scriptes, dessen Laufzeit und das programmierte Ausgabeverhalten. Von Bedeutung ist auch die Arbeitsweise und die Protokoll-Transformation in den verwendeten PowerShell Modulen. Viele Hersteller nutzen zur Verarbeitung der Kommandofolgen eines Scriptes mittels Cmdlets die Transformation in Web Service REST Aufrufe an ihre Schnittstelle. Details sollten den entsprechenden Herstellerdokumentationen entnommen werden.

 

Eine völlig andere Arbeitsweise ergibt sich unter Verwendung von PowerShell Remoting. Dabei wird das Active Directory Moduls auf einem AD Controller benutzt. Dazu muss in ScriptRunner ein Zielsystem, hier ein AD Controller, mit Einstellungen für das PowerShell Remoting konfiguriert sein. Das Starten einer Aktion in ScriptRunner führt vereinfacht zu folgenden Schritten:

  1. Es wird ein lokaler PowerShell-Prozess erzeugt. Diesen erkennen Sie im Windows Taskmanager als SRXPSHost.exe.
  2. An diesen Prozess werden alle notwendigen Informationen, Scripte, Credential-Referenzen etc. übergeben.
  3. Es wird über WinRM/PowerShell-Remoting versucht, eine Verbindung zum Active Directory Controller herzustellen.
  4. Konnte die Verbindung erfolgreich hergestellt werden, so wird auf dem Active Directory Controller ebenfalls ein Standard-PowerShell-Prozess erzeugt.
  5. Das Script und alle notwendigen Informationen werden an diesen entfernten Prozess übertragen.
  6. Das Script wird in dem entfernten Prozess gestartet und die Kommandofolge wird mit dem Active Directory Modul auf dem Controller verarbeitet.
  7. Die Verbindung zwischen dem lokalen PowerShell Prozess auf ScriptRunner Server und dem entfernten PowerShell Prozess bleibt bestehen, um die Ausgaben zum ScriptRunner Server zu übertragen.
  8. Nach dem Beenden der Scriptverarbeitung auf dem Active Directory Controller wird der entfernte PowerShell Prozess beendet.
  9. Nach dem Beenden des entfernten PowerShell Prozesses und nach vollständiger Übertragung der Ergebnisse wird der lokale PowerShell Prozess auf ScriptRunner Server beendet.
  10. Der PowerShell Report in ScriptRunner wird abgeschlossen.

Aus dieser Arbeitsweise ergeben sich einige Konsequenzen, welche Sie bei der Planung von Use Cases mit ScriptRunner berücksichtigen sollten:

  • Entfernte System, welche mit PowerShell Remoting angesprochen werden sollen, müssen dafür enabled sein.
  • Es wird WinRM/PowerShell-Remoting als Kommunikationsprotokoll verwendet. Das betrifft sowohl die lokale Firewall von ScriptRunner Server und Zielsystem als auch dazwischen geschaltete Firewalls und Proxies.
  • PowerShell Module, welche von den auszuführenden Scripten benötigt werden, müssen auf dem entfernten System installiert sein.
  • Die Verarbeitungslast zur Ausführung der Scripte liegt auf dem entfernten Zielsystem.
  • Auf dem ScriptRunner Server verbleibt die Steuerlast zur Kommunikation mit dem entfernten PowerShell Prozess.
  • Das Auf- und Abbauen der Verbindung über PowerShell Remoting, das Erzeugen des entfernten PowerShell Prozesses, das Laden der Module und das Verarbeiten des Scriptes wirkt sich auf die Gesamtperformance einer Aktion aus.

Hinweis

Das entfernte Ausführen von Scripten ist nur mit Systemen möglich, welche PowerShell Prozesse erzeugen und Scripte verarbeiten können. Es gibt unterschiedlich voreingestellte Endpunkte für die Kommunikation mit dem Zielsystem, z.B. Exchange PowerShell. Maßgeblich dafür ist die Funktionalität des Zielsystems. Für alle Zielsysteme, welche keine derartige Möglichkeit bieten, müssen die Scripte im lokalen Ausführungsmodus verarbeitet werden.

Testen mit der Aktion Get-ADUserProperties

Starten Sie die Admin App und wählen Sie im Hauptmenu Aktionen die Aktion Get-ADUserProperties aus und klicken in der Action Bar auf das Symbol Details. Die Ansicht wechselt in die Detaildarstellung und zeigt alle mit der Aktion verbundenen Richtlinien-Elemente an.

scriptrunner_action_getaduserproperties

Details view of the action get-aduserproperties.

Als Zielsystem wird ADC Remote mit einem verbundenen Credential angezeigt, was auf eine entfernte Ausführung des PowerShell Scipts verweist. Darunter befindet sich das Script mit zwei durch Queries verbundenen PowerShell Parametern.

Tipp

Sie können in der Detailansicht die einzelnen Richtlinien-Elemente direkt editieren, indem Sie das Element auswählen und in der Action Bar unten Editieren anklicken.

Um den Test erfolgreich absolvieren zu können, muss das PowerShell Moduls für Active Directory auf dem ScriptRunner Server installiert sein. Sie müssen außerdem am Zielsystem ein für ihre Umgebung gültiges Credential hinterlegt haben.  Sie können das Credential AD Admin direkt editieren oder im Hauptmenu Credentials ein neues Credential erstellen. Wenn Sie ein neues Credential erstellt haben, so weisen Sie dieses dem Zielsystem AD local zu. Dazu editieren Sie das Zielsystem AD local und wählen das erstellte Credential aus.

ScriptRunner Target Credential

Select the credential for the script execution on this target.

 

Im nächsten Schritt wählen Sie das Richtlinien-Element List of OUs from AD aus. Dieses und das nächste Element ist eine vorkonfigurierte AD-Query. Diese Query fragt alle OUs der nächsten Ebene ab einem Startpunkt im Active Directory ab und zeigt diese im Formular als Auswahl-Dropdown an. Klicken Sie Editieren und prüfen Sie die Einstellungen der Query auf ihr Active Directory.  Falls Sie in ein einer anderen, nichtvertrauten Domäne suchen wollen, müssen Sie ganz oben die Suchdomäne einstellen. Stellen Sie die Search Base auf den Startpunkt der Suche in Ihrem Active Directory in der Form OU=myou,DC=mydomain,DC=mydomain ein.

scriptrunner_query_serachbase

Edit the search base for the query.

 

Nun wählen Sie das Richtlinien-Element List of Users from AD aus. Diese vorkonfigurierte Query fragt alle aktiven User ab einem Startpunkt im Active Directory ab und zeigt diese im Formular als Auswahl-Dropdown an. Klicken Sie Editieren und prüfen Sie die Einstellungen der Query auf ihr Active Directory. Falls Sie in ein einer anderen, nichtvertrauten Domäne suchen wollen, müssen Sie ganz oben die Suchdomäne einstellen. Stellen Sie die Search Base auf den Startpunkt der Suche in Ihrem Active Directory in der Form OU=myou,DC=mydomain,DC=mydomain ein.

scriptrunner_query_user

Configure the user query, esp. search base

 

Hinweis

Die Search Base in der Konfiguration enthält die default-Einstellung für diese Query und wird durch kaskadierte Queries überschrieben. Es ist zu empfehlen, default- Einstellungen zu verwenden, wenn bestimmte, z.B. administrative, Zweige im AD nicht berücksichtigt werden sollen.

Sie können Queries testen, indem Sie auf das Hauptmenu Queries wechseln, die entsprechende Query auswählen und in der Action Bar auf das Symbol Testen klicken. Die Query kann durch Klicken auf das blaue Dreieck gestartet werden. Die ersten 100 Resultate der Query werden angezeigt.

scriptrunner_query_test

Testing the query by clicking the blue triangle.

 

Die Ausführungs- und die Darstellungsoptionen einer Query lassen sich ebenfalls beim Editieren ändern, indem Sie im Konfigurations-Assistenten eine Seite nach vorn blättern. Wenn die erwartete Ergebnismenge der Query größer 500 Einträgen ist, so schalten Sie die Option automatisches Ausführen der Query ab.

Anschließend markieren Sie die Aktion und klicken Editieren. Die Seite mit den PowerShell Parametern erscheint im Konfigurations-Assistenten. Beim Parameter $Username können Sie die Verknüpfung von AD-Queries nachvollziehen. Die Search Base der Query List of Users from AD wird über den Parameter $OUPath mit dem Ergebnis der Query List of OUs from AD gesteuert.

scriptrunner_action_queries

Linking parameters and queries in the action.

 

Wechseln Sie im Wizard auf die Seite zur Zielsystem-Auswahl und markieren Sie das Zielsystem AD local.

Wollen Sie nur eine selektive Auswahl an OU-Pfaden bereitstellen, so können Sie statt der AD-Query List of OUs from AD auch eine statische List Query verwenden. Wählen Sie dazu für den Parameter $OU-Path die Query Static List of OUs aus. Bestätigen Sie anschließend die Änderung mit OK. Danach klicken Sie Neu laden in der Action Bar, und wählen anschließend diese Query zum Editieren aus. Anschließend tragen Sie die entsprechenden OU-Pfade und den Anzeigenamen in die Liste ein und beenden mit OK.

scriptrunner_list_query

Configure List Query with display and parameter values.

 

Wenn Sie alle Anpassungen vorgenommen haben, beenden Sie das Editieren und klicken Sie das Symbol Ausführen in der Action Bar. Klicken Sie gleich anschließend rechts unten auf die blaue Osiris und wählen Sie im Popup die gestartete Aktion aus. Die Ansicht wechselt in den Live-Report und Sie können die Ausführung der Aktion verfolgen. Nach dem Beenden der Aktion sehen Sie den vollständigen Report. Danach wechseln Sie zurück auf die Listenansicht im Hauptmenu Aktionen und starten die Aktion erneut. Anschließend können Sie im Dashboard nach Reports dieser Aktion filtern.

scriptrunner_osiris

Open the pop-up list by clicking on the Osiris and then clicking on the entry.

 

Fehlerhinweise

Sollten beim Ausführen der Aktion Fehler auftreten, so lesen Sie die Fehlermeldungen und Hinweise genau durch. Sie verweisen auf die Ursachen. Prüfen Sie vor allem:

  • PowerShell Modul für Active Directory muss auf dem ScriptRunner Server funktionieren. Starten Sie die PowerShell Konsole im Kontext des hinterlegten administrativen Kontos und rufen Sie das Cmdlet Get-ADRootDSE auf.
  • das administratives Konto (Credential), welches vom Zielsystem AD local genutzt wird muss gültig und richtig hinterlegt sein (Passwort !!)
  • als Zielsystem kann AD local und ADC Remote verwendet werden. Kontrollieren Sie die Zielsystemkonfiguration und die Voraussetzungen für Remoting.
  • die beiden Queries müssen funktionieren, in dem beide separat getestet werden. Prüfen Sie die hinterlegte default-SearchBase.
  • das referenzierte Script darf nicht verschoben oder gelöscht worden sein
Ja Nicht Änderung vorschlagen

Exchange Server Test Case

Vorbereitungen

Für diesen Testcase benötigen Sie Zugang zum Active Directory und zu einem Exchange Server unter Verwendung von:

  • installiertem Active Directory PowerShell Module auf dem ScriptRunner Server. Das Modul können Sie mithilfe des Server Mangers installieren. Zur Kommunikation mit dem Active Directory verwendet das Modul die Protokolle LDAP und ADWS.
  • PowerShell Implicit Remoting auf einen ausgewählten Exchange Server. Auf diesem muss die Exchange PowerShell aktiv sein. Zur Kommunikation mit dem Exchange Server werden die Standard-Einstellungen für die Exchange PowerShell (Port 80) mit der URI des Exchange Servers verwendet.

Hinweis

Es werden für diesen Test Case nur Abfrage-Scripte mit Get-Cmdlets verwendet.

Erläuterungen zur Arbeitsweise der Exchange PowerShell

Bei Verwendung der Exchange PowerShell mit ScriptRunner wird PowerShell Implicit Remoting verwendet. Dazu wird die Schnittstelle und die Cmdlet-Aufrufe des PowerShell Moduls für Exchange in den PowerShell Prozess auf dem ScriptRunner Server importiert. Diese Arbeitsweise entspricht weitgehend einem New-PSSession mit anschließendem Import-PSSession auf der interaktiven Konsole.

Hinweis

Die Installation der Exchange PowerShell auf dem ScriptRunner Server ist NICHT notwendig und sollte unterbleiben.

Das Starten einer Aktion in ScriptRunner führt vereinfacht zu folgenden Schritten:

  1. Es wird ein lokaler PowerShell-Prozess erzeugt. Diesen erkennen Sie im Windows Taskmanager als SRXPSHost.exe.
  2. An diesen Prozess werden alle notwendigen Informationen, Scripte, Credential-Referenzen etc. übergeben.
  3. Es wird eine Verbindung zum Exchange Server aufgebaut und das Exchange PowerShell Modul in den lokalen PowerShell-Prozess importiert. Der Import generiert eine lokales Schnittstellenmodul mit den Cmdlets. Diese können nun direkt im lokalen Prozess verwendet werden.
  4. Das Script wird gestartet und die Cmdlets im temporären lokalen Exchange PowerShell Modul werden aufgerufen.
  5. Das lokale, temporäre Modul kommuniziert über die PowerShell Web Service URI mit dem Exchange Server.
  6. Die Befehle des PowerShell Scriptes werden vom lokalen, temporären Modul in PowerShell Web Service Aufrufe transformiert.
  7. Die Ergebnisse der Aufrufe werden vom lokalen temporären Modul rücktransformiert und vom PowerShell-Prozess weiterverarbeitet.
  8. Nach Beenden des Scriptes wird die importierte Session beendet und das temporäre, lokale Modul wird mit dem PowerShell-Prozess beendet.
  9. Der PowerShell Report in ScriptRunner wird abgeschlossen.

Aus dieser Arbeitsweise der Exchange PowerShell ergeben sich einige Konsequenzen, welche Sie bei der Planung von Use Cases mit ScriptRunner berücksichtigen sollten:

  • Es wird immer PowerShell Implicit Remoting für die Kommunikation zum Exchange Server verwendet.
  • Es wird immer die Exchange PowerShell Web Service URI verwendet. Standardmäßig wird dafür Port 80 mit integrierter Verschlüsselung verwendet. Das betrifft sowohl die lokale Firewall von ScriptRunner Server und Exchange Server als auch zwischengeschaltete Firewalls und Proxies.
  • Es muss immer der DNS-FQDN des Exchange Servers als Zielsystem angegeben werden. DNS-Einträge für OWA und andere Exchange Dienste können nicht verwendet werden.
  • Die Steuer- und die meiste Verarbeitungslast zur Ausführung der Scripte sind auf dem ScriptRunner Server konzentriert. Der entfernte Exchange Server ist von der PowerShell-Verarbeitung entlastet.
  • eine hohe Konzentration von Verarbeitungs- und Steuerlast auf dem ScriptRunner Server erfordert dort ein entsprechendes Sizing.
  • Das Aufbauen und Importieren der Session zum Exchange Server sowie das erstellen des temporären, lokalen Modul benötigt eine Initialisierungszeit, die von vielen Faktoren beeinflusst wird.

Tipp

Sie können jedoch mit dem Einrichten der Exchange-Rolle für den Service Account, welcher von ScriptRunner als administratives Credential verwendet wird, steuern, welche und wie viele Cmdlets zur Laufzeit importiert werden. Dadurch können Sie die benötige Initialisierungszeit verkürzen.

Testen mit der Aktion Get-MailboxProperties

Starten Sie die Admin App und wählen Sie im Hauptmenu Aktionen die Aktion Get-MailboxProperties aus und klicken in der Action Bar auf das Symbol Details. Die Ansicht wechselt in die Detaildarstellung und zeigt alle mit der Aktion verbundenen Richtlinien-Elemente an.

scriptrunner_action_getmailboxproperties

Details view of the Action Get-ExMailboxProperties.

 

Als Zielsystem wird Exchange Server mit einem verbundenen Credential angezeigt. Darunter befindet sich das Script mit einem durch eine Query verbundenem PowerShell Parameter.

Tipp

Sie können in der Detailansicht die einzelnen Richtlinien-Elemente direkt editieren, indem Sie das Element auswählen und in der Action Bar unten Editieren anklicken.

Um den Test erfolgreich absolvieren zu können, müssen Sie die Konfigurationen für folgende Richtlinien-Elemente anpassen:

  • Credential – Sie benötigen in Ihrer Umgebung ein gültiges administratives Konto zum Zugriff auf Exchange Server.  Wählen Sie dazu Exchange Admin aus und editieren direkt oder Erstellen Sie ein neues Credential im Hauptmenu Credentials.
  • Zielsystem – Wählen Sie das Zielsystem aus und ändern Sie den Namen und den FQDN auf einen gültigen Exchange Server. Wenn Sie ein neues Credential erstellt haben, so weisen Sie dieses zu.
    Klicken Sie auf die nächste Seite, um die Einstellungen für die Exchange PowerShell zu prüfen. Scrollen Sie nach ganz unten und klicken Sie Erweiterte Verbindungsoptionen. Geben Sie dort SkipCNCheck=1 ein. Diese Option unterdrückt mögliche Exchange-Zertifikatsfehler, um eine Installation der Exchange Zertifikate auf dem ScriptRunner Server zu vermeiden. Klicken Sie anschließend OK.
scriptrunner_exch_target_remoting

Configure the remoting options to access an exchange server.

 

Im nächsten Schritt wählen Sie das Richtlinien-Element List of Mailboxes from AD aus. Dieses Element ist eine vorkonfigurierte AD-Query. Diese Query fragt alle Mailboxen von aktiven Benutzern ab und zeigt diese im Formular als Auswahl-Dropdown an. Klicken Sie Editieren und prüfen Sie die Einstellungen der Query auf ihr Active Directory.

  • falls Sie in ein einer anderen, nichtvertrauten Domäne suchen wollen, müssen Sie ganz oben die Suchdomäne einstellen.
  • die ausgewählte Option Attributefilter Mustersuche enthält das AD-Attribut [HomeMDB] ohne Wert. Das bedeutet, dass bei der Suche auf die Benutzerobjekte nach einem vorhandenen Benutzerattribut [HomeMDB] gefiltert wird. Nur Benutzerobjekte mit einer Exchange Mailbox haben dieses Attribut. Das freie Feld Attribut-Wert sorgt dafür, dass die Suche alle Treffer findet, egal in welcher MDB sich das Postfach befindet.
  • Stellen Sie die SearchBase auf den Startpunkt der Suche nach Mailboxen im Active Directory in der Form OU=myou,DC=mydomain,DC=mydomain ein. Wählen Sie einen sinnvollen Startpunkt unterhalb der root, um die Anzeige von Exchange-Systemmailboxen auszuschließen.

Anschließend bestätigen Sie alles mit OK.

scriptrunner_query_mailbox

Configure the mailbox query esp. attribute pattern and the search base.

Hinweis

Die SearchBase in der Konfiguration enthält die default-Einstellung für diese Query und wird durch kaskadierte Queries überschrieben. So kann eine übergeordnete Query OU-Pfade ermitteln und zur Auswahl stellen. Die Suche nach den Mailboxen bezieht sich dann auf alle Userobjekte unterhalb des ausgewählten OU-Pfades. Ein Beispel dafür finden Sie im Active Directory Test Case.

Sie können die Query List of Mailboxes from AD testen, indem Sie auf das Hauptmenu Queries wechseln, die entsprechende Query auswählen und in der Action Bar auf das Symbol Testen klicken. Die Query kann durch Klicken auf das blaue Dreieck gestartet werden. Die ersten 100 Resultate der Query werden angezeigt.

Die Ausführungs- und die Darstellungsoptionen einer Query lassen sich ebenfalls beim Editieren ändern, indem im Konfigurations-Assistenten eine Seite nach vorn gewechselt wird. Wenn die erwartete Ergebnismenge der Query größer 500 Einträgen ist, so schalten Sie die Option automatisches Ausführen der Query aus.

Tipp

Wenn Sie keine kaskadierten Queries verwenden, können Sie den Modus der Query von Realtime auch auf eine der Cache-Optionen setzen. Der Cache wird im Hauptspeicher von ScriptRunner Server gehalten.

Anschließend markieren Sie die Aktion Get-MailboxProperties und klicken Editieren. Die Seite mit den PowerShell Parametern erscheint im Konfigurations-Assistenten. Beim Parameter $MailboxID können Sie die Verknüpfung der Query nachvollziehen.

scriptrunner_action_queries_mailbox

Linking parameters and queries in the action.

 

Wenn Sie alle Anpassungen vorgenommen haben, beenden Sie das Editieren und klicken Sie das Symbol Ausführen in der Action Bar. Klicken Sie gleich anschließend rechts unten auf die blaue Osiris und wählen Sie im Popup die gestartete Aktion aus. Die Ansicht wechselt in den Live-Report und Sie können die Ausführung der Aktion verfolgen. Nach dem Beenden der Aktion sehen Sie den vollständigen Report. Danach wechseln Sie zurück auf die Listenansicht im Hauptmenu Aktionen und starten die Aktion erneut. Anschließend können Sie im Dashboard nach Reports dieser Aktion filtern.

Fehlerhinweis

Sollten beim Ausführen der Aktion Fehler auftreten, so lesen Sie die Fehlermeldungen und Hinweise genau durch. Sie verweisen auf die Ursachen. Prüfen Sie vor allem:

  • das administratives Konto (Credential), welches vom Zielsystem Exchange Server genutzt wird muss gültig und richtig hinterlegt sein (Passwort !!) Das Konto muss eine gültige Exchange Rolle besitzen.
  • Implicit Remoting der Exchange PowerShell zum Exchange Server muss auf dem ScriptRunner Server funktionieren. Starten Sie die PowerShell Konsole im Kontext des hinterlegten administrativen Kontos und bauen Sie manuell eine neue Session zum Exchange Server auf und importieren diese. So können Sie auch prüfen, welche Cmdlets für das verwendete administrative Kontos geladen werden. Gegebenenfalls reicht die zugewiesene Exchange Rolle nicht aus.
  • die Mailbox-Query muss funktionieren, in diese separat getestet wird. Prüfen Sie die hinterlegte default-SearchBase.
  • das referenzierte Script darf nicht verschoben oder gelöscht worden sein
Ja Nicht Änderung vorschlagen

Sie möchten ein Support-Ticket eröffnen?

  • Bild anklicken.
  • Problem schildern.
  • E-Mail absenden.
  • Ticket-ID von uns erhalten.

Alternativ können Sie sich in unserem Ticketsystem registrieren und ein Ticket eröffnen.

Ja Nicht Änderung vorschlagen

Sie möchten ein persönliches Online-Meeting?

  • Termin auswählen
  • Formular ausfüllen und absenden


Ja Nicht Änderung vorschlagen
Änderung vorschlagen