Skip to the main content.

ScriptRunner Blog

ScriptRunner 2020R2 – Volle Azure Integration, Azure Queries und das neue ScriptRunner Portal

Inhaltsverzeichnis

Post Featured Image

Mit der Version 2020R2 wird ein neues Kapitel bei der Integration von ScriptRunner mit Azure AD, M365 Services und Azure Cloud aufgeschlagen. Gleichzeitig ist es die erste Version, mit der das rollenbasierte Portal ausgeliefert wird, welches die bisherigen Web-Apps ablösen wird. Eine weitere Reihe von Features rundet die Version 2020R2 ab.

Integration von ScriptRunner mit Azure AD

Das Management von O365/M365 und vielen anderen Clouddiensten mit PowerShell ist seit der Version 2018 immer weiter verbessert worden. Mit der neuen Version 2020R2 gibt es nun erstmals die Möglichkeit, mit ScriptRunner nicht nur die Dienste zu managen, sondern eine direkte Integration mit Azure AD, M365 und Azure Cloud bereitzustellen. Dadurch ergeben sich die in den nachfolgenden Abschnitten beschriebenen Möglichkeiten.

Die Registrierung von ScriptRunner in Azure erfolgt mittels App-Registrierung in Azure AD. Es werden dazu zwei Apps registriert, eine für den ScriptRunner Service und eine für das neue ScriptRunner Portal.

Mit der ScriptRunner Service-Registrierung stehen anschließend folgende Funktionen zur Verfügung:

  • Zertifikats basierte Authentifizierung von ScriptRunner Server am Azure AD

  • Einrichten eines Service Principal mit Leserechten auf die Objekte in Azure AD zur Konfiguration von Rollen in ScriptRunner mit Azure AD Sicherheitsgruppen und Azure AD Accounts

  • Verwenden von Azure Queries auf Objekte im Azure AD

Die Registrierung erzeugt in ScriptRunner ein Zielsystemen „Azure AD Home Tenant“.

Die Registrierung des ScriptRunner Portals in Azure AD erlaubt:

  • Anmelden von Benutzern an ScriptRunner mit ihrem Azure AD Account

  • Autorisierung am ScriptRunner Server gemäß der Mitgliedschaft in Rollen

  • Aufnehmen von ScriptRunner Portal in das App-Panel im M365 Benutzerportal

Mehr zur Integration von ScriptRunner mit Azure sowie zur Registrierung finden Sie im Blogbeitrag ScriptRunner, Azure und M365 – ein perfektes Trio  sowie dem ScriptRunner Einstellungen-Handbuch.

        

Benutzeranmeldung mit Azure AD Konten

Mit der Registrierung des ScriptRunner Portal in Azure AD wird gleichzeitig die Umstellung der Anmeldung auf Azure AD Konten aktiviert. Beim Aufruf der URL erscheint das Azure AD Anmeldefenster. Nach erfolgreicher Anmeldung erkennen Sie rechts oben am Account die Erweiterung (JWT).

Wichtig: nach der Umstellung der Benutzeranmeldung können sie die Benutzer nicht mehr mit ihrem internen AD Account anmelden. Alle Konfigurationsdaten in ScriptRunner Server und der Webanwendungen werden umgeschrieben.

Sie können die Umstellung rückgängig machen, indem Sie auf dem ScriptRunner Server den Befehl

Unregister-AsrAzureADApp -TenantID -App Portal

ausführen.

Mehr zur Registrierung und Anmeldung finden Sie im ScriptRunner Einstellungen-Handbuch.

        

Azure Queries

Die direkte Integration mit Azure erlaubt es ab dieser Version die beliebte Query-Funktionalität von ScriptRunner auf Azure AD, Azure Ressourcen und Azure Daten zu erweitern. Mit dem neuen Query Type Azure (Abb. 1) steht nun ein sehr mächtiges Werkzeug zur Verfügung, um Use Cases für M365, Azure AD und Azure Cloud zu gestalten.

Screenshot der ScriptRunner Admin App, Funktion zum Erstellen neuer Queries. Im Reiter 'Select Query Type' ist die Option 'Azure' ausgewählt

Abb. 1: Der neue Query Type Azure steht nun zur Auswahl

Um die Verwendbarkeit für viele Use Cases zu vereinfachen, gibt es folgende Möglichkeiten als Template:

  • Azure User Query: Abfragen von Benutzerobjekten aller Art

  • Azure Group Query: Abfragen von Gruppenobjekten aller Art

  • Azure Group Members Query: Abfragen von Gruppenmitglieder

  • Azure Member of Query: Abfragen von Gruppenmitgliedschaften

Für frei gestaltbare Abfragen können verwendet werden:

  • Microsoft Graph Query

  • Azure Resource Graph Query

  • Azure Data Explorer Query

