VUMXtra 1.1 Update

This is just a quick post to mention that there’s a new VUMXtra 1.1 module now available. It’s mostly numerous small changes to satisfy my OCD. If I’m being honest, 1.0 was written “at pace” to get something functional and possibly ignored a lot of best practices. Using a bit of downtime over the Christmas break I’ve gone over the code and made some improvements. Read on the find out more…….

A lot of these hinge around PSScriptAnalyzer output. If you aren’t familiar with this, PSScriptAnalyzer performs an analysis of your code against a rules based engine. It will return a report of items of varying severity that should be addressed for your code to adhere to best practice.

PSScriptAnalyzer can be found here.

Anyway, on to what has changed with VUMXtra:

New CMDlet Names

A number of CMDlets have changed their name. This is again to do with best practice and avoid using “unapproved verbs”. Looking at the official PowerCLI VUM CMDlets, originally VMWare also used unapproved verbs. For example, Attach-Baseline where “Attach” is not an approved PowerShell verb. They changed this at a later date to “Add-EntityBaseline”, although left an alias of the old CMDlet to allow for backward compatibility.

• Attach-BaselineGroup has changed to Add-EntityBaselineGroup
• Attach-BaselineToGroup has changed to Add-BaselineToGroup
• Detach-BaselineGroup has changed to Remove-BaselineGroup
• Get-HostImages has changed to Get-HostImage
• Remediate-BaselineGroup has changed to Update-EntityBaselineGroup

If you have scripts that use these already, do a simple search and replace, or if you have to, add the required aliases to the module manifest as VMWare have done. I promise these won’t change again 🙂

Verbose Output

The original module had too many Write-Debug outputs. Where it’s more appropriate, these have been changed to a Write-Verbose. All CMDlets now support the -Verbose common parameter, so if required, you can get a bit more insight into what the CMDlet is doing.

General OCD Tidy Up

Too many small changes and rough edges have been filed off to mention in detail, but suffice to say the code is in a much better place.

Non-Self Managed vCenter Support

The only new functionality that has been added is to the Import-VUMContent CMDlet. As a bit of context, this CMDlet will make use of VM Tools to get content onto the appliance file system prior to import. An issue arises here if the VCSA VM object is not managed by itself. For this to work, we would need two VI connections, one to the vCenter managing the VM object, and one to the vCenter whose VUM API we wanted to work with. This is now possible with a new optional parameter -vumVI. This allows us to tell the CMdlet which VI connection to use for VUM. Let’s take a look at an example of how this would work.

Let’s suppose we have a vCenter vcsa01.lab.local which manages a VM object VCSA02. VCSA02 is another vCenter instance that we want to import to, vcsa02.lab.local (this gets a bit like Inception but bear with me). In this scenario, we would have a PowerCLI VI connection established to both instances. Then, using the new parameter, we can use something like this to do out import:

Import-VUMContent -VUMType VCSA -FilePath E:\VUM\Images\VMware-VMvisor-Installer-6.7.0.update03-14320388.x86_64.iso -ImportType Image -VCSAVM DEVVCSA -VCSACred $rootCred -vumVI devvcsa.lab.local -Verbose

PowerShell Gallery

VUMXtra is available on GitHub, but now also on PowerShell Gallery. This makes it very easy to install and get started with. Just run the following command:

Install-Module -Name VUMXtra

That’s about it for now, get in touch with any issues or suggestions.