Home > Blogs > VMware PowerCLI Blog


PowerCLI Offline Installation Walkthrough

Can you believe it? PowerCLI is closing in on a year of being in the PowerShell Gallery! We’re up to 20 different modules and, wait for it, over 2,000,000 downloads of those modules!

VMware Profile on PowerShell Gallery

As exciting as that is, there’s still quite a few questions on how to install PowerCLI to systems that do not have internet access. We’re going to take a much closer look at that with this post.

Preparing the Offline System

First things first, we need to uninstall any prior instance of PowerCLI that was installed by way of the MSI. This can be done by:

  • Open the Control Panel
  • Look beneath the ‘Programs’ section, select ‘Uninstall a Program’
  • Select ‘VMware PowerCLI’, click ‘Uninstall’

Uninstalling Prior PowerCLI Versions

One last thing to check, ensure there is no folder containing PowerCLI as part of the title in the following directory: C:\Program Files (x86)\VMware\Infrastructure\

We can verify whether such a folder exists or not with a oneliner:

Accessing the PowerCLI Modules

We’re now ready to download the PowerCLI modules. This task will require a system with internet access. This section has a couple of variables which depend on the version of PowerShell available on your online system and whether or not you’ve ever accessed the PowerShell Gallery previously by way of the PowerShellGet module.

The easiest way to figure out which version of PowerShell you have is by using the PSVersionTable variable. Based on the output of that, follow the set of instructions below that matches the output.

PowerShell PSVersionTable Output

Online System with PowerShell 5.x:

  • Open PowerShell
  • Use the ‘Save-Module’ cmdlet to download the PowerCLI modules locally. Example:

    • If requested, update the NuGet provider
    • If requested, trust the ‘Untrusted repository’ that is named PSGallery
      Note: This is a local system trust, not something that has something to do with an SSL certificate
  • Copy those downloaded module folders to a location that can be made accessible to the offline system.
    Example: USB Flash Drive, Internal File Share, etc.

Online systems with the older PowerShell versions of 4.0 or 3.0, may need to have an additional module installed to access the PowerShell Gallery. The module is called ‘PowerShellGet’. We can verify whether the online system has the ‘PowerShellGet’ module available with the following command:

If there’s a response, you have it already! If there’s no output, you’ll need to make it available. Depending on the output, follow the instructions below.

Online System with PowerShell 4.0 or 3.0 with the PowerShellGet module:

  • Open PowerShell
  • Use the ‘Save-Module’ cmdlet to download the PowerCLI modules locally. Example:

    • If requested, update the NuGet provider
    • If requested, trust the ‘Untrusted repository’ that is named PSGallery
      Note: This is a local system trust, not something that has something to do with an SSL certificate
  • Copy those downloaded module folders to a location that can be made accessible to the offline system.
    Example: USB Flash Drive, Internal File Share, etc.

Online System with PowerShell 4.0 or 3.0 without the PowerShellGet module:

  • Download and install the ‘PowerShellGet’ module by way of the PackageManagement PowerShell Modules MSI.
  • Open PowerShell
  • Use the ‘Save-Module’ cmdlet to download the PowerCLI modules locally. Example:

    • If requested, update the NuGet provider
    • If requested, trust the ‘Untrusted repository’ that is named PSGallery
      Note: This is a local system trust, not something that has something to do with an SSL certificate
  • Copy those downloaded module folders to a location that can be made accessible to the offline system.
    Example: USB Flash Drive, Internal File Share, etc.

Save-Module Example and associated output

Adding PowerCLI to the Offline System

It’s now time to put the PowerCLI modules on to the offline system. To take advantage of the magic that is module auto-loading, we’ll want to copy and paste those downloaded folders in one of the locations listed in the PSModulePath variable.

By default, the PSModulePath variable contains the following directories:

  • $home\Documents\WindowsPowerShell\Modules
  • $pshome\Modules

When everything is all said and done, you should have one of the directories listed above looking a bit like this:
Directory Structure with PowerCLI Modules on the Offline System

That’s it! Open a PowerShell session and start using your PowerCLI commands as you did before!

Wait… It’s Not Working For Me!

What happens when you go through the above instructions and it’s not working?

