Universal PowerCLI Loader

PowerCLI is great tool, and the Team behind it surprises us on a regular basis with a new Release. With the v6.x generation we witnessed the introduction of Modules. And the Team keeps adding further integration with other VMware products.

With the PowerCLI installation comes a shortcut to a PowerShell sessions, loaded with all the PowerCLI goodness. And this is ideal to make your first steps in the wonderful world of PowerShell and PowerCLI.

But soon you’ll start using more advanced features of PowerShell. You’ll be scheduling jobs, running parallel workflows, start using PowerCLI in Desired State Configuration (DSC). At that moment, the simple PowerCLI session doesn’t cut it anymore, and even the Init scripts that are installed together with PowerCLI, will not give you the exact environment as you want it. Hence my Universal PowerCLI Loader!


I have been using a “Universal PowerCLI loader” function since quite some time now. I thought it was time to prettify it a bit, and share it with the community.

To create the Universal PowerCLI loader, I first needed to take stock of what all the different PowerCLI versions require and bring. The result of that inquiry is reflected in the following spreadsheet.

Some clarifications on the table:

Columns E, F and G: contain hyperlinks to the respective Release Notes, Download link and Online Helppage for each PowerCLI release. Note that the download will require you to enter a MyVMware account.

Columns H and I: the minimum and maximum supported PowerShell version

Columns J and K: the minimum and maximum supported OS (for workstations) on which you can use PowerCLI

Columns L till P: the required .Net version

Columns Q and R: the minimum and maximum supported vSphere version. These are just an indication, always use the VMware Product Interoperability Matrixes to determine which version is required.

Columns U and V: the number of cmdlets available for the “regular” modules and for the “Cloud” modules. To get the total number of cmdlets in a specific release, add these two numbers together.

Some interesting observations that can be made from this table:

  • The table starts with PowerCLI, since I personally think you should never need an older version. If you do, let me know, and I’ll see if I can expand the table and the function.
  • Notice that with PowerCLI 5.8 a separate installation for PowerCLI for Tenants was introduced (row 7)
  • With the PowerCLI v6.x series, modules were introduced
  • Not all cmdlets are currently migrated from PSSnapins to Modules, hence the mix of PSSnapin and Modules
  • WMF 5 support is included from the PowerCLI v6.3. Note that this is for the WMF 5 that comes with Windows 10. The WMF 5 that is still in preview, and that will probably be released with Windows 2016, is not yet officially supported

The Function


Line 27-44: in these tables the relation between the PowerCLI version and the required modules and PSSnapin are defined

Line 47-53: depending if the PowerShell session is a 32- or 64-bit process, another registry branch needs to be accessed.

Line 56-63: check if PowerCLI, or PowerCLI for Tenants, is actually installed on the station before continuing

Line 66-83: the buildnumber and the installation path are retrieved from the registry

Line 86-106: loads the requested PowerCLI modules, if we are in a PowerCLI v6.x environment. The logic first determines which modules are available, then substracts the ones that are already loaded and finally loads the missing ones. This means that the function can be called more than once.

Line 94: in combination with the table, define earlier, this line will check for each known PowerCLI module, if it is present in the current PowerCLI installation.

Line 109-135: similar logic as before with the modules, to load the required PowerCLI PSSnapins.

Line 127-133: execute the PSSnapin initialisation scripts if requested. The default is not to run these scripts.

Sample Usage

The purpose of the function is quite straightforward, it loads the PowerCLI PSSnapin and modules. The call to the function can be placed in the beginning of your scripts. No more need to handle the loading of PowerCLI in your scripts.

This will load all PowerCLI PSSnapins and modules, depending on the installed PowerCLI version, minus the Cloud related modules and PSSnapins.

If you need the Cloud functionality, you just need to do

The Enable-PowerCLI function is available on my Github Scripts repository.

Note that the Enable-PowerCLI function can not be added to a module. The Add-PSSnapin cmdlets executed inside a module, are not propagated to the caller!
This is a know, unresolved issue.




    I got this error with esxi 6.7

    PS C:\> Connect-VIServer -Server -User root -Password Password

    Name Port User
    —- —- —- 443 root

    PS C:\> ls .\Clone-MasterVM.ps1 -MasterName WIN2016 -CloneName AD1 -DatastoreName 600GB -register
    Get-ChildItem : A parameter cannot be found that matches parameter name ‘MasterName’.
    At line:1 char:25
    + ls .\Clone-MasterVM.ps1 -MasterName WIN2016 -CloneName AD1 -Datastore …
    + ~~~~~~~~~~~
    + CategoryInfo : InvalidArgument: (:) [Get-ChildItem], ParameterBindingException
    + FullyQualifiedErrorId : NamedParameterNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand


    Hi.. I am not versed in Powershell or PowerCLI.. but found this function very handy. Is there way to just include it in a powershell script so it prepares the environment within the script and not call out to a function? If so.. how would i go abouts doing that?

    I am asking as i have a laundry list of PowerCLI and need to run a very simple get-dvswitch but cannot execute from powercli (need to invoke thru command.com -> powershell.exe).

    Any help is much appreciated!


    Graham Mitchell

    Any plans to update this for PowerCLI 6.5R1?



    This is great work and seems really cool Luc! I am trying to build up mu proficiency with both PowerCLI and Powershell and wanted to ask how this is used. Does this script need to be executed in Powershell? or in PowerCLI? Once executed, it installs what is needed and then one can simply add the “Enable-PowerCLI” at the beginning of a script? Sorry for the “noob-like” questions, but this is something I am trying to get a grasp of.


      Hi Alex,
      PowerCLI is added on top of PowerShell.
      And yes, you load the function and then you call Enable-PowerCLI.
      This should make sure that all required PSSnapins and modules for PowerCLI are loaded.

    Nick M

    I also just ran into an issue with my version of powercli, which was 3639347, which wasn’t a part of the arrays you put together for $pclipssnapin and $pclimodule, so nothing happened.

    I’m not good enough at powershell to know how to make the version checking component that you put in more tolerable to changes if folks were to have a newer, older, or different version loaded, but that may make it better and more modular for the future if that was there. 🙂


      I don’t seem to have that specific build in my “official” list of PowerCLI versions.
      I strongly suspect that this is a private beta that came just before PowerCLI 6.3R1.
      I did, on purpose, not include support for beta releases. If you run a beta, you’re on your own 🙂

    Nick M

    Hi LucD, to get your powershell header items to work, they need to exist on their own lines. If you do help on your function, it currently doesn’t report back proper information. But once on new lines, everything looks good.


      Thanks, I corrected that, on my blog and on the Github repository

    Damien Solodow

    Looks really cool. 🙂 Any plans to publish on GitHub/PowerShellGallery?


      Yes, was planning on starting a module on Github/PSGallery with some of my functions in there.


      Unfortunately, as I discovered, you can’t use Add-PSSnapin cmdlets inside a module. The loaded PSSnapin will not be propagated to the caller.
      This is a known issue I’m afraid.

Leave a Reply

Your email address will not be published.


This site uses Akismet to reduce spam. Learn how your comment data is processed.