Remediate remote hosts using central VUM

Ran into an interesting design problem at work. Design calls for a central vCenter to manage multiple remote site hosts. How do you go about remediating these remote hosts? There's a 1 to 1 relationship between vCenter and VUM. Pushing remediate package for each host across WAN seems extremely inefficient. I get the feeling if we deploy a repository at each remote site, VUM will pull the patch to central then push it out to remote site.

Anyone have a good solution? I think auto deploy with local TFTP server at each remote site will probably work, but statelessness of 5.0 auto deploy makes this a tough sell.

Find more posts tagged with

SAVE $250 on Your Boot Camp — Use Code "EXAM26"

Exclusively for TechExams members for Infosec Boot Camps starting before April 30, 2026

View Boot Camps

Comments

meadIT

The update repository is designed for multiple vCenters to download updates from one place. It is inefficient to have to transfer that data multiple times, but that is just a design risk created by the requirement of having a central vCenter server. The patches shouldn't be too large if the updates are done on a regular basis. Upgrades (which require the complete install image) on the other hand could be an issue.

Off the top of my head, some workarounds could be A) a WAN optimization appliance that would cache the data on the remote site or

stage the ISO for the upgrade at the remote site and then upgrade the hosts via their iLO or iDRAC, etc instead of VUM.

dave330i

meadIT wrote: »

stage the ISO for the upgrade at the remote site and then upgrade the hosts via their iLO or iDRAC, etc instead of VUM.

Co-worker mentioned patch via CLI, so that's an option. Not sure why there's a 1 to 1 relationship between vCenter and VUM. Other appliances such as vDR can have many to 1 vCenter. Submitted a VMware feature request.

blargoe

The individual patches shouldn't be a problem over the WAN, particularly if you are staging first, but a version update might be painful. Autodeploy might make them want to go home and kick their dog if multiple remote servers had to reboot.

You could do local TFTP/PXE for booting hosts and go with a good old fashioned kickstart script for initial deployment, host profiles with answer files for compliance, a combination of a local web server per site hosting offline bundles and vMA esxcli commands for installing updates, and Update Manager for assessing updates compliance and for deploying smaller updates.

They really should removed the 1:1 restriction for Update Manager by now, it doesn't make sense to be this restrictive anymore.

QHalo

DFS share for the VUM repository and patch via CLI script. The script would be the same for all sites since the namespace would be the same.