With ScriptRunner 2018R2 we have consistently continued the path we took in version 2018R1. The queries were functionally extended and the functionality improved in many details. We have also focused on improving usability. In addition, there are other functions such as script execution timeouts and a library of reusable function scripts.
Even more queries in ScriptRunner 2018R2
The enthusiastic feedback of our customers on the query functions has induced us to take up many of the constructive suggestions and immediately implement them in order to “round off” the entire topic block of queries.
The set of usage cases for AD queries has been extended to include attribute queries. These types of queries are suitable for automatically reading out individual AD attributes, such as department, phone, mail or user address. In combination with a previously executed OU and User query, you can select a user from a specific OU branch of the AD. You can then read other attributes of the user object. You can assign the values to script parameters and use them in the script or modify them in the displayed form.
Auto-Run for Queries
In addition to the interactive mode for starting queries, you can now also start queries automatically. This is especially advantageous if the number of expected results of a query will be less than 100 result entries.
You also benefit from the auto run with cascaded queries. For example, a user could select an AD group and then the query is started automatically to break down the group members. Or a user is selected and the cascaded attribute queries for the user object are executed automatically and the values are displayed in the form.
The Auto-Run function can also be used for script queries.
Credentials in Script Queries
Queries queries using PowerShell Script are a very effective way to perform a wide variety of queries and thus make the result list available to the user as a dropdown menu in the automatically generated form. For example, a list of all active VMs on a virtualization host can be generated via script. A user can then select the appropriate VM from the dropdown menu and run a script to increase the number of vCPUs or attach an ISO.
A query script is not necessarily executed on the same system as the actual work script. In the example above, the query script is to be executed on a Hyper-V host or ESX host and the work script is to be executed on the actual VM. In this context, it is possible that the rights context is different for both scripts. For this purpose, ScriptRunner now also supports queries for corresponding credentials. To do this, an input parameter of type [PSCredential] must be defined in the param-block of the query script.
param ( [PSCredential] $Cred ... )
The credential can then be assigned within the query configuration without the account and password having to be stored in the query script. The credential is introduced into the PowerShell process at runtime of the query script. This procedure significantly improves the security in handling account information and now corresponds to the procedure in actions.
Assigning a credential in a query script
Parameter references in queries with scripts
New parameters were added or the sequence changed in query scripts, so the query had to be recreated. This restriction was removed by a parameter reference function. Changes in the param-block of the query script are now automatically referenced in the query wizard, changes take effect immediately.
Editable forms with current values from a system
Everyone knows the challenge in change processes and tasks that one would like to show the user the value that the respective field already has in the system when filling out form fields. An example would be changing typical user properties.
Classical graphical administration tools per se have the possibility to display the values already. However, these tools are not suitable for performing tasks for service desks or end users securely and without administrative rights delegation.
PowerShell, in its native form, has the ability to output values across different Get cmdlets. However, the variant does not allow you to change the value interactively and then use it again as an input value.
The ScriptRunner Admin and Delegate App with the automatically generated input forms in the web browser are a graphical user interface for PowerShell. The new functions allow for the display of an editable form with existing values using Attribute Query, Auto Run, and generic mask generation enhancements. The displayed values can be changed or supplemented. By pressing the Run button they are used as input value for the script.
Input form with automatically queried actual values
The function of the mask shown above: After selecting the country organization, you can search for and select a user in this example. After the user has been selected, further attributes (here department, street, email) of his user object are automatically queried in the AD and entered into the mask. The user can now change or supplement the attributes. If the user wants to use the previous value, he can restore it by deleting the input data in the field.
The script then starts with these input parameters and changes the values in the AD.
This functionality is not only available for AD queries, but can also be used in conjunction with query scripts.
More overview in actions
With the increasing use of ScriptRunner for use cases with PowerShell in an environment, the number of configured actions and script policies continues to increase. In very long lists, the overview can quickly get lost. At the same time, changing or reconfiguring actions is no longer as easy as it is with only a few entries per list. In particular, the need to jump back and forth between the main menus for queries, target systems, etc. can hinder effective and simple configuration.
Global Tags for Filtered Selection
With this new function, the already proven tags can now be used for comprehensive filtering. The tag filter bar has therefore been removed from the list header. The full text search has been retained at list level.
If you assign “Exchange” to the global tag filter, all elements of the main menus “Actions”, “Queries”, “Targets”, “Scripts” and “Credentials” are filtered in the display. The filter is now retained when switching to another main menu and is no longer reset. The selected tags in the filter field now act as logical OR.
Global filter for all main menus of the Script Policy
The whole thing simplifies the handling of the various lists with many entries in the main menus and better represents the application context of the Script Policy components for you as administrator. However, it requires the consistent use of tags on all of these components, which you can do at any time.
To avoid jumping back and forth when configuring and testing actions and to simplify the process, a new view has been introduced. The Action Bar contains a new function “Details” for this purpose. If you select an action and apply the Detail button, the view for the action changes to the new tree-like detail view. Press the button again to return to the overview list.
Detailed view for an action for configuration and testing
The structure of the view also shows the dependencies of the individual components of a script policy and the use of their elements, such as credentials as script parameters, in a target system or query configuration. In the view, individual elements can be selected and their associated configuration wizard called with EDIT.
If you select the action yourself, all necessary functions are available in the Action Bar as usual.
Even more possibilities with actions
The functionality with ScriptRunner actions was also further expanded. You can now use two new PowerShell options.
Powershell Execution Timeout
This option controls the abort for longer running scripts, e.g. reporting scripts, if they threaten to run into an endless loop. In this way you define a default duration after which the execution of the script is to be aborted. The default is to take the average execution time of the action from the reports and add +25 to +50% to buffer for unforeseen load cases that are not due to PowerShell.
Library for function scripts
If you work a lot with scripts, you will notice after a while that there are script passages that you need more often. PowerShell provides functions for this. In order to be able to use functions in different actions and contexts, such scripts can be tagged with “_LIB_” in the ScriptRunner repository.
Afterwards your self-created function scripts (e.g. for connecting drives, connecting to shares, etc.) are available in ScriptRunner actions. You can assign multiple function scripts to an action.
New options: script execution timeout and function scripts
In the working script, i.e. in the main script of the action, you can now use the function calls as if the function were defined in the working script. Note that parameters used within the function have been assigned values at runtime. If these are variable parameters, e.g. the share name, this must either be fixed in the working script or declared as an input parameter for the action.
At runtime, all function scripts and the working script are loaded into the PowerShell execution process and are thus available as overall functionality.
https://www.scriptrunner.com/wp-content/uploads/2021/03/citrixactionpack.jpg441441Heiko Brenn, Head of International Businesshttps://www.scriptrunner.com/wp-content/uploads/2018/05/ScriptRunner_Logo_RGB-300x45.pngHeiko Brenn, Head of International Business2021-03-11 13:02:162021-03-11 14:46:04ScriptRunner ActionPack for CitrixScriptRunner Software GmbH
https://www.scriptrunner.com/wp-content/uploads/2021/03/sr-vorschau-produktjahr.png10001000Frank Kressehttps://www.scriptrunner.com/wp-content/uploads/2018/05/ScriptRunner_Logo_RGB-300x45.pngFrank Kresse2021-03-09 10:00:512021-03-26 15:44:12Preview of the product year 2021ScriptRunner Software GmbH