Jetzt testen

ScriptRunner 2020R3 – voller Funktionsumfang im Portal, Multi-Attribute Queries und mehr Aktionen für Endanwender

Inhaltsverzeichnis

Post Featured Image

Die Version 2020R3 rundet den Entwicklungszyklus mit einer Reihe von Verbesserungen und neuen Funktionen ab. Sowohl in ScriptRunner Portal als auch im ScriptRunner Server gibt es Neuigkeiten:

  • Erweiterungen und neue Apps im ScriptRunner Portal
  • Multi-Attribute Queries für Azure, Active Directory und mit Scripten
  • Queries mit Parametern zur Suchsteuerung
  • Erweiterte Cache-Modi für Queries
  • Script Repositories für Admin-Teams
  • Vereinfachte Azure AD App Registrierung
  • Mehr Aktionen für Endanwender

Ausblick auf die Produktstrategie

Wir haben unsere Entwicklungsaktivitäten mit Abschluss dieser Version aufgeteilt. Die konsequente Weiterentwicklung in einer Portal-Edition soll den Übergang aus der Welt der alten Web-Apps in die neue Welt des rollenbasierten ScriptRunner Portals bis zum Jahreswechsel weitgehend abschließen. Dafür sind drei Releases der Portal-Edition auf der Basis der aktuellen Backendversion geplant.

Parallel dazu beginnen die Entwicklungsarbeiten an der neuen Architektur ab Version 7 von ScriptRunner, welche ScriptRunner sowohl als Multi-Server-, als Multi-Location- und als Hybrid-Cloud-Lösung ermöglichen soll.

         

Erweiterungen und neue Apps im ScriptRunner Portal

Im ScriptRunner Portal sind nun die Apps „Ausführen/Run“ und „Reports“ im Funktionsumfang kompatibel bzw. sogar erweitert gegenüber der bisherigen Admin App.

Die neue Authorize & Delegate-App entspricht dem Hauptmenüpunkt „Delegation“ der Admin App, geht aber in vielen Details deutlich über dessen Funktionsumfang hinaus. Das Hauptmenü „Settings“ aus der Admin App wurde im Portal neu gestaltet.

Die eingebaute Supportticket-Funktion wurde erweitert, sodass unser Support gleich die installierte Version und den Build von Server und UI zur Hand hat.

Einstiegsseite des ScriptRunner Portals in der Admin-Ansicht

Einstiegsseite des ScriptRunner Portals in der Admin-Ansicht

Neues in der Run-App

In der Run-App wurde der Funktionsumfang so ergänzt, dass dieser zusätzlich zu Endanwendern und Helpdesk nun auch für die beiden Administrator-Rollen das Verhalten des „Run“- und des „Delegate“-Buttons aus der Admin App abbildet.

Administratoren können Parameter-Sets verwenden und Zielsysteme zur Ausführung auch abweichend von der Konfiguration wählen. Zusätzlich kann die Verbose-Option von PowerShell speziell für diese Ausführung eingeschaltet werden.

Sowohl in der Kachelansicht als auch in der Listenansicht sind nun jeweils die Funktionen „Edit Display Options“, „Show Reports“ und „Edit Delegations“ für Administratoren verfügbar.

Neu gestaltet und zusammengefasst wurden die bisher verstreuten Anzeigeoptionen unter „Edit Display Options“. Es können nun zentral konfiguriert werden:

  • Symbol der Aktion
  • Farbe der Aktion
  • Kurzbeschreibung der Aktion in verschiedenen Sprachen. Sind im Script die Sprachen für Synopsis und Description mit Sprachkennzeichen hinterlegt, so werden diese automatisch eingesetzt. Neu ist ebenfalls, dass Änderungen im Script sofort übernommen werden.
  • Die Langbeschreibung mit Markdown dient einer erweiterten Beschreibung für die Anwender. Durch die Verwendung von Markdown können Texte fett und kursiv sowie in Listen dargestellt werden. Auch das Einbinden von URLs ist nun möglich, um Anwendern zusätzliche Quellen und Verweise in der Aktion zugänglich zu machen
Screenshot: Dialog

Die „Edit Display“-Optionen wurden umgestaltet und in einem Dialog zusammengefasst

Im Funktionsblock „Edit Delegations“ an der jeweiligen Aktion können die entsprechenden Rollen zugeordnet werden, welche die Aktion verwenden dürfen.

Neues in der Report-App

Die neue Report-Apps wurde für die Administratorenrollen so ergänzt, dass es im Funktionsumfang dem Dashboard sowie den „Funktion Reports“ und Dashboard der Action Bar in der Admin App entspricht.

Über die Auswahl „My Reports“ und „All Reports“ wurde zudem eine zusätzliche Filtermöglichkeit geschaffen. Über die Kacheln kann schnell zwischen erfolgreichen und fehlgeschlagenen Aktionen gewechselt werden. Die Filter werden sowohl auf die Diagramme als auch die darunter positionierte Liste angewandt.

Die Liste selbst erlaubt zusätzlich die Auswahl und den Vergleich zweier beliebiger Reports in einem Vergleich-Fenster mit Diff-View, sowie das separate Abrufen von HTML-Reports.

Screenshot: Neue Report-Filteroptionen im Report-Modul von ScriptRunner Version 2020R3

Das Reports-Modul wurde um neue Filteroptionen ergänzt

Spezielle Möglichkeiten ergeben sich im Filter-Overlay. So können Reports nach Datum, Aktion, verwendetem Zielsystem und Script oder nach Anwendern gefiltert werden.

Screenshot: Neue Optionen im Filter-Overlay

Filter für Datum, Aktion, Zielsystem, Script und Anwender wurden in das Filter-Overlay des Berichtsmoduls eingefügt

Im Detailfenster des Reports kann über Tabs auf die PowerShell-Ausgabe, die scriptbare Result Message sowie einen erzeugten HTML Report zugegriffen werden (auch live während der Ausführung). Die Reportdetails können heruntergeladen, in die Zwischenablage kopiert oder per „mailto:“ versendet werden.

Screenshot: Dialog Report-Details in ScriptRunner Version 2020R3

Mit der neuen Tab-Navigation im Reports-Detail-Fenster können Sie schnell zwischen Aktionsreport, Ergebnismeldung und HTML-Report wechseln

Die neue Authorize and Delegate-App

Diese App vereint die Funktionen aus dem Hauptmenüpunkt „Delegation“ aus der Admin App sowie einen neuen Wizard zum Anlegen von Rollen und zum Konfigurieren von Mitgliedschaften zu den Rollen sowie die Delegation auf diese Rollen.

Auf der Übersichtsseite sind alle bereits konfigurierten Rollen basierend auf den Templates für Main Administrators, Administrators, Helpdesk und Endanwender aufgelistet.

Screenshot: Die neue Authorize and Delegate-App in ScriptRunner Version 2020R3

Das neue Modul Authorize and Delegate für die Rollen- und Delegationsverwaltung

Zum Anlegen einer Rolle wird der neu entwickelte Wizard verwendet, welcher gezielt durch die einzelnen Schritte führt. Je nach ausgewähltem Rollen-Template unterscheiden sich diese.

7-Role-Wizard-ScriptRunner-2020R3

Der neue Rollenkonfigurations-Wizard

Für die Rolle „Administratoren“ (eines Teams) kann zusätzlich die neue Funktion „Team Repository“ konfiguriert werden.

Die neue Settings-App

Die Settings-App gibt den Status der Lizenzen sowie die am Server vorgenommen Einstellungen an den Connectoren wieder.

Screenshot: Settings-App in ScriptRunner Portal

Die neue Settings-App

Multi-Attribute-Queries für Azure AD und AD

Queries dienen einer verbesserten Interaktivität, in dem sie eine Auswahlmöglichkeit für die Anwender von PowerShell-Scripten schaffen. So können Anwender im Portal Benutzer, Gruppen, Ressourcen oder andere durch Queries erzeugte Listen als Auswahlliste oder per Suche verwenden. Für das ausgewählte Objekt waren bisher ausschließlich der Displayname und ein Attribut, welches an einen Script-Parameter übergeben wird, möglich. Sollten mehrere Attribute des gleichen Objektes im Script verwendet werden, mussten bisher kaskadierte Queries verwendet werden.

