ScriptRunner-Version 2019R1 – was ist neu?

Autor: | Lesezeit: 7 Minuten | Kategorie: ScriptRunner

ScriptRunner 2019R1, Network, Multi-Teams

Kurzüberblick

Mit der Version 2019R1 erhalten unsere Kunden ein großes Update mit einer Vielzahl von Erweiterungen, Änderungen und Verbesserungen.

Die wichtigsten Neuerungen in dieser Version sind:

  • Multi-Team-Support in der Admin App und in der ISE für größere IT-Organisationen
  • Multimandanten-Support für MSPs
  • ScriptRunner goes to Self-Service für Endanwender
  • Überarbeitung der Admin App
  • Neuer Connector für Multiuser- und Multimachine Support
  • Unter der Haube: Umstellung auf 64-Bit und Support für Microsoft Cluster Service im active-passive-mode

WICHTIG: Diese Version bringt größere Veränderungen auf dem ScriptRunner Server mit sich. Bitte beachten Sie die unsere Update-Hinweise und unser Update-Webinar.

Unter der Haube – Große Veränderungen beim Update

Unter der Haube von ScriptRunner hat sich einiges getan. Insbesondere durch die umfassende Umstellung auf 64-Bit und die Unterstützung für Microsoft Cluster Service wurden entsprechende Veränderungen auf dem Server notwendig:

  • Installation der Binaries und der Web Apps unter .\Program Files\ScriptRunner\…
  • Die Self-Service App für Endanwender zieht ein weiteres Verzeichnis in den Web Apps Pfad und ein zusätzliches virtuelles Verzeichnis im IIS nach sich
  • Neuorganisation der Konfigurationsdaten unter .\Program Data\ScriptRunner\… zur besseren Unterstützung von Microsoft Cluster Service
  • Neuorganisation von Registry-Informationen unter HKLM\Software\ScriptRunner\
  • Re-Naming von „AppSphere ScriptRunner Service“ auf „ScriptRunner Service“
  • Update für das Datenbankschemas im SQL Server

Diese Veränderungen bedeuten für das Update von Version 2018 auf die neue Version 2019R1 besonderes Augenmerk in der Vorbereitung. So sind ein Snapshot der VM vor dem Update und eine Sicherung der bisherigen Daten unter .\Program Data\AppSphere\… Pflicht, da dieses Update kein Zurück mehr zulässt.

Auf die generelle Durchführung und die Reihenfolge der Einzelupdates Service, Web App, Team Apps haben diese Änderungen keinen Einfluss.

Kunden, welche den SQL-Report/Audit Connector einsetzen, müssen zusätzlich im SQL Server das Datenbankschema aktualisieren.

Unterstützung für Windows Server 2019

Die neue Version von ScriptRunner unterstützt nun auch die Implementierung auf Windows Server 2019. Es werden dabei folgende Konfigurationen unterstützt:

  • Windows Server 2019 mit Desktop Experience
  • Windows Server 2019 Core mit installiertem AppCompatibility Feature Set. Das Feature Set kann als Feature on Demand Paket von der Microsoft Site heruntergeladen und installiert werden.

Erweitertes Rollenmodell für Multi-Team und Multimandanten

Die deutlichste Veränderung bringt das erweiterte Rollenmodell unter dem Hauptmenüpunkt Delegation. Das Rollenmodell wurde so konzipiert, dass es automatisch alle Rechte in ScriptRunner so abbildet, wie diese für die jeweilige Benutzergruppe benötigt werden.

Es können nun deutlich mehr Anwendungsszenarien innerhalb und zwischen IT-Teams bis hin zum Endanwender umgesetzt werden.

Self Service für Endanwender

Dieses Szenario dehnt die Delegationsmöglichkeiten von ScriptRunner bis zum Endanwender aus. Administratoren können nun Use Cases definieren und in Aktionen umsetzen, welche direkt auf den Endanwender übertragen werden. Dadurch lassen sich sehr einfach einzelne Self Services für Endanwender einführen. Endanwender verwenden zum Ausführen von Aktionen die neue Self-Service App.

Multi-Team Anwendung in größeren IT-Organisationen

Die Verwendung von ScriptRunner in mehreren IT-Teams bei gleichzeitiger Trennung der Inhalte war bisher ausschließlich durch die Aufteilung auf mehrere Server möglich. Diese Form der Aufteilung ist auch weiterhin sinnvoll, wenn durch regulatorische Vorgaben zwingend getrennte Instanzen notwendig sind.

Mit der Version 2019 R1 besteht nun auch die Möglichkeit, eine logische Trennung vorzunehmen. Das ist dann der Fall, wenn mehrere Admin-Teams einzelne Richtlinien-Elemente und Aktionen in ScriptRunner sowohl getrennt als auch gemeinsam nutzen wollen.

Multi-Mandanten Anwendung für Managed Service Provider (MSPs)

Mit dem erweiterten Rollenmodell lassen sich auch MSP-Modelle deutlich einfacher umsetzen. So können nun alle Richtlinien-Elemente und Aktionen in ScriptRunner auf unterschiedliche Mandanten zugeordnet werden und dabei das Script-Repository dennoch gemeinsam genutzt und um kundenindividuelle Scripte ergänzt werden.

ScriptRunner admin groups, service desk groups and end user groups

Neue Sicht auf die Richtlinien-Elemente in ScriptRunner

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.

Beispiele:

Ein Script soll für alle verwendbar sein und ist deshalb vom Typ PUBLIC USE. Deshalb können auch Aktionen vom Typ PRIVATE USE dieses Script nutzen. So lassen sich unterschiedlich konfigurierte Aktionen mit dem gleichen Script in verschiedenen Mandanten aufsetzen.

Das Admin-Team für Exchange hinterlegt eigene administrative Konten für Exchange Server als Zielsysteme. Diese Konten sind nur für dieses Team sicht- und verwendbar.

Es soll eine Aktion für alle Teams bzw. Mandanten nutzbar sein. ALLE verwendeten Elemente in der Aktion müssen dann vom Typ PUBLIC USE sein.

Implementierte Rollen und Berechtigungen

Das erweiterte Rollen- und Berechtigungsmodell in ScriptRunner inkludiert nun folgende Rollen:

  • ScriptRunner Server Administratoren. Diese können sich interaktiv am ScriptRunner Server anmelden und entsprechende Konfigurationen am Betriebssystem und den Einstellungen des Servers selbst vornehmen. ScriptRunner Server Administratoren müssen keine weiteren Rollen innerhalb der Applikation innehaben.
  • ScriptRunner Haupt-Administratoren. Diese Administratoren haben Zugriff auf alle PUBLIC und PRIVATE USE Elemente und Aktionen in ScriptRunner. Anwender in dieser Rolle dürfen insbesondere als einzige neue Berechtigungs-Gruppen für Admin-Teams bzw. Mandanten, Service Desk und Endanwender anlegen und zuweisen. Es können nun auch mehrere Gruppen in dieser Rolle angelegt werden.
  • ScriptRunner Administratoren (Team bzw. Mandant). Anwender in dieser Rolle haben lesenden Zugriff auf alle PUBLIC USE Elemente und Aktionen sowie uneingeschränkten Zugriff auf die Elemente und Aktionen, welche dieser Gruppe als PRIVATE USE zugewiesen worden sind. Es können Scripte zur gemeinsamen Verwendung abgespeichert werden. Sie können Aktionen an Service Desk und Self-Service Endanwender sowie andere Admin-Teams bzw. Mandanten delegieren.
  • ScriptRunner Service Desk Anwender. Anwender in dieser Rolle können delegierte Aktionen parallel ausführen, Reports einsehen und eine Vielzahl von Aktionen als Kacheln oder Liste strukturiert darstellen, Favoriten einrichten, Aktionen suchen usw. Typische Anwender sind 1st, 2nd und 3rd Level Support sowie Anwender in Fachbereichen mit mehr als 10 an diese delegierten Aktionen.
  • ScriptRunner Self-Service Endanwender. Diese Rolle ermöglicht es, bis zu 10 Self-Service Aktionen direkt an die Endanwender zu delegieren. Diese können die Aktionen einzeln ausführen und erhalten eine interaktive Rückmeldung. Ein erneutes Starten einer Aktion ist erst nach Beenden der vorherigen Aktion möglich.

New role selection in ScriptRunner

Die Rollen werden mittels Zuordnung von AD-Gruppen und/oder AD User Accounts konfiguriert. Es können für alle Rollen (außer ScriptRunner Server Administratoren) beliebig viele Gruppen angelegt werden. Ist ein Anwender in mehreren Gruppen gleichzeitig, so erhält er immer auf die Summe der Elemente Zugriff.

WICHTIG: Es wird dringend empfohlen, beim Einsatz des erweiterten Rollenmodells in Verbindung mit Codeverwaltungs-Werkzeugen wie GIT oder TFS die Instanzen für die Produktionsumgebung und für eine Testumgebung zu trennen.

ScriptRunner für Endanwender – die neue Self Service App

Delegierte ScriptRunner-Aktionen eignen sich hervorragend für die Implementierung von User Self-Service Cases. Die Endanwender profitieren von der grafischen Browser-Oberfläche, die Admins davon, dass sie den Use Case mittels PowerShell Script perfekt für eigenen Gegebenheiten programmieren und anpassen können. Im Ergebnis erhält der Anwender genau das, was er bekommen sollte und seine Anforderungen erfüllt.

Die Self-Service Web App wird mit dem Web Apps Setup auf dem Webserver installiert und steht allen Anwendern in der Rolle „Self-Service Endanwender“ zur Verfügung. Für Administratoren erfolgt die Delegation analog zur bisherigen Verfahrensweise in der Admin App.

Die Standard-URL zum Aufrufen der Web App lautet: http(s)://fqdn_scriptrunner_server/scriptrunner/selfservice und kann über Aliasnamen im DNS für die Anwender verkürzt werden. Nach dem Aufruf wird die App in den Browser geladen und gestartet. Die Kommunikation mit dem ScriptRunner Webservice erfolgt über den Standard-Port 8091 (default).

ScriptRunner Self-Service App for end users

Wie bereits aus der Delegate App bekannt, kann die Self-Service App per Konfiguration auf dem Web Server auch mit mehreren ScriptRunner Server Instanzen verbunden werden.

Die Self-Service App hat gegenüber der Delegate Web App auf Endanwender reduzierte Funktionen.

Das sind die Funktionen der Self-Service App:

  • Kacheldarstellung für bis zu zehn an den Endanwender delegierte Aktionen
  • Browser App mit automatisch generierten Eingabeformularen
  • Umschalten auf Eingaberegister bei mehr als sieben Eingabefeldern
  • Feld zum Hinterlegen des Grundes für die Ausführung; kann pro Aktion auf verpflichtend voreingestellt werden
  • Verwendung von Queries zur dynamischen Auswahl für Parameter-Felder
  • Popup-Fenster zur Anzeige von Bearbeitungsfortschritt und Ergebnis der Aktion
  • Mehrsprachigkeit der App
  • Anzeige des internen Supportkontaktes
  • Verbindung zu mehreren ScriptRunner Server Instanzen möglich
  • Branding im Corporate Design wie Delegate App

Empfohlene Browser für Self-Service App: Chrome, Firefox, Opera, Edge, IE11

Verbesserungen für Service Desk

In der Delegate App wurden die Erneuerungsarbeiten aus der Version 2018 R3 fortgesetzt. Auffälligstes Merkmal sind die neuen Symbole. Vollständig erneuert wurde die Darstellung von [switch] $Parameter. Die Beschreibung des Parameters wird nun gleichzeitig als Schalter verwendet.

Um die Performance in der Darstellung für die alte Rendering-Engine im IE 11 zu erleichtern, werden bei mehr als 12 Aktionen diese im IE 11 nun standardmäßig als Liste angezeigt. Ein manueller Wechsel auf die Kacheldarstellung ist weiterhin möglich.

Für den Betrieb von ScriptRunner im Service Desk zusammen mit einem Ticketsystem besonders interessant ist die neue Option, das Beschreibungs- bzw. Ursachenfeld pro Aktion für eine verpflichtende Eingabe zu konfigurieren.

Mehr Möglichkeiten im Dashboard – Neues in der Admin App

Mit der Version 2019 R1 wurde ebenfalls die Erneuerung und teilweise Neustrukturierung der Admin App begonnen. Dazu wurden kaum genutzte Features, wie z.B. das Submenü, entfernt und durch eine funktionalere Bedienung ersetzt.

Zusätzliche Anzeigeoptionen und Reporting-Filter im Dashboard

Sofort sichtbar in der Admin App sind die neuen und erweiterten Symbole auch bei den Anzeigeoptionen im Dashboard.

Die zusätzlichen Anzeigeoptionen im Diagramm Panel:

  • Alle Reports ausblenden, welche aus Scripted Queries resultieren
  • Alle Reports ausblenden, welche aus Scheduled Actions resultieren

Die kombinierbaren Reporting Filter im Dashboard wurden funktional erheblich aufgewertet. So haben alle Inhaltsfilter nun die Möglichkeit zur Mehrfachauswahl. Dadurch kann nun nach Reports mehrerer Aktionen, Zielsysteme oder Delegationen selektiert werden. Alle diese Filter haben zusätzlich die Möglichkeit, invertiert angewendet zu werden, also alle Reports heraus zu filtern, die NICHT der Auswahl entsprechen.

Globaler Anzeigefilter

Die mit der Version 2018R3 eingeführten globalen Anzeigefilter wurden erweitert und ergänzt. So wirkt der globale Tag-Filter nun auch auf alle Elemente direkt im Dashboard.

Der neue Element Filter wirkt additiv zum Tag-Filter und ermöglicht, die einzelnen Elemente public oder der jeweiligen Gruppe zu selektieren. Diese Funktion ist besonders nützlich für Hauptadministratoren, aber auch für Administratoren, welche gleichzeitig in mehreren Teams bzw. Mandanten arbeiten.

Global filter setting in ScriptRunner Admin App

Alle globalen Filter bleiben beim Wechsel zwischen den Hauptmenüs und dem Dashboard erhalten bis eine andere Auswahl erfolgt ist.

Lokale Anzeigefilter

Wurde ein Hauptmenü ausgewählt, so erscheinen alle Elemente dieses Menüs in einer Liste. Alle Elemente können durch Klicken auf den jeweiligen Spaltenbezeichner auf- und absteigend sortiert werden. Im Kopf des Listenfeldes unterhalb der globalen Filter befindet sich die Volltextsuche auf die gefilterten Elemente.

List filter in ScriptRunner Admin App

Zusätzlich zu den globalen Filtermöglichkeiten können einige spezifische Anzeigefilter für die angezeigte Liste (bisher im Submenü) nun direkt in der Listenansicht genutzt werden.

Lokale Hilfe in der Admin App

Die lokale Hilfe für Administratoren wurde um die neuen Funktionen ergänzt. Gleichzeitig wurde die direkte Hilfe auf den jeweiligen Wizard-Seiten besser kenntlich gemacht.

Die Elemente in der Top-Bar der Admin App wurden deutlich reduziert. Es gibt nun nur noch fünf Elemente:

  1. Anzeige des Logins
  2. Sprachumschalter
  3. „About“ mit Anzeige der Versionsinformationen
  4. Direkter Zugang zu unserer Support Website
  5. Direkter Zugang zu unseren Action Packs auf GitHub

Neuer Web Service Connector

Zur Unterstützung der neuen Rollen über das ScriptRunner Web Service Interface über REST wurde das Konzept erweitert und der Connector für Web Services ergänzt. Es gibt nun zwei Arbeitsmodi für unterschiedliche Einsatzgebiete.

System oder Application Backend

Dieser Arbeitsmodus koppelt je Connector ein Quellsystem mit ScriptRunner. Quellsysteme können zentrale Monitoringsysteme oder Application Server, wie bspw. Workflowsysteme, sein. Zur Authentifizierung des Aufrufes am ScriptRunner Server und zur Zuordnung der Aktionen können einzelne Service Accounts oder Gruppen konfiguriert werden.

Beispiel Monitoring

Es soll ein zentrales PRTG Monitoring mit ScriptRunner für die Automatisierung gekoppelt werden. Dazu wird im Connector die Quelladresse des aufrufenden Monitoringsystems eingetragen und unter Delegation ein Account eingerichtet, welcher zur Authentifizierung des PRTG-Aufrufes verwendet wird. Alle Aktionen, welche vom Monitoring aufgerufen werden können, sind an diesen Account zu delegieren.

Beispiel Workflow

Es soll ein zentrales Workflow-Backend mit ScriptRunner für die Automatisierung gekoppelt werden. Alle Anwender des Workflows sollen die darin definierten Aktionen in ScriptRunner starten dürfen. Dazu wird im Connector die Quelladresse des aufrufenden Workflow-Backends eingetragen und unter Delegation die Gruppe der Administratoren bzw. des Mandanten, des Service Desk oder der Endanwender eingerichtet, welche sich authentifizieren müssen. Alle Aktionen, welche vom Workflow aufgerufen werden können, sind an diese Gruppe zu delegieren.

Clientanwendung oder Computer direkt

In diesem Arbeitsmodus können Anwendungen und Computer den Web Service in ScriptRunner direkt OHNE System oder Application Backend verwenden. Im Connector wird dann jede Quelladressen akzeptiert. Zur Authentifizierung des Aufrufes am ScriptRunner Server und zur Zuordnung der Aktionen können ausschließlich Gruppen in der Rolle Self-Service Endanwender verwendet werden. Die referenzierten AD-Gruppen können Benutzerkonten oder Maschinenkonten enthalten.

Beispiel Clientanwendung

Eine Fachanwendung in JavaScript wird so erweitert, dass diese per Klick eine Aktion in ScriptRunner aufrufen kann und die Eingaben aus der Seite heraus direkt übermittelt. Der Aufruf erfolgt im Benutzerkontext. Im Connector wird die Quelladresse des Clients über den Quelladressbereich abgedeckt. Zur Authentifizierung wird der Benutzer-Account verwendet, welcher in einer Gruppe in der Rolle Self-Service Endanwender enthalten sein muss. Die Aktion, welche von der Clientanwendung aufgerufen werden soll, ist an diese Gruppe zu delegieren.

Options for two scenarios with Web Service Connector

Beispiel Computer direkt

Über einen Trigger soll eine Clientmaschine eine Aktion in ScriptRunner direkt aufrufen. Der Aufruf soll im Kontext des Computers erfolgen. Im Connector wird die Quelladresse des Clientcomputers über den Quelladressbereich abgedeckt. Zur Authentifizierung wird der Maschinen-Account aus dem AD verwendet, welcher in einer Gruppe in der Rolle Self-Service Endanwender enthalten sein muss. Die Aktion, welche vom Clientcomputer aufgerufen werden soll, ist an diese Gruppe zu delegieren.

Weitere Verbesserungen und Erweiterungen

Neben den oben genannten großen Features wurden in vielen Teilbereichen Verbesserungen und Erweiterungen vorgenommen.

Erweiterte PowerShell-Richtlinien

Für lokale Zielsysteme kann für den „RunAs“ Mode nun auch der spezifische Login Mode konfiguriert werden, um spezielle Nutzungsvarianten und Erfordernisse besser zu unterstützen. Im Mode „Logon as batch“ erhält das zugeordnete administrative Konto nun auch alle elevated rights und entspricht damit dem Verhalten „Als Administrator ausführen …“. Das administrative Konto benötigt dafür auf dem ScriptRunner Server das „logon as batch“-Privileg.

Das Cloud Service Target für AzureRM wurde erweitert und ist nun als Azure Cloud Service in der Auswahl der Zielsysteme zu finden. Dieses Element unterstützt nun neben AzureRM nun auch die Verbindungsaufnahme mit Azure Az.

Select the options to connect to the Azure Cloud services

Das zeitgesteuerte Ausführen von Aktionen ist ein häufiger Anwendungsfall in ScriptRunner. Deshalb wurden in die Zeitsteuerung zwei Anforderungen integriert:

  • die mehrfache tägliche Ausführung einer Aktion z.B. 09:00, 13:00 und 21:00 Uhr
  • die Ausführung an einem bestimmten Tag im Monat, z.B. immer am 15. eines Monats

Im Wizard für die Eigenschaften der Scripte können diese und Funktionen in Scripten nun explizit als Library und/oder zur Verwendung in einer Query gekennzeichnet werden. Die Funktion setzt die entsprechenden System-Tags _LIB_ und _QUERY_.

Noch mehr PowerShell

Mit den Erweiterungen kommen auch einige neue PowerShell Cmdlets im Modul ScriptRunnerSettings.

  • Test-AsrUri dient zum Überprüfen der Erreichbarkeit des ScriptRunner Web Service Endpoints
  • Get-AsrWinEvent liest die ScriptRunner Einträge aus dem Windows Event Log aus

Das ScriptRunnerSettings PowerShell Module wird nun auch mit Get-Help supported.

c:\> get-help -Name cmdletname -full zeigt Ihnen die ausführliche Hilfe für diesen ScriptRunnerSettings-Befehl an.

Neue PowerShell ISE App

Die bereits bekannte PowerShell ISE App für ScriptRunner wurde im Wesentlichen auf das neue Rollenmodell erweitert. Anwender der ISE App müssen in der Rolle ScriptRunner Hauptadministrator oder in der Rolle ScriptRunner Administrator (Team bzw. Mandant) sein.

Anwender in der Rolle als ScriptRunner Hauptadministrator haben vollen Zugriff auf alle Scripte im Repository. Sie können diese aus- und einchecken sowie neue Scripte anlegen und hochladen.

New ScriptRunner role based ISE App

Anwender in der Rolle als ScriptRunner Administrator haben Lesezugriff auf alle Scripte und können Scripte aus- und einchecken sowie neue Scripte erstellen und hochladen, welche den Gruppen, in denen er Mitglied ist oder welche PUBLIC USE zugeordnet sind.

Unabhängig von der Rolle muss ein Script zum Ändern zur Verwendung in der ISE App freigegeben werden. Diese Freischaltung erfolgt in der Admin App im Hauptmenü „Scripte“ und berücksichtig die Rollenzuordnung des Anwenders.

ScriptRunner Hauptadministratoren können alle Scripte zum Ändern freischalten. ScriptRunner Administratoren können nur die Scripte zum Ändern freischalten, welche der jeweiligen Gruppe zugeordnet sind.

Erweiterung im Passwort Server Connector

Die Optionen im Passwort Connector für Thycotic Secret Server wurden erweitert, um Umgebungen mit non-default-URIs zu unterstützen.

Kunden werden per E-Mail über den Release der neuen Version informiert und können sich diese wie gewohnt hier herunterladen.

In unserem Update-Webinar zur neuen ScriptRunner Version 2019R1 zeigen wir Ihnen die neuen Funktionen live. Sie können sich hier anmelden.

Diese Beiträge könnten Sie auch interessieren:

ScriptRunner Version 2018R3