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

Advertisements

About snoopj

vExpert 2014/2015/2016, Cisco Champion 2015/2016. Virtualization and data center enthusiast. Working too long and too hard in the technology field since college graduation in 2000.
This entry was posted in Technical and tagged , , . Bookmark the permalink.

3 Responses to Cisco PowerShell Agent Service and VMware VUM PowerCLI

  1. Nerenther says:

    It’s so good to see others blogging about UCS Director and powershell 😀
    I was also having some trouble with the PSA not sticking around, instead the workflow just skipped to the next step before the commands even finished, making the script/commands fail.
    The workaround I initially used was making the PSA create a new powershell process that in turn runs a script. That approach made the scripts finish, but the workflow still skipped to the next step before it finished.
    Using start-job and wait-job is a much better approach 🙂 The only thing that bothers me is that I didn’t think of it 😉

    Like

    • snoopj says:

      Sounds like I accidentally solved your issue with Start-Job. Nice to see that it helped solve issues in your environment.

      I’ve also put some requests into Cisco related to UCSD and PowerShell. Mostly related to rolling back any change that I push through the Execute PowerShell task. Make it more like the Execute Network CLI task, where you can specify a rollback script and/or error handling script, along with the main script to run.

      Like

  2. Pingback: UCSD: Passing multiple arguments to start-job while using the Cisco PowerShell Agent | cloud.kemta.net

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s