Ab ScriptRunner 2020R3 können nun Multi-Attribute-Queries verwendet werden. Eine AD, Azure AD MS/Azure Graph Query kann also eine Vielzahl von Attributen mit einer Abfrage ermitteln und an das Script übergeben.

Schematische Darstellung des Funktionsprinzips der Multi-Attribut Queries in ScriptRunner 2020R3

So funktionieren Multi-Attribut Queries in ScriptRunner 2020R3

In ScriptRunner werden Attribute des ausgewählten Datensatzes als encodiertes JSON-Objekt an den PowerShell-Prozess übergeben. Wurde im Script ein Parameter vom Typ [hashtable] mit dem ScriptRunner Splatting-Feature im Param-Block definiert, können die Attributwerte an die Parameter der Hashtable im Hauptscript übergeben werden. Soll ein spezifisches Mapping der Attributnamen aus dem JSON-Objekt auf die Parameternamen der Hashtable erfolgen, so kann dafür das ScriptRunner Alias-Feature verwendet werden.

Der Zugriff auf die Parameter im JSON der kann in folgenden Varianten erfolgen:

  • über einen PowerShell Parameter, der Namensgleichheit mit dem JSON Parameter besitzt (Automapping)
  • über einen PowerShell Parameter, der ein Alias-Attribut für JSON Parameter besitzt (Alias-Mapping)
  • direkt auf die Parameter der Hashtable

So ist es möglich, dass das JSON-Objekt und die PowerShell-Hashtable bspw. 10 Parameter enthält, aber nur 5 davon als einzelne PowerShell Parameter bearbeitet werden sollen.
Das Mappen auf PowerShell Parameter hat zudem den Vorteil, dass diese Parameter verändert werden können, jedoch jederzeit auf die originalen Werte in der Hashtable zugegriffen werden kann.

Param(
		[Parameter(HelpMessage=„ASRDisplay(Splatting)“)]
		[hashtable] $object,
		…
		[Parameter(HelpMessage=„ASRDisplay(Alias=l)“)]
		[string] $location
		…
)

$City = $object.location

Die Konfiguration an der Query erfolgt im Abschnitt der Parameter Values. Wenn als Parameter Value „JSON object“ ausgewählt wurde, kann anschließend die Attributliste zusammengestellt werden.

Für AD Queries sind alle AD Attribute für das jeweilige Objekt erlaubt. Ein Minimalset wird als default immer angewendet. AD Attribute können mit dem AD Attribut-Editor ermittelt werden. Es ist auf korrekte Namensgleichheit zu achten.

Kommen Azure AD Queries zum Einsatz ist das Verfahren äquivalent. Die verfügbaren Attribute können der Azure AD Dokumentation entnommen werden.

Bei Testen der Query in der Admin App wird eine Testergebnismenge ermittelt. Mittels Mouse-Over über den encodierten JSON-String können die einzelnen Attribute des Objektes aufgelöst und angezeigt werden.

Parametergesteuerte AD und Azure Queries

Abfragen auf Objekte im Active Directory, ins Azure AA oder mittels MS / Azure Graph mussten bisher so konfiguriert werden, dass sie bei jedem Aufruf eine vorab definierte Ergebnismenge liefern, aus welcher der Anwender Elemente auswählen kann.

Ziel unserer Weiterentwicklung von Parameter-gesteuerten Queries war, eine höhere Flexibilität zu ermöglichen. Es ist nun möglich, mit einer Query verschiedene Ergebnismengen zu adressieren (z.B. Benutzer/Gruppen verschiedener Department oder Standorte). Im Zusammenspiel mit Multi-Attribute-Queries sowie dem Splatting-Feature kann die Vielfalt und Anzahl an Queries deutlich reduziert werden.

Die neuen Funktionen erlauben es, die Queries mit Eingangsparametern zu steuern. Die Eingangsparameter können entweder über eine manuelle Eingabe oder durch Auswahl aus einer vorangegangenen Query zugeführt werden. Zudem können in der Konfiguration Default-Werte bestimmt werden, was den Einsatz einer Query sowohl als fixe als flexible Abfrage ermöglicht.

 

