The first release on new platform technology is available! Following the successful launch with selected customers, the release is now also being made available for widespread use. The focus is primarily on trial users and new customers as well as customers who want to migrate to the new platform. 

Important note: The in-place upgrade of an existing ScriptRunner will only be supported as of the next release. If you want to upgrade your system, please contact our support.

This blog post summarizes the most important new features for single-node deployment.  

• Azure Marketplace deployment
• Setup and first steps for administrators
• New AI help system 
• New documentation versiones
• New licensing service
• Central data storage and database
• Node monitoring and maintenance
• Script management with integrated Git (local and remote)
• New team resources for password security and notifications
• Azure Key Vault as a central vault for confidential data (secrets)
• PnP PowerShell in the M365 target
• New query settings
• Transfer of parameters to a query via URL
• Parallel use of multiple IdM providers for user authentication 
   

Since this platform is accompanied by a number of changes and further developments for multi-node environments, these changes will be covered in the separate "News & Changes" series of articles in the blog over the next few weeks.

Features removed from ScriptRunner Enterprise

The new platform architecture also results in changes to previous features that have become obsolete and will no longer be supported.

• IIS web server support: The portal is exclusively deployed via the integrated web service.  
• SQL server connector: All reports are now stored in the ScriptRunner database. Separate external storage is no longer required. As the database structure has changed and also contains configuration data in version 7.0, data from the audit database can no longer be used. This connector is therefore obsolete. 
• Email inbound connector: The use of web service interfaces on many systems has made the former link via e-mail obsolete. The new platform uses the Rest-API to integrate with third-party systems.
• File-based script management: This has been replaced by Git-based script management (see below).
  
  

Discontinuation of ScriptRunner Portal Edition releases

The versions of ScriptRunner Portal Editions R1 to R5 have already been discontinued as of December 31, 2024. No further fixes or adjustments will be made for these versions. If known issues occur, they have already been fixed in subsequent versions. Ultimate Edition 6 will continue to be supported as the last release on the legacy platform. Customers who do not wish to migrate to the new platform should update Portal Edition R1 through R5 to the latest fix release of Ultimate Edition 6 (see release history).

If there are any previously unknown issues, they will only be fixed in releases of the new Platform Enterprise version 7.0 and later.  

Azure Marketplace deployment

The new deployment is suitable for quick testing of the new version, but also for productive use of ScriptRunner, especially if the automation and management of services and resources in Entra ID, Azure and Microsoft 365 are the main focus of the deployment. ScriptRunner is automatically implemented in the your own tenant in a separate resource group. After the Marketplace deployment, only a few configuration steps are required to complete the integration into your tenant. You can operate the software instance yourself or outsource this to us or to a partner (Azure Marketplace: click here for ScriptRunner, available as of June '24).

New PowerShell settings module

A new PowerShell module has been developed for the new Enterprise Version 7.0 software platform, which is based on the ScriptRunner API and has therefore been functionally extended. The module is also installed on the server during setup. In addition to many similar functions to the previous Settings module, there are many new cmdlets for new functions and settings.

The naming of the cmdlets has also been altered. They now start with Srx after the standard command Get/Set/... and more, e.g. Get-SrxLicense or Get-SrxAzureHome.

Display all commands of the new settings module in the Powershell console:

Get-command -module ScriptrunnerSettings -ShowCommandInfo

Show the complete help for a cmdlet from the Settings module:

Get-Help SrxAzureHome -Full

The Settings module is located in Drive:\Program Files\ScriptRunner\Services\Bin\PsModules\

Setup and commissioning for administrators

The ScriptRunner automation platform can still be operated using the company's in-house resources. With Enterprise Version 7.0, the system requirements have changed (see: system requirements). ScriptRunner Enterprise Version 7.0 requires Windows Server 2022 as the operating system as well as the .NET 8.0 Hosting Bundle (LTS) to be pre-installed. 

Setup note for missing .NET 8.0 Hosting Bundle 

ScriptRunner is delivered with two hosts including PowerShell 5.1 and PowerShell 7.4 (LTS). Which one you can use at run time depends on the availability of PowerShell modules from the vendor. The modules can be downloaded from the PowerShell Gallery and installed on the ScriptRunner server.

During setup, our new configuration examples can be installed. After installation, a large number of scripts and sample configurations for targets, queries and actions are available to quickly explore and demonstrate the scope of ScriptRunner's capabilities.

The new "Getting started" section provides an overview of the new configuration examples. This section is always shown during the trial period, and can be activated via the rocket item or the helpdesk menu on the top right when the software has been licensed. 

"Getting started" for new ScriptRunner users  

In addition to ready-to-use examples, the "Getting started" section also contains examples that first need to be customized to your own infrastructure, as well as several tutorial videos. For every sample action and its elements, you will find step-by-step instructions for the necessary customizations.  

Examples range from Active Directory, EntraID, and various M365 services to Azure, VMware, Hyper-V, and file systems.

New AI help system 

The previous context-sensitive help system has been replaced with an AI assistant (ScriptRunner AI co-pilot), available both in the product and in our documentation portal.

The AI assistant allows prompts or requests containing natural language and answers them with links to the sources in our documentation. Queries can be, for example:

• "What is an action?"
• "How do I configure a user query to EntraID?"
• "What are my input validation options?"
• "Can I validate my scripts at runtime?"
• "How do I configure a connection to Teams?"
• "How do I edit a script?"

Interactive help dialog with AI assistant

New documentation versions

The numerous changes to the platform have necessitated new versions of most of our user guides on our support page, where you find all of our documentation. The latest versions are displayed by default. All older versions can be selected from the version drop-down menu located above the table of contents in each guide. 

Selecting a version in the Portal Guide

New license service

License activation and distribution has been completely redesigned. Both the activation and distribution of licenses are now automated via a cloud platform. When the ScriptRunner team issues or renews licenses, this is automatically reported to the ScriptRunner Portal. After being confirmed by the main administrator, the licenses are applied. For ScriptRunner environments that run completely offline, including Portal access in a web browser, licenses can still be activated manually, either via the Portal or by using our PowerShell cmdlets.

Activating a license online

Our licensing model now includes a floating license concept for all user roles. This approach eliminates the need to release licenses of retired users manually. The policy automatically releases inactive Administrator and Help desk user licenses after 60 days and End user licenses after 90 days. Also, it is no longer necessary to reactivate accounts after a timeout of the same duration.

Centralized data storage

The data storage model for system data, configuration data, reports and statistics has been changed to a centralized database use. ScriptRunner 7.0 uses by default an SQLite database. 

The following variants are also available:

• SQL Server – single-node instances (either on-premises or on cloud environments)
• SQL Server – multi-node environments (either on-premises or on cloud environments)
• MongoDB Standard – single-node instances and multinode environments (either on-premises or on cloud environments)
• MongoDB Atlas – single-node instances and multi-node environments (on cloud environments)

Note: hybrid environments/a mix of on-premises and cloud environments is not recommended

You can only use one database at a time. Backing up and restoring the contained data are your own responsibility. ScriptRunner does not provide backups. 

The settings for the database are made using the Set-SrxPersistence PowerShell cmdlet. Data can be migrated with the Move-SrxPersistence cmdlet.

Regardless of where the data is stored, the system and engine log files are still written to the file system of the respective node. 

Node monitoring 

Node monitoring is new to ScriptRunner and allows you to monitor the individual nodes of a ScriptRunner environment. It consists of a status display and an event display per node. For a quick overview of the nodes in your environment, click "Monitoring" > "Nodes". The overview displays all available nodes each on an individual tile. Each tile shows the software version installed on the node, the current node status, the current statuses of the connected resources, such as the password server or the Git repository, and the most recent events. The node being the license service node has a key icon next to the software version.

Overview tab of a node 

The node event log provides information about errors, warnings, and information.

Detailed view of node monitoring events 

Manage scripts with built-in Git – locally and remotely

The previous management of scripts directly on the file system of the ScriptRunner server has been replaced by the use of a built-in Git mechanism. This mechanism now allows to manage, edit and use scripts in a modern way.

The managed scripts can be accessed in the Portal, via Visual Studio Code with our ScriptRunner Enterprise for VS Code extension using the ScriptRunner API, as well as via Visual Studio Code directly with your preferred Git server. (Visual Studio Marketplace: ScriptRunner Enterprise for VS Code).

Concept of Git-managed script sources 

Git-managed script sources are the organizational core of script management in ScriptRunner. All script sources are represented in Git-managed folders in a node's file system. There are two types of script sources: local script sources and remote script sources. 

Local script sources exist only on the node where they have been created. They are managed locally by Git and should only be used in single-node environments. Synchronization between nodes is not possible. The scripts are accessed via the Portal or via Visual Studio Code with the ScriptRunner Enterprise for VS Code extension. 

Remote script sources are connected to repositories on a Git server. This type of script source can be used in both single-node and multi-node environments. In single-node environments, it can also be combined with local script sources. In multi-node environments, remote script sources are mandatory to ensure proper synchronization and failover in case of errors. 

Regardless of which of the aforementioned ways is used to make changes to scripts contained in a remote script source, the scripts are always synchronized via the central repository on the Git server so that all connected nodes are up to date at all times. If a remote script source is removed in ScriptRunner, only the connection to the Git server and the associated scripts in ScriptRunner are deleted. The content in the repository on the Git server will remain. 

Remote Git repository for the Azure administration team 

This change is quite interesting when ScriptRunner is used in multi-team mode. Each access group of the Administrators role, i.e. a team, can be assigned one or more script sources. The script sources can be connected to various remote repositories on Git servers or to local folders on the ScriptRunner node. All scripts in a team repository are automatically assigned the ownership of the team. It is not possible to assign multiple owners to scripts of a single repository. 

New team settings for password vaults and email notifications 

The use of centralized password services to better protect passwords and manage password access is on the rise in organizations. ScriptRunner now supports different security scenarios when using password services. 

In the simplest scenario, ScriptRunner is only configured in the role of the main administrator. In this case, access to the password server is stored in ScriptRunner. For all password vaults that ScriptRunner is supposed to use, the access to the password server is given the corresponding permissions, usually read permissions only.

For more complex scenarios in which differentiated access is required, you can create several access groups of the Administrator role, i.e. teams. Each team can create and manage its own resources only. This applies to the configuration elements scripts, targets, queries and actions, and now also to access their own password vault. This makes it possible to assign each team its own password safe on a central password server. 

New settings for each administration team 

Sending email notifications through a single mailbox is often not practical in large, global IT organizations. With the new email notification setting, a pre-created credential containing an email address with a password can be selected. At runtime, it represents the setting to send notification emails to that very mailbox. Each team can now define its own mailbox for this purpose.

Azure Key Vault as a central vault for secrets

Azure Key Vault is a service for the secure storage of secrets. ScriptRunner now supports storing secrets in Azure Key Vault and using them as an alternative to the local Windows credential store of Windows Server, which is only useful in single-node environments. 

Creating an Azure Key Vault secret in the Portal 

Modifying an Azure Key Vault crendential

To use Azure Key Vault, the ScriptRunner service must be registered with Azure and the Azure home tenant settings must be configured in ScriptRunner.  An Azure Key Vault can then be created and connected directly using the New-SrxAzureHomeVault cmdlet.

Encrypted credentials in the Azure Key Vault 

ScriptRunner does not enter secrets with a human-readable name, but rather as a reference ID. This ensures that ScriptRunner secrets in the vault are clearly distinguished from other entries and that it is not possible to identify them easily.

PnP PowerShell service in the M365 target

PnP PowerShell is a cross-platform PowerShell module with more than 650 cmdlets that work with Microsoft 365 environments and products such as SharePoint Online, Microsoft Teams, Microsoft Planner, Microsoft Flow, and more. It runs on Windows, Linux, and MacOS (learn more about PnP PowerShell here).

With a new service available in the ‘Microsoft 365 & Azure’ target type,  you can now take full advantage of PnP PowerShell. To do this, install the appropriate PnP PowerShell module on the ScriptRunner server in the global machine context, create an appropriate service principal in Entra ID (or use an existing one), and then add and configure the PnP PowerShell service in an M365 target.

PnP PowerShell target in ScriptRunner

New settings for queries

Queries are a powerful feature for designing user-friendly actions with various selection options. Technically, a data query to a directory or third-party system is performed either via REST or by processing a script, list, or file. The result set of a query can consist of simple strings as well as complex JSON structures. When a query is linked to an action, users are displayed a drop-down menu that contains the display values of the returned results. See our Coding Guide for more information on queries. 

To limit the number of records that immediately appear in a drop-down menu, you can now limit the number of entries that are instantly available in the query settings. This removes the previous limit of 500 records. 

Customized count of entries and timeout settings for queries

Particularly queries to a system or data source using PowerShell scripts (i.e. script queries) can take longer if the entries are not loaded from the cache but are determined in real time. To avoid excessively long query times, for example, because of high system load on the data source, you can now set a timeout for the query operation.

We generally recommended executing these script queries with PowerShell scripts in Cached mode or to use an alternative query that queries Active Directory, Entra ID or Azure resources directly.  

Passing parameters to a query via a Portal URL

Actions and queries are typically called through either the Portal or the Portal widget. Third-party systems such as ITSM, workflow, IdM or monitoring for seamless end-to-end automation cannot use this method. Therefore, ScriptRunner also offers the option to call actions via URL. 

The URL can be used to transfer values to the Portal.  

"https://mycorp/scriptrunner/portal/#/actions/37?username=John%20Smith", for example, calls the action with ID 37 in the Run section of the Portal and prepopulates the field $Username with the value 'John Smith'. 

Prepopulated form field via Portal URL

This option was previously only available for fields that had no queries assigned to them. In this release, input for an interactive query search can be transferred via the URL as well. 

In the example above, the $Username parameter in the action configuration is now assigned a query to search for accounts in Active Directory. With the URL "https://mycorp/scriptrunner/portal/#/actions/37?qry_username=John", the search field of the query is assigned the value 'John' and automatically executed. All records containing 'John' in the username are determined and displayed in the drop-down menu. 

Query search field with value 'John' 

With this solution, it is now possible to fully populate an input form to execute an action via a URL sent from an external system and have the queries executed automatically.  

An example for this could be a ticket in an ITSM system whose fields are transferred to a ScriptRunner action via a link behind a button. The action opens in the browser, the help desk employee checks the automatically transferred entries and starts the action. This is a frontend-to-frontend connection that can be implemented quickly and easily. Alternatively, our Web Service connector is available for a fully automated end-to-end connection.  

Parallel use of multiple IdM providers for user authentication

With the new ScriptRunner release, it is now possible to use multiple mechanisms for user authentication in parallel. This is particularly helpful when migrating between and to different IdM providers. For example, if some users are still authenticated via Active Directory and others are already authenticated via Entra ID, or when an overarching IdM such as Okta is introduced and user authentication is gradually migrated.

The IdM connections are configured through ScriptRunner cmdlets and through appropriate settings and groups in the IdM systems.  

Outlook on version 7.1

Version 7.1 of ScriptRunner Enterprise will also include new features and a number of improvements. The most important new features will be:

• Actions: Run an action at a user-configurable time.
• Actions: Authorize the execution of an action by one or more other users.
• Actions: New calendar view for better overview, creation and monitoring of scheduled tasks.
• Reports: Automatic anonymization and deletion of reports after a configurable period of time to improve compliance and data protection.
• Compliance: Track and trace configuration changes in ScriptRunner for control and audit purposes.

Our roadmap (here) provides an overview.  

Related links

• ScriptRunner Release Guide for Enterprise Version 7.0
• ScriptRunner roadmap
• System requirements
• .NET 8.0 Hosting Bundle (LTS)
• Microsoft Azure Key Vault
• "Input with Queries"  – article in the Coding Guide
• Azure Marketplace: click here for ScriptRunner, available as of June '24
• Link to Visual Studio Marketplace  –  ScriptRunner Enterprise for VS Code