If you manage a VMware environment and you're still clicking through the vSphere Client for routine tasks, you're spending hours every week on work that scripts can do in seconds. VCF PowerCLI (the tool formerly known as VMware PowerCLI) is the standard automation tool for vSphere admins, and the setup story changed materially over the last year. This guide walks through installing the current version, handling the gotchas that trip people up, and running your first real automation.

Version note: commands below assume VCF PowerCLI 9.x. Check the latest available version on the PowerShell Gallery with Find-Module VCF.PowerCLI or Find-PSResource VCF.PowerCLI before pinning anything in build standards.

The rename: VMware PowerCLI is now VCF PowerCLI

The first thing that confuses everyone is the package name. The module you've been installing for years, VMware.PowerCLI, has been rebranded to VCF.PowerCLI. This happened alongside the VCF 9.0 release and carried through to the current VCF 9.1 release. Broadcom's documentation now points to VCF.PowerCLI as the current package.

The older VMware.PowerCLI package may still be present on the Gallery for compatibility, but new installs should use VCF.PowerCLI. The cmdlets you already know (Get-VM, Connect-VIServer, New-VM, Start-VM) all work the same way under the new package. The rebrand is mostly cosmetic at the module level.

For traditional vSphere operations, familiar cmdlets such as Get-VM and Connect-VIServer remain the main interface. Separately, newer VCF-specific modules expose more of the VCF REST API surface, which means VCF-level operations (managing SDDC Manager, working with VCF inventory, lifecycle operations) now have native cmdlets instead of requiring you to hand-roll REST calls.

The practical split: if you're managing a traditional vSphere cluster (ESXi hosts, vCenter, VMs), you're using the same core cmdlets you've always used. If you're running full VCF with SDDC Manager and the lifecycle tooling, you now have first-class automation for that layer too. For a deeper look at the VCF 9 platform itself, see the VCF 9 nested lab walkthrough.

Prerequisites: what you need before installing

VCF PowerCLI runs on PowerShell 5.1 (Windows) and PowerShell 7.x (cross-platform). Check the module's supported PowerShell versions in the current Broadcom or PowerShell Gallery documentation for your specific case. For anything new, prefer PowerShell 7.x unless you have a Windows PowerShell 5.1 dependency. Microsoft is not adding features to Windows PowerShell 5.1, and several newer modules behave better on PowerShell 7.

The cross-platform support is genuine: PowerCLI can run from Windows, macOS, or Linux when installed in PowerShell 7. You need a machine with internet access to the PowerShell Gallery for online installation, or a way to transfer the offline package for air-gapped environments. You do not need a VMware/Broadcom account to install from the Gallery. That trips people up because Broadcom has put download walls in front of so many things since the acquisition, but the PSGallery modules are public.

Installing VCF PowerCLI

The install is one command. Open PowerShell (as your normal user; no admin required if you use the CurrentUser scope) and run:

Install-Module -Name VCF.PowerCLI -Scope CurrentUser

If you're on PowerShell 7.x and prefer the newer PSResourceGet cmdlet (which is replacing PowerShellGet over time):

Install-PSResource -Name VCF.PowerCLI -Scope CurrentUser

Either works. The first time you run either, you'll get a prompt about trusting the PowerShell Gallery repository. The PSGallery is not trusted by default in fresh PowerShell installations. Answer Yes, or unblock it once.

For PowerShellGet (Install-Module):

Set-PSRepository -Name PSGallery -InstallationPolicy Trusted

For PSResourceGet (Install-PSResource), the cmdlet is different:

Set-PSResourceRepository -Name PSGallery -Trusted

If you previously installed the old VMware.PowerCLI package, both can coexist. Do not remove the older package from shared automation hosts until you have tested existing scripts. On a workstation, you can inspect what's installed first:

Get-Module -ListAvailable VMware.PowerCLI, VCF.PowerCLI

Depending on how the modules were installed, shared VMware.* submodules (VMware.VimAutomation.Core, VMware.VimAutomation.Vds, etc.) may remain as dependencies of the newer package. That's normal.

Confirm the install and check your version:

Get-Module -ListAvailable VCF.PowerCLI

As of this writing, the current release is 9.1. If you're upgrading from an older VMware PowerCLI release, the update path is the same command:

Update-Module -Name VCF.PowerCLI

Or with PSResourceGet:

Update-PSResource -Name VCF.PowerCLI

The offline install path (air-gapped environments)