Beispiel: Azure User Query

Mit einer Azure Query sollen alle Räume ermittelt werden, welche in Exchange Online als Ressourcen ansprechbar sind. Im Use Case soll eine ad-hoc Statistik die Belegung bestimmter Räume als HTML-Report zur Verfügung gestellt werden.

Nachfolgend betrachten wir ausschließlich die Query zur Raumauswahl. Es wird dafür eine Azure User Query verwendet, das Exchange Online Ressourcen wie Räume als Benutzerobjekte abbildet. Um die Abfrage auf Raumobjekte zu steuern, wird hier ein einfacher Property Filter auf das Azure AD User Property DisplayName verwendet.

Screenshot der Azure-Einstellungen in der ScriptRunner Admin App: Filterung nach Objekten deren DisplayName 'room' enthält

Abb. 2: Abfrage von Objekten, deren DisplayName ‚room‘ enthält

Das Testen der Query erfolgt wie gewohnt. Wurde als Parameter Value in der Query -JSON- gewählt, so enthält die Ergebnismenge eine Liste der Räume als JSON-Objekt. Per Mouse-over kann der Wert des JSON-Objektes angezeigt werden. Die weitere Verwendung des JSON-Objektes erfolgt mit dem neuen Feature PowerShell Splatting (siehe Abschnitt PowerShell Splatting feature).

Beispiel: Azure Group Query

In diesem Beispiel sollen alle Azure AD-Gruppen gesucht werden, welche die Eigenschaft ‚mailEnabled‘ haben. Für diesen Fall wird im Beispiel ein ODATA-Filter verwendet.
Hinweis: Azure AD-Abfragen sind Case-Sensitiv!

Screenshot der Azure Configuration in der ScriptRunner Admin App.

Abb. 3: Filtern von Azure AD-Gruppen mit der Eigenschaft ‚mailEnabled‘


Beispiel: Kaskadierbare Query

In einem Use Case soll zuerst eine Auswahl einer Azure AD-Gruppe erfolgen und anschließend die Mitglieder der Gruppe aufgelistet werden, um einen oder mehrere auswählen zu können. Die Anforderung lässt sich am besten mit einer kaskadierten Query lösen.

Die Azure Group Query liefert eine Liste aller Gruppen (ggfs. mit Filter wie in Abb. 3). Als Parameter Value werden die Objekt-Ids der Gruppen benötigt, da diese ID die anschließende Query zur Auflösung der Gruppe in Mitglieder variabel steuert (Abb. 4).

Screenshot der Azure Configuration in der ScriptRunner Admin App.

Abb. 4: Kaskadierbare Azure Query, bei der zuerst eine Gruppe ausgewählt und anschließend deren Mitglieder als Auswahl aufgelistet werden.

Die Azure Query zum Auflösen der Gruppe liefert eine Liste der Gruppenmitglieder samt der Eigenschaften-Sets der Mitglieder als JSON-Objekt (Abb. 5).

Screenshot of the Azure Configuration in the ScriptRunner Admin App.

Abb. 5: Die Liste der Gruppenmitglieder ihrer Eigenschaften-Sets werden als JSON-Objekt geliefert

Die Verbindung beider Queries erfolgt in der Aktion auf der Parameter-Page nach dem schon bekannten Schema.

Screenshot einer ScriptRunner Aktion: Die Ergebnisse der Azure Queries stehen im Eingabformular der Aktion als Auswahl zur Verfügung

Abb. 6: Im Formular der ScriptRunner Aktion stehen die Query-Ergebnisse als Auswahl zur Verfügung

Mehr zu den Microsoft Graph und Azure Ressource Queries können Sie im Blogbeitrag ScriptRunner, Azure und M365 – ein perfektes Trio nachlesen.

Rollenbasiertes ScriptRunner Portal

Zur Verbesserung von UX und CX wurde das neue ScriptRunner Portal entwickelt. Es vereinigt die bisherigen ScriptRunner Web Apps für Helpdesk und Endanwender sowie neue Funktionen für Administratoren.

Das Portal löst die ScriptRunner Delegate App und die ScriptRunner Self-Service App ab. Kunden können im Rahmen des Updates auf diese Version das neue Portal installieren und die Anwender auf die einheitliche URL zum Aufrufen umstellen.

Das Portal ist in Apps unterteilt (Abb. 7) und unterstützt die Anmeldung mit Azure AD Benutzerkonten. Ist MFA aktiviert, erfolgt bei der Anmeldung auch die Abfrage des zweiten Faktors der Authentifizierung.

Screenshot der Einstiegsseite des ScriptRunner Portals im Admin View.

Abb. 7: Übersicht der Apps des neuen ScriptRunner Portals im Admin View