Schematische Darstellung des Funktionsprinzips parametergesteuerter AD und Azure Queries in ScriptRunner 2020R3

Schema: Parameter-gesteuerte AD und Azure Queries in ScriptRunner 2020R3

Aus Anwenderperspektive verhalten sich Parameter-gesteuerte Abfragen wie sonstige Formulare. Der Anwender befüllt also im Formular der Aktion die Eingangsparameter manuell oder durch Auswahl aus den Ergebnissen einer anderen Query. Die Query startet und verwendet die Eingaben als Eingangswerte für die Suche und liefert je nach Eingangswerten eine unterschiedliche Ergebnismenge.

Beispiel: Exchange Ressourcen

An einem Anwendungsbeispiel mit Ressourcen (Räume und Equipment) in Exchange wird es transparent. Der Use Case soll das Managen beider Arten von Ressourcen-Typen in einer ScriptRunner Aktion ermöglichen.

Zuerst wird ein Script benötigt, welches die notwendigen Parameter und dann auch die Logik enthält. Hier beschränken wir uns auf die Parameter und die Query.

Screenshot: Script-Snippet

Der Parameter $Type soll als Eingangswert in die Query verwendet werden und nur die beiden Werte „room“ und „equipment“ annehmen. Die beiden Parameter $MailboxId und $Properties dienen für die Auswahl der Ressource und das Festlegen ihrer Eigenschaften.

In der Konfiguration der Query „List of Exchange Resources“ werden zum Filter auf Exchange Ressourcen im Active Directory die Einstellungen „deaktivierter User“ sowie der Attributfilter „[msExchResourceDisplay]“ festgelegt. Im Feld Attributewert wird die Variable „%SRXQueryIn1%“ verwendet. Diese soll steuern, ob in der Ergebnismenge Räume oder Equipment zur Auswahl stehen werden.

11-Query

In der Aktionskonfiguration kann nun festgelegt werden, wie die Query verwendet werden soll. Sie könnte sowohl als fixe Query auf Räume oder Equipment verwendet werden als auch flexibel für beide Fälle. Das erfolgt mittels Voreinstellung am Parameter $Type.

Dem Parameter $MailboxId wird nun die Query „List of Exchnage Resources“ zugewiesen. Außerdem muss die Zuweisung des Parameter $Type auf den Eingangsparameter %SRXQueryIn1% erfolgen.

12-Action

Verbesserter Query Cache

Die Möglichkeiten, um Ergebnisse von Abfragen zu cachen, wurden gezielt erweitert. Der neue Caching-Mechanismus unterstützt dabei vor allem den Umgang mit großen Datensatzmengen und zeitaufwendigen Abfragen. Insbesondere alle Arten von Scripted Queries und Multi-Attribute-Queries auf das AD und Azure AD profitieren merklich davon.

Die zwischengespeicherten Ergebnisse erlauben dem Portal-Anwender die Suche und den schnellen Zugriff auf bis zu 100.000 Datensätze mit einer sehr kurzen Interaktionszeit. Es können sowohl JSON-Objekte als auch Einzelparameter als Datensatz zwischengespeichert werden.

Schematische Darstellung des Query Cache in ScriptRunner 2020R3

Funktionsweise des Query Caches in ScriptRunner 2020R3

Zum Aktualisieren des Cache stehen wie bisher zwei Optionen zur Verfügung: nutzungsabhängiger automatischer Refresh oder zeitgesteuerter Refresh.

Team-Repositories für Scripte

Arbeiten mehrere Admin-Teams auf einer ScriptRunner-Instanz, wird durch das Rollenkonzept sichergestellt, dass jedes Team nur seine eigenen Elemente (Credentials, Targets, Queries, Actions) erstellen, konfigurieren und verwenden kann. Darüber hinaus können Elemente auch allen zur Verfügung stehen (public).

Bei Script-Elementen war das bisher etwas anders. Diese mussten von einem Main-Administrator nach manuell den einzelnen Teams zugewiesen werden.

Mit der Version 2020R3 wurde die Unterstützung von Team-Repositories eingeführt, um Ordner und Scripte, welche dort synchronisiert bzw. gespeichert werden, automatisch dem jeweiligen Team als Owner zuzuweisen.

So ist es nun auch möglich, in getrennte Repositories aus Git in das jeweilige Repo des Teams zu synchronisieren.

ACHTUNG: die Stammordner für die Team-Repositories müssen sich in der Script-Library auf der obersten Ebene befinden.

Screenshot: Team Repository-Option in den Gruppen oder Account Eigenschaften in ScriptRunner 2020R3

Über die Option Team Repository können mehrere Scripte einem Team zugeordnet werden

Zur Einrichtung der Teamfolder-Funktion ist folgende Reihenfolge einzuhalten:

  1. Anlegen eines Stammfolders für das Team-Repo als Subfolder der Script-Library-Root
  2. Admin App (Delegation) oder Portal (Authorize & Delegate) öffnen
  3. Team Folder Option aktivieren und Stammordnernamen des Team Repositorys eintragen

Anschließend können diesem Team-Repository neue Script hinzugefügt werden, z.B. durch Synchronisation mit einem Git-Repository.

ACHTUNG: wenn Sie einen bereits vorhandenen Ordner mit Scripten als Stammordner verwenden, so wird die Ownership dieser Scripte NICHT automatisch geändert, um die Funktionsweise bestehender Aktionen und Konfigurationen weiterhin sicherzustellen.

Bitte kontaktieren Sie bei Fragen zur Umstellung auf Team-Repositories unseren Support.

Mehr Aktionen für Endanwender

Mit dieser Version wurde die Lizenzierung für Endanwender erweitert. Bisher standen für jeden Endanwender nur bis zu 10 zugewiesene Aktionen zur Verfügung.

Um auch Anforderungen nach mehr Self-Service für Endanwender abdecken zu können, sind die Lizenzen für Endanwender nun auch in Staffeln für bis zu 20 und bis zu 30 Aktionen je Endanwender verfügbar.

Ein Mischbetrieb ist nicht möglich, die erweiterte Lizenz ist für alle Endanwender zu erwerben. Ist die Anzahl der Endanwender mit mehr als 10 Aktionen begrenzt, so empfehlen wir diese Anwender alternativ mit einer Helpdesk-Lizenz auszustatten.

Erweiterte Supportfunktion im Portal

Wird das Portal in der Rolle Main Administrator oder Administrator verwendet, können Sie im Portal direkt unseren Support kontaktieren. Dabei werden nun automatisch die Versionsinformationen von ScriptRunner hinzugefügt.

Setup ohne Beispielkonfiguration

Das Unattended-Setup für ScriptRunner wurde um die Option zum Installieren ohne Beispielkonfiguration erweitert. Somit können Neuinstallationen und Migrationen bestehender Systeme erfolgen, ohne dass die Beispiele für den produktiven Betrieb entfernt werden müssen.

Weitere Verbesserungen

Der PowerShell Host von ScriptRunner verwendet nun standardmäßig die Einstellung TLS 1.2. Das ist insbesondere für ältere Windows Server Varianten bedeutsam, um kompatible Verbindungen zu M365 und höherwertigen Windows Server Versionen zu ermöglichen.

Bei der Konfiguration von Rollen in ScriptRunner können nun auch Gruppen und Accounts in multi-trusted-forest Konstellationen gefunden werden.

Die Einschränkungen zur Verwendung einer bestimmten des Az-Moduls wurden beseitigt.
Änderungen in der Synopsis und Description eines Scriptes werden nun ebenfalls im UI aktualisiert.

 

ScriptRunner Mascot Jeff Scriptwalker

Entdecken Sie ScriptRunner Version 2020R3 live und in Farbe

Buchen Sie noch heute Ihre kostenlose Demo mit Produktexperte Clemens Feigl und erfahren Sie, wie ScriptRunner das PowerShell-Management in Ihrem Unternehmen vereinfacht. 

Demo vereinbaren

Über den Autor: