Neue ScriptRunner Version2018R3 Features PowerShell Password Server Cyberark Thycotic Pleasant

Feature-Überblick zur neuen Version 2018R3

Die neue ScriptRunner Version 2018R3 bringt viele neue Features und Verbesserungen für unsere Kunden. Die Schwerpunkte der Entwicklungsarbeiten waren unter anderem Passwort-Sicherheit und Benutzerfreundlichkeit für die Anwender der Delegate App. Alle Neuerungen wollen wir hier nachfolgend im Detail vorstellen.

Neue Delegate App

Die Delegate App wurde im Rahmen der Aktualisierungen unserer verwendeten Code-Frameworks komplett überarbeitet. Zur Darstellung der Aktionen gibt es nun eine zweite Ansicht. Neben der klassischen Kacheldarstellung gibt es nun auch die Listenansicht. Alle Informationen, welche im Kachelformat dargestellt werden, sind auch in der Listenansicht verfügbar. Zusätzlich wird in der neuen Ansicht der Zeitpunkt der letzten Ausführung sowie der Zeitpunkt der nächsten zeitgesteuerten Ausführung angezeigt. Die Umschaltung zwischen den Ansichten erfolgt mit dem leicht erkennbaren Liste/Kachel Symbol mit dem Button neben dem Suchfeld.

new ScriptRunner Delegate App Powershell GUI

New Delegate App in ScriptRunner 2018R3. The new list view on the left, the classic tiles on the right.

Völlig neu gestaltet wurden ebenfalls die Registerkarten. So kann sich nun jeder Anwender seine Registerkarten-Auswahl selbst zusammenstellen. Mit dem „+“ Button in der Menüleiste kann er ein noch nicht angezeigtes Register auswählen und hinzufügen. Die neue Registerkarte gliedert sich in die Leiste ein; die Register bleiben weiterhin alphabetisch sortiert. Nicht oder selten benötigte Register können einfach am Register selbst mit dem „x“-Button geschlossen werden.

Ebenfalls verändert wurde das Startverhalten der Delegate App. Sind keine Aktionen als Favoriten über das Setzen des Stern-Symbols ausgewählt, so wird das Register „Alle“ verwendet.

Alle Einstellungen werden anwenderbezogen gespeichert, so dass beim erneuten Starten der Delegate App deren Einstellungen sofort wieder zur Verfügung stehen.

Überarbeitete Formulare und neue Datentypen

Weitere neue Features betreffen die Anwendung von Aktionen und die Formulare selbst. Sind für eine Aktion mehr als 7 Eingabefelder definiert, kann auf eine Ansicht mit mehreren Eingaberegistern umgeschaltet werden. So wird die Übersichtlichkeit für den Anwender verbessert und das Scrollen in langen Formularen entfällt.

Die automatische Generierungsfunktion für PowerShell-Datentypen wurde um die zwei Typen [SecureString] und [DateTime] erweitert. [SecureString] verdeckt die Eingabe, [DateTime] stellt einen Datums-Picker zur Verfügung. Beide neuen Datentypen stehen auch in den Formularen der Admin App zur Verfügung. Mehr zur Darstellung von Datentypen in ScriptRunner haben wir Ihnen hier erläutert.

Neben dem Datentyp [SecureString] können auch andere Datentypen mit einer verdeckten Eingabe versehen werden. Außerdem können Eingabefelder nun als Multiline-Eingaben definiert werden. Für beide Szenarien wird in der Parameter-Deklaration im Script ein zusätzliches Parameter-Attribut verwendet.

 

 

new input form, powershell

New input forms in the ScriptRunner Delegate App

Änderungen an Eingabefeldern, welche von Attribute-Queries befüllt worden sind, werden nun mit einem farbigen Hintergrund hervorgehoben. So können geänderte Felder besser von unveränderten Feldern unterschieden werden.

