Try Now

ScriptRunner Portal Edition R2

Table of Contents

Post Featured Image

Portal Edition R2 is the second release in a series that focuses on the role-based portal.

With Release 2, previous features in the Portal are improved and another new Portal App for monitoring ScriptRunner servers is introduced and made available in the browser for the first time:


  • new Portal App "Monitor"
  • monitor script execution on all servers
  • display running scripts and show them in their PowerShell output
  • quick filter on different executions of scripts (scheduled, scripted queries,  etc.)
  • graphical display of the load situation on the individual servers
  • separate display of pending script processing in the queue
  • cancel running script processing in the Monitor
  • multi-server support for Run App and Reporting App
  • transparent display and execution of actions from different servers (all roles)
  • transparent access to reports from different servers (all roles)

Additional features in Release 2 include:

  • integrated online & offline help in the portal
  • limit parallel execution of scripts on all targets
  • deleting scripts in the Portal App Scripts
  • hide action list in input mode
  • setting the default language for the portal during the initial call
  • integrated trial guide during the test phase
  • fixes and enhancements (Release Guide here)

  



The New Monitor App

With this release, the ScriptRunner Portal App for Monitoring is delivered for the first time.

Application Szenarios

The following application scenarios are foreseen for the Monitor App:

  • individual monitoring of server activity as part of daily activities
  • monitoring of server activities as a control center via a separate screen 

Both types of use require the "Main Administrator" role.

 

Functions and Added Value

The Monitor App provides the following functions:

  • monitoring a configurable list of ScriptRunner servers
  • overview of all running script processing per server
  • display of the total running script processing
  • display of the maximum capacity of parallel script processing per server
  • display of running script processing per server
  • display of pending script processing per server
  • display of just finished script processing per server
  • switching to the output of the respective script processing
  • cancel running script processing 

 Functional principle of the ScriptRunner Portal App for Script Monitoring
Functional principle of the ScriptRunner Portal App for Script Monitoring

 

The Monitor App helps administrators and teams to:

  • monitor script processing on all ScriptRunner servers in one central location
  • be able to assess the processing capacity of each individual server
  • check the respective sizing of the servers and to be able to adjust in time
  • check, plan, and adjust the distribution of script processing resources
  • identify and respond to bottlenecks in script processing resources
  • be able to quickly get insight into running script processing

The Components of the Monitor App

Within the Monitor App, there are different functional areas for quick orientation.

  • header block with display filters
  • live output for a selected script processing
  • list of script processing
  • overview of running  script processing per server

Header Block

The left tile displays the total number of script processing across all servers. In the middle chart, the running script processing (orange) and pending script processing in the queue (blue) are differentiated by color for each server. The scale shows the number of processing engines on the server. The server with the highest number of engines determines the scaling. By default, 10 engines are provided on the server for parallel script processing. On the right side there are buttons for the filters.

Workload 

When evaluating pending processing in the queue (blue in the chart) on the respective server, the following settings must be taken into account:

  • Number of maximum available processing engines. If more parallel requests occur permanently, the number of  engines  on the affected server can be increased by using the Set-AsrSettings cmdlet. 
  • Limiting parallel session accesses to the target system. If more connections are to be established in parallel than are allowed at the target settings, the requests are placed in the queue.
  • Limiting parallel executions of an action or scripts. If more than the allowed number of requests are to be executed in parallel, they will be placed in the queue.
 
Note: So script processing can already be set as pending, although engine resources are still available.


Overview and filter both, running scripts and server load
Overview and filter both, running scripts and server load

Display Filter

The display of which script processings are shown can be set with the filter buttons in the upper right corner of the header block. By default, all script processing without queue and without scripted queries are displayed. The badges on the filter buttons indicate the amount of processing that is running, the amount scheduled, the ones waiting in the queue, and how many scripted queries are being processed.

Queued ON/OFF

Queued script processing waiting for execution is displayed/not displayed.

Scheduled ON/OFF

Processing of scheduled actions and scripted queries (for queries ON) is displayed/not displayed.

Queries ON/OFF

Processing of scripted queries is displayed/not displayed.

Server Selection

If only one or a selection of servers are to be monitored at a time, these can be specified in the server selection.

 

List of Script Processing and Live Output

Depending on the filters set, the following script processing is displayed in a list view:

  • top light blue: pending script processing
  • center orange: currently running script processing
  • bottom black with flag: aborted script processing
  • bottom black: 10 most recently finished script processing 

Note: After switching to another Portal App and returning, the current status is reloaded.  

List view and live output of current and pending script processing operations

List view and live output of current and pending script processing operations

If a running or just finished script processing is clicked, the live output of this action opens. You can freely switch back and forth between the processings.

A running script processing can be aborted in the header of the live output.

 

Successful termination of the selected script processing

Successful termination of the selected script processing

 

Configuration of the Monitored Servers

The configuration of the servers to be monitored is done in the configuration file App.Json in the portal directory on the server. The base URI corresponds to the master server from which the portal is loaded, and the data is used for the other Portal Apps, e.g. Script App.

Depending on the use case for individual monitoring or the design of the control center, the ScriptRunner servers are stored in the "monitoringServer" section. Note that, when using load balancers, the corresponding entries in the App.Json must be made on each server.

In the example, there are two servers to be monitored, each with a specific purpose. "Host 1", the first server, hosts all actions that are used interactively by service desk employees and end users in the portal, "Host 2", the other server, is responsible for all scheduled actions.

"monitoringServer": [
{
"displayName": "Host 1",
"identifier": "host1",
"path": "https://serverA.myorg.local:8091/scriptrunner"
},
{
"displayName": "Host 2",
"identifier": "host2",
"path": "https://serverB.myorg.local:8091/scriptrunner"
}

….
],

When the Portal is opened, the connections for the servers to be monitored are checked. If a ScriptRunner server is not reachable, a corresponding error message is displayed, and the connection is deactivated for the duration of the browser session. If a connection fails for a short time during monitoring, a reconnect is performed.


Error message if a ScriptRunner server is not reachable when starting the portalt

Error message if a ScriptRunner server is not reachable when starting the portal

Multi-Server Support for Run & Reports

The portal architecture has been enhanced with capabilities for parallel addressing of ScriptRunner servers. This enhancement focuses on running actions on different servers and viewing reports. This enables transparent use of the portal, especially for help desks and end users. In the Run App, all delegated actions are displayed to the portal user, no matter on which ScriptRunner server it has been configured and is being processed after startup.

Functional principle of ScriptRunner Portal App Run for multi-server
Functional principle of ScriptRunner Portal App Run for multi-server

 

The configuration of the servers to be included is done in the configuration file App.Json in the Portal directory on the server. The base URI corresponds to the master server from which the portal is loaded, and the data is used for the other portal apps, e.g. Script App.

The corresponding servers are stored in the "executionServer" section. When using load balancers, note that the corresponding entries in the App.Json must be made on each server.

"executionServer": [
{
"displayName": "Server Team A",
"identifier": "server_a",
"path": "https://serverA.myorg.local:8091/scriptrunner"
},
{
"displayName": "Server Team B",
"identifier": "server_b",
"path": "https://serverB.myorg.local:8091/scriptrunner"
},
{
"displayName": "Server Special C",
"identifier": "server_c",
"path": "https://serverC.myorg.local:8091/scriptrunner"
}
],

 

Error message when disconnecting from a ScriptRunner server

Error message when disconnecting from a ScriptRunner server


When the user starts the portal, the connections to the stored servers are now checked. If a ScriptRunner server is not available, a corresponding error message is displayed and the connection is deactivated for the duration of the browser session. If a connection fails for a short time during Portal use, a reconnect is performed.

Access only to delegated actions even with multiserver access

Access only to delegated actions even with multiserver access

If a portal user switches to the Run App, all actions to which he has authorized access are now displayed, no matter on which server the action resides. The same applies to the display of report results. In the example above, from three different servers (represented by the colors).

Integrated Online & Offline Help

The Portal Edition R2 is the first version to be equipped with the new integrated and context-sensitive online help. Changes and extensions to the help content are thus always available to users immediately after publication on our systems. The expansion of our help is being consistently driven forward.

Access to the integrated context-sensitive help at any time

Access to the integrated context-sensitive help at any time

Depending on the app context, Portal Guide content is displayed on our support page. Help is accessed via the Help button in the Portal header. For this purpose, a panel is displayed on the right side and the mobile view of the respective section is displayed. The connection to the content is established directly from the portal in the user's browser to the online source, i.e. it does not depend on whether ScriptRunner Server itself being able to connect to the Internet.

For the use of the Portal in sensitive security areas without Internet access, an offline help is available as a PDF.

Limiting Parallel Script Execution at the Target

In the existing action settings in the Admin App, the parallel execution of actions on the server can be limited. If, for example, the limit is set to 5, each further start of this action is placed in a queue. If one of the already running executions has been terminated, the next action from the queue is processed. This mechanism allows you to better control executions and the load on resources on ScriptRunner Server.

Limiting actions that can be executed in parallel on the server

Limiting actions that can be executed in parallel on the server

The purely action-related limitation has been supplemented in this release by the limitation on the target as a whole. Thus, the processing processes per target can now also be better restricted. This is particularly important for remote connections where there are only a limited number of PowerShell endpoints. For example, Microsoft's parallel PowerShell access to Azure and M365 services is limited. If the limit is exceeded without control with Queuing, the automated script execution leads to an error and termination.

With ScriptRunner Server, correct session set-up and dismantling is now ensured. Likewise, control and queuing of the scripts to be executed up to the maximum number of available or configured connections is warranted.

 

Deleting Scripts from the Script Repo

A delete function has been added to the Portal App for scripts. Depending on the role and the ScriptEditMode set on ScriptRunner Server, the following options are available:

ON (default): This setting allows all administrators to delete scripts in the ScriptRunner Portal.

OFF: The functions of the script editor are completely disabled. The code of the scripts is not displayed. The scripts cannot be deleted.

ViewOnly: The functions of the script editor are turned off, but the code of the scripts can be viewed. The scripts cannot be deleted. This setting is recommended for sync with a Git repository if the server is not designed for fast prototyping directly on the server.

Restricted: The functions of the script editor are limited to the system directory _Upload_ on ScriptRunner Server. This setting is recommended for fast script prototyping. The scripts in this directory can be deleted. This setting is recommended for syncing with a Git repository.

Further information about the Script App can be found here.

 

Deleting scripts directly from ScriptRunner

Deleting scripts directly from ScriptRunner

Before the actual deletion, a list of actions and queries is displayed in which the script is used. If the script is deleted anyway, ScriptRunner Server detects the missing references and marks the actions and queries as incorrect, and it does not execute them anymore.

Attention: the scripts are deleted from the repo on the disc at file level.

Hide the Action List in Input Mode

After selecting an action in the Run app, the input mask for this action appears. On the left, all other actions to which the portal user is entitled are displayed in a list panel.
To provide better orientation for the fields on the input mask, the list panel with the other actions can be closed and re-opened with a button. The setting is saved in the browser.

close and re-open       close and re-open

close and re-open the list

Default-Language when Launching the Portal

Administrators can now set a specific language setting for the first time the portal is launched, after which users can change it themselves if necessary.

The default setting can be made in the Main Administrator role in the Settings App

Setting a portal-wide default language directly from the Settings App

Setting a portal-wide default language directly from the Settings App


Integrated Trial Guide during Test Phase

In order to better support the free test phase for ScriptRunner, the Trial Guide on our Support Portal has been revised and integrated into Portal Home. It will be displayed as long as the product has not been licensed yet.

Direct access to the trial guide on ScriptRunner Portal Home

Direct access to the trial guide on ScriptRunner Portal Home


 

Portal Edition R2 Monitor AppTry Portal Edition R2 now

Discover the new features and benefits of automation and delegation with PowerShell!

Get your free trial

 


 

Related Links



About the author: