How to use vSphere Update Manager to automate ESXi patch deployments

Keeping ESXi hosts patched is essential for security, stability, and compatibility with vCenter Server, storage systems, and virtual hardware. Manual updates can work for a small environment, but they become difficult to control when a cluster contains many hosts or when maintenance windows are tightly managed.

vSphere Update Manager provides a centralized way to download VMware patches, compare host versions against a defined standard, and remediate non-compliant hosts. In newer vSphere releases, the feature is integrated into vSphere Lifecycle Manager, although many administrators still use the familiar Update Manager name.

Automation does not mean applying every patch immediately. A reliable process includes patch validation, host baselines, staged remediation, maintenance-mode handling, and post-update verification. These controls reduce the risk of taking down workloads while keeping the environment current.

Understand the update workflow

Update Manager connects to VMware patch repositories or an approved internal depot, downloads available metadata, and evaluates ESXi hosts against baselines. A baseline is a collection of patches, extensions, or upgrade rules that defines the desired state.

The basic workflow has four stages: synchronize patch metadata, create or select a baseline, scan hosts for compliance, and remediate hosts that need updates. Remediation can place hosts into maintenance mode, evacuate virtual machines with vMotion, install patches, reboot the host, and return it to service.

In vSphere Lifecycle Manager, administrators may also manage cluster images instead of traditional baselines. Image-based management defines the ESXi image, vendor add-ons, firmware, and additional components as a single desired configuration. Baselines remain useful for environments using the older update model or for targeted patch operations.

Prepare vCenter Server and ESXi hosts

Before creating a remediation task, confirm that vCenter Server can reach the configured VMware depot or the organization’s update repository. Restricted networks may require a proxy, an offline depot, or downloaded patch bundles transferred into the environment. Verify DNS, certificates, firewall rules, and available storage for downloaded updates.

Check that every host is connected, licensed appropriately, and assigned to the correct data center or cluster. Review host hardware compatibility, third-party drivers, storage multipathing modules, and vendor-specific firmware guidance. A patch can be technically valid for ESXi while still requiring a coordinated update to a network adapter driver or storage controller.

Take a configuration backup of vCenter Server and document the current ESXi build numbers. For a lab environment, a Proxmox and vSphere lab can provide a safe place to test baselines, host reboots, and rollback procedures before changing production clusters.

Create baselines and scan for compliance

Open Update Manager from the vSphere Client and review the available patch metadata. Create a baseline that contains the approved ESXi patches for the target release. Avoid combining unrelated driver or extension updates unless they have been tested together and are required for the hosts being remediated.

Attach the baseline to a cluster or selected hosts, then run a compliance scan. The results normally identify hosts as compliant, non-compliant, or unknown. Investigate unknown status before remediation because it can indicate communication problems, missing metadata, unsupported hardware, or an incomplete inventory state.

Use separate baselines for different host generations when their CPUs, controllers, network adapters, or vendor images differ. A narrowly scoped baseline is easier to audit and less likely to install an unsuitable component. Record the baseline name, patch release, approval date, and intended cluster.

Plan automated remediation

Select a maintenance window that allows time for vMotion, host evacuation, reboot, validation, and recovery if a host fails. Confirm that the cluster has sufficient capacity to tolerate one host in maintenance mode. Check admission control, HA settings, DRS automation, affinity rules, reservations, and any workloads that cannot be migrated.

Remediation settings control how Update Manager handles the host. Depending on the vSphere version, you can configure automatic maintenance mode, VM migration, power-state handling, retry behavior, and reboot options. For production systems, review these choices rather than accepting defaults.

A rolling process is generally safer than updating every host simultaneously. Update one host from a cluster, verify its health, then continue with the next host. DRS and vMotion can maintain application availability, but they do not protect workloads with hard host affinity, local storage dependencies, or special passthrough devices.

Deployment approach	Best use	Main control	Primary risk
Manual host update	Small lab or emergency patch	Administrator performs each step	Inconsistent results
Baseline remediation	Standardized clusters	Approved patch baseline	Incorrect scope or dependency
Rolling cluster remediation	Production maintenance	One host at a time	Insufficient cluster capacity
Image-based lifecycle	Consistent modern clusters	Desired ESXi image	Hardware or add-on incompatibility
Offline depot update	Isolated environments	Imported patch bundle	Stale or incomplete metadata

Run and monitor the deployment

Start remediation from the selected cluster or host after reviewing the pre-check results. Update Manager will typically scan the target, migrate workloads, place the host into maintenance mode, install the selected patches, reboot ESXi, and reconnect it to vCenter Server. The exact sequence depends on the remediation settings and vSphere release.

Watch recent tasks and events in the vSphere Client instead of assuming that a scheduled job completed successfully. Look for failed evacuations, blocked maintenance mode, insufficient datastore space, missing baselines, and hosts that do not reconnect after reboot. If a host remains unavailable, use the out-of-band management console and ESXi logs to determine whether the issue is related to boot media, firmware, storage, or networking.

Do not start the next host until the previous one has passed health checks. Confirm datastore visibility, vmkernel interfaces, management connectivity, vMotion, HA heartbeats, and network uplinks. For a cluster with strict availability requirements, pause the job after each host and require an operator approval before continuing.

Verify results and handle failures

After remediation, rescan the cluster and confirm that all intended hosts are compliant. Record the new ESXi build number and compare it with the approved patch level. Also verify that vCenter reports the expected host version and that no warning remains for outdated VMware Tools, virtual hardware, or installed extensions.

Test representative workloads, including application connectivity, storage access, backup jobs, monitoring, and management operations. A host can appear compliant while an operational issue remains hidden in a driver, firmware component, or network path.

If remediation fails, leave the host isolated until its state is understood. Review Update Manager events, host logs, compatibility reports, and the vendor release notes. Correct the underlying issue, then retry only the failed host when possible. Keep the previous ESXi image or bootbank available according to VMware’s supported rollback procedures, and do not treat rollback as a substitute for investigating the failure.

Build repeatable patch operations

Use a documented approval process so that patch content is tested before production deployment. Maintain separate test, staging, and production baselines, and assign remediation windows to cluster owners. Export compliance reports for audit records and retain the results with the change ticket.

Recommended operating practices include:

• Synchronize patch metadata on a predictable schedule.
• Test each approved ESXi build on representative hardware.
• Patch one host at a time in production clusters.
• Confirm vMotion, HA, storage, and backup health before remediation.
• Review compliance and host logs after every deployment.

PowerCLI can extend the process by reporting host build versions, checking baseline compliance, and generating inventory summaries before a maintenance window. Automation is most valuable when it exposes exceptions early and leaves a clear record of what changed.

Use vSphere Update Manager or vSphere Lifecycle Manager as part of a controlled lifecycle process rather than a one-click replacement for operational judgment. Define the desired state, validate it in a safe environment, remediate in measured batches, and document the result after every maintenance cycle. That approach turns ESXi patching into a repeatable procedure that scales across clusters without sacrificing visibility.