New in ScriptRunner 2018R2

Author: | Reading time: 4 minutes | Category: ScriptRunner

ScriptRunner PowerShell Version 2018R2

This article has been translated automatically.

With ScriptRunner 2018R2 we have consistently continued the path we took in version 2018R1. The queries were functionally extended and the functionality improved in many details. We have also focused on improving usability. In addition, there are other functions such as script execution timeouts and a library of reusable function scripts.

Even more queries in ScriptRunner 2018R2

The enthusiastic feedback of our customers on the query functions has induced us to take up many of the constructive suggestions and immediately implement them in order to “round off” the entire topic block of queries.

Attribute Queries for Active Directory Objects

The set of usage cases for AD queries has been extended to include attribute queries. These types of queries are suitable for automatically reading out individual AD attributes, such as department, phone, mail or user address. In combination with a previously executed OU and User query, you can select a user from a specific OU branch of the AD. You can then read other attributes of the user object. You can assign the values to script parameters and use them in the script or modify them in the displayed form.

Auto-Run for Queries

In addition to the interactive mode for starting queries, you can now also start queries automatically. This is especially advantageous if the number of expected results of a query will be less than 100 result entries.

You also benefit from the auto run with cascaded queries. For example, a user could select an AD group and then the query is started automatically to break down the group members. Or a user is selected and the cascaded attribute queries for the user object are executed automatically and the values are displayed in the form.

The Auto-Run function can also be used for script queries.

Credentials in Script Queries

Queries queries using PowerShell Script are a very effective way to perform a wide variety of queries and thus make the result list available to the user as a dropdown menu in the automatically generated form. For example, a list of all active VMs on a virtualization host can be generated via script. A user can then select the appropriate VM from the dropdown menu and run a script to increase the number of vCPUs or attach an ISO.

A query script is not necessarily executed on the same system as the actual work script. In the example above, the query script is to be executed on a Hyper-V host or ESX host and the work script is to be executed on the actual VM. In this context, it is possible that the rights context is different for both scripts. For this purpose, ScriptRunner now also supports queries for corresponding credentials. To do this, an input parameter of type [PSCredential] must be defined in the param-block of the query script.

param ( [PSCredential] $Cred ... )

The credential can then be assigned within the query configuration without the account and password having to be stored in the query script. The credential is introduced into the PowerShell process at runtime of the query script. This procedure significantly improves the security in handling account information and now corresponds to the procedure in actions.

Screenshot ScriptRunner 2018R2: Zuweisen eines Credentials in einem Query-Script

Assigning a credential in a query script

Parameter references in queries with scripts

New parameters were added or the sequence changed in query scripts, so the query had to be recreated. This restriction was removed by a parameter reference function. Changes in the param-block of the query script are now automatically referenced in the query wizard, changes take effect immediately.

Editable forms with current values from a system

Everyone knows the challenge in change processes and tasks that one would like to show the user the value that the respective field already has in the system when filling out form fields. An example would be changing typical user properties.

Classical graphical administration tools per se have the possibility to display the values already. However, these tools are not suitable for performing tasks for service desks or end users securely and without administrative rights delegation.

PowerShell, in its native form, has the ability to output values across different Get cmdlets. However, the variant does not allow you to change the value interactively and then use it again as an input value.

The ScriptRunner Admin and Delegate App with the automatically generated input forms in the web browser are a graphical user interface for PowerShell. The new functions allow for the display of an editable form with existing values using Attribute Query, Auto Run, and generic mask generation enhancements. The displayed values can be changed or supplemented. By pressing the Run button they are used as input value for the script.

Screenshot ScriptRunner 2018R2: Input form with automatically queried actual values

Input form with automatically queried actual values

The function of the mask shown above: After selecting the country organization, you can search for and select a user in this example. After the user has been selected, further attributes (here department, street, email) of his user object are automatically queried in the AD and entered into the mask. The user can now change or supplement the attributes. If the user wants to use the previous value, he can restore it by deleting the input data in the field.

The script then starts with these input parameters and changes the values in the AD.

This functionality is not only available for AD queries, but can also be used in conjunction with query scripts.

More overview in actions

With the increasing use of ScriptRunner for use cases with PowerShell in an environment, the number of configured actions and script policies continues to increase. In very long lists, the overview can quickly get lost. At the same time, changing or reconfiguring actions is no longer as easy as it is with only a few entries per list. In particular, the need to jump back and forth between the main menus for queries, target systems, etc. can hinder effective and simple configuration.

Global Tags for Filtered Selection

With this new function, the already proven tags can now be used for comprehensive filtering. The tag filter bar has therefore been removed from the list header. The full text search has been retained at list level.

If you assign “Exchange” to the global tag filter, all elements of the main menus “Actions”, “Queries”, “Targets”, “Scripts” and “Credentials” are filtered in the display. The filter is now retained when switching to another main menu and is no longer reset. The selected tags in the filter field now act as logical OR.

Global filter for all main menus of the Script Policy

Global filter for all main menus of the Script Policy

The whole thing simplifies the handling of the various lists with many entries in the main menus and better represents the application context of the Script Policy components for you as administrator. However, it requires the consistent use of tags on all of these components, which you can do at any time.

To avoid jumping back and forth when configuring and testing actions and to simplify the process, a new view has been introduced. The Action Bar contains a new function “Details” for this purpose. If you select an action and apply the Detail button, the view for the action changes to the new tree-like detail view. Press the button again to return to the overview list.

Detailed view for an action for configuration and testing

The structure of the view also shows the dependencies of the individual components of a script policy and the use of their elements, such as credentials as script parameters, in a target system or query configuration. In the view, individual elements can be selected and their associated configuration wizard called with EDIT.

If you select the action yourself, all necessary functions are available in the Action Bar as usual.

Even more possibilities with actions

The functionality with ScriptRunner actions was also further expanded. You can now use two new PowerShell options.

Powershell Execution Timeout

This option controls the abort for longer running scripts, e.g. reporting scripts, if they threaten to run into an endless loop. In this way you define a default duration after which the execution of the script is to be aborted. The default is to take the average execution time of the action from the reports and add +25 to +50% to buffer for unforeseen load cases that are not due to PowerShell.

Library for function scripts

If you work a lot with scripts, you will notice after a while that there are script passages that you need more often. PowerShell provides functions for this. In order to be able to use functions in different actions and contexts, such scripts can be tagged with “_LIB_” in the ScriptRunner repository.

Afterwards your self-created function scripts (e.g. for connecting drives, connecting to shares, etc.) are available in ScriptRunner actions. You can assign multiple function scripts to an action.

Screenshot ScriptRunner 2018R2: New options: script execution timeout and function scripts

New options: script execution timeout and function scripts

In the working script, i.e. in the main script of the action, you can now use the function calls as if the function were defined in the working script. Note that parameters used within the function have been assigned values at runtime. If these are variable parameters, e.g. the share name, this must either be fixed in the working script or declared as an input parameter for the action.

At runtime, all function scripts and the working script are loaded into the PowerShell execution process and are thus available as overall functionality.

You might also be interested in these posts:

Secure Password Server, PowerShell
ScriptRunner 2019R1, Network, Multi-Team
ScriptRunner Version 2018R3