Home > Blogs > VMware PowerCLI Blog


PowerCLI 6.0 – Introducing PowerCLI Modules

If you read the previous post about what’s new in PowerCLI, you will have seen that we have been busy transitioning the core distribution model of PowerCLI cmdlets from Snapins to modules. This release is a hybrid deployment where you will still see several last PSSnapins. To see which PSSnapins still exist, you can run:

Get-PSSnapin -Name VMware*

Screenshot-2015-03-10-14.16.21.png

If you open your PowerCLI Modules folder (default is found at C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\Modules) you will find a number of modules that have now been converted from PSSnapins:

Screenshot-2015-03-10-14.17.15.png

What does this mean for PowerCLI users?

The move to modules is a good thing. PSSnapins were created when PowerShell was still in its infancy, since then modules have become the preferred method of adding onto PowerShell. The PSSnapins are compiled in .Net and require an installer, which will also add information to your computer’s registry, however, modules can be imported using the ‘Import-Module’ cmdlet and does not require any sort of installation process.

Modules also are more flexible than snapins. They allow the developers more flexibility and robustness in that a module can consist of additional scripts, manifests, binaries, and more. Allowing the developers the ability to enhance future PowerCLI releases even more.

When PowerCLI 6 installs, it adds the filepath of the new modules to the $env:PSModulePath, which allows you to use the import-module <module name> command from a PowerShell session. Additionally, you can run Get-Module -ListAvailable to see all modules that can be imported from their current directories.

Screenshot 2015-03-16 11.06.36

You will want to look through your scripts to update any Add-PSSnapin calls for importing the modules. You can use the following code to find any instance of Add-PSSnapin in your scripts:

Get-ChildItem -Path C:\Scripts -Include *.ps1 -Recurse | Select-String -Pattern add-pssnapin

Alan Renouf has suggested to replace the Add-PSSnapin line with the following:

if ( !(Get-Module -Name VMware.VimAutomation.Core -ErrorAction SilentlyContinue) ) {
. “C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\Scripts\Initialize-PowerCLIEnvironment.ps1”
}

This will allow your scripts to load the entire PowerCLI library into the PowerShell session for full PowerCLI capabilities.

***NOTE***

We’ve had several users run into an issue where PowerCLI was installed as a different user and the PSModulePath is installing to the user rather than the system-wide PSModulePath, giving the user an error. an easy fix for this is to run the following code:

#Save the current value in the $p variable.
$p = [Environment]::GetEnvironmentVariable("PSModulePath")

#Add the new path to the $p variable. Begin with a semi-colon separator.
$p += ";C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\Modules\"

#Add the paths in $p to the PSModulePath value.
[Environment]::SetEnvironmentVariable("PSModulePath",$p)
This entry was posted in General and tagged , , , on by .
Brian Graf

About Brian Graf

Brian Graf is a Senior Product Manager - Distributed Resource Management (DRS/HA/DPM) at VMware. Previous to Product Management, Brian worked as a Senior Technical Marketing Manager at VMware, focused on PowerCLI Automation and ESXi Lifecycle technologies. Previous roles also include: Consultant for EMC Consulting. His main focus was Data center migration methodologies and implementations. His background previous to VMware includes Operations Engineering, Virtualization, Business Intelligence, and Exchange/Blackberry Engineering. Get notification of new blog postings and more by following Brian on Twitter: @vBrianGraf

