On the Steps page of the Approval Workflow, Completion Workflow and Command Workflow wizards, you can specify steps, or actions, to execute as part of the workflow. The actions you can choose depend on:

the type of workflow (for example, whether it's a workflow for a virtual service versus a VM, or a workflow for a new request versus a change request)

the managed system type (for example, SCVMM or AWS)

You can also create conditional workflow steps.

Adding actions is optional. There are scenarios in which it makes sense to create a workflow without actions. For example:

You can set up an approval and pre-provisioning workflow whose only purpose is to to deploy VMs and virtual services automatically.

You can set up a completion workflow that overrides a default completion workflow. For example, let's say you have set up a default VM completion workflow to run every time a new VM is provisioned, but you don't want that workflow to run on one or more specific VMs. In this case, you can configure a VM completion workflow that contains no steps - its only purpose is to override the default VM completion workflow.

Workflow steps available in Embotics® vCommander®

Email workflow steps

These steps are supported for all service types.

 

Workflow Step

Description

Available in these workflow types

Send Approval Email

Notify one or more "approvers", people with authority to approve the service request. Can be a vCommander user, a Service Portal user or simply an email address. See Configuring workflow steps that send an email below.

Approval

Command

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 antivirus program before performing subsequent software installations. Emails sent using a send email step are used for notification purposes only, and do not allow recipients to acknowledge an action has been completed.

See also Configuring workflow steps that send an email below.

Completion

Send Email

Send an email (other than an approval or acknowledgment email). See Configuring workflow steps that send an email below.

You can choose either plain text format (the email will include only the information you specify in this step) or HTML format (the email will also include all details of the service request).

Approval

Completion

Command

Quota workflow steps

 

Workflow Step

Description

Available in these workflow types

Quota Approval

Send a quota-based approval email or reject a request automatically when quota is exceeded. See Configuring a Quota-based Service Request Approval Process.

NotePencil-smallIn an approval workflow for a change in VM ownership or organization assignment, the Quota Approval step must appear after the Approval Email step.

Approval

VM action workflow steps

 

Workflow Step

Description

Available in these workflow types

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 managed systems. See Managing the Power State of Services for details.

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

Completion

Command

Perform Remove Action

Perform one of the following:

Remove From Inventory - supported for VMs and virtual services on vCenter managed systems

Delete From Disk - supported for all service types

When all VMs are deleted from a virtual service through a policy action (that is, when VMs are deleted by a policy action or by a command workflow attached to an expiry policy), the empty virtual service is not automatically deleted unless it too is targeted by policy.

Change Request Completion

Command

Script workflow steps

You can specify that the value returned by the script be captured as a comment, thus determining whether the request is approved or rejected. When you capture script output as comment, you can use script output as the input to a subsequent Set Custom Attribute step. See Using Script Output as Input to a Workflow Step. Scripts in approval workflows can also set deployment parameters.

NotePencil-smallWhen configuring the command line for script steps, you must use an absolute path to the executable, even if the executable exists in the Windows path. Otherwise, Java may attempt to execute the command in an incorrect location.

For script syntax, see Variable Syntax for Emails and Scripts.

These steps are supported for all service types.

 

Workflow Step

Description

Available in these workflow types

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.

Approval

Command

Execute Script

Execute a script.

Approval

Completion

Command

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 does not automatically use sudo with non-root-user credentials. vCommander supports interactive sudo prompts.

NotePencil-smallYou can use variables in the Host Name field of this workflow step. Any variable supported for the workflow type can be used.

Approval

Completion

Command

Wait for Event workflow step

 

Workflow Step

Description

Available in these workflow types

Wait for Event

Allow one of the following events to complete before the next step is started:

Guest OS customization to complete

Guest OS to power on

Service to obtain DNS name

Service to obtain IP address

Service to obtain IP address and DNS name

Service to power off

Service to power on

Time to elapse

The available events depend on the workflow type.

These events are supported for VMs only, except for Service to power on, which is supported for VMs, virtual services, databases and load balancers.

Note: The first step in a component-level completion workflow for a new VM should be "Guest OS to power on", so that variables such as IP addresses have values before other steps are run. For Windows VMs, it may take longer than the default 300 seconds (five minutes) to obtain an IP address and DNS name. You may want to use two steps: one that waits for guest OS customization to complete, and one that waits for IP address and DNS name.

SCVMM: If you select Guest OS to Power On, vCommander checks the power state of the container, not the power state of the guest OS itself.

Public cloud managed systems: vCommander must retrieve information from the managed system and generate the relevant event. Information is retrieved from the managed system according to the Update Frequency schedule defined for each public cloud managed system. Ensure that the Wait Time setting is longer than the Update Frequency.

Microsoft Azure: Only Service to power on and Time to elapse are supported.

Change Request Approval

Completion

Command

Migrate VM workflow step

 

Workflow Step

Description

Available in these workflow types

Migrate VM

Migrate a vCenter VM to another destination. For complete information, see Migrating a VM through a Workflow Step.

Completion

Command

Guest OS workflow steps

These steps allow you to customize a VM after deployment. For examples, see Automating VM Customization through Workflows: Examples. For troubleshooting, see Troubleshooting and Tracking Workflows. These steps are supported for VMs only.

NotePencil-smallIf the Dynamic Resource Scheduling (DRS) automation level for a cluster is set to Fully Automated and VM-level DRS control is allowed, vCommander temporarily disables DRS during post-deployment configuration for new VMs deployed into the cluster. Disabling DRS ensures that vSphere will not migrate a newly provisioned VM before customization is complete. DRS is re-enabled once the service is completed or the request is rejected. A vCommander event is generated for the cluster when DRS is disabled, and again when it's re-enabled. This feature is supported for VMware 4.0 and higher.

 

Workflow Step

Description

Available in these workflow types

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 does not automatically use sudo with non-root-user credentials. When connecting with VMware Tools (the default method for VMware VMs), vCommander does not 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, vCommander supports interactive sudo. This means that vCommander detects password prompts from the remote system and responds with the password, so the step can run its command.  

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

vCenter VMs, vSphere 4 and earlier: Either VMware Tools or Open Virtual  Machine Tools is required to obtain the IP address, but vCommander uses WMI (for Windows) or SSH (for Linux) to run the command in the guest OS.

SCVMM: The latest guest integration services is required to obtain the IP address. To run the command in the guest OS, vCommander 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: cannot run guest command.

Ports: See "Port Requirements" in the vCommander Installation Guide.

Change Request Approval

Completion (VM component-level)

Command (VM type)

Copy File

Copy a file from a specified source on the vCommander 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.

Completion (VM component-level)

Command (VM type)

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.

NotePencil-smallIf 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 does not exist and the credentials you provided have the associated permissions, the folder will be created.

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

Completion (VM component-level)

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.

Completion (VM component-level)

Command (VM type)

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 Configuring Virtual Networking through a Workflow Step.

Completion (VM component-level)

Command (VM type)

Configure OS Networking

Assign network settings in the guest OS. For complete information, see Configuring OS Networking through a Workflow Step.

Completion (VM component-level)

Command (VM type)

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.

Completion (VM component-level)

Command (VM type)

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 vCommander cannot 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 vCommander 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 managed system 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 is not 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.

Completion (VM component-level)

Command (VM type)

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 vCommander 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.

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

Troubleshooting:

If you know customization specs exist on the vCenter but do not see any on this page, see the Knowledge Base article Why Are Customization Specs Not Appearing in vCommander™?

See also the Knowledge Base article Tracking Guest OS Customization Failures.

Completion (VM component-level)

Command (VM type)

Configure Puppet

Configure provisioned VMs using Puppet Labs® 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.

NotePencil-smallYou 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, vCommander 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 vCommander can remove pinned nodes, but not unpinned nodes, from a group.

For Environment, Classes and Groups fields, 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 Integrating Puppet with Embotics® vCommander® for details and an example.

Completion (VM component-level)

Command (VM type)

Configure Chef

Configure provisioned VMs using Chef™. The following Chef actions are supported:

Create Node (Roles and Recipes): Create a node on the Chef server for this VM and optionally set individual recipes and roles. The Recipes and Roles fields accept a comma-separated list of recipes and roles, respectively.  For the Recipes and Roles fields, 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, respectively:

#{target.settings.chef.recipes}

#{target.settings.chef.roles}

The variable #{target.settings.chef.runlist} can also be used to retrieve the requested roles and recipes.

This step also outputs a private RSA key for the Chef client, which must then be copied to the target VM in a later step. See Integrating Chef with Embotics® vCommander® to learn how.

Create Node (Run-List): Create a node on the Chef server for this VM and optionally set a run-list. The Run-List field accepts a comma-separated list of roles and recipes, in Chef run-list format. For example:

role[linux],recipe[logrotate],recipe[logrotate::global]

For the Run-List field, 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 variable: #{target.settings.chef.runlist}

This step also outputs a private RSA key for the Chef client, which must then be copied to the target VM in a later step. See Integrating Chef with Embotics® vCommander® to learn how.

Delete Node: Delete this node from the Chef server. You should always include this action in decommissioning workflows for Chef nodes, before the step that deletes the VM from disk.

Set Recipes: Enter a comma-separated list of recipes for this node. Overwrites any existing recipes.

For the Recipes field, 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 variable: #{target.settings.chef.recipes}

The variable #{target.settings.chef.runlist} can also be used to retrieve the requested recipes.

Set Roles: Enter a comma-separated list of roles for this node. Overwrites any existing roles. For the Roles field, 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 variable: #{target.settings.chef.roles}

The variable #{target.settings.chef.runlist} can also be used to retrieve the requested roles.

Set Run-List: Enter a comma-separated list of recipes and roles in Chef run-list format. See the Chef documentation for syntax details. For example:

role[linux],recipe[logrotate],recipe[logrotate::global]

For the Run-List field, 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 variable: #{target.settings.chef.runlist}

See Integrating Chef with Embotics® vCommander® for details and an example.

Completion (VM component-level)

Command (VM type)

Lifecycle management workflow steps

Using a workflow step to set metadata for a service can be a convenient shortcut. To ensure that the proper values are set, it's best practice to set metadata through policy or through a completion workflow, not both. The metadata values that are applied last are those that take effect. These steps are supported for all service types.

 

Workflow Step

Description

Available in these workflow types

Set Ownership

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

Completion

Command

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.

Completion

Command

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 compliance policy. Whenever a VM becomes uncompliant, the 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 Using Script Output as Input to a Workflow Step.

Completion

Command

Set Groups

Set one or more of the following service group types for the component:

Expiry

Guest OS Scan

Maintenance

Power Schedule

Rightsizing

For example, if you have added a custom attribute to your component blueprint form for selecting the required power schedule, such as Always On, Business Hours and Weekdays, you can add multiple conditional workflow steps to set the Power Schedule group to match the power schedule selected on the form.

As another example, if your component blueprint form includes a custom attribute for Service Level Agreement, you can add multiple conditional workflow steps to set the Rightsizing group to match the SLA selected on the form.

Expiry groups and maintenance groups apply to all service types — VMs, virtual services, stacks, auto scaling groups, databases and load balancers. The other group types apply only to VMs.

Because a completion workflow runs after deployment, the VM groups set with a completion workflow step take precedence. All VMs must belong to a group of each type, so if a group is not specified through a workflow step or some other method such as policy, the VM is assigned to the default group. See Order of Precedence for Metadata and Other Service Settings for more information.

When adding a Set Groups workflow step, you need to specify the group types and then set their values:

1.Click Add Groups to add one or more group types.

2.In the Add Groups dialog, select the types of group you want to assign, and click OK. The group types you added appear in the workflow wizard.

3.For each group type, make a selection from the drop-down menu.

Completion

Command

Workflow steps that send an email

In any workflow step that sends an email, in the Address List field, enter the email account(s) to which you want any emails sent in the order you want them sent (multiple email accounts must be separated by a semi-colon). These email addresses do not have to be associated with vCommander or Service Portal accounts. They can include group accounts.

When vCommander sends an email to a group of people requesting approval for a service request, all people in that group receive the email. As soon as one person has clicked Approve on the approval landing page, other people who have received the same email are no longer able to approve the request. If multiple levels of approval are configured (meaning that multiple Send Approval Email steps were added to the approval workflow), vCommander then sends the email to the next person or group in the approver list. If the request is rejected, no other emails are sent.

If a vCommander user has Administrator access rights on the relevant managed system and their email address matches the email address in the approval workflow, the user can also view a list of service requests awaiting their approval and approve requests right in the vCommander console.

If a Service Portal user has the required permissions and their email address matches the email address in the approval workflow, the user can also view a list of service requests awaiting their approval and approve requests right in the Service Portal. The required permissions are Approve Requests, Request New Service, and Request Service Change. If the requester is a member of an organization, the approver must be a member of the same organization and must also have the Show All Organization Services permission.

Using variables to populate email addresses

Using variables to populate email addresses allows you to configure dynamic recipient lists. For example, to send the email to the primary contacts of the organization, enter the following variable in the Address List field:

#{request.requester.organization.email}

You can pass other variables into the email address field, email subject and email body.

Formatting in the email body

The <a> tag is automatically added to links in emails (only the http protocol is supported). For example, if the value of a custom attribute is a link, the value will be formatted as a link in the email.

If you do not use HTML markup in the email body, the body is assumed to be plain text; <br> and <p> tags are automatically added for new lines.

If you add HTML markup to the email body, however, no additional tags are added.