Abkündigungen

Windows Server 2012 wird zukünftig nicht mehr im Support unterstützt. Neuinstallationen und Migrationen sollten auf Windows Server 2019 erfolgen.

ScriptRunner in den Versionen 2016 und 2017 wird ab 01.06.2020 nicht mehr unterstützt. Wir empfehlen ein Update auf die aktuelle Version 2019R3.

Support für Active-Passive Cluster

ScriptRunner 2019 kann zur Erhöhung der Ausfallsicherheit in einem Windows Active-Passive Cluster installiert werden.
Im Betrieb werden folgende Ressourcen im Sharing verwendet:

• Script repository
• ScriptRunner Configuration
• Reporting database

Folgende Einstellungen sind an einen Clusterknoten gebunden:

• Program binaries
• Work directories
• Log directories
• Windows event log entries
• Windows Performance Counter
• Active PowerShell processes during script execution
• Credentials for script execution
• License file and activation keys
• ScriptRunner connectors
• Installed/applied PowerShell modules

ScriptRunner muss auf beiden Clusterknoten installiert werden. Im Cluster Manager müssen außerdem die Clusterressourcen für die Knotenressourcen sowie die Shared Disk eingerichtet werden.
Die URI für ScriptRunner Web Service und die Web Apps wird durch eine Ressource mit Client Access Point nach außen zur Verfügung gestellt.

Eine ausführliche Anleitung für die Installation im Cluster können Sie beim ScriptRunner Support anfordern.

Personalisierbare HTML-Reports für PowerShell

ScriptRunner bietet detaillierte Berichte über die Ausführung von Actions und damit die Ausführung von PowerShell-Scripten. Die bisherigen Berichte enthielten die folgenden Informationen:

• Metainformationen zur Scriptausführung
• Eingabeparameter
• Result- bzw. Error-Messages
• PowerShell Konsolenausgabe

Mit diesen Infomationen kann, die Ausführung der PowerShell-Scripte überwacht und das Auditing sichergestellt werden.

Mit steigender Verbreitung von PowerShell steigen jedoch auch Anforderungen an die Inhalte und die Darstellung von Ergebnisreports. Besonders hervorgehoben seien hier Auswertungen und Übersichten.

PowerShell selbst bietet die Möglichkeit mit der Funktion ConvertTo-Html, Ausgaben als HTML-Dokument auszugeben. Zusätzlich gibt es zwei populäre Module, ReportHTML und PSHTML in der PowerShell-Gallery, um umfangreiche grafische Reports mit PowerShell zu erzeugen.

Mit Version 2019R3 stellt ScriptRunner diese Funktionalität nun in der Breite auch zur Delegation und Automatisierung zur Verfügung.

In unserem Video [English only] gibt Ihnen Heiko Brenn, Produktexperte bei ScriptRunner, einen Überblick über das neue Feature:

Neue Use Cases mit HTML-Reports

Durch die neue Funktion erschließen sich neue Use Cases für die ScriptRunner-Anwender.

Administratoren profitieren von aussagekräftigeren und übersichtlicheren Reports zu Ergebnissen der Script-Ausführung. Insbesondere wiederkehrende Analyse- und Reporting-Scriptläufe zur Ressourcennutzung, Berechtigungen, Konfigurationen etc. sind Beispiele dafür.

Service Desk Anwender profitieren von einer übersichtlichen und ansprechenden Darstellung von Ergebnissen der ausgeführten Actions.

Mit den neuen Möglichkeiten rücken nun auch Fachanwender stärker in den Fokus. So können für diese Gruppe spezifische Analysen und Auswertungen mit PowerShell geschrieben (bspw. zur Auswertung verteilter Daten in O365, Teams, SharePoint, Datenbanken usw.) und grafisch aussagekräftig aufbereitet werden. Die Aufbereitung der Daten erfolgt im Hintergrund und der Fachanwender erhält einen Link zum fertigen Report.

PowerShell built-in ConvertTo-Html

Die PowerShell selbst stellt eine Funktion zum Erzeugen von HTML-Reports zur Verfügung. Die Darstellung des HTML kann mit einem entsprechenden CSS-Stylesheet gesteuert werden, um bspw. Header und Footer, Schriftarten und Farben auf alle Reports anwenden zu können.

Das Erzeugen der entsprechenden Ausgaben erfolgt im PowerShell-Script. Nachfolgender Codeausschnitt zeigt die Funktionsweise zum Erzeugen der Ausgabe und die Zuweisung an ScriptRunner über die Systemvariable $SRXEnv.ResultHTML :

$preContent = "

$(Get-Date -Format 'dddd yyyy-MM-dd HH:MM:ss')

