Die Portal Edition R4 ist ein Meilenstein in der Portalentwicklung und zeichnet die zukünftigen Entwicklungen vor. Dieses Release ist ein wichtiger Schritt zur vollständigen Ablösung der bisherigen Web Apps durch ein rollenbasiertes Portal.

Mit dem Release der Portal Edition R4 wird ein neues Design und eine neue Benutzerführung eingeführt, die Strukturierung in Portal Apps entfällt.

Die Neuerungen im Detail:

• Neue Informationsarchitektur, UX und UI Design
• Neues Portal mit Dashboard
• Überarbeitetes Ausführen
• Neu im Portal: Credential-Konfiguration inklusive SSH
• Neu im Portal: Target-Konfiguration
• Automatische Modulerkennung mit erweiterter Target-Test Funktionalität
• Microsoft Graph als neuer Service für M365-Targets
• Token-based Authentication für M365-Services (Teams und Graph)
• Upload von Dateien durch Anwender für Massenverarbeitung
• Erzwingen von signierten Skripten

Neue Informationsarchitektur, UI und UX

Dem Portal liegt jetzt eine neue Informationsarchitektur zu Grunde. Das Ziel war, eine einfache und schnell verständliche Anwendung mit einer modernen, intuitiven Benutzererfahrung zu verbinden. Vieles wurde neu gedacht und gestaltet sowie bewährte Strukturelemente aus den bisherigen Web Apps integriert. Die Übersichtlichkeit wurde deutlich verbessert, Bedienelemente so gestaltet, dass ihre Funktion und Wirkung erkennbar sind, alte Limitierungen wurden beseitigt. Am deutlichsten ist das zu bemerken im neuen Hauptmenu, den Übersichten und den einzelnen Konfigurationselementen.

Portaldashboard mit den unterschiedlichen Widgets

Das neue Design ist wegweisend für die Weiterentwicklungen im Portal in den nächsten Jahren. Durch diese Architektur entfallen die bisherigen Portal Apps. Die Funktionen gehen nun in den neuen Konfigurations- und Anwendungsmodulen des Portals auf.

Ein wichtiger Punkt beim Neudesign war auch die Barrierefreiheit. Durch die Überarbeitung der Farbpalette wurde die Erkennbarkeit z.B. für Anwender mit Farbsehschwäche erhöht.

Neues Portal

Die Apps-Übersicht auf der Einstiegsseite des Portals wurde im ersten Schritt durch ein übersichtliches Dashboard ersetzt (siehe Abbildung oben). In späteren Versionen wird es möglich sein, diese Widgets individuell zu konfigurieren. Wesentliche Elemente im Dashboard sind die Anzeigen für die letzten Reports, die Top Aktionen sowie angepinnte Aktionen, das heißt die Aktionen, die ein Anwender im sofortigen Zugriff haben möchte.

Das Portal kann wie bisher mittels http(s)://<servername>/scriptrunner/portal aufgerufen werden.

Die bisherige Top-Bar wurde beibehalten. Enthalten sind Kurzinformationen, Sprachauswahl, Anmelde-Account, Support-Widget und Online-Hilfe.

NEU! Im Portal sind nun für alle Anwender die Sprachen SPANISCH und FRANZÖSISCH verfügbar.

Neue Sprachoptionen – nouveau choix de langue: français – nueva selección de idiomas: español

Das thematisch orientierte Hauptmenu mit Run/Automation, Delegation, Überwachung, Konfiguration und Einstellungen sorgt für Übersichtlichkeit und einfachen Zugang. Es kann fixiert oder gleitend verwendet werden.

Wird ein Hauptmenüpunkt ausgewählt, wechselt die Darstellung in eine Übersichtsseite für die entsprechenden Elemente, hier im Beispiel unten auf die Liste aller Skripte. Im Fenster oben sind folgende Navigationselemente platziert:

• Klickbare Breadcrumb für eine schnelle Navigation zwischen den Ebenen und Zurück-Button.
• Globaler Tag-Filter zum Filtern auf bestimmte Elemente. Dieser Filter bleibt auch beim Wechseln zwischen Hauptmenüpunkten erhalten. Klickbare Tags in der Tabelle vereinfachen die Benutzung. 
• Auswahl des Eigentümers (Owners). Diese Auswahl erscheint nur im Multi-Team Modus.

Die Navigation innerhalb der Module wurde global geändert. In jedem Modul stehen Breadcrumb und Zurück zur Verfügung.

Die Übersicht zeigt neben dem Namen des gewählten Menüpunktes immer die Anzahl der gefilterten bzw. angezeigten und der insgesamt verfügbaren Elemente.

Gesamtübersicht der Scripte, direktes Editieren möglich

Darunter finden sich kontextorientierte Funktions-Buttons, wobei der primäre hervorgehoben ist (im Screenshot +New script). Rechts auf gleicher Höhe befindet sich das Suchfeld (Search).

Ausgewählte Spalten der Tabelle sind sortierbar und bestimmte angezeigte Eigenschaften klick- und editierbar. 

Geöffnetes Skript im Code Editor

Das Klicken auf den Namen eines Elementes öffnet die Detailseite. Im Beispiel oben wurde das Skript Add-ADUsersToGroups ausgewählt. 

Im Abschnitt Configuration befinden sich die einzelnen Optionen zum Bearbeiten von Eigenschaften und Details des Elements. Der Abschnitt General ist für alle Elemente gleich, die weiteren Abschnitte hängen vom jeweiligen Typ und Kontext des Elements ab.

Im Abschnitt Information befinden sich einzelne Gruppierungen zu weiteren Informationen im Kontext des Elementes, bspw. an welcher Stelle es verwendet wird.

In Abhängigkeit des Elementes sowie des Kontextes eines Elementes werden auf der rechten Seite zusätzliche Informationen bereitgestellt.

• Onlinehilfe
• Eingabehilfe
• Eingabeinformation
• Tipp
• Warnhinweise (Caution/Warning)

Die kontextorientierte Online-Hilfe öffnet sich einfach durch Klicken des Hilfe-Buttons in der Top-Bar. Dazu wird ein Anzeigebereich für die Hilfe überlagert, die Konfigurationseinstellungen bleiben dennoch verwendbar.

Eine Eingabehilfe ist am "?" direkt am Eingabefeld zu erkennen. Beim Anklicken erscheint die Kurzhilfe.

Eine erläuternde Eingabeinformation befindet sich immer unter einem Eingabefeld und ist am "i" erkennbar.

Einblendung des Tipps und Warnhinweises

Ein Tip (grau) auf der rechten Seite neben den Details gibt für komplexe Sachverhalte und Zusammenhänge zusätzliche Informationen und nützliche Hinweise zum Kontext.

Eine Caution (gelb-orange) auf der rechten Seite neben den Details zeigt an, das etwas zu beachten ist, z.B. dass bestimmte Voraussetzungen erfüllt sein müssen oder etwas veraltet ist.

Eine Warning (rot) auf der rechten Seite neben den Details zeigt ein Problem an, bspw. dass etwas unvollständig ist oder nicht funktionieren kann.

Festlegen des Hex-Farbcodes für Tags

Tags können nun mit verschiedenen Farbwerten aus einer empfohlenen Palette oder mit eigens gewählten Farbwerten eingefärbt werden, um eine schnellere Unterscheidung zu ermöglichen. Eine Description am Tag wird in den Listenansichten bei Mouseover angezeigt.

Überarbeitetes Ausführen

Der Hauptmenüpunkt Run wurde sowohl im Design als auch in der Benutzerführung überarbeitet und angeglichen. Es existiert nun ebenso wie in allen anderen Übersichten ein Zurück-Button sowie eine klickbare Breadcrumb.

Die Darstellung des Eingabeformulars einer Aktion wurde überarbeitet, um die Übersichtlichkeit zu verbessern und die Eingaben klarer von weiteren rollenabhängigen Zusatzoptionen zu trennen. Für eine zukünftige Version wird ein einfacher Formulardesigner zusätzliche Möglichkeiten schaffen.

Standardansicht Ausführen (Run): erweiterte Kacheln

In der bekannten, erweiterten Ansicht werden neben einer mehrsprachlichen Bezeichnung und Beschreibung weitere Informationen angezeigt. Administratoren und Helpdesk können sich in Abhängigkeit der Rolle die Reports einer Aktion anzeigen lassen. Anwender in der Rolle Administrator können zusätzlich die Delegationen für die Aktion einstellen sowie die Beschreibungen einer Aktion editieren.

Die bekannten Kacheln gibt es nach wie vor, allerdings jetzt in modernem Design und mit der neuen reduzierten Kacheldarstellung neben der erweiterten und der Listenansicht. Die Kacheldarstellung reduziert ist insbesondere für Helpdesk und Endanwender entwickelt. Die Informationen auf den Kacheln sind vereinfacht und für schnelles Auswählen einer Aktion optimiert. Die Namen der Aktionen können multilingual in Abhängigkeit der gewählten Sprache bereits im Skript oder an der Aktion selbst hinterlegt und dargestellt werden.

vereinfachte, reduzierte Kachelansicht 

Komplett neu entwickelt wurden die An- und Abwahl der Anzeige-Tabs und die Ansichten. Die Listenansicht zeigt zusätzlich zu den typischen Elementen die Farbe, das Icon und den Pin-Status der jeweiligen Aktion an. Wurde eine Aktion gepinnt, erscheint diese bei Administratoren auch im Widget auf dem Dashboard.

Listenansicht des Run Bereichs mit Farbe, Icon und Pin-Status der Aktionen

Neu im Portal: Credential-Konfiguration

Die Konfiguration von Credentials in der alten Admin App war sehr komplex und unübersichtlich. Im Portal wurden die Einträge typisiert und die Benutzerführung komplett umgestaltet, damit Nutzer intuitiver damit arbeiten können. In der Übersicht werden alle angelegten Einträge mit dem zugehörigen Typ dargestellt. Als Typen werden je nach Anwendungsfall unterstützt: User credential, Client secret, Password Server reference, SSH Keys sowie Einträge für das PowerShell Secrets Management und die Verwendung von WinRM Client-Zertifikaten.

Beim Anklicken der Auswahlbox an einem Listenelement erscheinen im darüber liegenden Anzeigebereich neben dem primären Button +Create die zusätzlichen Buttons Edit und Delete.

Das Anklicken des Namens öffnet die Detailkonfiguration, das Anklicken eines Tags setzt dieses in den globalen Tag-Filter.

Im erweiterten Zeilenmenü finden sich weitere Funktionen.

Anlegen eines neuen Credentials

Beim Erzeugen eines Credentials ist zuerst der Typ festzulegen. Es können weitere Optionen folgen wie Eigentümerschaft und Subvarianten .

Für den Einsatz von PowerShell 7 wird das Remoting über SSH immer wichtiger, daher gehen wir hier näher darauf ein. Beim Erzeugen eines Eintrages für einen SSH-Schlüssel kann als Subvariante "via file path" oder "via file content" gewählt werden.

Hintergrund zur Verwendung von SSH-Schlüsseldateien in ScriptRunner

SSH (Secure Shell) stellt ursprünglich auf Schlüsseldateien (Keyfiles) in Benutzerverzeichnissen mit besonderen Berechtigungen ab. Damit diese Benutzerverzeichnisse existieren können, muss ein Benutzerprofil auf dem ScriptRunner-Server vorhanden sein.

Die Subvariante "via file path" erlaubt die Anwendung von SSH in dieser Variante. Allerdings ist zu beachten, in welchem Benutzerkontext das Skript ausgeführt wird. Es muss sichergestellt sein, dass der ScriptRunner-Server zur Laufzeit auf das Benutzerprofil und damit auf das SSH-Verzeichnis zugreifen kann.

Unkomplizierter und deshalb die präferierte Variante ist "via file content". In diesem Fall verwaltet der ScriptRunner-Server die SSH-Schlüsseldateien, der Administrator muss sich um Berechtigungen und Zugriffe nicht weiter kümmern.

 Verwendung eines SSH-Schlüssels via Dateipfad

Nach der Auswahl "via file path" kann in der Konfiguration der Pfad angegeben werden, in welchem die Schlüsseldatei gespeichert ist. Zu beachten ist, dass die Berechtigungen auf dem Pfad korrekt eingestellt sind.

 Verwendung eines SSH-Schlüssels via Dateiinhalt (File Content) 

Die Auswahl "via file content" erlaubt zwei Möglichkeiten. Es kann zum einen der Inhalt der Schlüsseldatei in die Textbox kopiert werden. Alternativ kann der Filepicker verwendet werden, der Inhalt wird extrahiert und ist in der Textbox zu sehen.

Mit dem Speichern wird eine Schlüsseldatei (Keyfile) mit dem Inhalt angelegt und vom ScriptRunner-Server verwaltet.

Neu im Portal: Target-Konfiguration

Im Portal von Release 4 sind nun alle Konfigurationseinstellungen für Targets (Zielsysteme) enthalten. Der in der Admin App enthaltene Wizard wurde durch die neue Benutzerführung ersetzt. In der Übersicht werden die Typen sowie weitere Informationen zu den Targets angezeigt.

Beim Anklicken der Auswahlbox an einem Listenelement erscheinen im darüber liegenden Anzeigebereich neben dem primären Button +Create die zusätzlichen Buttons Edit, Run test und Delete.

Das Anklicken des Namens öffnet die Detailkonfiguration. Das Anklicken eines Tags setzt dieses in den globalen Tag-Filter.

Im erweiterten Zeilenmenü finden sich weitere Funktionen.

Anlegen eines neuen Targets / Übersicht der möglichen Zielsysteme

Die Details der Konfiguration sollen hier exemplarisch am Target (Zielsystem) für M365 dargestellt werden. Es können mehrere Targets z.B. für unterschiedliche Administratoren-Teams oder zum Managen unterschiedlicher Mandanten angelegt werden.

Hinweis: Services, die Microsoft bereits abgekündigt hat, werden als veraltet (deprecated) markiert. Sie stehen zwar zur Verfügung, Anwender sollten jedoch davon absehen, diese einzusetzen.

In der Rubrik General werden Name, Tags und die Beschreibung hinterlegt. Die nachfolgende Rubrik ist abhängig vom Typ des Targets und vom Kontext seiner Verwendung. Im Target für M365 werden nun die zu verwendenden Services durch das Aktivieren zugeordnet. Es ist darauf zu achten, dass keine konkurrierenden Varianten eines Services ausgewählt werden.

Dialog zum Hinzufügen eines oder mehrerer Microsoft-Services 

Anschließend ist die Konfiguration des einzelnen Services einzustellen. Durch Aufklappen der jeweiligen Servicekonfiguration gelangt man dorthin.

In den Erweiterten Einstellungen (advanced settings) lassen sich für jeden Target-Typ die Anzahl möglicher parallel laufender Aktionen beschränken, ebenso kann das Verhalten beim Überschreiten des Limits konfiguriert werden. 

Erweiterte Einstellungen / Festlegen des Limits

Bei Verwendung von Jumphosts lassen sich verschiedene Szenarien in ScriptRunner abbilden. Hierdurch ist es möglich, definierte Pfade für das Remoting durch die Infrastruktur festzulegen. Es können mit ScriptRunner auch mehrere Jumphosts in Reihe verwendet werden.

In der Konfiguration unten wird das M365 Target über den Jumphost angesteuert. Das Skript läuft im konfigurierten Rechtekontext auf dem Jumphost, der ScriptRunner-Server sammelt die Ergebnisse und Rückmeldungen ein. Die notwendigen PowerShell Module müssen in diesem Fall auf dem Jumphost installiert sein. Das kann mit dem neuen, erweiterten Target-Test überprüft werden, welcher mittels Button nach dem Speichern verfügbar ist. Details dazu im nächsten Abschnitt.

Das bei der Verwendung von Jumphosts typische double-hop-Problem der PowerShell löst ScriptRunner eigenständig auf.

Automatische Modulerkennung und erweiterter Target-Test

Die ScriptRunner Serverfunktionen wurden um das automatische Erkennen von PowerShell Modulen erweitert. Dazu wird das #Requires-Statement der PowerShell ausgewertet. Typischerweise wird das Statement in Skripten verwendet, um schon vor dem Starten des eigentlichen Funktionscodes zu prüfen, ob das Modul in der PowerShell Session überhaupt verfügbar ist.

Beispiel


#Requires -Modules ActiveDirectory,ExchangeOnline,Teams

Es wird  geprüft, ob diese PowerShell Module installiert und in der Session verfügbar sind. Wenn nicht, wird die Verarbeitung des Skripts bereits an dieser Stelle abgebrochen. Die Verwendung ist also sehr sinnvoll, um Probleme und Fehler in der späteren Ausführung des Funktionscodes zu vermeiden.

Automatischer System-Tag für das ActiveDirectory PowerShell Modul

ScriptRunner legt für jedes erkannte Modul automatisch ein Tag an. Dieses Tag ist bei einigen Einstellungen am PowerShell Symbol erkennbar. Auf die Verwendung des Tags für Filtering und Darstellung wie bisher hat das keinen Einfluss.

Neu ist die Verwendung dieser Tags zum erweiterten Testen eines Targets. Neben dem Verbindungsaufbau wird auch überprüft, ob die Module auf dem Target, bspw. einem Remotesystem mit seinen Einstellungen verfügbar wäre. Zum Testen kann manuell die Liste der zu prüfenden PowerShell Module ergänzt werden.

Target-Test inklusive Prüfung des PowerShell AD Moduls

Microsoft Graph als neuer Service für M365-Targets

Der Target-Typ für M365 wurde um den Service für das Microsoft Graph Modul erweitert. Die Verwendung von Microsoft Graph mit PowerShell ermöglicht das Automatisieren von komplexen Zusammenhängen im Kontext von Infrastruktur, Anwendern, deren Content und diversen Services und Eigenschaften.  Für Microsoft ist es insofern strategisch, als es  den Zugriff  auf sehr unterschiedliche Daten ermöglichen soll als auch die Begrenzungen von PowerShell-Verbindungen (Connections) zu einem Mandanten (Tenant) aufheben soll, da es zustandslos mit REST arbeitet. 

Einen ersten Überblick zu Microsoft Graph mit PowerShell gibt es hier:
https://docs.microsoft.com/en-us/powershell/microsoftgraph/overview

Neues Microsoft Graph Target (certificate & client secret)

Die Implementierung in ScriptRunner folgt der neuen Anwenderführung zum Anlegen und Konfigurieren von Targets. Einem bestehenden oder anzulegenden M365 Target kann der Service Microsoft Graph hinzugefügt werden. Die aktuelle Version von Microsoft Graph unterstützt die zwei Authentifizierungsverfahren mit Zertifikat oder mit Client Secret. Wird ein Zertifikat verwendet, so muss das Zertifikat im lokalen Zertifikatsspeicher abgelegt sein. Wird hingegen ein Client Secret verwendet, muss Name und Secret unter Credentials konfiguriert worden sein. In beiden Fällen ist im Mandanten (Tenant) ein Service Principal einzurichten oder es müssen dem registrierten ScriptRunner Service die Berechtigungen zugewiesen worden sein.

Token-based Authentication für M365 Services

Microsoft hat Modifizierungen für das Anmelden und Verwenden von Services vorgenommen. Die neue token-based Authentication beseitigt im Hintergrund alte Referenzen auf AADGraph und verwendet nun moderne Methoden mit einer verbesserten Sicherheit.

Betroffen davon sind das Teams PowerShell Modul ab V4 als auch Microsoft Graph PowerShell Module. Es ist zu erwarten, dass zukünftig auch andere PowerShell Module betroffen sind.

In ScriptRunner wurde nun für das M365 Target eine automatische Erkennung implementiert, welche zunächst die Methode ermittelt und dann die passende verwendet.

Dadurch sind keine Änderungen an der Konfiguration notwendig, wenn ein neueres PowerShell Modul zum Einsatz kommt.

Upload von Dateien durch Anwender für Massenverarbeitung (Bulk Operations)

Im Tagesgeschäft von Helpdesk und Administratoren kommt es oft vor, dass Datensätze als Masse verarbeitet werden müssen. Oftmals liegen die Datensätze im Format CSV, TXT, XML oder JSON vor. Mit einem PowerShell Skript sollen die Datensätze verarbeitet werden, bspw. zur Neuanlage oder zum Sperren von Benutzerkonten, zum Ändern von Eigenschaften an Systemen oder Datenobjekten.

ScriptRunner bietet in der Portal Edition R4 nun die Möglichkeit eines Datei-Uploads. Es können die Dateiformate CSV, TXT, XML oder JSON hochgeladen werden. Es gilt die Empfehlung, sich auf max. 1 MB zu beschränken.

Code-Editor in ScriptRunner

Das Beispiel unten zeigt die Parameterdeklaration, um eine Datensatzdatei als Datenstrom an das Skript zu übergeben. Unterstützt werden die genannten Formate. Es gilt die Empfehlung, sich auf max. 1 MB zu beschränken. 

<#

    .SYNOPSIS

      This is an example of using the fileupload for bulk operations.

      The file type must be TXT, CSV, XML or JSON. The file size is limited to 1 MB. 

 

    .DESCRIPTION

      With bulk operations, the same tasks, such as creating users or changing properties 
      on many objects, can be processed as a batch. You can use more than one batch file params.

 

    .PARAMETER batchfile

      Pls. drop your batch file into the field

#>

 

Param

(

    [Parameter(HelpMessage="ASRDisplay(FromFile)")]

    [string]$batchfile

)

Um eine größtmögliche Freiheit und Flexibilität bzgl. der verwendeten Datensatzstrukturen zu ermöglichen, wird ein Datenstrom statt der Datei selbst verwendet. Der Datenstrom entspricht dem Encoding und dem Bytestrom der Datei. Zum Parsen und Zuweisen der Einzeldaten zu lokalen Verarbeitungsparametern kann eine PowerShell Function aus einer _LIB_ verwendet werden. Das hat den Vorteil, dass diese Funktion mehrfach verwendet werden kann.

Drag & Drop Funktion ermöglicht schnelles Anstoßen von Massenverarbeitung

Die Darstellung im Portal erfolgt als no-code-Parameter mit einer Drop-Zone zum Einlesen der Datensatzdatei. Es können auch mehrere Datensatzdateien eingelesen werden. Für jede wird ein eigener Datenstrom-Parameter benötigt. Wird die Aktion dann gestartet, können die eingelesenen Daten im PowerShell Prozess verarbeitet werden.

Erzwingen signierter Skripte

Für ScriptRunner kann nun die Verwendung signierter Skripte erzwungen werden, unabhängig von den Einstellungen der PowerShell Execution Policy auf dem ScriptRunner-Server.

Das wirkt sich nicht nur auf die lokale Ausführung von Skripten auf dem ScriptRunner-Server selbst aus, sondern auch auf das Remoting, da ScriptRunner die Remoteverbindungen steuert und die Verarbeitung von Skripten ohne oder mit falscher Signatur ablehnt. Die Funktionalität bezieht _LIB_ und _QUERY_ Scripts immer mit ein.

Aktiviert werden kann diese Funktion mit dem Kommando:

Set-ASRSettings -SignedScriptsOnly yes/no

Fazit

Es hat sich einiges getan! Neben den technischen Neuerungen lag der Fokus dieses Releases auf der Benutzerfreundlichkeit. Mittelpunkt des moderneren, intuitiveren Navigationskonzepts ist das neue Hauptmenü, für das im Frontend Entwicklungsteam zunächst die Informationsarchitektur unter die Lupe genommen und dann umgestaltet
wurde. 

Zum ersten Mal ist ScriptRunner neben Deutsch und Englisch auch auf Spanisch und Französisch verfügbar.

Die Portal Edition R4 enthält Features wie Drag & Drop von Dateien zur automatisierten Massenverarbeitung in ScriptRunner Actions auch das zukunftsweisende Thema der Token-basierten Authentifizierung. Damit wird die Verbindung mit M365-Services (Teams, Exchange Online, Graph) vereinfacht und sicherer. ScriptRunner unterstützt ab sofort das Microsoft Graph PowerShell Modul als Target zur Automation von IT-Managementaufgaben in Microsoft 365 und Microsoft Azure.

Weiterführende Links 

• Hier buchen Sie eine Demo und testen die neue Software
• Mehr Informationen zum Release finden Sie im Release Guide