17 thoughts on “PowerCLI 6.0 – Introducing PowerCLI Modules

  1. aaronk

    The above example for ‘fixing’ the profile doesn’t work consistently as it only changes the user environment variable. To force the ‘Machine’ PSModulePath to be updated, this bit of code is a little more reliable: (and it avoids creating double entries if you run it multiple times)

    I have added this to our silent install package.

    $PowerCLIModulePath = “C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\Modules”
    $OldModulePath = [Environment]::GetEnvironmentVariable(‘PSModulePath’,’Machine’)
    if ($OldModulePath -notmatch “PowerCLI”) {
    Write-Host “[Adding PowerCLI Module directory to Machine PSModulePath]” -ForegroundColor Green
    $OldModulePath += “;$PowerCLIModulePath”
    [Environment]::SetEnvironmentVariable(‘PSModulePath’,”$OldModulePath”,’Machine’)
    } else {
    Write-Host “[PowerCLI Module directory already in PSModulePath. No action taken]” -ForegroundColor Cyan
    }

    Reply
    1. Brian GrafBrian Graf Post author

      Jeff,
      there is a known issue with this that is being worked on as we speak. One of the ways that some have seen improvements is to explicitly state the credentials in the connect-viserver command (using -credential or -username/-password). Others have also stated that including the -Protocol and the corresponding protocol http(s) decreased the time.

      Hope this helps!

      Reply
      1. Jeff Couch

        Thanks Brian. But no luck here…

        $credential = Get-Credential
        Measure-Command {connect-viserver xxxx -Credential $credential -Protocol:https } | fl TotalSeconds
        TotalSeconds : 57.1843299

        Reply
  2. Leo Rzz

    This is at least ridiculous. Importing the “module” carries the Snapin. Without a snapin registered the PowerCLI does not. A module does not depend on it. This is deception.

    PS> Get-ChildItem -Path “C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\Modules” -Include *.ps1 -Recurse | Select-String -Pattern add-pssnapin

    C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\Modules\VMware.VimAutomation.Core\VMware.VimAutomation.Core.ps1:19:Add-PSSnapin vmware.vimautomation.core

    Reply
    1. Brian

      lol wow.. they’re telling us to remove the add-pssnapin but telling us to import a module that runs the same command? what a joke

      Reply
  3. Steve SChofield

    Ran into the PSModulePath issue with the latest release posted online. I manually added to the machine environment variable, resolved the issue. I was looking to use the Get-DVSwitch to write some backup automation. I like the fact I can run modules in 64 bit and no more 32 bit powershell required 🙂

    Reply
  4. Ross

    I still see the following when i get pssnappin against 6.0 R1:

    Get-PSSnapin -name VMware* -Registered

    Name : VMware.DeployAutomation
    PSVersion : 4.0
    Description : This Windows Powershell snap-in contains vSphere Auto Deploy related cmdlets for Rule-Based-Deployment

    Name : VMware.ImageBuilder
    PSVersion : 4.0
    Description : This Windows PowerShell snap-in contains VMware ESXi Image Builder cmdlets used to generate custom images.

    Name : VMware.VimAutomation.Core
    PSVersion : 4.0
    Description : This Windows PowerShell snap-in contains Windows PowerShell cmdlets for managing vSphere.

    Name : VMware.VimAutomation.License
    PSVersion : 4.0
    Description : This Windows Powershell snap-in contains cmdlets for managing License components.

    Why does it not match the above?

    Reply
    1. Brian GrafBrian Graf Post author

      What you need to remember is that, as it states, the current release is a hybrid release with both PSSnapins and Modules, we are currently working to remove all PSSnapin dependencies in a future release. Seeing the 4 snap-in’s in your session is just fine, it is down from the 8+ you would have seen in PowerCLI 5.8

      Reply
  5. Pingback: Quick Hit – PowerCLI as a Module and Loading it up | JKavPowerShell

  6. Pingback: theboywonder.co.uk

  7. wanttolearn1

    does any one know how to improve the loading time of
    VMware.VimAutomation.Core (when i do it using import-module or addsnapin the time is the same, almost 20 seconds).
    any way to improve this time?

    Reply
  8. Pingback: PowerCLI: The term 'Connect-VIServer' is not recognized ...

  9. Pingback: PowerCLI 6.0 and vCheck, Vds Module | VirtualDataCave

  10. Krish Devan

    Regarding vFRC PowerCLI cmdlets. It used to be in VMwareVimAutomation.Extensions and I have used it in my scripts. But with PowerCLI 6.0, my scripts are breaking down on the Get-HardDiskVFlashConfiguration cmdlet. Is it not there anymore? How do I get it working again?

    Reply
  11. Pingback: Exploring the types exposed by PowerCLI | The Shell Nut

  12. Pingback: PowerCLI study guide – core concepts - The Crazy Consultant

Leave a Reply

Your email address will not be published. Required fields are marked *

*