ScriptRunner Version 2019R2: PowerShell scripting for teams with self-service

• Author
• Recent Posts

Graham Beer

Graham is an experienced system engineer with a passion for PowerShell and automation. You can follow his blog or reach him on Twitter at @GKBeer.

Latest posts by Graham Beer (see all)

• How to create and use Adaptive Cards - Thu, Oct 5 2023
• Using AWS Lambda functions with Docker containers - Fri, May 12 2023
• A Go AWS SDK example - Fri, Nov 11 2022

ScriptRunner was a product I had heard much about, but had not yet used. The application was first created back in 2013 and has been gradually gaining traction ever since. In the past 18 months, it has grown into a viable product for companies. When you open the ScriptRunner admin app, its clean, slick design is the first indication of why it is popular.

Taking advantage of one of the new features, Support for Windows Server 2019, you can install ScriptRunner. You can now download the application without having to participate in a live demo first. It is expected, though, that you fill out a form before you are given a download link to a 30-day trial evaluation. I won't go into further detail on the install itself, as Timothy described this in his article. There is also a guide provided by ScriptRunner.

ScriptRunner admin console

When you first open the ScriptRunner admin app, you are presented with a dashboard and some menu options on the left side:

ScriptRunner menu options

Here is a summary of each of these options:

1. Actions – Schedule your script and add mail alerts with the selected targets.
2. Queries – Performs a query. This includes querying a system, a cloud service, Active Directory, and more.
3. Targets – Your servers and cloud tenants (Office 365 and Azure).
4. Credentials – Service accounts and permissions to run tasks are stored here.
5. Scripts|Cmdlets – Your script library.
6. Delegation – Active Directory groups to allow delegation of tasks.
7. Automation – Triggered on incoming email or REST.

What's new or updated?

There have been some changes to the underlying engine. Most notably, it has switched to 64-bit architecture. In addition, a self-service feature has been added, which creates another directory to the Web Apps path and an additional virtual directory to the IIS.

Administrators can now define use cases with actions to create and delegate to end users, which enables Self-Service. When you create a new delegation, you will notice the Self-Service End Users role.

The Self Service End Users role

A graphical user interface is available to end users, who can log onto this self-service web page to view assigned actions. The ScriptRunner Admin can delegate any action case to meet the user's requirements.

As the web service is installed on the server, all users with the Self-Service End User role have access the URL http(s)://fqdn_scriptrunner_server/scriptrunner/selfservice, and from there, to desktops without the need for additional software. This makes the feature a light, easy way to get users up and running quickly with little fuss.

Self service web app

Providing self-service to your users empowers them to begin resolving their own issues, which can ease the workload for your busy Service Desk Analysts. This is certainly a welcome feature for companies.

You can now set actions and other elements in ScriptRunner for PRIVATE USE or PUBLIC USE. To use the PRIVATE setting, create an Admin Team with the use of the Administrators (Team) role under Delegation.

Add a name for your team and choose a team color.

Group or account properties for a team

 As with all groups and accounts in ScriptRunner, you need to have an Active Directory group available to assign. To assign users to roles, groups, etc., simply add the user to the corresponding Active Directory group. Elements and actions that have been assigned can only be used by members of the group. PRIVATE USE overrules PUBLIC USE. So any elements that have been assigned to a private admin team can't be used for PUBLIC USE. PUBLIC USE elements can, however, be attached to PRIVATE USE elements.

Multi-team and client scenarios also see improvements. Previously, if you wanted use ScriptRunner across different IT teams without sharing content, you needed several servers. Extra server licensing costs and added support for these additional servers made this an expensive feature to pursue. Now you can use individual policy elements and actions without the need of extra servers. Version 2019R1 allows for this logical separation.

Managed service providers (MSP) are an option many companies utilize today. The ability to implement models for MSPs can be a useful addition, which ScriptRunner now offers. In addition, ScriptRunner can now assign policy elements and actions to different clients. Even the script repository can include customer scripts and be shared.

Dashboard enhancements

Let's take a look at the aesthetics of the ScriptRunner tool and the changes made in this update.

Two new display options are available from the dashboard screen. These are:

1. Hide All Reports Resulting from Scripted Queries
2. Hide All Reports Resulting from Scheduled Actions

New reporting filters in the dashboard

All the filters on the dashboard support multiple selections, giving you the flexibility to select actions, target systems, or delegation reports. So you can filter out all reports that do not match your criteria.

This version also provides global display filtering, which is another feature to be extended. Global tag filtering now influences all elements in the dashboard.

At first glance, the global filter display feature appears to be inactive since it is shaded.

Global filters before activation

Once I clicked in the area, however, it did become active and I could choose from the list of tags that were set as well as elements that were either public or part of the respective group.

Global filters in ScriptRunner

Global tag filtering can be a useful addition to main administrators as well as admins who work on more than one team/client.

In addition to a global filter, local display filters are also available. A local filter takes free text to filter out your results.

Using local filters

Conclusion

ScriptRunner has added some great new features to an already capable tool. It's a growing product which is now becoming a well-established corporate tool. Documentation for many areas needs improvement on the main website to allow newcomers a quicker path to get started.

It would be also be good to see ScriptRunner adopt PowerShell Core with the imminent arrival of version 7 for general availability. This would also enable developing a Linux installation, since Microsoft is making applications available for this platform. Joining Office 365 on Linux, Teams has now been announced as cross-platform.

But these are small wishes to make a good product even better. More features are available that I have not covered, so take a look at the What's New section on the site.