Der Einstieg in das Portal sowie die verfügbaren Funktionen hängen von der Zugehörigkeit einer Sicherheitsgruppe oder eines Accounts zu einer ScriptRunner Rolle ab.

Helpdesk und Endanwender starten sofort imn der Run-App. Zusätzlich dazu hat ein Helpdesk-Anwender Zugang zur Reports-App.

Administratoren haben sowohl in diesen beiden Apps zusätzliche Möglichkeiten. So können die Kacheln in Farbe und Icon direkt angepasst werden.

Die neue Statistics-App (Abb. 8) ermöglicht es, den Nutzen von ScriptRunner transparent zu machen.

Screenshot der Einstiegsseite der Statistics-App im ScriptRunner Portal

Abb. 8: Das neue Statistics-App in ScriptRunner Portal

Weitere Informationen und Details zum neuen Portal können Sie im Blogbeitrag Das neue ScriptRunner Portal – aus drei mach eins nachlesen.

ScriptRunner Portal Widget

Mit dem Portal Widget können unsere Kunden ScriptRunner Aktionen in verschiedenste Anwendungen nahtlos einbinden und die volle Funktionalität von Validation und Queries nutzen.

Das ermöglicht „unsichtbare“ kontextnahe Verwendung von mit ScriptRunner automatisierten Aufgaben in anderen Applikationen. So kann eine ScriptRunner Aktion für Endanwender im Intranet direkt an der Stelle platziert werden, die inhaltlich in Bezug damit steht (Abb. 9).

Mit dem Widget können bereits vorhandene eigene Self-Service Portale funktional ausgebaut, Fachanwendungen um neue Funktionen erweitert sowie ITSM Systeme aufgewertet werden.

Aufgrund der einfachen Integrierbarkeit sind ihren Vorstellungen keine Grenzen gesetzt, Anpassen des Stylings inklusive.

Screenshot einer eingebetteten ScriptRunner Aktion zur Erstellung einer virtuellen Maschine

Abb. 9: Anwendungsbeispiel des ScriptRunner Portal Widgets

Weitere Informationen und Details zum neuen Portal Widget fiden Sie im Bogbeitrag Das neue ScriptRunner Portal – aus drei mach eins oder auf der Portal Widget Seite.

Erweiterte Rollenkonfiguration

Mit der Integration in Azure AD wurden Erweiterungen und Verbesserungen in der Rollenkonfiguration implementiert. So können nun einer Rollengruppe in ScriptRunner mehrere Gruppen und/oder Einzelaccounts zugewiesen werden.

Dazu klicken Sie einfach den +-Button bei My Claims (Abb. 10). Sie können nun eine Gruppe oder einen Account hinzufügen.

Neu ist die Suchfunktion bei für lokale Gruppen/Accounts, für Active Directory Gruppen und Accounts sowie Azure AD Gruppen und Accounts.

Die Option Basic Auth ist der Verwendung mit Web Service Connectoren vorbehalten.

Screenshot ScriptRunner Portal: Function for adding new groups or accounts

Abb. 10: Funktion zum Hinzufügen neuer Gruppen oder Accounts

Verbindungstest zu Zielsystemen

Verbindungsprobleme zu Zielsystemen oder Cloudservices gehören zum Alltag von Administratoren. Die Ursachen können vielfältig sein. Die Probleme können von der Infrastruktur zwischen ScriptRunner Server und dem Zielsystem herrühren, wie Firewalls, Proxies etc. Auch das Zielsystem kann nicht ausreichend konfiguriert sein (lokale Firewall, Remoting) oder Authentifizierung schlägt fehl.

Bisher mussten dafür Testscripte geschrieben und Testaktionen eingerichtet werden. Ab dieser Version übernimmt ScriptRunner direkt den Verbindungstest. So können Fehler schneller eingegrenzt und behoben werden. Einfach das Zielsystem auswählen, in der Action Bar Test klicken und dann den Test starten. Die Liveausgabe zeigt Ihnen, was gerade passiert.

Screenshot Protokoll eines Verbindungstests in ScriptRunner

Abb. 11: Liveausgabe eines Verbindungstests

Im Testablauf wird eine Remote Session mit dem hinterlegten Credential zum Zielsystem aufgebaut und $PSVersion des Zielsystems ausgegeben. Anschließend wird die Verbindung wieder geschlossen. Die Ergebnisse können jederzeit als PowerShell Report eingesehen werden.

PowerShell Remoting mit Zertifikats-basierter Authentifizierung

Der WinRM-Dienst in Windows bietet die Möglichkeit eine PowerShell Remoting Session mittels eines Zertifikats zu authentifizieren. Dazu muss WinRM über HTTPS am Zielsystem aktiviert sein und ein Zertifikat dort gespeichert sein. Details dazu finden Sie in der Microsoft Dokumentation.

In ScriptRunner wird anschließend ein entsprechendes Credential konfiguriert. Anschließend weisen Sie das Credential dem Zielsystem zu und nutzen die https Option bei den Remoting-Einstellungen.

Screenshot des neuen ScriptRunner Credentials für Zertifikats-basierte Authentifizierung mit WinRM

Abb. 12: ScriptRunner Credential für PowerShell Remoting mit Zertifikats-basierter Authentifizierung mit WinRM

 PowerShell Splatting Feature

Dieses neue Feature bringt mehrere Vorteile für das Design von Use Cases in ScriptRunner. So können mit einer einzigen Query mehrere Attribute bzw. Properties eines Objektes ermittelt und an das Hauptscript übergeben werden.

In dieser Version können dazu Scripted Queries und Azure Queries verwendet werden. Somit können aufwendige Query-Kaskaden entfallen, der Use Case wird für die Anwender übersichtlicher und in einem Use Cases können mehrere Attribute einfacher weiterverarbeitet werden. Die Komplexität im PowerShell Script wird wegen der direkten Zugriffe auf die Inhalte reduziert.

Bei Scripted Queries kommt im Query Script eine Hashtable zum Einsatz, welcher die Ergebnisse der Query zugewiesen werden. Unter Verwendung von Azure Queries ist die Ergebnismenge in einem JSON Objekt gespeichert.

Egal ob Hashtable oder JSON in der Query, die Ergebnisse werden kodiert an einem Parameter im Hauptscript übergeben, dem die Query zugewiesen wurde.

Der Parameter im Hauptscript muss vom Typ Hashtable sein. Der Aufbau der Hashtable folgt den zu verwendenden Einzelparametern in der Hashtable. Die Namen der Parameter in der Hashtable müssen den Namen Parameter in der Query-Hashtable bzw. des JSON-Objektes entsprechen. Dadurch werden von ScriptRunner die passenden Werte automatisch gemapped.

Zusätzlich kann für einzelne Parameter der Hashtable ein Read-Only-Attribut verwendet werden. Der nachfolgende Beispielcode zeigt die Verwendung im Hauptscript der Aktion.

Das Parameter-Attribut [Parameter(HelpMessage=“ASRDisplay(Splatting)“)] schaltet das Feature für den Parameter [hashtable] $Address ein. Diesem Parameter $Address muss in der Action-Konfiguration die entsprechende Query zugewiesen werden.

Die weiteren Parameter in der Hashtable selbst definieren deren Aufbau. Die Parameternamen müssen den Namen in der Ergebnismenge entsprechen.

Wird nun im UI ein Element aus der Ergebnismenge ausgewählt (hier Peter Heim), so mapped ScriptRunner die Werte für die nachfolgenden Parameter automatisch.

Mit dem Parameter-Attribut [Parameter(HelpMessage=“ASRDisplay(Readonly)“)] wird der Parameter [string] $Name im UI als nicht änderbar verwendet.

Der Parameter [string] DateofBirth erhält keine Werte, da er entweder in der Ergebnismenge nicht vorhanden ist oder keine Namensgleichheit des Parameters existiert.

Weitere Informationen zu diesem Feature finden Sie auf unserer Knowledge Base: Return multiple properties with a single Query.

        

ScriptRunner SRXEnv-Systemhashtable

Die in Scripten verwendbare Systemhashtable wurde um weitere Parameter erweitert:

  • SRXEnv.ActionID enthält die ID der gestarteten Aktion

  • SRXEnv.StartedReason enthält den String, welcher als Grund im UI eigegeben wurde

  • SRXEnv.CommandPath enthält den Pfad und Name der verwendeten Scriptdatei

PowerShell 7

Die wahlweise Verwendung von PowerShell 7 wurde auf weitere Elemente in ScriptRunner ausgebaut. Neben Aktionen können nun Scripted Queries ebenfalls PowerShell 7 nutzen. Der Verbindungstest unterstützt ebenfalls Zielsysteme mit PowerShell 7. 

scriptrunner-portal-783x447-1

Webinar Special

ScriptRunner 2020R2 – Was ist neu?

Unsere aktuelle ScriptRunner Version 2020R2 kommt mit vielen neuen Funktionen. In diesem Webinar werden wir die Highlights dieser Version präsentieren und zeigen, wie sie Ihnen bei Ihrer Automationsmission helfen.

Jetzt kostenlos ansehen >

Weiterführende Links

Zusammenhängende Posts

2 min read

VMUG Webcast: VMware Management meistern mit PowerCLI

5 min read

PowerShell mit Get-Help meistern

Über den Autor: