Fig. 1: The new Query Type Azure is now available for selection

To simplify usability for many use cases, the following options are available as templates:

• Azure User Query: Queries user objects of all types
• Azure Group Query: Queries group objects of all types
• Azure Group Members Query: Queries group members
• Azure Member of Query: Queries group memberships

The following can be used for customizable queries:

• Microsoft Graph Query
• Azure Resource Graph Query
• Azure Data Explorer Query

In the following, we will only consider the query for room selection. An Azure user query is used for this, which maps Exchange Online resources such as rooms as user objects. To control the query on room objects, a simple property filter on the Azure AD User Property DisplayName is used here.

Figure 2: Querying objects whose DisplayName contains ‘room’

Testing the query is done as usual. If “-JSON-” was selected as the Value parameter in the query, the result set will contain a list of rooms as JSON objects. The value of the JSON object can be displayed via mouse-over. Further use of the JSON object is done with the new Feature PowerShell Splatting (see section “PowerShell Splatting feature”).

Note: Azure AD queries are case-sensitive!

Fig. 3: Filtering Azure AD groups with the ‘mailEnabled’ property

The Azure Group Query returns a list of all groups (with filters if necessary, as in Fig. 3). As parameter Value, the Object-Ids of the groups are required, since this ID variably controls the subsequent query to resolve the group into members (Fig. 4).

Fig. 4: Cascadable Azure Query where first a group is selected and then its members are listed as choices

The Azure Query to resolve the group returns a list of the group members along with the members’ property sets as a JSON object (Fig. 5)

Fig. 5: The list of group members of their property sets are delivered as JSON object

The connection of both queries is done in the Action on the parameter page according to the already known scheme.

Fig. 6: In the form of the ScriptRunner Action, the query results are available as a selection

You can read more about Microsoft Graph and Azure resource queries in the blog post ScriptRunner, Azure and M365 – a perfect trio.

The portal replaces the ScriptRunner Delegate App and the ScriptRunner Self-Service App. Customers can install the new portal as part of the update to this release and switch users to the unified URL to access it.

The portal is divided into functional apps(Fig. 7) and supports logging in with Azure AD user accounts. If MFA is enabled, the second factor of authentication is also requested during login.

Fig. 7: Overview of the apps of the new ScriptRunner Portal in the Admin View

The entry into the portal as well as the available functions depend on the affiliation of a security group or an account to a ScriptRunner role.

Help desk and end users immediately start in the Run App. In addition, a help desk user has access to the Reports App.

Administrators have additional options in both of these apps. For example, the Action tiles can be directly customized in color and icon.

The new Statistics App (Fig. 8) makes it possible to make the benefits of ScriptRunner transparent.

Fig. 8: The new Statistics App in ScriptRunner Portal

You can read more information and details about the new portal in the blog post The new role-based ScriptRunner Portal.

This allows “invisible” contextual use of ScriptRunner automated tasks in other applications. Thus, a ScriptRunner Action can be placed in the intranet for end users directly in the place that is related to it in terms of content (Fig. 9).

The widget can be used to expand the functionality of existing self-service portals, to add new functions to business applications and to upgrade ITSM systems.

Because it is so easy to integrate, there are no limits to what you can do, including customizing the styling.

Fig. 9: Application example of the ScriptRunner Portal Widget

Further information and details on the new Portal Widget can be found in the bog article The new role-based ScriptRunner Portal or on the Portal Widget page.

Fig. 11: Live output of a connection test

In the test run, a remote session is established with the stored credential to the target system and $PSVersion of the target system is returned. The connection is then closed again. The results can be viewed at any time as a PowerShell report.

Additionally, a read-only attribute can be used for individual parameters of the hashtable. The following sample code shows the usage in the main Action script.

You can find further information on this feature in our Knowledge Base: Return multiple properties with a single Query.

The parameter attribute [Parameter(HelpMessage=”ASRDisplay(Splatting)”)] turns on the feature for the parameter [hashtable] $Address. This parameter $Address must be assigned the appropriate query in the Action configuration.

The other parameters in the hashtable itself define their structure. The parameter names must correspond to the names in the result set.
If an element is now selected from the result set in the UI (here “Peter Heim”), ScriptRunner automatically maps the values for the subsequent parameters.

With the parameter attribute [Parameter(HelpMessage=”ASRDisplay(Readonly)”)] the parameter [string] $Name is used in the UI as not changeable.

The [string] DateofBirth parameter is not given any values because it either does not exist in the result set or there is no name match for the parameter.