When you want to start your PowerCLI scripts or just use the cmdlets for VMware, you can start VMware vSphere PowerCLI from your start menu. From the window you get you can use all PowerCLI cmdlets that you need or your own scripts.

But what if you want to use the default PowerShell instance or PowerShell ISE to edit and run your scripts? Then you have to load the modules and snapins yourself, since the PowerCLI configuration isn’t loaded automatically.

When you start PowerCLI a lot of things are loaded and configured. If you know all the modules that need to be loaded you can do it by hand. But if you write your scripts for other systems or other users you can’t be sure which version of PowerCLI they are using or where they installed PowerCLI.

The following modules are loaded on my system:

  • VMware.VimAutomation.Core
  • VMware.VimAutomation.Vds
  • VMware.VimAutomation.Cloud
  • VMware.VimAutomation.PCloud
  • VMware.VimAutomation.Cis.Core
  • VMware.VimAutomation.Storage
  • VMware.VimAutomation.HA
  • VMware.VimAutomation.vROps
  • VMware.VumAutomation
  • VMware.VimAutomation.License

If you want to use all of these in your script you need to import the modules with Import-Module <module name>. Since PowerCLI still uses some PowerShell Snapins next to the modules chances are that you have to update your scripts when you update PowerCLI.

An easier way

Isn’t there an easier way then? Yes, of course there is.  An easier way is to load the same file that PowerCLI uses to load all necessary modules and snapins, namely “Initialize-PowerCLIEnvironment.ps1”. This file is under the installation folder of PowerCLI in “Scripts”. By default it is in “C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\Scripts”. So you can load PowerCLI with “. C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\Scripts\Initialize-PowerCLIEnvironment.ps1”. Notice the ‘dot space’ before the file to execute the file within the current context to preserve variables.

Since you can’t count on that PowerCLI is installed in the default location you have to find some way to find the location. One of these ways is checking the registry. You can find the location of PowerCLI in “hklm:\software\VMware, Inc.\VMware vSphere PowerCLI” (32bit Windows) or “hklm:\software\wow6432node\VMware, Inc.\VMware vSphere PowerCLI” (64bit Windows). The value to check is “InstallPath”.

The result – load PowerCLI

The script below puts it all together. First it checks if the the core module is loaded. If not it checks the registry for the installation location. It checks the 64bits portion first. If it doesn’t find the registry key it assumes 32bit. After loading the key it adds the location and name of the PowerCLI initialization script and executes it. Then it, again, checks if the module is loaded. If it isn’t the script fails with error 99.

# +------------------------------------------------------+
# |        Load VMware modules if not loaded             |
# +------------------------------------------------------+

if ( !(Get-Module -Name VMware.VimAutomation.Core -ErrorAction SilentlyContinue) ) {
    if (Test-Path -Path 'Registry::HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMware vSphere PowerCLI' ) {
        $Regkey = 'Registry::HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VMware, Inc.\VMware vSphere PowerCLI'
       
    } else {
        $Regkey = 'Registry::HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware vSphere PowerCLI'
    }
    . (join-path -path (Get-ItemProperty  $Regkey).InstallPath -childpath 'Scripts\Initialize-PowerCLIEnvironment.ps1')
}
if ( !(Get-Module -Name VMware.VimAutomation.Core -ErrorAction SilentlyContinue) ) {
    Write-Host "VMware modules not loaded/unable to load"
    Exit 99
}

The script isn’t foolproof though. If PowerCLI isn’t installed it fails reading the registry part. So there is room for improvement. Perhaps something for another time.