How to Install and Update VCF PowerCLI 9.1 on Windows, macOS, and Linux

TL;DR

PowerCLI is now distributed through the VCF.PowerCLI package. The older VMware.PowerCLI package is deprecated, although many familiar cmdlets and underlying VMware.* modules remain in use.

For a new installation, use:

Install-Module -Name VCF.PowerCLI `
    -Scope CurrentUser `
    -Repository PSGallery

For an existing VMware.PowerCLI installation, audit scripts for explicit Import-Module VMware.PowerCLI statements, prefer a clean migration where practical, and use -AllowClobber and -SkipPublisherCheck only when resolving the documented upgrade conflicts.

VCF PowerCLI 9.1 can also be installed offline by downloading the complete Broadcom ZIP package or staging the package and its dependencies with Save-Module. Offline installations cannot be updated with Update-Module. They must be refreshed by deploying a newer offline bundle.

This guide targets VCF.PowerCLI version 9.1.0.25380678.

Introduction

PowerCLI installation used to begin with one familiar package name:

Install-Module -Name VMware.PowerCLI

That command is now outdated. PowerCLI continues as VCF.PowerCLI, aligning the automation toolkit with VMware Cloud Foundation while preserving the cmdlets administrators already use for vCenter, ESXi, vSAN, NSX, Cloud Director, and related platforms.

The package transition is straightforward on a clean workstation. It becomes more complicated on long-lived administration systems where several PowerCLI versions, module paths, script imports, service accounts, and manually copied modules may already exist.

A successful upgrade therefore requires more than replacing one package name. You need to determine what is installed, where it is installed, how scripts import it, which package manager owns it, and whether the system can reach the PowerShell Gallery.

This article provides a complete installation and update workflow for Windows, macOS, and Linux. It also covers migration from VMware.PowerCLI, offline deployment, version verification, certificate configuration, and the most common installation failures.

What You Will Accomplish

By the end of this guide, you will be able to:

• Identify existing VMware.PowerCLI and VCF.PowerCLI installations.
• Install VCF PowerCLI 9.1 on Windows, macOS, and Linux.
• Migrate scripts from the deprecated top-level package.
• Install VCF PowerCLI on disconnected systems.
• Update gallery-managed installations correctly.
• Verify the top-level package and its child modules.
• Confirm which copy of a module PowerShell is loading.
• Test PowerCLI by connecting to a vCenter Server.
• Troubleshoot command conflicts, publisher changes, module-path problems, and offline update failures.

Understanding the VMware.PowerCLI to VCF.PowerCLI Transition

The most important change is the name of the top-level distribution package.

Component	Previous state	Current state	Required action
Installation package	VMware.PowerCLI	VCF.PowerCLI	Update install and update commands
Explicit top-level import	Import-Module VMware.PowerCLI	Import-Module VCF.PowerCLI	Update scripts and profiles
Common cmdlets	Connect-VIServer, Get-VM, Get-Cluster	Same cmdlet names	Usually no cmdlet rewrite required
Child modules	Primarily VMware.*	Many remain VMware.*	Do not rename child-module imports without checking
Top-level version	13.3 release family	9.1 release family	Validate the package separately from dependencies
Code-signing publisher	VMware-era signing	Broadcom signing	Existing systems may report a publisher mismatch

Broadcom describes VCF.PowerCLI as the continuation of VMware.PowerCLI. That does not mean every existing environment can be upgraded without review.

Most scripts that simply call PowerCLI cmdlets should continue to operate. Scripts that explicitly import VMware.PowerCLI, validate package names, pin old versions, or build runners from the deprecated package must be updated.

Many child modules still use names such as:

VMware.VimAutomation.Core
VMware.VimAutomation.Storage
VMware.VimAutomation.Nsxt
VMware.VimAutomation.Sdk

This is expected. The move to VCF.PowerCLI does not mean every module and cmdlet has been renamed.

The Installation and Migration Workflow

The workflow below separates fresh installation, package migration, updating, and offline deployment.

The point to notice is that installation method determines update method. A gallery-managed module can use the package manager for updates. A module copied into a PowerShell module path must be updated by replacing or supplementing the offline files.

Prerequisites and Assumptions