A lot of VMware environments don't have direct internet access from the management network. For those, you need the offline package.

The simplest approach doesn't require the Broadcom portal at all. From an internet-connected machine, use Save-Module or Save-PSResource to pull the package locally:

Save-Module -Name VCF.PowerCLI -Path C:\Temp\PowerCLI-Offline

Then transfer that folder to your target machine and copy it into one of your PowerShell module paths. Find those paths with $env:PSModulePath. The CurrentUser module path on Windows is typically C:\Users\<you>\Documents\PowerShell\Modules.

The expected layout after copying:

C:\Users\<you>\Documents\PowerShell\Modules\VCF.PowerCLI\<version>\VCF.PowerCLI.psd1

The module folder name must match the module name exactly (VCF.PowerCLI) and must sit directly under a path listed in $env:PSModulePath. If Get-Module -ListAvailable VCF.PowerCLI returns nothing after an offline install, the folder is in the wrong place or the version subfolder is missing.

Broadcom also hosts a VCF PowerCLI zip on the developer portal for offline download. Access there may require a Broadcom account depending on the download location. If you need help finding downloads inside the Broadcom portal, the Broadcom support portal guide covers where things live after the reorganization.

First-time configuration: two settings you should change

After installation, PowerCLI has two default behaviors you should change before doing anything else. Both are one-time settings scoped to your user that persist across sessions.

The first is CEIP, the Customer Experience Improvement Program. By default, PowerCLI may prompt you about CEIP participation on first use. If you're in an environment where telemetry needs explicit approval, handle it explicitly:

Set-PowerCLIConfiguration -ParticipateInCEIP $false -Scope User -Confirm:$false

The second is certificate validation. If your vCenter uses the VMware default self-signed certificate (which it does out of the box, and which many shops never replace), PowerCLI will refuse to connect by default because the cert isn't trusted. For labs, set InvalidCertificateAction to Ignore:

Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Scope User -Confirm:$false

For production, do it properly: export the vCenter certificate and add it to the trusted root certification authorities on whatever machine runs your PowerCLI scripts. The ignore setting is fine for a lab or a throwaway workstation. It is not fine for a production admin machine that touches multiple environments.

One more configuration that matters if you work across multiple vCenters simultaneously. By default, PowerCLI operates in single-server mode: connecting to a second vCenter disconnects the first. If you regularly work across two or more vCenters, switch to multiple mode:

Set-PowerCLIConfiguration -DefaultVIServerMode Multiple -Scope User -Confirm:$false

In multiple mode, your $global:defaultVIServers array holds every connected vCenter, and cmdlets like Get-VM return results from all of them unless you scope with the -Server parameter.

Connecting to vCenter

For interactive use, prompt for credentials. Don't hardcode passwords in scripts.

$cred = Get-Credential
Connect-VIServer -Server vcenter.domain.local -Credential $cred

If you're deploying vCenter fresh, the vCenter Server Appliance deployment walkthrough covers getting to the point where you have something to connect to.

Once connected, a quick health check:

Get-VM | Select-Object Name, PowerState, NumCpu, MemoryGB

That returns every VM on the connected vCenter with its name, power state, CPU count, and memory allocation. If that returns data, your installation and connection are working.

Common first automation tasks

Here are three tasks I've seen admins need in their first week with PowerCLI. These are the building blocks for everything else.

Report on all powered-off VMs across the environment:

Get-VM | Where-Object { $_.PowerState -eq 'PoweredOff' } |
  Select-Object Name,
    @{N='Folder';E={$_.Folder.Name}},
    @{N='Host';E={ if ($_.VMHost) { $_.VMHost.Name } else { '' } }} |
  Export-Csv -Path C:\temp\powered-off-vms.csv -NoTypeInformation

Powered-off VMs still consume datastore capacity and create operational overhead. Cleaning them up reclaims storage and makes consolidation easier, which matters under Broadcom's VVF/VCF licensing where every host core is a paid asset whether those VMs are running or not.

Create a new VM from a template (the most common provisioning pattern):

$template = Get-Template -Name "WindowsServer2022_Template"
$rp = Get-ResourcePool -Name "Production"
$datastore = Get-Datastore -Name "vsanDatastore"
$spec = Get-OSCustomizationSpec -Name "Windows-Domain-Join"

New-VM -Name "web-srv-01" -Template $template -ResourcePool $rp `
  -Datastore $datastore -OSCustomizationSpec $spec

The -OSCustomizationSpec applies your sysprep configuration (domain join, IP assignment, admin password) automatically. Without guest customization, you risk duplicate hostname, network identity, and domain-join problems unless your template and post-clone process handle that separately.

Take a snapshot of every VM in a specific folder before a maintenance window:

$folder = Get-Folder -Name "Pre-Maintenance"
Get-VM -Location $folder | New-Snapshot -Name "Pre-Patch-$(Get-Date -Format yyyyMMdd)" -Description "Pre-maintenance rollback point"

Snapshots are not backups, but a pre-maintenance snapshot is a fast rollback point. Just remember to delete them after you've confirmed the patches applied cleanly, because snapshots grow and degrade performance over time.

Running PowerCLI from Linux and macOS

The cross-platform support is one of the genuine improvements since the rebrand. Install PowerShell 7 on a Linux management box and you have the same cmdlet set. On Ubuntu 24.04, you need Microsoft's package repository first:

# Add Microsoft's package repository (Ubuntu 24.04 example)
wget https://packages.microsoft.com/config/ubuntu/24.04/packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
sudo apt update
sudo apt install -y powershell
pwsh

Then inside the pwsh session:

Install-Module -Name VCF.PowerCLI -Scope CurrentUser
Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Scope User -Confirm:$false
Connect-VIServer -Server vcenter.domain.local

This matters because a lot of automation infrastructure runs on Linux. If your CI/CD pipeline, scheduled job runner, or Ansible control node is already Linux, you don't need to stand up a Windows VM just to run PowerCLI.

Common problems and fixes

The most common error after a fresh install is a certificate validation failure when connecting. You'll see something like "The server certificate on 'vcenter.domain.local' could not be validated." That's the InvalidCertificateAction setting covered above. For labs, set it to Ignore. For production, import the vCenter certificate into the trusted root store.

The second most common is a module load failure after the offline install path, usually because the zip was extracted to the wrong directory. The module folder name must match the module name exactly (VCF.PowerCLI) and must sit directly under a path listed in $env:PSModulePath. If Get-Module -ListAvailable VCF.PowerCLI returns nothing after an offline install, the folder is in the wrong place or the version subfolder is missing.

The third is running an old script that references VMware.VimAutomation.Core explicitly in an Import-Module line at the top. That submodule still exists under VCF.PowerCLI, so the import will work, but if you're modernizing the script, drop the explicit Import-Module line entirely. PowerShell auto-loads modules when you use a cmdlet from them, and the explicit import is legacy from the PowerCLI 5.x days.

Migrating your existing scripts

If you have a library of VMware PowerCLI scripts, most will work unchanged under VCF PowerCLI. The cmdlet names are identical. What you should do:

If a script breaks after upgrade, check the release notes on the Broadcom developer portal before assuming a bug.

When to use PowerCLI vs other tools

VCF PowerCLI is the right tool for vSphere and VCF automation. It is not the right tool for everything. If you're scripting guest-OS-level operations (installing software, managing services inside Windows or Linux VMs), use the native OS tooling: PowerShell remoting or DSC for Windows, Ansible or SSH-based bash for Linux. PowerCLI manages the VM as an object in vSphere; it doesn't replace guest-level config management.

For infrastructure-as-code across large deployments, Terraform is often a better fit when you need declarative state, repeatable builds, and dependency tracking. PowerCLI is usually better for reporting, one-off remediation, and imperative day-2 operations on an existing environment. Most mature teams use both: Terraform to build, PowerCLI to operate.

Keeping it updated

VCF PowerCLI 9.x is aligned with the VCF 9.x generation. Always check the PowerShell Gallery and Broadcom release notes for the current version and compatibility details. The update is a single command:

# PowerShellGet
Update-Module -Name VCF.PowerCLI

# PSResourceGet
Update-PSResource -Name VCF.PowerCLI

Check your installed version before and after with Get-Module -ListAvailable VCF.PowerCLI. Older PowerCLI versions will connect to newer vCenters, but newer features and properties won't be available, and you may hit API compatibility warnings.

The setup is a one-time investment. Once VCF PowerCLI is installed and configured, every report, bulk change, and inventory export you'd otherwise do by hand becomes a script you write once and run forever. That's the entire value proposition, and it pays back the setup time within the first week of real use.

Stay ahead of the VMware changes

We're publishing detailed licensing breakdowns, comparison guides, migration walkthroughs, and cost calculators. Get them in your inbox.