Working with PowerShell

In this recipe, we will enable Orchestrator to execute PowerShell scripts on a Windows host and deal with the results.

Getting ready

We need a Windows host where the PowerShell scripts are stored and can be executed from. This can be any Windows host; however, a Windows 2008 R2 (or better) server contains all the programs required to allow Orchestrator to connect to the Windows host.

To configure the Windows host, we need to use Windows Remote Management (WinRM), which is already installed and integrated into Windows.

Installing the VMware PowerCLI add-on to PowerShell on the Windows host is optional.

You may also add a Linux PowerShell host to vRO. Check this: http://kaloferov.com/blog/how-to-add-a-linux-machine-as-powershell-host-in-vro-skkb1030/

How to do it...

This recipe is split into preparation, adding the host, executing a PowerShell script, and generating a workflow.

Preparing the Windows host with WinRM

In this part, we will configure WinRM with basic authentication, HTTP, and unencrypted transfer. To configure WinRM for HTTPS, please refer to the PowerShell plugin documentation:

  1. Log in to the Windows OS with administrator rights.
  2. Create a local user who is part of the local administrator group.
  3. Start a Windows command line with elevated rights.
  4. Run the following command to configure the listener:
          winrm quickconfig
  5. Enable basic authentication and unencrypted transfer for the service by running the following commands:
          winrm set winrm/config/service/auth @{Basic="true"} 
      winrm set winrm/config/service @{AllowUnencrypted="true"}
  6. Last but not least, we need to increase the package size that can be received:
          winrm set winrm/config/winrs @{MaxMemoryPerShellMB="2048"}
  7. Make sure that TCP 5985 is accessible from Orchestrator to the PowerShell host.

This is a fast and easy configuration that leaves security wanting; however, it enables you to connect Orchestrator to a PowerShell host and run PowerShell scripts without facing any obstacles. If this connection works, you might want to shift to the more secure Kerberos connections (discussed later).

Adding a PowerShell host

Now that have we configured the Windows host, we need to connect Orchestrator to the Windows host. As this is a one-off operation, we will use the existing workflow to do this:

  1. Start the workflow by navigating to Library | PowerShell | Configuration | Add a PowerShell host.
  2. Enter a name for the connection to the PowerShell host. We will use this name later to establish connections to this host. Also, add the FQDN of the Windows host as well as port 5985
  3. Choose WinRM, HTTP (HTTP:5985, HTTPS:5986) as the transport protocol and Basic for the authentication.
  4. If your Orchestrator is configured for SSO, you have to choose Shared Session. Otherwise, you are welcome to use Session per User. If you choose Shared Session, you will need to provide a username and password.
  5. Click on Submit and wait until the workflow is completed successfully. If that is not the case, check out the WinRM configuration:

    Adding a PowerShell host

  6. In the Orchestrator Client, click on Inventory (the paper symbol with a blue puzzle piece) and explore the tree under PowerShell. You will find all available PowerShell SnapIns as well as their Cmdlets:

    Adding a PowerShell host

Using Kerberos authentication

In this section, we are configuring Orchestrator to connect to the PowerShell host using Kerberos authentication:

  1. In Windows host, make sure Kerberos is enabled:
          winrm set winrm/config/service/auth @{Kerberos="true"}
  2. The AD user that should be used needs to be part of the Administrator group.
  3. Use the Configuring the Kerberos authentication recipe in Chapter 2, Optimizing Orchestrator Configuration, to configure Orchestrator to use Kerberos authentication (even if you are using the Windows version).
  4. Rerun the Add a PowerShell host workflow but, this time, use Kerberos as the authentication type.

This should work in most cases; however, Windows can be a bit tricky. If you experience problems, take a look at Spas Kaloferov's awesome article (see the See also section of this recipe for the link).

Executing a script

Now that we have added a PowerShell host, we can run a script. There are two workflows that can be used for this by navigating to Library | PowerShell; they are discussed in upcoming sections.

Calling a script that is stored on the PowerShell host

For this to work, you need a PowerShell script on the PowerShell host, preferably one that requires some arguments, such as get-PSDrive -name c:

  1. Start the workflow by navigating to Library | PowerShell | Invoke an external script.
  2. Select the PowerShell host that you have added to Orchestrator.
  3. Enter the complete path to the script.
  4. In Arguments, enter all the arguments that you want to transfer, like this:
          -Argument1 value1 -Argument2 value2
  5. Click on Submit and wait until the script is executed.
  6. Take a look at the logs to see the results.

Sending a script to be executed to the PowerShell host

  1. Start the workflow by navigating to Library | PowerShell | Invoke a PowerShell script.
  2. Select the PowerShell host that you have added to Orchestrator.
  3. For the script, enter Get-PSDrive -name c.
  4. Click on Submit and wait until the script is executed.
  5. Take a look at the logs to see the results.

Generating an action and workflow from a script

The PowerShell plugin brings with it the ability to automatically create an action and a workflow from a PowerShell script. This allows you to integrate PowerShell permanently into your automation:

  1. Start the workflow by navigating to Library | PowerShell | Generate | Generate an Action from a PowerShell script.
  2. Enter the script you would like to run in the script. Replace all argument values with the {#ParamName#} placeholder. Here's an example:

    Original

    Get-PSDrive -Name C

    Enter

    Get-PSDrive -Name {#DriveName#}

  3. Select a name for the action you would like to create as well as the module where you want to create it.
  4. Choose whether you would like to create a workflow and also choose the folder you would like to create it in.
  5. Click on Submit and wait until the process has finished.
  6. Check out the created workflow, called Invoke Script [Action Name]:

    Generating an action and workflow from a script

  7. See how {#Parameter#} has been changed into an in-parameter in the action you created:

    Generating an action and workflow from a script

  8. Run the new workflow and take a look at the logs.

How it works...

Adding PowerShell to Orchestrator will give you a far greater perspective on what Orchestrator can be used for. In the last few years, PowerShell has become a broadly used tool to write automation scripts. Microsoft uses PowerShell for a lot of management functions, such as System Center Configuration Manager (SCCM), System Center Virtual Machine Manager (SCVMM), and System Center Operations Manager (SCOM).

Using PowerShell with Orchestrator, we are basically able to execute PowerShell scripts with a right-click in the vSphere Web Client and even transport VMware objects to PowerShell scripts.

Workflow TLC

A workflow or action that has been generated by Orchestrator will require some TLC (tender loving care), for instance, changing a password entry from string to SecureString, reworking the naming structure, rearranging the variables in the workflow call, and so on.

Another typical and vital task is escaping variables. When you run a command that requires entering a string that contains special characters such as spaces, backslashes or quotation marks ", you need to escape them using an additional or use single quotation marks '. In the following example, we will show you both methods:

Original

psScript +='Get-PSDrive -Name ' + DriveName + ' ';

Output: Get-PSDrive -Name c:

Using "

psScript +='Get-PSDrive -Name "' + DriveName + '" ';

Output: Get-PSDrive -Name "c:"

Escaping '

psScript +='Get-PSDrive -Name '' + DriveName + '' ';

Output: Get-PSDrive -Name 'c:'

The difference between " and ' is that PowerShell will look inside " " for $ and assumes that what follows is a variable, whereas it will take all content between the ' as it is.

Entry

"Test $date"

'Test $date'

Output

Test 12.01.12

Test $date

Basic versus Kerberos authentication

In this recipe, we used the basic connection to connect Orchestrator to the PowerShell host. As mentioned, this is the easiest way to build the connection, and therefore it is good for a beginner. As a professional, you want to use Kerberos as the authentication; however, you should first try to connect via the basic method to make sure that you don't have any Firewall or other basic connection problems before going for the secure connect.

One of the differences between basic and Kerberos authentication is that basic authentication can only use local users, whereas Kerberos uses AD users. Secondly, Kerberos uses encryption when communicating, whereas basic doesn't. This is quite a big difference, especially in a business environment where local users should really not be used and encryption is a must.

As already mentioned, if you use Orchestrator with SSO, you can only use Shared Session, as Orchestrator is not able to forward the session. You can use Session per User only with an LDAP-connected Orchestrator.

PowerShell output to XML

To convert the PowerShell output into XML, run the following lines:

psXML = PowerShellOutput.getXml();

The XML output of PowerShell can be quite messy. The first thing that one needs to realize is that the PowerShell XML output adds a large amount of spaces between tags. To clean this up, run the following regular expression:

xmlClean = psXML.replace(/>s+</g, "><");

The following is an example of the Get-Culture PowerShell command. You can clearly see how the diminished command-line output (the blue PowerShell window) looks in PowerShell XML:

PowerShell output to XML

As you can see, PowerShell creates tag names along with the variable names (Obj=Object, S=String, and I32=32-bit Integer) and sets the name of the output as an attribute with the N key. It's not easy to phrase these constructs; however, it's doable.

See also

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset