General

Saying Farewell to Snapins!

One of the key improvements to the VMware PowerCLI 6.5 R1 release is the absence of PowerShell snapins. All of the remaining snapins have been converted to modules!

Snapin History

If you don’t know why this is such a big deal, let me take a second to cover some history on snapins. Going back to the days of PowerShell version 1, snapins were the only way to extend the shell, or add additional features and functionalities. The issue with snapins begin due to how they can only be written in a .NET programming language and then have to be assembled before being handed off to the user. Then, once the user has them, the issues continue due to the snapins having to be installed and registered to each individual system a user wishes to use them on. Snapins also lack the ability to explicitly define dependencies, this causes issues for a product like PowerCLI which is comprised of several individual components.

PowerShell version 2 introduced modules, which resolved a majority of those issues. Modules can still be written in any .NET programming language, or can even be written in PowerShell itself! Modules are mobile and don’t require any registrations. Once the modules are in hand, they can be referenced automatically by placing them in one of the proper folders or by specifying the directory path to where they reside for each system requiring access.

Finding Snapins

This change in architecture introduces an issue for already created scripts which are trying to load the old VMware snapins. Instead of performing something that looks like:

Add-PSSnapin –Name VM*

We’re recommending a replacement from that command to this command:

Get-Module –ListAvailable VM* | Import-Module

We’re not going to leave the rest to you to handle. There’s some functions which have been added to the PowerCLI Community Repository which will point out which scripts contain that line. There’s also a function which can comment out that line and add the new recommended command. These functions are available within the Update_PowerCLI_Scripts.ps1 script.

The first function is “Get-PowerCLISnapinUse” and will show what scripts (.ps1 extensioned) include the string “Add-PSSnapin*VM*” and will display the file name, line where the string resides, path to the directory, and the full path of the file.

Get-PowerCLISnapinUse Example Output

The second function is “Update-PowerCLISnapinUse” and is based around adding the new Import-Module command and commenting that string out.

Results from using Update-PowerCLISnapinUse

Additionally, if you’ve already updated your version of PowerCLI, you may have noticed the installation directory has changed as well. If you have the “Initialize-PowerCLIEnvironment” script hardcoded into your scripts, there are also some functions to handle that as well. The functions for that are done by way of “Get-PowerCLIInitialization” and “Update-PowerCLIInitialization”. These functions work similarly to the above, however the “Update-PowerCLIInitialization” function just updates the directory path and does not comment anything out.

Conclusion

VMware PowerCLI moving over to be completely modules is a huge accomplishment in this newest release. As always, it’s backwards compatible and we recommend upgrading to the latest version.

You can find the PowerCLI 6.5 Release 1 download HERE.