The most common scenario we’ve come across is where the ‘Save-Module’ cmdlet was used with an online system that has PowerShell version 5.x. When this happens, there are an additional level of folders created between the top-level module folder and the module files themselves. This is extremely beneficial because we can then have multiple versions of the same module available on the local system. The issue though, older versions of PowerShell do not recognize those folders and therefore cannot load the modules.

When I say issue, I truly mean it. Jake Robinson, the PowerCLI Product Manager, actually created a GitHub issue for PowerShellGet calling out this problem: Offline installation of modules from Save-Module does not work on PS <5.x

Good news though, there are a couple workarounds available!

First option: Upgrade your version of PowerShell on the offline system to 5.x with Windows Management Framework 5.0.
Second option: Find an online system that has PowerShell versions 4.0 or 3.0 installed and use ‘Save-Module’ on that system.

Those two options are simple enough, but generally in an ‘easier said than done’ manner. With that said, I’m very excited to show off a third option. This option doesn’t require installing any software or powering on that older VM you hadn’t decommissioned quite yet. This option is a simple script that is run on the offline system. The script simply looks for the folders that already exist in any of the PSModulePath listed directories, searching specifically for PowerCLI module folders, and then removes that additional nested level of version-based folders.

The script is openly available on the PowerCLI Community Repository and is named: PowerCLI_FixNestedFolders.ps1

Here’s an example of the script in action:
Fixing the nested PowerCLI folders on older versions of PowerShell

Here’s an example of the results: (Left is the before, right is the after)
Directory Structure Before, left, and After, right

Wrap-Up

PowerCLI has seen a lot of success on the PowerShell Gallery. A set of modules with over 2,000,000 combined downloads is pretty impressive! However, there’s still a lot of questions over the installation process for systems that are offline. This blog post walked us through the offline installation process, covers the most common issue users hit, and provides a new solution to help overcome that issue.

Don’t delay, upgrade your version of PowerCLI on all your systems to ensure you’re getting access to the most up-to-date features, performance improvements, and bug fixes today!

This entry was posted in General and tagged , , , on by .
Kyle Ruddy

About Kyle Ruddy

Kyle Ruddy is a Senior Technical Marketing Engineer at VMware in the Cloud Platform Business Unit. Kyle currently focuses on vSphere with Operations Management as well as all things API, SDK, and CLI. Kyle can be found blogging on VMware blogs, http://blogs.vmware.com/vSphere and http://blogs.vmware.com/PowerCLI, and his personal blog, http://www.thatcouldbeaproblem.com. You can follow Kyle on twitter as @kmruddy.

4 thoughts on “PowerCLI Offline Installation Walkthrough

  1. Rudolf Dudek

    Hello,
    any idea:

    ‘https://www.powershellgallery.com/api/v2/package/VMware.VimAutomation.Sdk/1.0.0.5334677’.
    VERBOSE: Completed downloading ‘VMware.VimAutomation.Sdk’.
    VERBOSE: Hash for package ‘VMware.VimAutomation.Sdk’ does not match hash provided from the server.
    DEBUG: 00:00:44.4786127 Calling ‘NuGetClient’::’InstallPackageLocal’.
    VERBOSE: InstallPackageLocal’ – name=’VMware.VimAutomation.Sdk’,
    version=’1.0.0.5334677′,destination=’C:\Users\xxxxx\AppData\Local\Temp\942494772′
    DEBUG: 00:00:44.4786772
    C:\Users\xxxxx\AppData\Local\Temp\942494772\VMware.VimAutomation.Sdk\VMware.VimAutomation.Sdk.nupkg
    DEBUG: 00:00:45.0762142 System.IO.IOException: Operation did not complete successfully because the file contains a
    virus or potentially unwanted software.

    at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
    at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite, Boolean checkHost)
    at System.IO.FileInfo.CopyTo(String destFileName, Boolean overwrite)
    at Microsoft.PackageManagement.Provider.Utility.FileUtility.CopyDirectory(String source, String dest, Boolean
    copySubDirs)
    at Microsoft.PackageManagement.NuGetProvider.NuGetClient.InstallPackageLocal(String packageName, String version,
    NuGetRequest request, PackageSource source, String sourceFilePath, ProgressTracker progressTracker)

    Confirm
    Package ‘VMware.VimAutomation.Sdk’ failed to be installed because: Operation did not complete successfully because the
    file contains a virus or potentially unwanted software.

    Reply

Leave a Reply

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

*