Ivanti Automation powered by RES
In any Ivanti Automation environment, there will be Tasks that are used many times over, with just minor changes to their configuration. For example, you may have configured a Task Create Local User. Each time you use this Task to create a new local user, the only thing that differs from the last time is the user name. Of course, you could manually adjust the values in the Task each time you use it, but it is much more efficient to parameterize these values. In Ivanti Automation, parameters function as placeholders for values in various fields, such as text, file paths, credentials, etc. The actual values of these fields can be provided when they are needed. This makes it possible to create generic Modules, Projects and Run Books that can be customized to each situation when required.
For example, if you want to create a new local user Amanda Cavendish, you could create a Task that looks like this:
The next day, if you need to create the local user John Smith, you could of course edit the original Module, save it, and schedule it in a Job. And do the same again the next time you need to create a local user, and so on. However, it is more efficient to use parameters in the Task:
Now, when you need to create a new local user, you simply schedule the Module in a Job. Ivanti Automation will then prompt you to provide the logon name, full name and password of the local user that should be created: it is no longer necessary to edit the Module first.
Generic Modules, Projects and Run Books are also very useful for system integration purposes: If you create Building Blocks to transport Modules, Projects and Run Books from one Ivanti Automation environment to another, the configuration of some Tasks may need to be changed to the new environment. This can be achieved efficiently using parameters.
For example, if you create a Building Block of a Task that creates an Active Directory user, many values need to be changed for the receiving environment. This can be set up efficiently by replacing the values in the Tasks with parameters. Then, each time the Building Block is imported in a different environment, Ivanti Automation will prompt for new parameter values:
With parameters you can:
- Allow parts of a Task to be customized when it is actually used. For example, in a Task Local User, most settings that are used to create local users can remain the same, but each time the Task is scheduled a different user name needs to be specified. This makes it possible to create generic Modules, Projects and Run Books that can be customized at the moment of use or when imported as a Building Block.
- Allow users with a specific administrative role to schedule Jobs and customize some fields, but prevent them from changing the standard configured fields.
- Restrict the type of input provided at the moment of use. For example, with a List parameter, you can present a list of values from which to choose, making it impossible to enter other data in that field. As a result, you can control the kind of information that is used in a Task. See
- Provide default values for parameters, with the option to overrule these defaults at the moment of use.
- Use the same information in various Modules of a Project or Run Book. For example, a Project can contain 4 Modules that all require the same user name to be filled out. By inserting linked parameters in those user name fields, input will be requested once and will fill all fields. See
- Use a parameter as the basis for a condition, so that the value of the parameter determines whether a Modules, Projects or Run Books should be executed. For example, you can configure a condition so that a Module is skipped if the person scheduling it does not provide the correct value for a Password parameter.
You can configure parameters on three levels:
- With Module parameters, you can parameterize values in Tasks.
- With Project parameters, you can link Module parameters from various Modules in a Project.
- With Run Book parameters, you can link Module parameters and/or Project parameters from various Modules and/or Projects in a Run Book.
- Parameters can be renamed. For example, this makes it easier to correct earlier mistakes or changes in naming conventions. When renaming parameters, linked parameters may become unlinked. This may lead to unexpected results when executing Modules, Projects or Run Books in which they are used:
- If you rename a Module parameter that is linked to a Project parameter, the link will be broken.
- If you rename a Project parameter that is linked to a Module parameter, the link will remain.
- If you rename a Project parameter that is linked to a Run Book parameter, the link will be broken.
- If you rename a Run Book parameter that is linked to a Project parameter, the link will remain.
- The new name of the parameter will also be reflected when used in other parameters, conditions and evaluators.
- You can use various types of parameters. Each parameter type represents a different type of information (e.g. parameters for text, for passwords, for credentials, for a list of values, etc).
- You can define a default value for the parameter. You can define these values manually, but can also base them on other parameters and functions (by right-clicking the Value field and choosing from the context menu). The values of Text and Credentials parameters can also be based on Global Variables.
- Parameter values can have a maximum length of 512 characters.
- If a different parameter value is provided at the moment of use, the default value will be overwritten.
- Alternatively, you may choose to leave the Value field empty.
- When configuring List or Multi-select list parameters, you can specify the order in which the list values will be shown at the input moment by using the arrow buttons .
This tab is only available when configuring parameters on Project level or Run Book level. On this tab, you can view the way in which parameters are linked to each other and change this, if necessary. It is not possible to create new parameter links.
The input settings of a parameter determine when a new value for a parameter needs to be provided (e.g. when scheduling a Job or when importing a Building Block), but also if this is mandatory, if the new value needs to be confirmed, etc).
In previous versions of Ivanti Automation, parameter values in List and Multi-select List parameters were sorted alphabetically at the input moment. Although the specific order of parameter values will be retained when downgrading again to a previous version of Ivanti Automation, it will revert to an alphabetical order once the Task in which the parameters are used is edited again.
Was this article useful?
The topic was:
Not what I expected
Copyright © 2019, Ivanti. All rights reserved.