ScriptRunner 2020R1 – Multi-language support, webhooks and target selection for admins

From version 2020R1 on, users who want to update from an older ScriptRunner version can update directly to the latest version (previously, users had to update to intermediate versions first).

For the update itself, please note that both ScriptRunner Server and all apps will be updated. If an external SQL database is used via the Report/Audit Connector, the database schema must also be updated with SQL Server Management Studio. The corresponding schema file can be found under the path “./programs/scriptrunner/bin/support/”.

For instructions on how to update ScriptRunner, please refer to the Installation & Update Guide.

Localization of scripts and input forms

With the new feature for localizing scripts and input forms in ScriptRunner, we have implemented in version 2020R1 a feature long awaited by international customers.

The basic idea starts with the script header.

The information for

• .DESCRIPTION
• .NOTE
• .PARAMETER

can be stored transparently and completely in the PowerShell standard in English and in German. One of both can be set as default: the default language is used by ScriptRunner if a language has been selected in the ScriptRunner app, which is not available in the script as a separate localization. Example:

.PARAMETER InputField 
		this is the default 
		[sr-en] this is the english description
		[sr-de] das ist die deutsche Beschreibung 
		Param ( 
				[type] $InputField
			)

The automatically generated input forms in the ScriptRunner apps show the field description as well as the script description in the selected language, if there is a corresponding localization in the script header. Otherwise, the default language is used.

Localization of action names

Action names can also be localized from version 2020R1 on: In the tile and list view of Web Apps for Service Desk and Self-Service users, Action names and descriptions can be displayed depending on the language of the app (see Figure 1). The same language ‘tags’ are used as in the script header.

Figure 1: New localization options for Actions in the ScriptRunner Admin App

Already in version 2020PS7-Edition, a new feature was introduced that allows to specify a preselection for target systems when creating an Action. This allows Delegate App users to independently select one or more target systems to run the Action on when the Action is executed (see ScriptRunner 2020PS7 – Selecting the Target System at Script Execution).

This feature has been redesigned and enhanced with a focus on admin users, so that Admin App users can now also use the Target System preselection when executing an Action (Figure 2).

Figure 2: Target System preselection in the ScriptRunner Admin App

The user can still exit the Target System preselection and switch to the Target System Admin view. There he can also select other target systems for execution (see Figure 3). Which additional target systems are displayed to the user depends on the user’s role and team/tenant affiliation.

Figure 3: Admin view for target systems in the ScriptRunner Admin App

Microsoft has been pursuing the modernization of authentication methods at Azure and Microsoft 365 Online Services for some time. Specifically, this involves a certificate-based logon to a specific service API (AppID), to a specific tenant. David Pinkawa from TechSnips explains how this can be done manually in the following video:

You can now use the Modern Auth method with the Exchange Online V2 Module in ScriptRunner. The following prerequisites must be met:

• Exchange Online V2 Module is installed on ScriptRunner Server
• App-only Authentication is set up
• A valid certificate has been downloaded and installed locally on the ScriptRunner Server

Figure 4: Cloud connection via EXO V2 model

Now a corresponding target can be set up in ScriptRunner (Figure 4). It is important to note the context in which the target system on the ScriptRunner server is used to ensure access to the certificate.

Webhooks are a popular and widespread means of communication between servers. They are used to inform a message recipient that a certain event has occurred.

The basic concept is that a payload URL is registered on the source system, which is to be called at a certain event. For authentication to the Web Service Connector by the caller, you can use NTLM or Kerberos, or even Basic Auth if necessary.

The ScriptRunner Web Service Connector now also supports calling and starting ScriptRunner Actions via registered webhooks. For this purpose an additional call has been added to the connector, whose payload URL can be registered with a webhook (Figure 5).

Figure 5: Action ID and Webhook URL on the first page of the Action configuration wizard

The Web Service Connector can receive post requests in JSON format from the registered Webhook. The elements of the JSON package are passed to the Action as parameters.

The URL to be registered is specified in the following format

[https://FQDN]/ScriptRunner/api2/PostWebhook/[ID]

[ID] stands for the ID of the Action. From version 2020R1, the ID is displayed on the first page of the Action in the wizard.

The Theming function already allowed you to define your own logos and background colors for ScriptRunner Web Apps.

To ensure readability, the background colors for header bar and splash screen can now be defined separately.

For this purpose, the following two CSS classes have been added to the customstyle.css file (located at “[…]programsscriptrunnerweb apps[app]customcustomstyle.css”):

/* Header-Bar background color */
.sr-appbackg.app-sr-blue.customstyle {
		background-color: aqua;
}
/* Splashscreen background color */
.sr-appbackg.app-sr-blue.customsplash {
    		background-color: aqua;
}

The switch to PowerShell 7 within ScriptRunner has been simplified. After updating or installing version 2020R1, you can now immediately configure and use Actions with PowerShell 7 scripts. A separate installation of PowerShell 7 and .NET Core is no longer necessary.

The new version includes a self-contained PowerShell 7 host that provides a standalone PowerShell 7 process at PowerShell 7 script runtime. This enables PowerShell 7 scripts to run locally on the ScriptRunner server as well as remotely via PowerShell Remoting with SSH. As before, the appropriate modules of the cmdlets that you want to use must also be installed at the location where the script runs.

The Self-Contained Host is regularly updated with ScriptRunner updates and upgrades. Since the PowerShell community and Microsoft are committed to backward compatibility as they continue to develop PowerShell, the PowerShell 7 scripts are not tied to an older version.

Windows PowerShell scripts continue to run in their own environment regardless of the PowerShell 7 host.

Parallel to the Self-Contained Host, the ISE Add-On has also been adapted to the new PowerShell version. Even though many developers are already using Visual Studio Code and Git, PowerShell ISE still remains a fast and lightweight UI for PowerShell scripting for many administrators.

The ISE Add-On is installed on the administrator’s work environment. The add-on connects to the ScriptRunner script repository as well as to the installed PowerShell versions. Windows PowerShell is usually already preinstalled. If PowerShell 7 is installed on the client in the default directory, you can also script in PowerShell 7. The functions Check-out, Check-in, Revert etc. in the ScriptRunner tool panel can also be used as usual.

The following functions are now available in the ScriptRunner toolbar (Figure 6):

• Show/Hide ScriptRunner Tool Panel
• Switch to PowerShell 7 Host
• Switch to Windows PowerShell Host
• Reset SRXEnv
• Upload current script to ScriptRunner Server

Figure 6: Toolbar of the ScriptRunner ISE Add-on

The Switch to PS7 Host button is only active if PowerShell 7 is installed in the default directory. If PowerShell 7 is installed in a different directory, the path to pwsh.exe can be changed in the Config file of the ISE Add-On. The corresponding config file can be found under:
“C:ProgramFilesWindowsPowerShellModulesISEScriptRunnerBinCom.ScriptRunner.UI.ISEAddOn.dll.config”.
The ISE Add-On can be set up and disabled by using the Start-ISEScriptRunner cmdlet and other cmdlets.

As always, the latest ScriptRunner version is available for download on our support page:
Download from support.scriptrunner.com