Cisco PowerShell Agent Service and VMware VUM PowerCLI

Whew.  That was a long winded title.  Those who use the PowerShell Agent Service with UCS Director should be aware that in most cases, you just send a few things for that service to run PowerShell related commands through it.  There’s very little interaction with UCS Director, short of “Was it successful/Did it fail?”.  I found an interesting issue in which I had to get creative in the way that the PowerShell script I needed to run would work through the Cisco PSA.

Let’s rewind a little bit to VMware’s Update Manager PowerCLI snap-in.  Rarely have I needed to use it, but in my current workflow, I’m working on pushing the latest version of the Cisco Nexus 1000v VEM component to some brand new hosts I’m building in the lab.  I created my script (which was relatively simple):

Add-PSSnapin VMware.VimAutomation.Core -ErrorAction SilentlyContinue
Add-PSSnapin VMware.VumAutomation -ErrorAction SilentlyContinue

$esx_hostIP = $args[0]
$vcenter_username = “<removed>”
$vcenter_password = ConvertTo-SecureString -String "<removed>" -AsPlainText -Force
$vcenter_cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $vcenter_username, $vcenter_password

$vcenter_conn = Connect-VIServer -Server <vCenter Name/IP> -Credential $vcenter_cred
$n1kv_baseline = Get-Baseline -Name "Nexus 1000V VEM"
$command_1 = Get-VMHost -Name $esx_hostIP | Attach-Baseline -Baseline $n1kv_baseline
$command_2 = Get-VMHost -Name $esx_hostIP | Remediate-Inventory -Baseline $n1kv_baseline -Confirm:$false

Disconnect-VIServer -Server <vCenter Name/IP> -Confirm:$false

Pretty simple script. Get the patch baseline, attach it to the new host, remediate the baseline to the host (the Nexus 1000v VEM package doesn’t not require a reboot to install).

Now, the problem with this script is that if you try to run in in Powershell 3.0 or 4.0, it will immediately crash PowerShell environment with an error message stating Process is terminated due to StackOverflowException. After a little research, I found that the VUM PowerCLI components need to be ran through a PowerShell 2.0 environment. Since I have little control over what environment parameters to send to the Cisco PSA, I was stumped.

The good news is that it didn’t take me very long to find another PowerShell cmdlet to try. In this case, I found that the Start-Job cmdlet takes a parameter of PSVersion. After some experimentation with the right order of parameters, I was able to come up with a command to send the Cisco PSA to run the VUM PowerCLI script. Here is the command I put into the Execute PowerShell Command task to allow for this:

Start-Job -FilePath “C:\\Powershell\\VMware_InstallNexus1000v.ps1” -PSVersion 2.0 -ArgumentList “${GetResolvedIPAddressFromIPPoolTask_772.IPAddress}” | Wait-Job

This allows for the call on the Cisco PSA device to a local PS1 file, setting up the PSVersion to be 2.0, and passes an argument (in this case from UCS Director, the IP address I pulled from a pool earlier in the workflow). I will note that when you run the Start-Job cmdlet through the PSA, the PSA will not stick around to wait for the job to run to completion to get the success/fail result. This is why I added the | Wait-Job section to the overall command. When ran, the PSA will not return the success/fail notification to UCS Director until the entire script has been ran.

So far, I’ve been able to successfully deploy the Nexus 1000v VEM to any new hosts I’ve been building in the lab with my workflow. Hopefully this helps someone else in the same scenario trying to run the VMware VUM PowerCLI snap-in through the Cisco PSA. 🙂

Advertisement