VMware vSphere Lifecycle Manager with custom ISO baselines

Most vSphere estates in Australian data centres hit a wall the first time someone moves off the legacy Update Manager workflow. vSphere Lifecycle Manager changes how clusters are kept current, shifting from independent VIB packages to a single desired-state image per cluster. When standard ESXi downloads from the VMware depot are enough, the experience is straightforward. The moment a vendor supplies its own customised ISO, the process needs more planning.

Vendor images from Dell, HPE, Cisco UCS and Lenovo bundle drivers, management agents and firmware tooling absent from the public depot. Skipping them leads to storage controllers dropping offline, NICs losing iSCSI paths, or BMC functions disappearing after a reboot. Custom ISO baselines exist for exactly this reason — they let an admin point vLCM at a vendor-supplied payload while keeping the desired-state model intact.

The mechanics are simple after a couple of runs, but depot configuration, HCL checks and remediation sequencing catch out plenty of teams. Whether the work happens in a Sydney CBD colocation room, a Melbourne secondary site or a remote Pilbara mining campus, the same discipline applies.

How vLCM differs from Update Manager

vLCM treats a cluster as a single unit rather than a pile of hosts to be patched independently. The desired-state configuration captures the ESXi version, vendor add-ons, drivers, firmware packages and supported firmware versions on the underlying hardware. Once that image is defined, every host is checked against it on each compliance scan, and remediation pulls the whole cluster back into line in one operation.

With Update Manager, baseline attachment was a host-level exercise. You'd attach a patch baseline here, an extension baseline there, and hope the order of operations didn't produce a dependency error. vLCM removes that ambiguity. A cluster image contains everything, ordered, and the platform refuses to remediate if any element violates the HCL. Australian teams operating under APRA CPS 234 often appreciate this strictness — auditors want proof that production matches an approved definition, and a single signed image descriptor is easier to evidence than a dozen overlapping baselines.

Preparing the vendor ISO for upload

The vendor ISO — say a Dell EMC customised image for ESXi 8.0 Update 3 — needs inspection before upload. Mount it, browse the offline bundle, and confirm the metadata matches your hardware support matrix. Drop the file on a share the vCenter Server Appliance can reach, ideally one with reasonable throughput. A 1.5 GB ISO copied across a congested link between Brisbane and a Sydney DR site frustrates everyone waiting on the remediation window.

Keep a local archive of each ISO alongside its SHA-256 checksum. When you eventually need to roll back or rebuild a depot from scratch — especially after a hardware refresh in a Perth office — having a verified copy of the original payload saves hours. Size the depot generously up front; the default 25 GB is tight once you accumulate baselines across two or three major ESXi releases.

Uploading the ISO to the image depot

vLCM uses a depot accessible from the cluster's Updates tab. After uploading the ISO through the vSphere Client, it appears as a vendor add-on alongside the standard VMware components. The cluster image editor then lets you drag the add-on into the desired state, where vLCM validates it against the HCL before accepting it. If the upload fails with an integrity error, double-check that the ISO hasn't been corrupted during transfer.

Australian WAN links between metro data centres are usually solid, but sites in regional WA or the NT often cope with higher latency and the occasional packet loss that breaks large file transfers. Resumable tools and a retry usually clear it. PowerCLI makes this scriptable for fleets across multiple clusters — the Set-VlmImage cmdlet and the depot cmdlets accept pipeline input, so a CSV listing each cluster, its preferred ISO and its depot location is enough to spin up baselines across a Sydney-to-Melbourne stretched estate without manual clicking.

Attaching the baseline and checking compliance

With the depot populated, attach the custom ISO baseline to a cluster and run a compliance check. The result tells you which hosts already match the desired state and which need remediation. Pay attention to the per-component breakdown — a host might match the ESXi base but lag on the vendor add-on because it was patched manually last quarter.

For clusters that can't tolerate a maintenance window — think payments processing for a Big Four bank in Sydney, or the SCADA front-end at a Pilbara iron ore operation — run the scan during business hours but defer remediation to a scheduled change window. vLCM supports this through separate staging and remediation phases. ASD's Essential Eight maturity guidance encourages exactly this separation of duties: one operator runs the scan, another holds the keys for remediation. Bake those roles into your vCenter SSO groups before the first production run.

Running remediation and capturing the logs

Remediation happens one host at a time, respecting the cluster's HA settings. The host enters maintenance mode, evicts VMs via vMotion, applies the new image, reboots and rejoins the cluster. Watch the task console closely — the longest delays usually come from firmware flash operations on the BMC or storage controller, not from ESXi itself.

A failed remediation doesn't roll back automatically. If the new image breaks a NIC driver, the host may reboot into a state where vCenter can't see it. Out-of-band management — iLO, iDRAC, CIMC — becomes your lifeline. Have those credentials cached somewhere reachable; a 2 a.m. trip to a Sydney Macquarie Park data centre because the iDRAC IP was unknown to the on-call is a preventable lesson. Capture the remediation log as soon as each host finishes — the logs end up buried under task IDs, and pulling them later for a post-incident review is painful. A small PowerCLI snippet that exports logs per host to a dated folder pays for itself the first time something goes sideways.

Common pitfalls and how to dodge them

The most frequent issue is a baseline that references a vendor ISO no longer in the depot, usually because someone cleaned up old payloads. vLCM flags the cluster as non-compliant and refuses to remediate. Never delete a baseline until every cluster referencing it has moved on.

Another trap is mismatched firmware. The vendor ISO might require a minimum iDRAC or UCS Manager version that isn't yet applied to the rack. vLCM catches this through the HCL check, but only if the hardware support manager is current. Sync firmware first, then run the compliance scan. Watch out for stretched clusters with mixed hardware generations too — an older host in a Melbourne site may not support the same driver set as its Sydney sibling. Either carve the cluster into separate vLCM groups or accept a lower common-denominator image.

Automating the cycle with PowerCLI

Once the manual run is done, automating the next cycle is straightforward. A scheduled script can pull the latest vendor ISO from an internal SFTP server, upload it to the depot, refresh the baseline and trigger a compliance scan. Remediation itself should still require human approval — automation that reboots production hosts without a sign-off rarely survives a post-mortem.

Store the script in a Git repo and tag each release with the matching ISO checksum. Australian teams subject to PSPF or IRAP assessments will recognise the audit value of a versioned pipeline that produces a clear trail from ISO checksum to cluster image to remediation timestamp.

Pair the automation with a simple dashboard — a Power BI tile or a scheduled email — that lists each cluster, its compliance status and the age of its current image. Watching a fleet of two dozen clusters across Sydney, Melbourne, Brisbane and a remote WA site tick from amber to green after a maintenance weekend is one of the small wins that keeps the job rewarding.