The new “Settings” module
The “Settings” module displays the status of the licenses and the settings made on the server for the connectors.
Multi-Attribute-Queries for Azure AD and AD
Queries serve to improve interactivity by creating a selection option for the users of PowerShell scripts. Thus, users in the Portal can access users, groups, resources or other lists generated by queries as a selection list or by search. For the selected object, only the display name and an attribute passed to a script parameter were previously available. If several attributes of the same object were used in the script, cascaded queries had to be used until now.
As of ScriptRunner 2020R3, multi-attribute queries can now be used. An AD, Azure AD MS/Azure Graph query can therefore determine a large number of attributes with one query and pass them to the script.
In ScriptRunner, attributes of the selected dataset are passed to the PowerShell process as an encoded JSON object. If a parameter of type [hashtable] has been defined in the script with the ScriptRunner splatting feature in the param block, the attribute values can be passed to the hashtable parameters in the main script. If a specific mapping of the attribute names from the JSON object to the parameter names of the hashtable is to be done, the ScriptRunner Alias feature can be used for this.
The parameters in the JSON object can be accessed in the following ways:
- via a PowerShell parameter that has the same name as the JSON parameter (automapping)
- via a PowerShell parameter that has an alias attribute for JSON parameters (alias mapping)
- directly by accessing the parameters of the hashtable
Thus, it is possible that the JSON object and the PowerShell hashtable contains, for instance, 10 parameters, but only 5 of them are to be processed as individual PowerShell parameters.
Mapping to PowerShell parameters also brings the advantage that these parameters can be modified, but the original values in the hashtable can be accessed at any time.
Param( [Parameter(HelpMessage=„ASRDisplay(Splatting)“)] [hashtable] $object, … [Parameter(HelpMessage=„ASRDisplay(Alias=l)“)] [string] $location … ) $City = $location $City = $Object.index
The configuration of the query is done in the Parameter Values section. If “JSON object” was selected as the Value parameter, the attribute list can then be compiled.
For AD queries all AD attributes are allowed for the respective object. A minimal set is always applied as default. AD attributes can be determined with the AD attribute editor. It must be ensured that the names are correct.
If Azure AD queries are used, the procedure is equivalent. The available attributes can be found in the Azure AD documentation.
When testing the query in the Admin App, a test result set is determined. By mouse-over the encoded JSON string, the individual attributes of the object can be resolved and displayed.
Parameter-driven AD and Azure queries
Queries on objects in Active Directory, in Azure AA or via MS / Azure Graph previously had to be configured in such a way that they deliver a predefined result set for each call, from which the user can select elements.
The goal of our further development of parameter-driven queries was to enable greater flexibility. It is now possible to address different result sets with one query (e.g. users/groups of different departments or locations). In combination with multi-attribute queries and the splatting feature, the variety and number of queries can be reduced significantly.
The new functions allow to control the queries with input parameters. The input parameters can be supplied either by manual input or by selection from a previous query. In addition, default values can be determined in the configuration, which allows a query to be used as both a fixed and flexible query.
From a user perspective, parameter-driven queries behave like other input forms. Thus, the user fills the input parameters in the form of the action manually or by selecting them from the results of another query. The query starts and uses the inputs as input values for the search and returns a different result set depending on the input values.
Example: Exchange resources
It becomes obvious on a use case with resources (rooms and equipment) in Exchange. The use case is to enable the management of both types of resource types in one ScriptRunner action.
First a script is needed, which contains the necessary parameters and then also the logic. Here we limit ourselves to the parameters and the query.
The $Type parameter should be used as an input value in the query and should only accept the two values “room” and “equipment”. The $MailboxId and $Properties parameters are used to select the resource and set its properties.
In the configuration of the query “List of Exchange Resources” the settings “deactivated user” and the attribute filter “[msExchResourceDisplay]” are defined for the filter on Exchange resources in the Active Directory. In the Attribute value field the variable “%SRXQueryIn1%” is used. This is to control whether rooms or equipment will be available for selection in the result set.
In the action configuration, you can now define how the query is to be used. It can be used as a fixed query for rooms or equipment or flexibly for both cases. This is done by presetting the $Type parameter.
The query “List of Exchnage Resources” is now assigned to the parameter $MailboxId. In addition, the $Type parameter must be assigned to the %SRXQueryIn1% input parameter.
If the action is now run, the user first selects the resource type in the UI. After doing so, the parameter-driven query starts and can determine and display two different result sets in this example.