VCF.PowerCLI 9.1 lists PowerShell 5.1 as its minimum PowerShell version. PowerShell 7 is the better baseline for new deployments because the same runtime can be used across Windows, macOS, and Linux.

Before installing or updating PowerCLI, confirm:

• PowerShell 7 is installed on macOS and Linux.
• Windows is using either Windows PowerShell 5.1 or PowerShell 7.
• The account has permission to write to the selected module path.
• Internet-connected systems can reach the PowerShell Gallery.
• Proxy and TLS controls permit PowerShell package downloads.
• Offline systems have an approved artifact-transfer process.
• Existing automation jobs are stopped before modules are removed or replaced.
• A representative vCenter endpoint is available for functional validation.
• Existing scripts and PowerShell profiles have been backed up or committed to source control.

Use CurrentUser scope unless there is a defined requirement for a shared AllUsers installation. User-scoped installations reduce the need for elevation and make it easier to isolate administrator and service-account dependencies.

Inspect the Existing PowerCLI Installation

Do not uninstall anything until you understand the current state.

Start by identifying the PowerShell runtime:

$PSVersionTable |
    Select-Object PSVersion, PSEdition, Platform, OS

Then inspect the module paths searched by the current PowerShell process:

$env:PSModulePath -split [IO.Path]::PathSeparator

The order matters. PowerShell can find several versions of the same module in different directories. A newer package can be installed correctly while an older package is still loaded from another path.

Check for package-manager records:

'VMware.PowerCLI', 'VCF.PowerCLI' |
    ForEach-Object {
        Get-InstalledModule -Name $_ `
            -AllVersions `
            -ErrorAction SilentlyContinue
    } |
    Sort-Object Name, Version -Descending |
    Select-Object Name, Version, InstalledLocation

Now check everything PowerShell can discover, including manually copied modules:

Get-Module -Name VMware.PowerCLI, VCF.PowerCLI `
    -ListAvailable |
    Sort-Object Name, Version -Descending |
    Select-Object Name, Version, ModuleBase

These two checks answer different questions.

Get-InstalledModule reports modules installed through PowerShellGet. Get-Module -ListAvailable searches the active module paths and can find copied offline modules that have no package-manager record.

Also inspect loaded modules:

Get-Module VMware.*, VCF.PowerCLI |
    Sort-Object Name |
    Select-Object Name, Version, ModuleBase

If PowerCLI modules are already loaded, close PowerShell before removing or replacing them. Updating files does not replace modules already loaded into the current process.

Install VCF PowerCLI 9.1 on Windows

Open PowerShell 7 or Windows PowerShell.

A CurrentUser installation normally does not require an elevated console:

Install-Module -Name VCF.PowerCLI `
    -Scope CurrentUser `
    -Repository PSGallery

This command:

• Retrieves VCF.PowerCLI from the registered PowerShell Gallery.
• Installs the top-level package.
• Downloads the required dependencies.
• Places the modules in the CurrentUser module path.
• Makes the modules available to future PowerShell sessions.

To install the exact VCF PowerCLI 9.1 build used in this article:

Install-Module -Name VCF.PowerCLI `
    -RequiredVersion 9.1.0.25380678 `
    -Scope CurrentUser `
    -Repository PSGallery

Version pinning is useful for shared administration workstations, build runners, scheduled tasks, and automation servers where a controlled dependency baseline matters more than automatically receiving the newest release.

For an AllUsers installation, open an elevated PowerShell session and use:

Install-Module -Name VCF.PowerCLI `
    -Scope AllUsers `
    -Repository PSGallery

Do not alternate between CurrentUser and AllUsers installations without documenting the module paths. The same workstation can otherwise contain several copies, making interactive testing different from scheduled execution.

Install VCF PowerCLI 9.1 on macOS

PowerCLI runs on macOS through PowerShell 7.

Open Terminal and start PowerShell:

pwsh

Install VCF.PowerCLI for the current user:

Install-Module -Name VCF.PowerCLI `
    -Scope CurrentUser `
    -Repository PSGallery

To install the exact 9.1 build:

Install-Module -Name VCF.PowerCLI `
    -RequiredVersion 9.1.0.25380678 `
    -Scope CurrentUser `
    -Repository PSGallery

The common CurrentUser module location on macOS is:

$HOME/.local/share/powershell/Modules

Always confirm the actual module paths with:

$env:PSModulePath -split [IO.Path]::PathSeparator

Do not assume a module path based only on the operating system. PowerShell profiles, package managers, and enterprise configuration can modify the path list.

Install VCF PowerCLI 9.1 on Linux

Open the Linux shell and start PowerShell:

pwsh

Install VCF.PowerCLI for the current user:

Install-Module -Name VCF.PowerCLI `
    -Scope CurrentUser `
    -Repository PSGallery

To install the exact 9.1 package:

Install-Module -Name VCF.PowerCLI `
    -RequiredVersion 9.1.0.25380678 `
    -Scope CurrentUser `
    -Repository PSGallery

The common CurrentUser module location on Linux is:

$HOME/.local/share/powershell/Modules

On shared automation hosts, decide whether the automation account should own its module installation or whether the system image should provide an AllUsers installation. Mixing both models often causes version drift between interactive sessions and scheduled jobs.

Install VCF PowerCLI with PSResourceGet

Newer PowerShell environments can use Microsoft.PowerShell.PSResourceGet instead of PowerShellGet.

For a fresh installation:

Install-PSResource -Name VCF.PowerCLI `
    -Version 9.1.0.25380678 `
    -Scope CurrentUser `
    -Repository PSGallery `
    -TrustRepository

Use one package-management approach consistently on a host.

Avoid installing with Install-Module, updating with Update-PSResource, copying newer files manually, and then expecting all tools to report the same installation state. A consistent method makes troubleshooting and rollback significantly easier.

Migrate from VMware.PowerCLI to VCF.PowerCLI

Broadcom recommends starting with a clean installation where practical. The migration should begin with script analysis, not package removal.

Find Explicit VMware.PowerCLI Imports

Search scripts, profiles, scheduled-task wrappers, pipeline files, and runbooks for:

Import-Module VMware.PowerCLI

Update the top-level import to:

Import-Module VCF.PowerCLI

A simple repository scan can locate affected PowerShell files:

$ScriptRoot="C:\Automation"

Get-ChildItem -Path $ScriptRoot `
    -Filter '*.ps1' `
    -Recurse `
    -File |
    Select-String -Pattern 'VMware\.PowerCLI' |
    Select-Object Path, LineNumber, Line

Change $ScriptRoot to the folder containing your scripts.

Do not automatically replace specific child-module imports such as:

Import-Module VMware.VimAutomation.Core

Those module names may still be valid and are separate from the deprecated top-level package.

Perform a Clean Migration

Close all PowerShell sessions running PowerCLI.

Open a new session and capture the legacy installation:

Get-InstalledModule -Name VMware.PowerCLI `
    -AllVersions `
    -ErrorAction SilentlyContinue |
    Select-Object Name, Version, InstalledLocation

Remove the old top-level package:

Uninstall-Module -Name VMware.PowerCLI `
    -AllVersions `
    -Force

Install VCF.PowerCLI 9.1:

Install-Module -Name VCF.PowerCLI `
    -RequiredVersion 9.1.0.25380678 `
    -Scope CurrentUser `
    -Repository PSGallery

Uninstall-Module only manages modules installed through Install-Module. It can also refuse to remove a module when another installed module depends on it.

Do not respond by deleting every VMware.* directory. VCF.PowerCLI itself depends on VMware-named modules. Remove only the confirmed legacy top-level package or the exact obsolete version directories you have validated.

Perform an In-Place Migration

An in-place transition may be necessary on a shared administration system where removing the old package first creates too much operational risk.

Before using conflict-bypass parameters, verify the repository and package:

Get-PSRepository -Name PSGallery

Find-Module -Name VCF.PowerCLI `
    -Repository PSGallery |
    Select-Object Name, Version, Repository

Then install VCF.PowerCLI with the documented migration parameters:

Install-Module -Name VCF.PowerCLI `
    -RequiredVersion 9.1.0.25380678 `
    -Scope CurrentUser `
    -Repository PSGallery `
    -Force `
    -AllowClobber `
    -SkipPublisherCheck

-AllowClobber permits installation when command names overlap with modules already installed.

-SkipPublisherCheck allows the installation to proceed when existing VMware-signed modules conflict with newer Broadcom-signed modules.

These parameters should not become standard installation defaults. Use them only after confirming the package source and understanding why the conflict occurred.

After installation:

• Close PowerShell.
• Open a new session.
• Import VCF.PowerCLI.
• Run representative automation scripts.
• Validate vCenter connectivity.
• Remove the deprecated top-level package after successful testing.

Update an Online VCF PowerCLI Installation

The update command depends on the tool used for the original installation.

Update a PowerShellGet Installation

For a package installed with Install-Module:

Update-Module -Name VCF.PowerCLI `
    -Scope CurrentUser

To update to a specific approved version:

Update-Module -Name VCF.PowerCLI `
    -RequiredVersion 9.1.0.25380678 `
    -Scope CurrentUser

To reinstall without confirmation:

Update-Module -Name VCF.PowerCLI `
    -Scope CurrentUser `
    -Force

Update-Module only updates modules installed through Install-Module. It searches the active module paths and installs the updated version side by side.

The current PowerShell process does not automatically switch to the new version. Close and reopen PowerShell, or explicitly import the required version after removing the loaded copy.

Update a PSResourceGet Installation

For a package installed with Install-PSResource:

Update-PSResource -Name VCF.PowerCLI `
    -Scope CurrentUser `
    -Repository PSGallery `
    -TrustRepository

PSResourceGet also installs the updated resource side by side with older versions. Start a new PowerShell session before final validation.

Install VCF PowerCLI 9.1 Offline

Offline installation is common in secure management networks, disconnected administration zones, isolated laboratories, and production jump hosts with restricted internet access.

There are two practical methods:

• Download the complete ZIP package from Broadcom.
• Build a controlled dependency bundle with Save-Module.

Use the Official Broadcom ZIP Package

For VCF PowerCLI 9.1, the official package is:

VCF-PowerCLI-9.1.0-25380678.zip

Broadcom publishes the following MD5 value for that file:

17bd70c7af5d3655b2cf29790ac12ab6

After downloading the file on an internet-connected workstation, verify it:

$PackagePath="C:\Staging\VCF-PowerCLI-9.1.0-25380678.zip"

(Get-FileHash -Path $PackagePath -Algorithm MD5).Hash.ToLowerInvariant()

Compare the output with the published value.

MD5 is being used here as a transfer-integrity check because it is the hash Broadcom publishes with this package. It does not replace source validation, trusted artifact handling, or digital-signature verification.

Transfer the ZIP file through the organization-approved process and preserve the original archive in an internal software repository.

Build an Offline Bundle with Save-Module

Save-Module downloads the selected module and its dependencies without installing them.

On an internet-connected staging system:

$StagingRoot="C:\Staging\VCF-PowerCLI-9.1"

New-Item -ItemType Directory `
    -Path $StagingRoot `
    -Force |
    Out-Null

Save-Module -Name VCF.PowerCLI `
    -RequiredVersion 9.1.0.25380678 `
    -Repository PSGallery `
    -Path $StagingRoot `
    -Force

Review the downloaded folders:

Get-ChildItem -Path $StagingRoot -Directory |
    Sort-Object Name |
    Select-Object Name

Create a transport archive:

$ArchivePath="C:\Staging\VCF-PowerCLI-9.1-Offline.zip"

Compress-Archive `
    -Path "$StagingRoot\*" `
    -DestinationPath $ArchivePath `
    -Force

The staging folder should contain the top-level VCF.PowerCLI package and its dependencies.

Do not use the raw .nupkg download as the only offline artifact unless you also handle extraction and dependencies. The PowerShell Gallery warns that the raw package is not unpacked and does not include dependency packages.

Select the Offline Target Module Path

On the disconnected system, inspect the active module paths:

$ModulePaths = $env:PSModulePath -split [IO.Path]::PathSeparator
$ModulePaths

Common paths include:

Platform	Common CurrentUser module path
PowerShell 7 on Windows	User Documents folder followed by PowerShell\Modules
Windows PowerShell 5.1	User Documents folder followed by WindowsPowerShell\Modules
PowerShell 7 on macOS	$HOME/.local/share/powershell/Modules
PowerShell 7 on Linux	$HOME/.local/share/powershell/Modules

Use a path returned by the current session. This is especially important on Windows systems where the Documents folder may be redirected through Group Policy or OneDrive.

Set the destination to one of the active module paths:

$ArchivePath="C:\Staging\VCF-PowerCLI-9.1-Offline.zip"
$TargetModulePath="C:\Users\Administrator\Documents\PowerShell\Modules"

New-Item -ItemType Directory `
    -Path $TargetModulePath `
    -Force |
    Out-Null

Expand-Archive `
    -Path $ArchivePath `
    -DestinationPath $TargetModulePath `
    -Force

Change $TargetModulePath to the valid location for the target user and PowerShell edition.

On Windows, unblock the transferred files:

Get-ChildItem -Path $TargetModulePath `
    -Recurse `
    -File |
    Unblock-File

Close PowerShell and open a new session before testing discovery.

Validate the Offline Folder Layout

Search for the top-level module manifest:

Get-ChildItem -Path $TargetModulePath `
    -Filter 'VCF.PowerCLI.psd1' `
    -Recurse |
    Select-Object FullName

Then verify module discovery:

Get-Module -Name VCF.PowerCLI `
    -ListAvailable |
    Sort-Object Version -Descending |
    Select-Object Name, Version, ModuleBase

If the manifest exists but the module is not discovered, the archive may have been extracted with an additional wrapper folder. Compare the manifest path with the module paths listed in $env:PSModulePath.

Update an Offline Installation

An offline installation cannot be updated with:

Update-Module -Name VCF.PowerCLI

Instead:

• Download or build the newer complete bundle on a connected system.
• Validate and approve the artifact.
• Transfer it to the disconnected system.
• Extract it into an approved module path.
• Start a new PowerShell session.
• Verify the selected version and module location.
• Run functional tests.
• Retain the previous validated version until the update is accepted.

Side-by-side version folders make rollback possible, but only when the previous files have not been overwritten or removed.

Verify the VCF PowerCLI Version

Installation is not complete until you confirm the version, location, command resolution, and basic functionality.

Verify the Top-Level Package

Get-Module -Name VCF.PowerCLI `
    -ListAvailable |
    Sort-Object Version -Descending |
    Select-Object Name, Version, ModuleBase

For the VCF PowerCLI 9.1 package used in this guide, the expected top-level version is:

9.1.0.25380678

Pay attention to ModuleBase. It shows the exact directory containing each discovered version.

Verify Package-Manager Metadata

For a PowerShellGet installation:

Get-InstalledModule -Name VCF.PowerCLI `
    -AllVersions |
    Sort-Object Version -Descending |
    Select-Object Name, Version, InstalledLocation

For a PSResourceGet installation:

Get-PSResource -Name VCF.PowerCLI |
    Sort-Object Version -Descending |
    Select-Object Name, Version, InstalledLocation

A copied offline installation may appear in Get-Module -ListAvailable without appearing in either package-manager inventory.

Import the Required Version

Import-Module VCF.PowerCLI `
    -RequiredVersion 9.1.0.25380678 `
    -Force

Successful execution should return no error and make the PowerCLI commands available in the current session.

Verify Important Cmdlets

Get-Command -Name Connect-VIServer, Get-VM, Get-Cluster |
    Select-Object Name, Source, Version

The command source will commonly be a child module such as:

VMware.VimAutomation.Core

That is expected. The top-level package is VCF.PowerCLI, while many cmdlets remain in VMware-named child modules.

Verify Child-Module Versions

Get-Module -Name VMware.* `
    -ListAvailable |
    Group-Object Name |
    ForEach-Object {
        $_.Group |
            Sort-Object Version -Descending |
            Select-Object -First 1
    } |
    Sort-Object Name |
    Select-Object Name, Version, ModuleBase

Do not expect every child module to report version 9.1. Several VCF PowerCLI 9.1 dependencies use the 13.5.0.25380678 version family.

The top-level package version and child-module versions must be evaluated separately.

Compare the Installed Version with the Gallery

This check requires internet access:

$Installed = Get-Module -Name VCF.PowerCLI `
    -ListAvailable |
    Sort-Object Version -Descending |
    Select-Object -First 1

$Available = Find-Module -Name VCF.PowerCLI `
    -Repository PSGallery

[pscustomobject]@{
    InstalledVersion = $Installed.Version
    AvailableVersion = $Available.Version
    UpdateAvailable  = [version]$Available.Version -gt [version]$Installed.Version
}

An offline environment should compare the installed package with the organization’s approved artifact register instead of querying the public gallery.

Run a Functional vCenter Connection Test

A module version check proves that PowerShell found the package. It does not prove that authentication, certificate validation, networking, and cmdlet execution work.

Use an approved validation endpoint:

$VIServer="vcenter.example.com"
$Credential = Get-Credential

$Connection = Connect-VIServer `
    -Server $VIServer `
    -Credential $Credential

Get-Datacenter |
    Select-Object -First 1 Name

Disconnect-VIServer `
    -Server $Connection `
    -Confirm:$false

Change $VIServer to the correct vCenter hostname.

Successful validation should confirm:

• Connect-VIServer resolves and runs.
• DNS resolves the vCenter hostname.
• The network path is open.
• Authentication succeeds.
• Certificate policy behaves as expected.
• An inventory command returns data.
• The session disconnects cleanly.

Use a credential object rather than embedding usernames and passwords in scripts.

Configure PowerCLI Certificate and CEIP Settings

Review the current PowerCLI configuration:

Get-PowerCLIConfiguration

To disable the Customer Experience Improvement Program prompt for the current user:

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

For an isolated lab using untrusted certificates:

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

Do not use Ignore as the default production response to certificate failures. Production environments should correct expired certificates, hostname mismatches, missing intermediate certificates, and untrusted certificate authorities.

Certificate policy is an operational security setting, not an installation requirement.

Troubleshooting VCF PowerCLI Installation and Updates

VMware.PowerCLI Is Reported as Deprecated

Cause: The installation or update command still references the old top-level package.

Fix:

Install-Module -Name VCF.PowerCLI `
    -Scope CurrentUser `
    -Repository PSGallery

Also update explicit Import-Module VMware.PowerCLI statements.

Commands Are Already Available on the System

Cause: Existing VMware.PowerCLI modules export commands that overlap with the VCF.PowerCLI dependency layout.

Fix:

Install-Module -Name VCF.PowerCLI `
    -Scope CurrentUser `
    -Repository PSGallery `
    -Force `
    -AllowClobber

Confirm the repository and package identity before allowing command replacement.

Publisher or Authenticode Mismatch

Cause: Existing modules were signed under the previous VMware publisher, while newer packages use Broadcom signing.

Fix:

Install-Module -Name VCF.PowerCLI `
    -Scope CurrentUser `
    -Repository PSGallery `
    -Force `
    -AllowClobber `
    -SkipPublisherCheck

Use -SkipPublisherCheck only for the documented migration scenario and only after validating the source.

Update-Module Cannot Find the Installation

Cause: The module was copied manually, installed offline, or is outside the active module paths.

Check both inventories:

Get-InstalledModule -Name VCF.PowerCLI `
    -AllVersions `
    -ErrorAction SilentlyContinue

Get-Module -Name VCF.PowerCLI `
    -ListAvailable

If only Get-Module -ListAvailable finds the package, deploy a new offline bundle instead of using Update-Module.

The New Version Is Installed but the Old Version Loads

Cause: The old module is already loaded, or another module path has higher precedence.

Inspect every available version:

Get-Module -Name VCF.PowerCLI `
    -ListAvailable |
    Sort-Object Version -Descending |
    Select-Object Name, Version, ModuleBase

Check the loaded version:

Get-Module -Name VCF.PowerCLI |
    Select-Object Name, Version, ModuleBase

Close PowerShell and open a new session. Then import the required version explicitly:

Import-Module VCF.PowerCLI `
    -RequiredVersion 9.1.0.25380678 `
    -Force

VCF.PowerCLI Exists on Disk but Is Not Discovered

Cause: The package was extracted outside $env:PSModulePath, or the archive created an extra directory layer.

Check the active paths:

$env:PSModulePath -split [IO.Path]::PathSeparator

Locate the manifest:

Get-ChildItem -Path $HOME `
    -Filter 'VCF.PowerCLI.psd1' `
    -Recurse `
    -ErrorAction SilentlyContinue |
    Select-Object FullName

Move the complete module hierarchy into a valid module path. Do not move only the top-level manifest while leaving dependencies behind.

Access Is Denied During Installation

Cause: The installation is targeting an AllUsers directory without sufficient permissions.

Use CurrentUser scope:

Install-Module -Name VCF.PowerCLI `
    -Scope CurrentUser `
    -Repository PSGallery

Use an elevated console only when the design explicitly requires AllUsers scope.

PSGallery Is Missing

Inspect the registered repositories:

Get-PSRepository

Where organizational policy permits the public PowerShell Gallery, restore the default registration:

Register-PSRepository -Default

Test package discovery:

Find-Module -Name VCF.PowerCLI `
    -Repository PSGallery

Gallery Access Fails Through a Proxy

Test whether PowerShell can query the repository:

Find-Module -Name VCF.PowerCLI `
    -Repository PSGallery `
    -Verbose

For PowerShellGet commands that support it, provide the approved proxy configuration:

$Proxy = 'http://proxy.example.com:8080'

Find-Module -Name VCF.PowerCLI `
    -Repository PSGallery `
    -Proxy $Proxy

Do not embed proxy credentials in reusable scripts. Use an approved credential-management mechanism.

macOS or Linux Reports Permission Errors

Inspect ownership and permissions on the CurrentUser module path:

$UserModulePath = Join-Path $HOME '.local/share/powershell/Modules'

Get-Item -Path $UserModulePath |
    Select-Object FullName, Attributes

Modules installed for the current user should be owned and writable by that account. Avoid using sudo pwsh for a user-scoped installation because it can create root-owned files inside paths later used by the normal account.

Child Modules Show Version 13.5 Instead of 9.1

This is expected for several dependencies.

Verify the top-level package separately:

Get-Module -Name VCF.PowerCLI `
    -ListAvailable |
    Sort-Object Version -Descending |
    Select-Object -First 1 Name, Version, ModuleBase

Then verify the child modules independently. Do not use a child-module version to determine whether the VCF.PowerCLI 9.1 meta-package is installed.

Connect-VIServer Reports a Certificate Error

Review the current policy:

Get-PowerCLIConfiguration |
    Select-Object Scope, InvalidCertificateAction

For production, repair the certificate trust path or connect with the hostname represented in the certificate.

For an isolated lab only:

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

Operational Recommendations for Automation Hosts

Treat PowerCLI like any other production automation dependency.

• Pin an approved VCF.PowerCLI version in build runners and scheduled automation.
• Record the PowerShell version, operating system, package version, child-module versions, and installation path.
• Use one package-management method per host.
• Test updates against a non-production vCenter before updating shared runners.
• Keep offline packages and hashes in an internal artifact repository.
• Update explicit top-level import statements before removing VMware.PowerCLI.
• Avoid globally disabling certificate validation.
• Start a new PowerShell process after every installation or update.
• Run at least one connection and inventory test before returning the system to service.
• Retain the previous approved offline package until the new build passes validation.
• Document whether automation uses CurrentUser or AllUsers scope.
• Test scripts under the same service account that runs them in production.

Conclusion

VCF PowerCLI 9.1 changes the PowerCLI package name, but it does not replace the PowerCLI operating model administrators already know. The top-level package has moved from VMware.PowerCLI to VCF.PowerCLI, while familiar cmdlets and many VMware.* child modules remain.

A fresh installation is straightforward across Windows, macOS, and Linux. Existing environments need a more deliberate migration. Inventory the current package and module paths, update explicit imports, prefer a clean installation, and use conflict-bypass parameters only when handling the documented command and publisher changes.

Offline systems require their own lifecycle. Deploy the complete Broadcom ZIP package or a dependency-complete Save-Module bundle, extract it into a valid module path, and refresh it through another offline deployment when a newer version is approved.

The final test should not stop at Get-Module. Confirm the package version, verify the loaded path, inspect command resolution, connect to vCenter, retrieve inventory data, and disconnect cleanly. That provides evidence that the complete PowerCLI automation path is ready for use.

External References