Die normierte Dateneingabe in Felder ist oftmals ein Problem. Unterschiedliche Schreibweisen für die gleichen Bezeichnungen etc. führen zu einer schlechten Datenqualität. In PowerShell-Scripten verwendet man dafür Validate-Sets. Diese werden in der Web App von ScriptRunner als Dropdown dargestellt. Neu ist nun die Berücksichtigung von Validate-Sets auch bei der Verwendung von Attribute-Queries. Diese Funktionalität lässt sich verwenden, um bspw. vorhandene unterschiedliche Werte von AD-Attributen bei Änderungen schrittweise zu vereinheitlichen. So lassen sich in einer Aktion zur Änderung der Benutzereigenschaften die Queries und Validate-Sets für Attribute wie Department, Location oder ähnliches kombinieren. Entspricht das Abfrageergebnis dem Wert im Validate-Set, bspw. „Sales“, wird es unverändert verwendet, im Dropdown-Menü ist der Wert bereits ausgewählt. Demgegenüber werden nicht konforme Abfrageergebnisse nicht angezeigt, sondern das Validate-Set steht zur Auswahl.

Wiederholtes Ausführen einer Aktion

Aktionen können nun mit den letzten Parameterwerten wiederholt ausgeführt werden, ohne dass diese neu eingegeben werden müssen. Diese Funktion steht ebenfalls in der Admin App zur Verfügung. Außerdem wurde das interaktive Rückmeldefenster nach dem Start der Aktion verbessert. Es enthält nun eine Fortschrittsanzeige als auch die Möglichkeit zur erneuten Ausführung der Aktion mit den gleichen Parametern wie beim letzten Ausführen.

Delegate App im Corporate Design

Sie können nun die Delegate App für die Anwender an Ihr Firmen-CD anpassen. Die Anpassung betrifft drei Eigenschaften:

  • das Startbild beim Aufrufen der App, auch Splashscreen genannt
  • das Logo links oben in der Top-Bar
  • die Farbe der Top-Bar

Die Einstellungen erfolgen im Verzeichnis der Web App auf dem Web Server. Wird der IIS mit der Standardinstallation verwendet, befinden sich unter

die dafür notwendigen Einstellungen. Diese bleiben bei zukünftigen Updates erhalten.

Zuerst sollten Sie zwei Bilddateien im PNG-Format in dem Verzeichnis speichern:

  • die Logodatei als custom_headerlogo.png mit einer max. Höhe von 30px
  • die Splashscreendatei als custom_splashscreen.png mit einer max. Breite von 530 px

Anschließend editieren Sie die Datei customstyle.css. Entfernen Sie das Ende-Kommentarzeichen „*/“  hinter dem Hintergrund-Farbwert. Tragen Sie den Farbwert für den Hintergrund als Name, z.B. green oder Hexwert, z.B. #a1cc1f, ein.

customizing scriptrunner app

Customizing der Delegate App im firmeneigenen CD

Starten Sie anschließend mit IISReset den Web Server durch. Nun können Sie die Delegate App im firmeneigenen CD nutzen.

Neue Sicherheitsstufe für Credentials

Für die Ausführung von PowerShell-Scripten sind in der Regel administrative Zugriffe notwendig. ScriptRunner verwaltet die Informationen für diese Credentials mit seinen Ausführungsrichtlinien (Aktionen).

Credentials in ScriptRunner

Die Speicherung der Credentials erfolgt im Credential Store des Windows Betriebssystems auf den ScriptRunner Host. Wird der ScriptRunner Service im Standard betrieben, wird der Credential Store von Local System verwendet, im Falle eines anderen Kontos dessen Credential Store auf der lokalen Maschine.

Wird ein Script gestartet, so startet auf dem ScriptRunner Host ein Windows Hintergrundprozess für die PowerShell. Je nach Konfiguration der Richtlinie greift dieser Prozess über die Betriebssystem-Mechanismen auf die dort gespeicherten Credentials zu. Durch diese Systematik hat der ScriptRunner-Prozess selbst zu KEINER Zeit Zugriff auf die Passwortinformationen. Die Steuerung der Policies erfolgt durch ScriptRunner ausschließlich durch Referenzen auf die im Betriebssystem gespeicherten Credentials.

