A lot has changed under the hood of ScriptRunner. In particular, the comprehensive switch to 64-bit and support for Microsoft Cluster Service made corresponding changes on the server necessary:
Installation of the Binaries and the Web Apps in .Program FilesScriptRunner…
The self-service app for end users adds another directory to the Web Apps path and an additional virtual directory to the IIS.
Reorganization of the configuration data in .Program DataScriptRunner… to better support Microsoft Cluster Service
Reorganization of Registry Information in HKLMSoftwareScriptRunner
Re-naming of “AppSphere ScriptRunner Service” to “ScriptRunner Service
Update for the database schema in SQL Server
These changes mean special attention for the update from version 2018 to the new version 2019R1. So a snapshot of the VM before the update and a backup of the previous data are in .Program DataAppSphere… mandatory, since this update does not allow any return.
These changes have no influence on the general implementation and the order of the individual updates Service, Web App, Team Apps.
Customers who use the SQL Report/Audit Connector must also update the database schema in the SQL Server.
Support for Windows Server 2019
The new version of ScriptRunner now also supports deployment on Windows Server 2019, supporting the following configurations:
Windows Server 2019 with Desktop Experience
Windows Server 2019 Core withAppAppCompatibility Feature Set installed
The Feature Set can be downloaded and installed as a Feature on Demand package from the Microsoft site.
Extended role model for multi-team and multi-clients
The most significant change is the extended role model under the main menu item Delegation.
The role model was designed to automatically map all rights in ScriptRunner as they are needed for the respective user group.
It is now possible to implement significantly more application scenarios within and between IT teams right up to the end user.
Self-Service for End Users
This scenario extends the delegation capabilities from ScriptRunner to the end user.
Administrators can now define use cases and convert them into actions that are directly transferred to the end user. This makes it very easy to introduce individual self-services for end users. End users use the new self-service app to perform actions.
Multi-team application in larger IT organizations
The use of ScriptRunner in multiple IT teams with simultaneous separation of content was previously only possible by splitting it across multiple servers.
This form of division continues to make sense where regulatory requirements require separate instances to be set up.
With version 2019 R1, it is now also possible to perform a logical separation. This is the case if several admin teams want to use individual policy elements and actions in ScriptRunner both separately and together.
Multi-client application for Managed Service Providers (MSPs)
The extended role model makes it much easier to implement MSP models.
All policy elements and actions in ScriptRunner can now be assigned to different clients and the script repository can still be shared and supplemented with customer-specific scripts.
ScriptRunner admin groups, service desk groups and end user groups
New view of the policy elements in ScriptRunner
Actions consist of several policy elements: scripts, administrative accounts, target systems, and queries.
Both actions and other elements can now be from the PRIVATE USE or PUBLIC USE setting.
PRIVATE USE symbolizes the assignment to a specific admin team or client. All elements and actions that have been assigned can only be used by this admin team or client.
PUBLIC USE implements the common use of individual elements and actions.
PRIVATE USE beats PUBLIC USE. This means that elements that have been assigned to an admin team or client cannot be used in higher-level elements and actions that are PUBLIC USE. Conversely, PUBLIC USE elements can always be used as subordinate elements in PRIVATE USE elements.
DELETE GROUP leads to PUBLIC USE. If the group of an admin team or tenant is deleted in ScriptRunner, all elements associated with this group are reset to PUBLIC USE. The deletion of such a group is only possible by a main administrator.
A script should be usable for all and is therefore of type PUBLIC USE.
Therefore, actions of the type PRIVATE USE can also use this script. In this way, differently configured actions with the same script can be set up in different clients.
The Admin Team for Exchange stores its own administrative accounts for Exchange Server as target systems. These accounts can only be viewed and used by this team.
One action should be usable for all teams or clients. ALL elements used in the action must then be of type PUBLIC USE.
Implemented roles and permissions
The extended roles and permissions model in ScriptRunner now includes the following roles:
ScriptRunner Server Administrators.
They can interactively log on to the ScriptRunner Server and configure the operating system and the server settings themselves. ScriptRunner Server administrators do not need to have any other roles within the application.
ScriptRunner main administrators. These administrators have access to all PUBLIC and PRIVATE USE elements and actions in ScriptRunner. In particular, users in this role may create and assign new authorization groups for admin teams or clients, service desk, and end users as the only new authorization groups. You can now create several groups in this role.
ScriptRunner administrators (team or client). Users in this role have read access to all PUBLIC USE elements and actions, as well as unrestricted access to the elements and actions assigned to this group as PRIVATE USE. Scripts can be saved for sharing. You can delegate actions to service desk and self-service end users and other admin teams or clients.
ScriptRunner Service Desk users. Users in this role can perform delegated actions in parallel, view reports and display a variety of actions as tiles or lists in a structured way, set up favorites, search for actions, etc. Typical users are 1st, 2nd and 3rd level support as well as users in departments with more than 10 actions delegated to them.
ScriptRunner Self-Service End User. This role enables you to delegate up to 10 self-service actions directly to end users. They can execute the actions individually and receive interactive feedback. An action can only be restarted after the previous action has been completed.
New role selection in ScriptRunner
The roles are configured by assigning AD groups and/or AD user accounts.
Any number of groups can be created for all roles (except ScriptRunner Server Administrators). If a user is in several groups at the same time, he always has access to the sum of the elements.
IMPORTANT: When using the extended role model in conjunction with code management tools such as GIT or TFS, it is strongly recommended to separate the instances for the production environment and for a test environment.
ScriptRunner for End Users – the new Self-Service App
Delegated ScriptRunner Actions are ideal for implementing User Self-Service Cases.
The end users benefit from the graphical browser interface, the admins from the fact that they can program and adapt the Use Case perfectly for their own circumstances using PowerShell Script. As a result, the user receives exactly what he should receive and meets his requirements.
The Self-Service Web App is installed on the Web server with the Web Apps Setup and is available to all users in the Self-Service End User role. For administrators, the delegation takes place analogous to the previous procedure in the Admin App.
The default URL for calling the Web App is: http(s)://fqdn_scriptrunner_server/scriptrunner/selfservice and can be shortened for users by using aliases in the DNS. After the call, the app is loaded into the browser and started. The communication with the ScriptRunner Webservice takes place via the standard port 8091 (default).
ScriptRunner Self-Service App for end users
As already known from the Delegate App, the Self-Service App can be configured on the Web Server to connect to multiple ScriptRunner Server instances.
Compared to the Delegate Web App, the Self-Service App has reduced functions for end users.
These are the functions of the Self-Service App:
Tile display for up to ten actions delegated to the end user
Browser App with automatically generated input forms
Switch to input tab for more than seven input fields
Field to store the reason for execution; can be preset to mandatory for each action
Use queries for dynamic selection for parameter fields
Popup window for displaying processing progress and results of the action
Multilingualism of the app
Display of the internal support contact
Connection to several ScriptRunner Server instances possible
Branding in corporate design such as delegates App
Recommended browsers for the self-service app: Chrome, Firefox, Opera, Edge, IE11
Improvements for Service Desk
In the Delegate App, the renewal work from version 2018 R3 was continued.
The most conspicuous feature are the new symbols. The display of [switch] $Parameter has been completely renewed. The description of the parameter is now also used as a switch.
To facilitate the performance of the old rendering engine in IE 11, more than 12 actions are now displayed as a list in IE 11 by default. A manual change to the tile display is still possible.
For the operation of ScriptRunner in the Service Desk together with a ticket system, the new option to configure the description or cause field per action for a mandatory entry is particularly interesting.
More possibilities in the Dashboard – News in the Admin App
With version 2019 R1 the renewal and partial restructuring of the Admin App was also started.
For this purpose, hardly used features, such as the submenu, were removed and replaced by a more functional operation.
Additional Display Options and Reporting Filters in Dashboard
Now visible in the Admin App, the new and expanded icons are also visible in the Display Options in Dashboard.
The additional display options in the Diagram Panel:
Hide All Reports Resulting from Scripted Queries
Hide all Reports Resulting from Scheduled Actions
The combinable reporting filters in the dashboard have been functionally significantly enhanced.
All content filters now have the option of multiple selections. This means that you can now select according to reports of several actions, target systems or delegations. All these filters additionally have the possibility to be applied inverted, i.e. to filter out all reports that do NOT match the selection.
Global display filter
The global display filter introduced with version 2018R3 has been extended and supplemented.
The global tag filter now affects all elements directly in the dashboard.
The new element filter has an additive effect to the tag filter and allows to select the individual elements public or the respective group. This function is particularly useful for main administrators, but also for administrators who work in several teams or clients at the same time.
Global filter setting in ScriptRunner Admin App
All global filters are retained when switching between the main menus and the dashboard until another selection is made.
Local display filters
When a main menu has been selected, all elements of this menu appear in a list. All elements can be sorted in ascending and descending order by clicking on the respective column identifier. The full text search for the filtered elements is located in the header of the list field below the global filters.
List filter in ScriptRunner Admin App
In addition to the global filter options, some specific display filters for the displayed list (previously in the submenu) can now be used directly in the list view.
Local Help in the Admin App
The local help for administrators has been extended with the new functions.
At the same time, the direct help on the respective wizard pages was better marked.
The elements in the top bar of the admin app have been significantly reduced.
There are now only five elements left:
Display of Login
“About” with Display of Version Information
Direct Access to our Support Website
Direct Access to our Action Packs on GitHub
New Web Service Connector
To support the new roles via the ScriptRunner Web Service Interface via REST, the concept has been extended and the Connector for Web Services has been added.
There are now two working modes for different applications.
System or Application Backend
This working mode couples one source system per connector with ScriptRunner.
Source systems can be central monitoring systems or application servers, such as workflow systems. Individual service accounts or groups can be configured to authenticate the call on the ScriptRunner Server and to assign the actions.
A central PRTG monitoring is to be coupled with ScriptRunner for automation.
The source address of the calling monitoring system is entered in the connector and an account is set up under Delegation, which is used to authenticate the PRTG call. All actions that can be called by the monitoring are to be delegated to this account.
A central workflow backend is to be coupled with ScriptRunner for automation.
All users of the workflow should be allowed to start the defined actions in ScriptRunner. To do this, the source address of the calling workflow backend is entered in the connector and the group of administrators or of the client, the service desk or the end users that must authenticate themselves is set up under Delegation. All actions that can be called by the workflow must be delegated to this group.
Client application or computer directly
In this working mode, applications and computers can use the Web Service in ScriptRunner directly WITHOUT system or application backend.
The connector then accepts every source address. Only groups in the Self-Service End User role can be used to authenticate the call to the ScriptRunner Server and to assign the actions. The referenced AD groups can contain user accounts or machine accounts.
Example client application
The call is made in the user context. In the connector, the source address of the client is covered by the source address area. The user account that must be contained in a group in the Self-Service End User role is used for authentication. The action to be called by the client application must be delegated to this group.
Options for two scenarios with Web Service Connector
Example Computer direct
With a trigger a client machine should call an action in ScriptRunner directly.
The call should be made in the context of the computer. In the Connector, the source address of the client computer is covered by the source address area. The machine account from the AD that must be contained in a group in the Self-Service End User role is used for authentication. The action to be called from the client computer must be delegated to this group.
Further improvements and enhancements
In addition to the major features mentioned above, improvements and enhancements have been made in many areas.
Enhanced PowerShell Policies
For local target systems, the specific login mode can now also be configured for the RunAs mode to better support specific usage variants and requirements.
In “Logon as batch” mode, the assigned administrative account now also receives all elevated rights and thus corresponds to the behavior “Run as administrator …”. The administrative account needs the “Logon as batch”-privilege on the ScriptRunner Server.
The Cloud Service Target for AzureRM has been extended and can now be found as Azure Cloud Service in the selection of target systems. This element now supports AzureRM as well as Azure Az.
Select the options to connect to the Azure Cloud services
Time-controlled execution of actions is a common use case in ScriptRunner.
Therefore two requirements were integrated into the time control:
the multiple daily execution of an action e.g. 09:00, 13:00 and 21:00 the
execution on a certain day in the month, e.g. always on the 15th of a month in the
wizard for the properties of the scripts these and functions can be marked in scripts now explicitly as library and/or for the use in a query.
The function sets the corresponding system tags _LIB_ and _QUERY_.
Even More PowerShell
The enhancements also include some new PowerShell cmdlets in the ScriptRunnerSettings module.
Test-AsrUri is used to check the availability of the ScriptRunner Web Service EndpointsGet-AsrWinEvent
reads the ScriptRunner entries from the Windows Event LogThe
ScriptRunnerSettings PowerShell Module is now also supported with Get-Help.
c:> get-help -Namecmdletname -full displays the detailed help for this ScriptRunnerSettings command.
New PowerShell ISE App
The well-known PowerShell ISE app for ScriptRunner has been extended to the new role model. Users of the ISE app must either have the ScriptRunner main administrator role or the ScriptRunner administrator role (team or client).
Users in the role of ScriptRunner main administrator have full access to all scripts in the repository. You can check them out and in as well as create and upload new scripts.
Users in the role as ScriptRunner Administrator have read access to all scripts and can check scripts out and in as well as create and upload new scripts which are assigned to the groups in which they are a member or which are assigned to PUBLIC USE.
Irrespective of the role, a script for modification must be released for use in the ISE App. This activation takes place in the Admin App in the main menu “Scripts” and considers the role assignment of the user.
ScriptRunner main administrators can unlock all scripts for modification. ScriptRunner administrators can only unlock scripts for modification that are assigned to the respective group.
Extension in Password Server Connector
The options in Password Connector for Thycotic Secret Server have been extended to support environments with non-default URIs.
Customers will be informed by e-mail about the release of the new version and can download it as usual.