VUMXtra 1.3 Update

VMWare Update Manager has been officially deprecated as of 8.0 and honestly I wasn’t expecting to be doing much more with VUMXtra since it’s last release. However here we are with VUMXtra 1.3 with some significant changes. Read on to find out more.

The VUM module has not seen much change, if any, for many years. I had the opportunity to speak with Kyle Ruddy at VMWorld 2019 where he was of the firm opinion that there would be no more development on the VUM module, so it came as a surprise when the module was ported to Core in PowerCLI 12.7. Up until now, it was only possible to use the VUM module with PowerShell for Windows which was a bit of a nuisance.

The “new” module was a port only, with no new functionality. What did change was how calls to the VUM API were made, both for PowerShell for Windows and for PowerShell Core. This broke VUMXtra, adding another hinderance in the form of also having to stick to old versions of PowerCLI.

In my place of work we still have a significant dependency on VUM and will have in the short to medium term. I set about updating VUMXtra without much success. I reached out on the VMWare Slack channel and was able to get in touch with the engineer responsible for the port, Lyuboslav Asenov. He very kindly took some time to send me a code sample that got the ball rolling and allowed me to rework the API calls for the new module. Without his assistance I’m sure this would not have been possible, so huge thanks to him.

What’s New

VUMXtra 1.3 has some significant changes:

• Reworked API calls to be compatible with PowerCLI 12.7 and later.
• Compatible with PowerShell Core.
• Support for Windows hosted vCenters has been dropped. Notably the Import-VUM content function has had all code relating to Windows removed to simplify it. Possibly other functions will still work, but have not been tested. If you require this functionality, continue using VUMXtra 1.2.
• Three new functions have been added to allow the user to work with VUM Host Remediation settings (Get-HostRemediationConfig, Update-HostRemediationConfig and Set-HostRemediationConfig). These can be applied as the default VUM configuration, or specified as part of a remediation job.
• It’s worth pointing out that the above remediation settings also includes enabling Quick Boot 🙂
• Support for cluster level remediation has been added. Previously, only individual hosts could be remediated via Update-EntityBaselineGroup.

So to be clear, PowerShell Core and PowerCLI 12.7 or above are requirements for this module. PowerShell for Windows or older PowerCLI versions are not compatible. Hopefully you’ve been able to move on from these in your environment, but if not, please continue to use VUMXtra 1.2.

Examples

Scenario 1: Configure the default Update Manager Host Remediation settings.

These are the settings that you see in the GUI :

To review what current configuration is, we can use the Get-HostRemediationConfig function which will return a configuration object:

$hostConfig = Get-HostRemediationConfig

This object can then be altered using the Update-HostRemediationConfig. This function has a long list of parameters for the various items that can be configured, so be sure to check out the help and examples. Here is an example where we want to set what happens when a host fails to enter maintenance mode, and to also enable Quick Boot.

$newConfig = $hostConfig | Update-HostRemediationConfig -HostFailureAction Retry -HostRetryDelaySeconds 180 -HostNumberOfRetries 3 -HostEnableQuickBoot $true

Note that this has not applied the configuration to Update Manager yet. We need a further command in the form of Set-HostRemediation:

$newConfig | Set-HostRemediationConfig

Of course, we can use the pipeline to do all of this in one move 🙂

Get-HostRemediationConfig | Update-HostRemediationConfig -HostFailureAction Retry -HostRetryDelaySeconds 180 -HostNumberOfRetries 3 -HostEnableQuickBoot $true | Set-HostRemediationConfig

Scenario 2: Specify Custom Host Remediation Settings at Runtime

The function Update-EntityBaselineGroup remediates either a host or a cluster against a specified baseline group (if you want to remediate to a patch baseline, then stick with the built in PowerCLI CMDlet Update-Entity).

This function now has an optional parameter, -HostRemediationConfig. If it is not specified, then the default VUM host remediation settings are used when remediating a host or cluster. However, there is now the option to pass a configuration object as previously created in Scenario 1 to apply a one time configuration for that remediation.

For example:

Update-EntityBaselineGroup -baselineGroupName "Test Baseline Group" -entity $cluster -HostRemediationConfig $newConfig

The remediation job will start with our custom Host Retry and Quick Boot settings, regardless of what the default Update Manager settings are.

Notes

A couple of things I noted along the way:

I tried to model the input parameters on Update-HostRemediationConfig on the existing VMWare CMDlet Update-Entity. This function has a parameter -ClusterDisableHighAvailability which is not surprisingly documented as “Indicates that you want to temporarily disable High Availability (HA) for the specified clusters“. This is not accurate, the parameter actual disables HA Admission Control, not High Availability. I have replaced this with -ClusterDisableHac in the VUMXtra function.

Parallel Remediation has an odd inconsistency between the GUI and the API. When enabling it via the GUI, it’s enabled for hosts in maintenance mode only. The result is that other hosts are skipped entirely If remediating via Update-HostRemediationConfig, if the user does not specify a value for -enableParallelRemediateOfMMHosts (or indeed explicitly sets it to true), then the default GUI behaviour will be applied. If the user explicitly sets this to false, then parallel remediation will take place for non-Maintenance Mode hosts 🙂 This does not apply to vSAN enabled clusters, where remediation will always take place serially regardless of configuration.

A Note on 1.2

Since there was no blog post accompanying the 1.2 release, I’ll mention the main change here. Import-VUMContent was updated to allow content to be pulled from an HTTP source in addition to a local path. This is very useful for centrally hosting VUM content on a web server then having an automation workflow pull from there. If the source is prefixed with HTTP then the function will invoke a CURL command on the remote vCenter to do a content pull.

Final Thoughts

It was an interesting piece of work putting this module together and hopefully it is useful to others.

The module can be obtained from PowerShell Gallery in the usual fashion:

Install-Module VUMXtra

…..or by visiting the project’s GitHub page.