Counter the self-aware VUM

Today there was quite a bit ofย  activity on Twitter following Jason Boche‘s blog post titled VMware Update Manager Becomes Self-Aware.
The problem Jason discovered was that the VUM skipped the guests which are hosting the VUM server and the vCenter server. As a consequence you can not select a cluster, select “remediate” and go out for lunch anymore. The resolution was a rather cumbersome and error prone manual procedure.
But of course PowerCLI can help the human vSphere administrator ๐Ÿ˜‰

The following script finds the ESX host(s) that is/are running the VUM guest and/or the vCenter guest and will vMotion the guest(s) to another ESX host when needed.

The script uses the brand-new VUM cmdlets to do the actual patching.

Note that the script assumes that the hostnames of the VUM server and the vCenter server correspond with the names of the guests.


Line 1: The name of the cluster you want to patch.

Line 2: The name of the baseline you want to use.

Line 7-11: These lines retrieve the name of the VUM Server.

Line 15: This line retrieves the name of the vCenter.

Line 26-36: When the loop reaches the ESX server that hosts the VUM server or the vCenter it will take one of the other nodes and vMotion the VUM server to that node.

Line 32: The $vm variable will be $null when there is no VUM or vCenter guest running on the ESX host and the If statement will fail.

Line 35,37: These lines contain -WhatIf parameters which will allow you to first do a trial run to see what will be done. Once you are happy with the result remove the -WhatIf parameter from both lines.

Line 37: The actual patching of the node.

With help of the script it should again be possible to remediate a complete cluster even when one of the nodes hosts the VUM server or the vCenter.

A small step, but we can’t let Skynet take over the world ๐Ÿ˜‰



    Hey Lucd, all good stuff. How easy would it be to have the script remediate only a given set of hosts? We trend to patch our hosts in a cluster over a five day period.


      @Stuarty, thanks.
      You can change line 20

      Get-Cluster -Name $clusName | Get-VMHost | %{

      into something like

      Get-VMHost esx1,esx2,esx3 | %{

      Then the Remediate would only be executed on hosts esx1, esx2 and esx3.

    Ted Thomas

    Elegant script; shows the power of the PowerCLI for sure.

    Perhaps I’m missing something; wouldn’t it be simpler (but not as elegant) to remediate twice, with a simple VM migration or three in between?

    Scripts are fast & powerful; so are bullets. KISS whenever possible…



      Thanks Ted.
      Sure, your suggestion would work as well.
      There are many ways to skin the cat ๐Ÿ˜‰


    Bloody awesome Luc, put you and PowerCLI together and anything is possible ๐Ÿ™‚

    Dave Convery

    Rock Star!


      Thanks Dave.

    Jason Boche

    Thanks for the post LucD. To clarify a bit, along with the VUM VM, a host containing the vCenter VM will also not be remediated.



      That was also the question in the other comment. I’ll update the script to handle the vCenter in a similar way.


    Hello, LucD. @1NaDaMtns here. ๐Ÿ™‚ Thx for the awesome script! Gonna test it on our enviro and see how it works out.

    My question is if you might know of a similar workaround if a vCenter server is virtualized. For example, when remediating a host that has the vCenter VM installed on it, one is prompted that this is not possible until the VM is migrated to another host (of course). I’m wondering if it’s possible to automate that process when remediating at the host level, i.e. automatically move the vCenter to another host.

    Have a good one!


      The script has been updated and now also handles the vMotion of the vCenter.

Leave a Reply

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.