ScriptRunner 2020R3 – full scope of functions in the portal, multi-attribute queries and more actions for end users
27 min read
April 27, 2021
By: Frank Kresse Apr 27, 2021 7:19:07 PM
Table of Contents
- Outlook on product strategy
- Enhancements and new apps in ScriptRunner Portal
- What’s new in the Run App
- What’s new in the Reports App
- The new Authorize and Delegate App
- The new Settings App
- Multi-Attribute-Queries for Azure AD and AD
- Parameter-driven AD and Azure queries
- Team Repositories for Scripts
- More Actions for End Users
- Advanced Support Function in the Portal
- Setup without sample configuration
- Other Improvements
- Explore ScriptRunner version 2020R3 live and in color
- Extensions and new apps in the ScriptRunner Portal
- Multi-Attribute Queries for Azure, Active Directory and with scripts
- Queries with parameters for search control
- Advanced caching modes for queries
- Script repositories for admin teams
- Simplified Azure AD App Registration
- More actions for end users
As of ScriptRunner 2020R3, multi-attribute queries can now be used. An AD, Azure AD MS/Azure Graph query can therefore determine a large number of attributes with one query and pass them to the script.
Param( [Parameter(HelpMessage=„ASRDisplay(Splatting)“)] [hashtable] $object, … [Parameter(HelpMessage=„ASRDisplay(Alias=l)“)] [string] $location … ) $City = $object.location
The configuration of the query is done in the Parameter Values section. If “JSON object” was selected as the Value parameter, the attribute list can then be compiled.
For AD queries all AD attributes are allowed for the respective object. A minimal set is always applied as default. AD attributes can be determined with the AD attribute editor. It must be ensured that the names are correct.
When testing the query in the Admin App, a test result set is determined. By mouse-over the encoded JSON string, the individual attributes of the object can be resolved and displayed.
Parameter-driven AD and Azure queries
Queries on objects in Active Directory, in Azure AA or via MS / Azure Graph previously had to be configured in such a way that they deliver a predefined result set for each call, from which the user can select elements.
The goal of our further development of parameter-driven queries was to enable greater flexibility. It is now possible to address different result sets with one query (e.g. users/groups of different departments or locations). In combination with multi-attribute queries and the splatting feature, the variety and number of queries can be reduced significantly.
The new functions allow to control the queries with input parameters. The input parameters can be supplied either by manual input or by selection from a previous query. In addition, default values can be determined in the configuration, which allows a query to be used as both a fixed and flexible query.
Parameter-driven AD and Azure queries in ScriptRunner 2020R3
From a user perspective, parameter-driven queries behave like other input forms. Thus, the user fills the input parameters in the form of the action manually or by selecting them from the results of another query. The query starts and uses the inputs as input values for the search and returns a different result set depending on the input values.
Example: Exchange resources
It becomes obvious on a use case with resources (rooms and equipment) in Exchange. The use case is to enable the management of both types of resource types in one ScriptRunner action.
First a script is needed, which contains the necessary parameters and then also the logic. Here we limit ourselves to the parameters and the query.
The $Type parameter should be used as an input value in the query and should only accept the two values “room” and “equipment”. The $MailboxId and $Properties parameters are used to select the resource and set its properties.
In the configuration of the query “List of Exchange Resources” the settings “deactivated user” and the attribute filter “[msExchResourceDisplay]” are defined for the filter on Exchange resources in the Active Directory. In the Attribute value field the variable “%SRXQueryIn1%” is used. This is to control whether rooms or equipment will be available for selection in the result set.
In the action configuration, you can now define how the query is to be used. It can be used as a fixed query for rooms or equipment or flexibly for both cases. This is done by presetting the $Type parameter.
The query “List of Exchnage Resources” is now assigned to the parameter $MailboxId. In addition, the $Type parameter must be assigned to the %SRXQueryIn1% input parameter.
If the action is now run, the user first selects the resource type in the UI. After doing so, the parameter-driven query starts and can determine and display two different result sets in this example.
Improved Query Cache
The options for caching query results have been systematically expanded. The new caching mechanism primarily supports the handling of large dataset volumes and time-consuming queries. In particular, all types of scripted queries and multi-attribute queries on the AD and Azure AD benefit significantly from this.
The cached results allow portal users to search and quickly access up to 100,000 datasets with a very short interaction time. Both JSON objects and single parameters can be cached as a record.
Principle of the query cache in ScriptRunner 2020R3
To refresh the cache, two options are available as before: per-use automatic refresh or scheduled refresh.
Team Repositories for Scripts
If several admin teams work on one ScriptRunner instance, the role concept ensures that each team can only create, configure and use its own assets (credentials, targets, queries, actions). In addition, assets can also be available to all (public).
With script elements, this was different until now. These had to be manually assigned to the individual teams by a main administrator.
With version 2020R3 team repositories were introduced, in order to assign folders and scripts, which are synchronized and/or stored there, automatically to the respective team as owner.
So it is now also possible to sync to separate repositories from Git to the respective team’s repo.
ATTENTION: the root folders for the team repositories must be on the top level in the script library.
Multiple scripts can be assigned to a team via the Team Repository option
To set up the team folder function, the following steps must be taken in order:
- Create a root folder for the team repo as a subfolder of the script library root.
- Open Admin App (Delegation) or Portal (Authorize & Delegate)
- Activate Team Folder option and enter root folder name of team repository
Afterwards, new scripts can be added to this team repository, e.g. by synchronizing with a Git repository.
ATTENTION: if you use an existing folder with scripts as root folder, the ownership of these scripts will NOT be changed automatically to ensure that existing actions and configurations continue to work.
Please contact our support if you have any questions about switching to team repositories.
More Actions for End Users
With this release, licensing for end users has been expanded. Previously, only up to 10 assigned actions were available for each end user.
In order to cover requirements for more end user self-service, end user licenses are now also available in tiers for up to 20 and up to 30 actions per end-user.
Mixed operation is not possible, the extended license must be purchased for all end users. If the number of end users with more than 10 actions is limited, we recommend equipping these users with a help desk license as an alternative.
Advanced Support Function in the Portal
If the portal is used in the Main Administrator or Administrator role, you can contact our support directly in the portal. The version details of ScriptRunner will now be added automatically.
Setup without sample configuration
The unattended setup for ScriptRunner has been extended with the option to install without sample configuration. Thus, new installations and migrations of existing systems can be done without removing the samples for productive operation.
ScriptRunner’s PowerShell host now uses the TLS 1.2 setting by default. This is especially significant for older Windows Server variants to enable compatible connections to M365 and higher Windows Server versions.
When configuring roles in ScriptRunner, groups and accounts can now be found in multi-trusted-forrest constellations.
The restrictions to use a specific one of the Az module have been removed.
Changes in the synopsis and description of a script are now also updated in the UI
About the author:
Frank Kresse is Head of Product and CEO of ScriptRunner. As the inventor of the automation and delegation solution for PowerShell, he advises clients on use case scenarios and develops solutions for the automation and the digitalization of their processes. He is also involved in technology start-ups.
- Working efficiently with the PowerShell pipeline: A guide for administrators (1)
- Licensing with Microsoft Graph PowerShell
- ScriptRunner Ultimate Edition 6 – AI‑powered scripting
- How to connect to Exchange Online with certificate based authentication (CBA)
- Get-View in PowerCLI – How to manage your VMware infrastructure more efficiently (part 3)