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*
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:
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.
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:
|
1 2 3 4 5 6 7 8 |
#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) |
