Automating vSphere Host Profile application with PowerCLI

A vSphere host profile stores an approved ESXi configuration baseline, including selected networking, storage, security and patch-related settings. Applying it through PowerCLI replaces a sequence of manual console choices with a repeatable command that can be logged, reviewed and reused. The practical goal is to automate vSphere Host Profile application without overlooking host maintenance, permissions or configuration drift.

This workflow suits Australian organisations operating ESXi across corporate data centres, managed service provider estates and regional branch offices. Teams in Sydney and Melbourne may have low-latency access to vCenter, while sites in Brisbane or Perth can experience slower WAN links. Scheduling must also account for AEST and AEDT, because daylight-saving changes shift UTC-based jobs by an hour.

Confirm support and prepare the environment

Before scripting, check the vCenter version, ESXi build and installed PowerCLI release. VMware deprecated vSphere Host Profiles in vSphere 7.0, and their availability is restricted in later releases. This guidance applies where Host Profile Manager and the relevant cmdlets remain available; otherwise, use the same approval and verification pattern with supported configuration-management tooling.

Create a dedicated service account with permission to read and apply profiles, manage hosts and enter maintenance mode. Test the process against a canary host, and document how HA and DRS evacuation will be handled. The Virtxpert technology blog contains related VMware automation material that complements this operational runbook.

Connect to vCenter with PowerCLI

Install the module in a controlled workstation or automation environment, then open a session with valid credentials:

Install-Module VMware.PowerCLI -Scope CurrentUser
Import-Module VMware.PowerCLI

$credential = Get-Credential
$vcenter = Connect-VIServer `
    -Server 'vc-au.example.com' `
    -Credential $credential

Use a certificate trusted by the workstation rather than disabling certificate validation globally. Keep the returned $vcenter connection for subsequent commands, and avoid embedding credentials in scripts or source control. For production automation, retrieve credentials from an approved vault or inject them through protected CI variables.

Resolve the profile and target hosts

Retrieve the named profile and select only the intended hosts. Explicit host names are suitable for a small pilot, while tags, an inventory source or a configuration-management database work better for a larger fleet.

$profile = Get-VMHostProfile `
    -Server $vcenter `
    -ProfileName 'AU Standard'

$targets = Get-VMHost -Server $vcenter |
    Where-Object {
        $_.ConnectionState -eq 'Connected' -and
        $_.Name -in @('esx-syd-01', 'esx-mel-01')
    }

if (@($profile).Count -ne 1) {
    throw 'Expected exactly one matching host profile.'
}

Review the profile contents before applying it. Confirm its scope, included settings, patch baseline and any local overrides. Host profiles can support evidence against ASD Essential Eight controls, but applying one does not by itself establish compliance. Any configuration outside the profile may remain locally managed.

Apply the profile and confirm the result

Place each target into maintenance mode using the approved change process, allowing HA and DRS to evacuate workloads safely. Then apply the profile with PowerCLI and stop on the first unexpected error:

foreach ($target in $targets) {
    try {
        $target |
            Update-VMHost `
                -HostProfile $profile `
                -ApplyProfile `
                -ErrorAction Stop

        Write-Host "Applied '$($profile.Name)' to $($target.Name)."
    }
    catch {
        Write-Error "Profile application failed for $($target.Name): $($_.Exception.Message)"
        throw
    }
}

Re-query the host and confirm the association after every application. An applied-profile name alone does not prove that every desired value took effect, so compare important settings with the approved baseline.

$check = Get-VMHost -Server $vcenter -Name $target.Name
$applied = Get-VMHostProfile -Entity $check -Server $vcenter

if ($applied.Name -notcontains $profile.Name) {
    throw "Profile verification failed for $($target.Name)."
}

Capture the target, profile identifier, timestamps, PowerCLI version and result in an audit log. Failed or partial changes should trigger investigation before the script continues across the fleet.

Compare the operating models

A one-time console change suits a single exceptional host, but it offers limited repeatability. Scripted execution scales better, while scheduled automation provides stronger approvals and auditability.

Approach Best fit Main strength Main limitation
vSphere interface Isolated manual change Familiar and visually verifiable Prone to drift and inconsistent execution
One-off PowerShell Known batch of hosts Fast, targeted and scriptable Depends on the administrator running it
GitLab CI or scheduler Recurring fleet workflow Approval gates, logging and controlled execution Requires secure runners and credential management

For Australian MSP-managed estates, the operating model matters as much as the command. Shared runbooks, explicit profile ownership and recorded rollback steps prevent important knowledge from remaining in one engineer’s shell history.

Standardise the workflow and prepare the next rollout

Store the script in Git, pin the supported PowerCLI version and run static analysis before deployment. Runner preparation is covered in the GitLab CI deployment guide, but production runners should use protected credentials, restricted network access and suitable approval gates.

A practical operating policy should include:

Select a non-production or canary ESXi host, record its current baseline, and run the application and verification sequence as your first controlled test. Expand the workflow only after the canary proves reliable during an approved AEST or AEDT maintenance window.