PowerShell Command Workflow: Setting the Execution Policy

Create a workflow to change the PowerShell Execution Policy

This workflow is responsible for calling the “Execute Powershell Command” workflow and executing the Set-ExecutionPolicy command on a Windows VM to set the PowerShell execution policy to unrestricted or restricted.  This is normally not a best practice to change it to unrestricted, but it can be beneficial to set this to unrestricted temporarily during an installation procedure and then set it back to restricted at the end restoring to a secure state.

Create the Workflow

Create a new workflow with the name “Set-ExecutionPolicy Unrestricted.”  We are going to place this workflow in the /Examples/Tools/Scripts/Powershell One Line Commands folder.

Inputs

The workflow should have four inputs:

Input

Type

Description

vmUsername

String

Admin username for the machine that has permissions to execute a process in the operating system

vmPassword

SecureString

The password for the admin username provided in the vmUsername input

vm

VC:VirtualMachine

A reference to the virtual machine in which we want to execute a program

Figure 1. Workflow inputs for the "Set-ExecutionPolicy Unrestricted" workflow

In the workflow designer, these inputs will look as follows:

Inputs for the workflow

Figure 2. Inputs for the "Set-ExecutionPolicy Unrestricted" workflow

Attributes

We will be assigning one attribute for this workflow:

Attribute

Type

Description

Value

arguments

String

The PowerShell command to execute

“Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Force”

Figure 3. Workflow attributes for the "Set-ExecutionPolicy Unrestricted" workflow

In the workflow designer, these will look as follows:

Attributes for the workflow

Figure 4. Attributes for the "Set-ExecutionPolicy Unrestricted" workflow

Outputs

This workflow has one output, which is the process ID (PID) from the process being executed in the guest:

Output

Type

Description

result

Number

Process ID (PID) of the process started in guest.

Figure 5. Workflow outputs for the "Set-ExecutionPolicy Unrestricted" workflow

In the workflow designer, these inputs will look as follows:

Outputs for the workflow

Figure 6. Outputs for the "Set-ExecutionPolicy Unrestricted" workflow

Schema

The workflow consists of one step – a call to the “Execute Powershell Command” workflow we previously created.  The schema we will build will look like this:

Workflow schema

Figure 7. Workflow schema for the "Set-ExecutionPolicy Unrestricted" workflow

 

Create the Execute Powershell Command step by dragging and dropping a new “Workflow element” node on to the schema canvas between the start and end nodes.  Search for “Execute Powershell Command” to find the workflow.  Double-click it to accept it on to the canvas.

Wire the inputs, attributes, and outputs in the following manner:

  • Inputs
    • vmUsername -> vmUsername
    • vmPassword -> vmPassword
    • vm -> vm
  • Attributes
    • arguments -> arguments
  • Outputs
    • result -> result

The visual binding on the “Run program in guest” step should look as follows:

Visual binding for the Execute Powershell Command step

Figure 8. Visual binding for the "Execute Powershell Command" step in the "Set-ExecutionPolicy Unrestricted" workflow

Save the workflow and test the execution on a Windows machine in your environment.  This workflow will set the PowerShell execution policy to unrestricted on the windows VM you run it against.

Create a Workflow to Set the Policy Back to Restricted

Duplicate the workflow created above in every respect, except for one - change the arguments attribute value to "Set-ExecutionPolicy -ExecutionPolicy Restricted -Force".  This will have the effect of reversing the action done by setting it to Unrestricted.  You could also choose other settings, such as RemoteSigned, if you desire.

Note that you could also make this a single workflow with a boolean input value that determines if it will be set to restricted or unrestricted.  In this case, we opt for two separate workflows with separate names simply because it's self documenting and doesn't require any special input to be provided, which makes it more "drag and drop," but the option is definitely there to tweak it and make it operate a bit differently.


Leave a comment