Dieses insgesamt sehr sichere Verfahren wurde bereits in einer früheren Version von ScriptRunner erweitert. Zum einen wurde der sichtbare Account-Name durch eine generierte GUID ersetzt. Im Weiteren wurde eine zusätzliche Verschlüsselung der Passwortinformationen implementiert, um einem Angreifer, welcher bereits Zugriff auf den ScriptRunner Host erlangt hat, keine Möglichkeit zu bieten, mit einem Tool wie Mimikaz die Passwortinformationen der Credentials auszulesen. Da die Verschlüsselung individuelle Maschinenmerkmale nutzt, kann auch ein Speicherabzug nicht dazu verwendet werden, um Passwortinformationen wiederherzustellen.

Diese Vorkehrungen sind bei der Einhaltung einiger Grundregeln sehr sicher, dennoch ist der ScriptRunner Host auch auf Grund seiner Funktionen eine kritische Komponente in der Infrastruktur. Aus diesem Grunde sollte der Zugriff und die interaktive Anmeldemöglichkeit am Host nur für einen sehr eingeschränkten Personenkreis erlaubt sein. Diese Accounts agieren in der Rolle des „Host Administrators“ könnten somit den Zugriff auf die Systemressourcen wie den Credential Store erlangen.

Ein zusätzliches Level an Sicherheit

Um ein noch höheres Level an Sicherheit für die Credentials implementieren zu können, unterstützt ScriptRunner ab dieser Version zentrale Passwort-Safes bzw. Passwort Server. Passwort Server sind eine spezifische Infrastruktur-Komponente, um netzweit Benutzer-, Applikations- und System-Passwörter zentral zu managen, automatisch zu erneuern und diversen Frontend- und Backend-Anwendungen zur Verfügung zu stellen. Dabei verwalten die Passwort Server verschiedene Safes, in denen jeweils die notwendigen Account-Informationen gespeichert sind. Der Zugriff der jeweiligen Applikation kann auf einen bestimmten Safe beschränkt werden.

ScriptRunner unterstützt die führenden Passwort Management Systeme wie Pleasant Password Server, Thycotic Secret Server, sowie CyberArk Password Vault.

Funktionsweise und Konfiguration

Wird ein Script gestartet, so startet auf dem ScriptRunner Host ein Windows-Hintergrundprozess für die PowerShell. Der Hintergrundprozess erhält ein temporäres Token. Mit diesem Token kann der Prozess auf den Passwort-Safe zugreifen und über eine Referenz-ID das zugehörige Credential abrufen. Durch diese Systematik ist auf dem ScriptRunner Host keine Account-Information mehr vorhanden, sondern nur noch die Referenz-ID auf das Credential im Passwort-Safe.

Neben dem Token-Mechanismus kann auch ein Reverse-Proxy-Mechanismus zum Einsatz kommen. CyberArk nutzt diese Form, um mittels einer Reverse-Anfrage sicherzustellen, dass nur ein vorher definierter und charakterisierter Prozess eine Passwortanfrage stellen darf, welche auch nur vom Passwort-Safe-Proxy an den Passwort Server weitergeleitet und beantwortet wird.

Die Verbindung zwischen ScriptRunner und dem Passwort Server System erfolgt mittels Connector. Die Konfiguration der Verbindung erfolgt über das PowerShell-Cmdlet

sowie für CyberArk zusätzlich mit dem Cmdlet

Wichtig ist die Auswahl der richtigen API für das jeweilige Produkt über den Parameter -API  ‚product_api_name‘ sowie die Konfiguration aller Verbindungsinformationen.

scriptrunner password server connector powershell

Password Server Connector eg. Pleasant

Für die Verwendung des Passwort Server Connectors ist eine separate Lizenz erforderlich.

Best Practise für Credentials und Passwort-Safes mit ScriptRunner

Hinterlegen Sie im ScriptRunner Richtlinienset an den Zielsystemen ausschließlich technische Administrations-Accounts, z.B. SR-AD-Admin, SR-VMware-Admin, SR-Exchange-Admin. Statten Sie diese Accounts nur mit den Rechten aus, welche diese zum Ausführen der PowerShell-Scripte auf den Zielsystemen benötigen, bspw. nur in der Rolle als Exchange Mailbox Admin, jedoch nicht in der Rolle als Organisations-Admin.

Legen Sie in einer Passwort Server-Umgebung auf dem Passwort Server einen separaten Safe für ScriptRunner an. Nehmen Sie in diesen Safe die technischen Administrations-Accounts für ScriptRunner auf. Anschließend konfigurieren Sie den Passwort Server Connector auf dem ScriptRunner Host wie oben beschrieben.

Credential in Pleasant Password Server used by ScriptRunner

Nun legen Sie im ScriptRunner Richtlinienset im Hauptmenü „Credentials“ ein neues Credential an. Wählen Sie die Option „Retrieve Password from Password Server“ und geben Sie die Referenz-ID für das Credential im Passwort Server ein. Diese Referenz-ID können Sie sich im Passwort Server anzeigen lassen. Im Beispiel Pleasant Password Server ist die Referenz-ID bspw. Bestandteil einer speziellen URI.

ScriptRunner Credential Thycotic powershell

ScriptRunner credentials configuration for Thycotic

Für einen einfachen und schrittweisen Übergang können beide Varianten der Credential-Speicherung parallel verwendet werden.

Erweiterte Ausführungsoptionen für Aktionen

Aktionen machen die Kernfunktionalität von ScriptRunner aus. In diesem Kontext werden Richtlinien zur Ausführung der einzelnen Scripte festgelegt als auch die gesamte Scriptausführung vom ScriptRunner Service gesteuert.

Insbesondere die Ausführung der Scripte kann in unterschiedlichen Kontexten erfolgen:

  • lokale Ausführung auf dem ScriptRunner Host im Systemkontext des ScriptRunner Dienstes (default LocalSystem)
  • lokale Ausführung auf dem ScriptRunner Host im Kontext eines bestimmten administrativen Accounts
  • remote Ausführung auf einem entfernten Zielsystem
  • remote Ausführung auf einem Office 365 Mandanten
  • remote Ausführung auf einen Azure Mandanten; hierfür gibt es einen neuen Zielsystem-Typ „AzureRM Services“
  • Ausführung einer Aktion auf einem Container für Zielsysteme

Geändert und Neu: Lokale Ausführungsmodi

Für die lokale Ausführung wurden die Modi erweitert und deren Verhalten verbessert. Es gibt nun neben dem Systemkontext drei Modi. Die Konfiguration erfolgt an den Zielsystem-Einstellungen.

  1. Der Thread-Impersonierungs-Modus führt PowerShell-Scripte mit einem impersonierten Thread aus, ohne dass die gesamte Prozess-Umgebung im Kontext dieses Benutzers läuft. Das ist der bevorzugte Modus, wenn das PowerShell-Script keine benutzerspezifischen lokalen Ressourcen benötigt. Der Prozess läuft im lokalen Systemkontext, der Thread personalisiert. Dieser Modus erlaubt die Verwendung von [PSCredential] Parametern und ermöglicht  das ScriptRunner Report Live-Update.
  2. Der einfache RunAs-Prozess-Modus führt PowerShell-Scripte in einem lokalen Prozess als RunAs im zugewiesenen Benutzerkontext aus. Er bietet dem Script dadurch Zugriff auf grundlegende lokal für diesen Benutzer installierte bzw. berechtigte Ressourcen, z.B. PowerShell-Module, Umgebungsvariablen, Benutzerverzeichnis. 
    Achtung: Dieser Modus bietet keine [PSCredential]-Parameter-Unterstützung und kein ScriptRunner Report Live-Update.
  3. Der lokale WSMAN-Prozess-Modus überlässt die Prozesssteuerung dem lokalen Windows WSMAN-Dienst. Dieser erstellt einen lokalen RunAs-Prozess mit einer vollständigen lokalen Benutzer-Umgebung. Dieser Modus bietet auch volle [PSCredential]-Parameter-Unterstützung und ScriptRunner Report Live-Update. 
    Achtung: Die Verbindung zum lokalen WSMAN-Dienst (über PowerShell Loopback Remoting) zählt bereits als der ‚erste Hop‘, was weitere implizite Remote-Zugriffe im Script erschweren kann (‚2nd hop problem‘).
