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
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
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
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
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 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
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
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
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
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
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
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 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
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
Try Portal Edition R2 now
Discover the new features and benefits of automation and delegation with PowerShell!
Related links
Related posts
About the author:
Frank Kresse is Head of Product and CEO of ScriptRunner. As the inventor of the automation and delegation solution for PowerShell, he advises clients on use case scenarios and develops solutions for the automation and the digitalization of their processes. He is also involved in technology start-ups.