Workflow Steps Reference

Send Approval Email

Notify one or more "approvers", people with authority to approve the service request. Can be a Commander user, a Service Portal user or an email address. For more information, see Workflow steps that send an email.

Limitation: When you add a Send Approval Email step to a command workflow, request comments may not appear on the approval landing page.

Send Acknowledgement Email

Notify people who must take an action before next steps can be carried out.

For example, you could use this step to make sure that an administrator has installed and updated an anti-virus program before performing subsequent software installations. Emails sent using a send email step are used for notification purposes only, and don't allow recipients to acknowledge an action has been completed.

See also Workflow steps that send an email below.

Important: To ensure that the information such as CPU count, MAC address and cost are complete and accurate in acknowledgment emails, add a "Wait for event" step to the beginning of the completion workflow. In the Wait For drop-down menu, select an option as follows:

• If VMware Tools is installed, Service to obtain IP address is the recommended option. You can also select Service to obtain DNS name or Service to obtain IP address and DNS name.
• If VMware Tools isn't installed, or for a non-vCenter VM, select Time to Elapse. Specify sufficient time for the hypervisor or cloud to update all properties changed by Commander.

Acknowledgment emails will display a service cost if the user accounts associated with the target email addresses have a role that contains the "Show Cost" Service Portal permission. A service cost is also displayed if no accounts are associated with the email addresses. A service cost isn't displayed if the user accounts associated with the target email addresses don't have the "Show Cost" permission.

Perform Power Action

Perform one of the following:

• Start
• Stop
• Shutdown guest OS and stop
• Reset (for a database, executes a Reboot command)
• Shutdown guest OS
• Reset guest OS

Not all power actions are supported for all cloud accounts. See Manage Service Power States for details.

These steps are supported only for VMs, except for Reset, which is also supported for databases.

Execute Script

Execute a script that's saved on the local system.

See Add Execute Script workflow steps for more details on how to configure an Execute Script.

Execute Embedded Script

Execute a script, whose contents is provided in the workflow step rather than on disk. For this type of execute script, you must provide the entire script contents, rather than a path to the executable.

See Add Execute Embedded Script workflow steps for more details on how to configure an Execute Embedded Script.

Execute Approval Script

Execute an approval script.

If the script output returns exit code 0, the workflow proceeds to the next step; if the script returns exit code 1, the workflow fails, and the request is automatically rejected.

Execute SSH Command

Execute an SSH command on any host running the SSH service.

Windows: This step requires elevated privileges. On Windows, if the credentials used are those of a member of the administrator group, as opposed to the actual administrator account itself, you will likely need to disable UAC (user access control) on your templates.

Linux: If you supply non-root-user credentials, the user must be able to run sudo, and you must add sudo to the command line. This step doesn't automatically use sudo with non-root-user credentials. Commander supports interactive sudo prompts.

You can use variables in the Host field of this workflow step. Any variable supported for the workflow type can be used. For releases 8.1 and later, you can set the port value using either a fixed integer or a variable. The default is port 22.

Run Program

Execute a program in the guest OS after deployment. For example, use this step to install software, configure a router, or run a batch file. Output from the guest OS is captured and stored as a workflow comment. This step requires you to specify guest OS credentials.

Windows: This step requires elevated privileges. On Windows, if the credentials used are those of a member of the administrator group, as opposed to the actual administrator account itself, you will likely need to disable UAC (user access control) on your templates.

Linux: If you supply non-root-user credentials, the user must be able to run sudo, and you must add sudo to the command line, because this step doesn't automatically use sudo with non-root-user credentials. When connecting with VMware Tools (the default method for VMware VMs), Commander doesn't support interactive sudo. This means that if the remote system prompts for a password, the step just waits until the timeout is reached. When connecting with SSH, on the other hand, Commander supports interactive sudo. This means that Commander detects password prompts from the remote system and responds with the password, so the step can run its command.

vCenter VMs: Commander uses VMware Tools to obtain the IP address and run the guest OS command; Open Virtual  Machine Tools will also work.

SCVMM: The latest guest integration services is required to obtain the IP address. To run the command in the guest OS, Commander uses WMI (for Windows) and SSH (for Linux).

Microsoft Azure: The Run Program workflow step is supported only for Linux VMs with the SSH endpoint configured. Run Program steps executed on an Azure Windows VM will fail with the following error: VM "<vm-name>" has no valid network address: can't run guest command.

Ports: See Port Requirements.

Copy File

Copy a file from a specified source on the Commander server to a specified destination on the target VM. You can use an absolute path referencing the file system (for example, C:\vcommander\scripts\updater.ps1) or a UNC path to a share. The credentials used must have access to read from and write to the source and destination, respectively. You can choose to overwrite the file if it already exists in the destination.

The mechanism by which this action is undertaken is the same as described for the Run Program step.

Copy Uploaded File

Copy a file uploaded as part of a new service request to a specified destination on the target VM. This step works with the File Upload element on the service catalog blueprint form.

If multiple File Upload form elements appear on the form, provide the Display Label of the associated form element in the Display Label field for the File Upload form element.

Enter the absolute path to the location where the files will be uploaded on the VM. If the path doesn't exist and the credentials you provided have the associated permissions, the folder will be created.

The file name provided by the user in the File Upload form element is preserved after upload.

Create File

Create a file on the guest OS. Similar to the Copy File step, but accepts file contents instead of pointing to a file location. Specify the credentials, the file contents, the destination location and whether to overwrite an existing file at the destination. The maximum file size is the size allowed for a text field for the type of database in use.

This step accepts variables in the Contents field. For example, if your users need to upload a file as part of a service request, you can add an Input Text Field element to the request form and then enter the following variable in the Contents field of the Create File workflow step:

#{target.settings.inputField['field name']}

For example, if your Input Text Field form element is labeled Properties File, use the following variable:

#{target.settings.inputField['Properties File']}

This step follows the same rules as the Run Program step.

Configure Virtual Networking

Add a NIC and assign a virtual network. Supported for vCenter only. For public cloud VMs, this step is skipped and a comment is added to the log. For complete information, see Configure Virtual Networking Through Workflow Steps.

Configure OS Networking

Assign network settings in the guest OS. For complete information, see Configure OS Networking Through Workflow Steps.

Decommission Networking

Remove host records and DHCP reservations from BlueCat™ IPAM. This step is to be used when decommissioning a VM, if you have integrated with BlueCat™ IPAM.

Note: If there is no record for the VM in BlueCat™ IPAM, the step will be marked as complete, and a comment will be added; it's not necessary to make this step conditional on BlueCat™ management.

Join Domain

Add a VM to a Windows domain without the need for a customization spec. For example, use this step to join a VM to a domain after all software has been installed; in this case, you would create a command workflow.

This step requires Guest OS Credentials (in the Guest OS category) and Domain Credentials (in the System category). See credentials for more information.

If Commander can't contact the VM using WMI, the step will fail.

Windows: This step requires elevated privileges. On Windows, if the credentials used are those of a member of the administrator group, as opposed to the actual administrator account itself, you will likely need to disable UAC (user access control) on your templates.

Enable Restart Guest OS if you want Commander to restart the guest OS as a part of this step. For vCenter, enabling this option causes the step to wait for VMware Tools (if installed) to be ready. For other cloud account types, enabling this option causes the step to wait for the VM to power on.

Domain Name and OU: Enter the domain name and optionally the OU (organizational unit), or use variables. For example, you can allow users to specify the domain name on the request form as a custom attribute. Then you can use a variable to retrieve the domain name specified on the form.

The Join Domain step isn't supported for fenced VMs.

For non-Windows VMs, the step is skipped, with a comment added to the log; it's not necessary to make this step conditional on the guest OS.

The Join Domain Guest OS workflow step may no longer work as expected due to Microsoft hardening changes in Distributed Component Object Model (DCOM). Alternatively, you can download and use the Join Domain plug-in workflow module from Snow Software's public Cloud Management Integrations repository on GitHub. For more information, see Use Workflow Modules.

Customize VM

Customize a vCenter VM by specifying a customization spec. You can select any customization spec available on the vCenter where the VM is deployed.

This step can take input from a Configure OS Networking step when Commander is integrated with BlueCat™ IPAM.

You can make this step conditional on the guest OS family, so that you use one customization spec for Windows, and one for Linux.

You can also assign a customization spec to a service catalog component. To avoid collisions, choose one of these methods, not both.

Configure Puppet

Configure provisioned VMs using Puppet. The following Puppet actions are supported:

• Authorize Node: Authorize communication between the Puppet master and the Puppet agent on this VM
• Set Classes: Set the classes for this node. Overwrites any existing classes.
• Set Environment: Set the environment for this node. The default environment is Production. Overwrites any existing environment.
• Set Groups: Set the node groups this node belongs to. Overwrites any existing groups.
• Set Variables: Set the variables for this node (name/value pairs). Overwrites any existing variables.

You can use the Execute SSH Command workflow step to pass commands to the Puppet master.

If you use the Configure Puppet workflow step to assign classes and variables to a node, Commander creates a group with the same name as the node and pins the node to the group. A parent group named "vCommander" is also created to contain these self-named node groups. Note that Commander can remove pinned nodes, but not unpinned nodes, from a group.

For Environment, Classes and Groups, when using this step in a completion workflow, you can access the values set in the service catalog (or on the request form, if applicable) by entering the following variables:

#{target.settings.puppet.environment}

#{target.settings.puppet.classes}

#{target.settings.puppet.groups}

See Integrate Puppet with Commander for details and an example.

Set Ownership

Set the primary owner, IT contact and secondary owners for a service or component.

Set Expiry Date

Specify that the service or component will never expire, set a fixed expiry date, or set a date relative to when the workflow executes.

Set Custom Attribute

Set a value for a preconfigured custom attribute.

You can create a command workflow that sets values for custom attributes required for VMs to be deemed compliant. You can then attach that command workflow to a tag compliance policy. Whenever a VM becomes uncompliant, the tag compliance policy will run the command workflow to reset the custom attribute values, automatically ensuring compliance.

When you capture script output as comment, you can use script output as the input to a subsequent Set Custom Attribute step in the workflow. See Use Script Output as Input to Workflow Steps.