powershell scriptrunner

local PowerShell execution modes in ScriptRunner

WICHTIG für das Update auf ScriptRunner 2018R3: manuell angelegte lokale Zielsysteme mit dem FQDN ‚.‘ werden automatisch in den Modus einfacher RunAs-Prozess konvertiert. Falls im Script weitere [PSCredential]-Parameter verwendet werden, muss das Zielsystem auf den Modus Thread-Impersonierung umgestellt werden.

Neu: Verarbeitungsoptionen für Container-Zielsysteme

Container sind eine Sammlung von Zielsystemen. Container können anstelle von Einzelsystemen in einer Aktion zugewiesen werden. Bisher war bei der Verwendung von Container-Zielsystemen nur die parallele Ausführung des PowerShell-Scriptes auf allen Zielsystemen innerhalb Containers möglich.

Jetzt gibt es dafür mehr Möglichkeiten:

  • parallele Ausführung auf allen Zielsystemen im Container
  • sequenzielle Ausführung auf allen Zielsystemen des Containers, eines nach dem anderen
  • zufallsgesteuerte Auswahl eines Zielsystems aus dem Container mit round robin
  • Auswahl eines Zielsystems solange es erreichbar ist, sonst Wechsel auf ein anderes
powershell container

Execution modes for ScriptRunner container targets

Neu: Synchronisation der Scriptverarbeitung

Die parallele Verarbeitung von Aktionen auf ScriptRunner kann zu ungewollten Überschneidungen in der Ausführung führen. Eine Überschneidung kann potenziell an zwei Stellen in ScriptRunner auftreten:

  • bei Verwendung der gleichen Aktion
  • bei Verwendung des gleichen Scriptes durch verschiedene Aktionen

Die Folge können Blockierungen, unerwünschte Effekte oder Lastsituationen am Zielsystem sein, wenn z.B. aufwendige Reportgenerierungen doppelt laufen. Eine Ursache dafür kann sein, dass die Laufzeit einer zeitgesteuerten Aktion länger ist als deren Zykluszeit. Dann würde die Aktion vom Scheduler erneut gestartet werden, ohne dass die vorangegangene Aktion bereits beendet wurde.

powershell ScriptRunner

Synchronizing the action execution in ScriptRunner

In diesem Zusammenhang wurde auch die Steuerung zur zeitgesteuerten Ausführung von Aktionen überarbeitet. Die Verarbeitungs-Queue prüft nun automatisch, ob eine zeitgesteuerte Verarbeitung bereits läuft oder ansteht und ignoriert eine erneute Verarbeitungsanforderung. Ziel ist es dabei, dass sich Ausführungszeitpunkte einer Aktion nicht übersteuern bzw. eine spätere Ausführung eine laufende oder anstehende nicht überholen kann. In einem solchen Fall wird der erneute Ausführungszeitpunkt ignoriert.

Neu: Zielsystem Azure Resource Manager

Es wurde ein weiterer Zielsystem-Typ eingeführt. Mit dem „Azure Resource Manager“ können Sie die Vielfalt der PowerShell Module für Azure Ressourcen nutzen. Das Verbindungshandling zu Azure übernimmt ScriptRunner, so wie schon bei den Office 365 Zielsystemen.

Um AzureRM nutzen zu können, müssen die Azure-RM PowerShell Module auf dem ScriptRunner Host installiert sein.

Bitte beachten Sie, dass AzureRM aus einem ganzen Set von PowerShell-Modulen besteht. Das Basismodul für die Verbindung zu Azure ist Azure.Profile. Dieses muss für die Verwendung des Zielsystemtyps auf dem ScriptRunner Host installiert sein.

 

powershell cloudshell Azure

New target type AzureRM in ScriptRunner

Verbesserte Query-Funktionen