"
$postContent = "

by $($SRXEnv.SRXStartedBy)

"
$SRXEnv.ResultHTML = Get-Process -Name $name |
Where-Object -FilterScript { $_.TotalProcessorTime } |
Sort-Object -Property VirtualMemorySize64, TotalProcessorTime -Descending |
Select-Object -Property Name,
Id,
@{
Label = 'VirtualMemory';
Expression = { '' + [math]::truncate($_.VirtualMemorySize64 / 1MB) + 'MB' }
},
TotalProcessorTime,
@{
Label = 'TotalRunningTime';
Expression = {(get-date) - $_.StartTime}
},
Productversion,
@{
Label = 'Path';
Expression = {
if ($_.MainModule -AND (Get-Member -InputObject ($_.MainModule) -Name 'FileName' -MemberType Properties)) {
$_.MainModule.FileName
}
else {
"---"
}
}
} |
ConvertTo-Html -Title 'Get Process' -As 'Table' -CssUri './sr-table.css' -PreContent $preContent -PostContent $postContent

Das HTML-Dokuments wird in folgendem Verzeichnis gespeichert

C:\ProgramData\ScriptRunner\Service\Local\ResultFiles

Abbildung 1: Report generiert mit dem ConvertTo-HTML-Modul, dargestellt in ScriptRunner

Mehr Informationen zu ConvertTo-Html finden Sie in der Microsoft Dokumentation.

Verwendung von populären HTML-Converter-Modulen

Die Flexibilität von ScriptRunner ermöglicht über die Standardfunktion ConvertTo-Html hinaus die Verwendung spezieller HTML-Generator-Module. Zu empfehlen sind dafür unter anderem:

• ReportHTML (siehe Abbildung 2)
• PSHTML

Beide Module stellen einen erweiterten Befehlssatz für die Erzeugung von HTML-Reports zur Verfügung. Dazu gehören Seitenaufbau und Seitendarstellung mit Tabs, unterschiedliche Grafiken, Suchfeld etc.

Abbildung 2: Report generiert mit dem ReportHTML-Modul, dargestellt in ScriptRunner

Ein Beispielscript zur Verwendung von ReportHTML mit ScriptRunner finden Sie in unserem ActionPack auf Github.
Im Rahmen unserer ActionPacks werden wir sukzessive weitere Reporting-Scripts zur Verfügung stellen oder auf diese in anderen Github-Repositories verweisen.

HTML-Reports in ScriptRunner

Die Verwendung von HTML-Reports ist ab ScriptRunner Version 2019R3 möglich. Dazu werden folgende Erweiterungen implementiert:

• System Hashtable: SRXEnv.ResultHTML
• Virtuelles Verzeichnis auf dem IIS …/scriptrunner/reports. Jeder Report erhält dort eine eigene GUID
• Standard-CSS auf
  

  C:\ProgramData\ScriptRunner\Service\Local\ResultFilessr-table.css<

• Admin Web App: erweiterte Metadaten in den PowerShell-Reports mit Link auf den HTML-Report
• Delegate and Self-Service Web App: erweitertes Dialogfenster mit Link auf den HTML-Report, das währende der Action-Ausführung angezeigt wird
• Delegate Web App: erweiterte Übersicht mit Link auf die HTML-Reports

The HTML reports can be accessed in 5 ways:

• Link in der Admin Web App
• Link in the Delegate Web App
• Link im Dialogfenster der Self-Service Web App
• Versenden des Reports aus einer ScriptRunner Action
• Versenden des Reports aus dem Script mittels $SRXEnv.ReportEmail

Erweiterte Eingabevalidierung

Um die Nutzerfreundlichkeit und Anwendungsbreite zu steigern, wurde die Unterstützung von Datentypen und die Eingabevalidierungen von ScriptRunner erweitert.

Regular expressions

Die automatisch generierten Eingabefelder in den Web Apps unterstützen nun auch die Eingabe von gesteuerten reguläre Ausdrücken. Die Validierungsinformationen werden dabei aus dem PowerShell-Script erzeugt und müssen im param-Block des Scriptes definiert werden.

param
(
[ValidatePattern("^[^@]+@.+$")
[string]$RegEx
)

Multiline Texteingabe

In einigen Anwendungsfällen sind längere Texteingaben als Eingabeparameter erforderlich. Dafür kann das neue Multiline-Feature verwendet werden. Die Definition erfolgt im param-Block des Scriptes.

param
(
[Parameter(HelpMessage="ASRDisplay(Multiline)")
[string]$MultilineText
)

Versteckter Text

In einigen Anwendungsfällen sollen Texteingaben nicht auf dem Bildschirm nicht sichtbar sein, sondern als Punktkette dargestellt werden. Das neue Hidden Text-Feature kann dafür verwendet werden. Die Definition erfolgt im param-Block des Scriptes.

param
(
[Parameter(HelpMessage="ASRDisplay(Password)")
[string]$HiddenText
)

Secure string type

In einigen Anwendungsfällen ist es sinnvoll, den Datentyp SecureString einzusetzen. In der äußerlich sichtbaren Anwendung unterscheidet er sich nicht vom erweiterten Attribut Hidden Text. In der Verwendung innerhalb des Scriptes sind allerdings entsprechende Cmdlets zu verwenden, welche diesen Datentyp unterstützen oder Konvertierungen vorzunehmen.

Param
(
[ValidatePattern("^d{6}")]
[securestring]$SecurePIN
)

Erweiterungen in _QUERY_ und _LIB_ Scripten

Die Wiederverwendbarkeit von Code steht immer wieder im Mittelpunkt von Programmieraufwendungen.

Das trifft auch auf PowerShell-Scripte zu. Aus der Anwendung von PowerShell-Scripten kristallisiert sich praktisch bei jedem unserer Kunden Funktionscode heraus, welcher in vielen Scripten per copy & paste zum Einsatz kommt. Das führt in der Folge zu viel und schlecht wartbarem PowerShell Code.

Um diesem Problem zu begegnen, eignen sich PowerShell functions. Eine PowerShell function kann in jedem Script verwendet werden, sofern der Zugriff auf den Code der function sichergestellt ist.

ScriptRunner unterstützt die Verwendung von PowerShell functions gleich mehrfach:

• Als aufrufbare Funktion einer Library mit dem Tag _LIB_ in einem Hauptscript
• Als aufrufbare Funktion einer Library mit dem Tag _LIB_ in einem Query-Script
• Als direkt verwendbare Funktion in einer ScriptRunner Action
• Als Cmdlet in einem selbst geschriebenen PowerShell-Modul

Die Funktionsweise einer Script Library _LIB_ gleicht dabei einem selbst gescripteten PowerShell-Modul, allerdings ohne dessen Overhead und ohne dessen innewohnende Statik.

Eine Script Library kann eine Vielzahl von Funktionen beinhalten. Wir empfehlen, thematisch nahe functions in jeweils einer gesonderten Library zusammenzustellen. Es ist darauf zu achten, dass innerhalb der jeweiligen function ein Header und ein param-Block existiert. Dadurch sind einzelne PowerShell functions in ScriptRunner direkt in einer Action verwendbar.

Um PowerShell functions in einem Hauptscript zu verwenden, muss in den Action-Einstellungen die entsprechende PowerShell-Option (Abbildung 3) gesetzt werden.

 

Abbildung 3: Die PowerShell-Ausführungsoption zum Vorladen von Library Scripten in die Session einer ScriptRunner Action finden Sie in den Einstellungen der Action

Sollen einzelne Funktionen einer Library in einem Query-Script verwendet werden, so kann diese Library in den Query-Einstellungen ausgewählt werden (siehe Abbildung 4).

 

Abbildung 4: Die PowerShell-Ausführungsoption zum Vorladen von Library Scripten in die Session einer ScriptRunner Query finden Sie in den Einstellungen der Query

Wenn Sie eine PowerShell-Funktion aus einer Library direkt als ScriptRunner Action verwenden möchten, können Sie die Funktion im Hauptmenü Scripts | Cmdlets auswählen und durch Klick auf + New Action eine neue Action erstellen.

Abbildung 5: Erstellen Sie eine neue Action basierend auf einer PowerShell-Funktion, indem Sie die entsprechende Funktion auswählen und in der Symbolleiste auf „+ New Action“ klicken.

 

Erweiterungen am Web Service Connector

Die Zahl der Einsatzszenarien des Web Service Connectors nehmen bei unseren Kunden beständig zu. Damit einher gehen neue Anforderungen u.a. zur Verwendung von Micro Service als Aufrufer von ScriptRunner Actions.

Zum besseren Verständnis der unterschiedlichen Einsatzszenarien mit ScriptRunner hier eine kurze Übersicht:

System- oder Application Backend

Der Aufruf von ScriptRunner über den Connector erfolgt durch ein anderes Backend-System. Quellsysteme können zentrale Monitoringsysteme oder Application Server, wie bspw. Workflowsysteme, sein. Zur Authentifizierung des Aufrufes am ScriptRunner Server und zur Zuordnung der Actions können einzelne Service Accounts oder Gruppen konfiguriert werden.

Client-Anwendungen oder Client-Computer

Hierbei können Client-Anwendungen oder Client-Computer den Web Service in ScriptRunner direkt verwenden. Zur Authentifizierung des Aufrufes am ScriptRunner Server und zur Zuordnung der Actions können ausschließlich Gruppen in der Rolle Self-Service Endanwender verwendet werden. Die referenzierten AD-Gruppen können Benutzerkonten oder Maschinenkonten enthalten.

Micro Services

Aus Gründen der Skalierbarkeit und der Ausfallsicherheit erfreuen sich Micro Services steigender Beliebtheit. Im Zusammenspiel mit ScriptRunner als Automationsplattform für PowerShell ergeben sich neue Möglichkeiten zum Einsatz von Scripten. Deshalb wurde die Möglichkeit geschaffen, Micro Services als aufrufendes Quellsystem für ScriptRunner einzusetzen (siehe Abbildung 6). Dafür ist eine gesonderte Lizenz erforderlich.

Abbildung 6: Um Micro Services/Kubernetes als aufrufendes Quellsystem für ScriptRunner zu verwenden, muss die entsprechende Option in den Eigenschaften des Web Service Connectors ausgewählt werden

 

Authentifizierung mit Basic Auth

Aufrufe von ScriptRunner durch Drittsysteme werden grundsätzlich nur authentifiziert durchgeführt. Die Authentifizierung erfolgt durch Applikationsrollen in ScriptRunner. Die Applikationsrollen selbst sind mit AD-Gruppen oder direkt mit AD-Accounts verknüpft.

Eine Reihe von Systemen, insbesondere Web-Anwendungen, unterstützen nicht alle modernen Authentifikationsverfahren. Obwohl veraltet, wird häufig noch Basic Auth von diesen Anwendungen verwendet. Um Basic Auth am ScriptRunner Web Service Connector verwenden zu können, muss dieser für Basic Auth enabled werden. Das erfolgt mit einem Cmdlet des ScriptRunnerSettings Moduls.

• Set-AsrSTSOptions -AuthMode WINBasic -ON schaltet Basic Auth für den Connector ein. Benutzername und Kennwort des Rufer-Account muss im AD existieren.
• Set-AsrSTSOptions -AuthMode WINBasic -BasicLocalAccounts 1 -ON schaltet Basic Auth für den Connector ein. Benutzername und Kennwort müssen als lokaler Benutzer auf dem ScriptRunner Server existieren.
  
  

Weitere Verbesserungen und Erweiterungen

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

Funktionen für das Lizenzmanagement

Das PowerShell-Module ScriptRunnerSettings wurde um einige Funktionen für die Verwaltung von Lizenzen erweitert.

• Mit Get-AsrLicensedUser -UserType ‚Self-Service Users‘ lassen sich nun die registrierten Self-Service User Accounts abfragen. Wird ein Account längere Zeit nicht benutzt, wird die Lizenz automatisch freigegeben.
• Gesperrte Accounts von Administratoren und Service Desk Usern können nun mit einem speziell angeforderten Key wieder aktiviert werden. Pro Account ist ein separater One-Time-Key notwendig. Beispiel:

Enable-AsrLicensedUser -ExactLicensedUserString 'asrmarion.mueller' -ActivationKey XXXX

Verbesserungen am Password Connector für CyberArk und Delinea

• Die Datenformate für die Abfrage von Credentialreferenzen für Benutzer und Computerkonten wurden um weitere Möglichkeiten, welche CyberArk bietet, erweitert.
• Der Password Connector für Delinea Secret Server unterstützt nun neben der on-prem Variante auch Delinea Secret Server Cloud.

Personalisierte Anpassungen für die Admin Web App

Die von der Delegate Web App bereits bekannten Anpassungen auf das eigene Corporate CI wurde mit dieser Version auf die Admin Web App ausgeweitet. Die Anpassungen erfolgen analog der Delegate Web App hierfür im Verzeichnis

C:\ProgramFiles\ScriptRunner\WebApps\AdminApp\custom

Nähere Informationen zur Anpassung finden Sie in unseren Handbüchern.

Neue ActionPacks

Wir erweitern beständig unsere ActionPacks um neue Beispiel-Scripte. Zusätzlich ergänzen wir diese um neue Sammlungen. Folgende ActionPacks sind mit ScriptRunner Version 2019R3 hinzugekommen:

• Office 365 Teams – basiert auf den neuen Modulen von Microsoft für Teams
• Office 365 PowerApps – basiert auf den neuen Modulen für Microsoft PowerApps und PowerAutomate
• SharePoint Online
• Skype4Business