Die mit der Version 2018R1 eingeführten Queries haben sich schnell zu einem der beliebtesten Features bei den Admins und den Service Desk Usern entwickelt. In der Version 2018R2 wurde dieser Weg fortgesetzt und auch in der neuen Version 2018R3 gibt es Neues und einige Verbesserungen.

Die Limitierung der sofort im Dropdown angezeigten Ergebnismenge wurde von 100 auf 500 Einträge erhöht. So können nun mehr Queries im AutoRun-Mode eingesetzt werden. Wird die Ergebnismenge dennoch einmal überschritten, so wird automatisch ein Suchfeld eingeblendet und die Suche kann genauer spezifiziert werden.

Die Queries auf Attribute im Active Directory wurden erweitert. So können nun AD Queries auch non-string Attribute, bspw. integer oder true/false Attribute als erweiterte Attribute verarbeiten. Ebenso ist es nun möglich, Attribute einzubeziehen, die nicht existieren bzw. im Attribute Editor als <not set> angezeigt werden. Das ist bspw. dann der Fall, wenn man eine Liste von Benutzern auslesen möchte, bei denen der Wert [ad-attribute] noch nicht gesetzt ist.

Zudem wurde die Verwendung von LDAP durch entsprechende Trimfunktionen für Leerzeichen und Zeilenumbrüche verbessert.

In den Listen von statischen List-Queries können die Einträge nun einfach umsortiert werden. So können nachträgliche Einträge im Dropdown-Menü passend positioniert werden.

Neue Script-Funktionen

Im zentralen Script Repository auf ScriptRunner werden derzeit vier unterschiedliche PowerShell-Elemente angezeigt:

  • PowerShell-Scripte, welche als Hauptscript in einer Aktion verwendet werden
  • PowerShell-Scripte, welche als Script in einer Query verwendet werden (Tag: _QUERY_)
  • PowerShell-Scripte, welche als Script Library eingebunden sind und deren einzelne Funktionen im Hauptscript verwendet werden können (Tag: _LIB_)
  • PowerShell-Cmdlets von direkt eingebundenen Modulen, welche direkt anstelle des Hauptscripts in einer Aktion verwendet werden können

PowerShell functions in einer Library

Für viele DevOps stellt sich bei der intensiveren Verwendung von PowerShell oftmals die Frage nach der Wiederverwendbarkeit von Funktionalität und Code. Im einfachsten und auch ungünstigsten Fall werden die entsprechenden Codeblöcke jeweils in andere Scripte kopiert. Das erschwert jedoch Änderungen, Wartung und Übersicht.

Eine viel einfachere und dauerhafte Lösung ist die Verwendung von Script Libraries in ScriptRunner. Dabei handelt es sich um PowerShell-Scripte, welche ausschließlich PowerShell-Funktionen enthalten. Bisher war diese Lösung auf eine PowerShell function pro Library Script begrenzt. Diese Begrenzung wurde aufgehoben. In einer Library können nun eine Vielzahl von wiederverwendbaren Funktionen zusammengefasst werden.

Library script with powershell functions in ScriptRunner

Die einzelnen PowerShell-Funktionen des Library Scriptes können ebenfalls in Queries (bei zusätzlichem Tag: _QUERY_) oder anstelle eines Hauptscripts in einer Aktion direkt angewendet werden.

Best Practise für Script Libraries in ScriptRunner

In einem ersten Schritt ist festzulegen, welche Funktionen wiederholt verwendet werden (sollen). Diese Funktionen sollten thematisch geclustert werden. Die Funktionen eines jeden Themencluster werden anschließend jeweils in ein Library Script implementiert.

Für die Bezeichnung der Funktionen sollte ein Namensschema festgelegt werden. Bspw. alle Funktionen für den Themenbereich Dateien/Shares mit „File-functionname„. Bei der Implementierung ist darauf zu achten, dass der Parameterblock innerhalb der Funktion definiert wird. Dadurch wird die lokale Gültigkeit des Parameters nur innerhalb der Funktion sichergestellt.  Mögliche Dopplungen von Parameternamen mit einem Hauptscript haben so keine Auswirkungen.

Beispiele für Libraries mit PowerShell functions können in unseren Action Packs auf GitHub eingesehen werden.

Verwendung von Funktionen aus Script Libraries

Die Verwendung der Funktionen aus den Libraries kann auf unterschiedliche Art und Weise erfolgen:

  • als Funktionsaufruf in einem Hauptscript
  • an Stelle eines Hauptscriptes in einer Aktion
  • als Scripted Query

Damit Funktionen in einem Hauptscript zur Laufzeit aufgerufen werden können, muss der Funktionscode in den PowerShell-Prozess des Hauptscriptes geladen sein. In ScriptRunner erfolgt dies durch eine Einstellung in den PowerShell-Optionen.

ScriptRunner Action with configured script library

Zusätzlicher und nicht zu unterschätzender Vorteil: die Aktion, einschließlich aller Funktionen, kann vollständig auch Remote ausgeführt werden, da ScriptRunner jeweils sicherstellt, dass alle Elemente zur Laufzeit auf dem entfernten Zielsystem zur Verfügung stehen. Im Gegensatz dazu müssen eigengeschriebene Module immer auf dem Zielsystem installiert sein.

Soll eine Funktion direkt anstelle eines Hauptscriptes in einer Aktion verwendet werden, so erfolgt die Konfiguration analog.

Zur Verwendung der Funktion als Scripted Query muss zuerst die entsprechende Funktion im Hauptmenü „Scripts|Cmdlets“ ausgewählt und mit dem Tag _QUERY_ versehen werden. Anschließend lässt sich eine entsprechende Query konfigurieren.

powershell

ScriptRunner Query with a library script function

Die Eingangsparameter für die Scripted Query können entweder als default-Wert direkt an der Query festgelegt oder über das Hauptscript eingesteuert werden.

Weitere Funktionen

Neben den oben beschriebenen Hauptfeatures wurden implementiert:

Live Output im Report

Wird eine Aktion gestartet, so wird nun sofort ein Report angelegt. Dieser Report kann sofort in der Admin App angesehen werden. Dazu die ausgewählte Aktion im Hauptmenü „Aktionen“ starten und anschließend den Button „Report“ in der Action Bar anklicken. Der Report öffnet sich. Der Status der Aktion ist „running“ und wird durch ein entsprechendes Symbol dargestellt. Am unteren Ende des Reports kann die laufende PowerShell-Ausgabe verfolgt werden.

Voraussetzung für eine Nutzung ist die Ausgabe von Meldungen für die Einzelschritte bei der Verarbeitung des Scriptes, unabhängig von der Result-Message. Fehlermeldungen werden ebenfalls ausgegeben.

Schneller Zugriff auf Reports über „Eye of Osiris“

Der Zugriff auf den aktuellen Reports einer Scriptausführung konnte bisher nur über die Action Bar oder das Dashboard erfolgen. Parallel dazu wurden beim Klicken auf „Eye of Osiris“ rechts unten entsprechende Statusmeldungen angezeigt.

Die Funktionalität wurde nun erweitert. Nach dem Anklicken von „Eye of Osiris“ werden nur klickbare Statusmeldungen angezeigt. Wird eine Statusmeldung angeklickt, so öffnet sich der zugehörige Report.

Side-by-side HTTP und HTTPS

ScriptRunner Host kann einen zweiten IP-Port nutzen. Hierdurch ist es möglich, dass der App Zugang über HTTP und HTTPS gleichzeitig erfolgen kann. Außerdem sind Szenarien für die Verwendung von Domänenauthentifizierung und ADFS parallel nutzbar.

Frank Kresse

Frank Kresse

Head of Products bei ScriptRunner
Frank Kresse ist verantwortlich für die technische Entwicklung von ScriptRunner. Als Erfinder der Automations- und Delegationslösung für PowerShell berät er Kunden bei Use Case Szenarien und entwickelt Lösungen für die Automation und Digitalisierung ihrer Prozesse. Darüber hinaus engagiert er sich bei Tech-Startups.
Frank Kresse