Installing PowerCLI on a disconnected network
It is a constant battle working on multiple secured disconnected networks when everything is going to the cloud. What's worse its now XAAS (Everything-as-a-Service) is the new norm and I guess this means Powershell modules as well...specifically the most important one for our environment, PowerCLI.
We upgrade out vCenter environment to 6.5.2 and I figured I wanted the same PowerCLI version
I guess starting with 6.5.1 it's now a module you can get only from Microsoft PowerShell Gallery. But I want to use 6.5.2...
HINT: You can still use the 6.5.0 installer if you like, but I like using the latest greatest and starting with
There is an article that states how to do this, but I found this does not work entirely.
https://blogs.vmware.com/PowerCLI/2017/08/new-release-powercli-652.html
I have downloaded the PowerCLI using the command
Save-Module -Name VMware.PowerCLI -Path <path\to\folder>
Copied it an external drive, moved it over and copied it into my profile path (C:\Users\Username\Documents\WindowsPowerShell\Modules\). Opened a new instance of powershell and its not loaded nor is it recognized as a module.
$env:PSModulePath does state my path is one of the locations. Hmmm...
I first try to import the module manually, but I kept getting the error when loading its first dependency, VMWare.VimAutomation.Sdk:
The log4net assembly is explicitly loaded by the PowerShell because it is in the RequiredAssemblies list of the VMware.VimAutomation.Sdk.psd1 module manifest (see VMware.VimAutomation.Sdk.psd1).
After troubleshooting this over and over and reading online forums about it and getting nowhere, for shits and giggles, I tried running this command on my disconnected system, thinking it would find the modules on my profile or at lease an error I could follow:
Install-Module -Name VMware.PowerCLI
Instead I get an message saying I need to get that latest nuget. What?
I was curious, I decided to click Yes knowingly it will not work, but thought it would give me an error code I could work with:
No file information but it did give me a link....
http://go.microsoft.com/fwlink/?LinkID=627338
I go to my internet connected PC type in that link. It takes me down the rabbit hole of the azure cloud
I get redirected to: https://az818661.vo.msecnd.net/providers/providers.masterList.feed.swidtag
Which then I find the link for Nuget: https://oneget.org/nuget-2.8.5.208.package.swidtag
That link takes me to the actual dll: https://oneget.org/Microsoft.PackageManagement.NuGetProvider-2.8.5.208.dll
Down the rabbit hole I go....
Based on this I search where this dll's get installed at on my connected system:
C:\Program Files\PackageManagement\ProviderAssemblies\nuget\2.8.5.208\Microsoft.PackageManagement.NuGetProvider.dll
Cool. I copied the dll over to my disconnect system (using the same folder structure). Then I re-ran just to see if I get prompted again:
Install-Module -Name VMware.PowerCLI -Verbose
No nuget message but now all I get is it can't find the repository. Great....not
Obviously I'm not connected to the internet so the repository its looking for is not available. What now?
Lets install PowerCLI manually. After trying to manually importing the VMware.PowerCLI.psd1;
Install-Module $home\Documents\WindowsPowershell\Modules\VMware.PowerCLI\6.5.2.6268016\VMware.PowerCLI.psd1
It came back with dependencies that weren't install.
I import the module VMWare.VimAutomation.Sdk, success!
Run the import again...another dependencies....there are 17 more to go....
The PowerCLI does have 18 other modules that are required to be loaded first. But which one first? If you try to import the each dependencies one by one (alphabetically it will not work), they too have dependency errors. If you open the VMware.PowerCLI.psd1 file in notepad (or ISE) you will see the dependencies with their version numbers:
I thought that by running this it would auto install the modules for me...Nope
Install-Module $home\Documents\WindowsPowerShell\Modules\VMware.PowerCLI\6.5.2.6268016\VMware.PowerCLI.psd1
If I run through each module in the order it specifies, they all install just fine calling each psd1 file. However Vmware.VIMAutomation.PSCloud dependency is Vmware.VIMAutomation.Cloud and Vmware.VIMAutomation.Storage requires Vmware.VIMAutomation.SotrageUtility, yet they are not in that order. I could change the order in the psd1 file, but I didn't want to mess with what VMware release.
Instead I wrote my own installer ps1 file. I wrote it to parse the required module in VMware.PowerCLI.psd1, then add it to a hashtable with its version, then find those folders and look in their psd1 file for sub dependency, then install in the appropriate order.
These are the features added to the script:
We upgrade out vCenter environment to 6.5.2 and I figured I wanted the same PowerCLI version
I guess starting with 6.5.1 it's now a module you can get only from Microsoft PowerShell Gallery. But I want to use 6.5.2...
HINT: You can still use the 6.5.0 installer if you like, but I like using the latest greatest and starting with
There is an article that states how to do this, but I found this does not work entirely.
https://blogs.vmware.com/PowerCLI/2017/08/new-release-powercli-652.html
I have downloaded the PowerCLI using the command
Save-Module -Name VMware.PowerCLI -Path <path\to\folder>
Copied it an external drive, moved it over and copied it into my profile path (C:\Users\Username\Documents\WindowsPowerShell\Modules\). Opened a new instance of powershell and its not loaded nor is it recognized as a module.
$env:PSModulePath does state my path is one of the locations. Hmmm...
I first try to import the module manually, but I kept getting the error when loading its first dependency, VMWare.VimAutomation.Sdk:
The log4net assembly is explicitly loaded by the PowerShell because it is in the RequiredAssemblies list of the VMware.VimAutomation.Sdk.psd1 module manifest (see VMware.VimAutomation.Sdk.psd1).
Huh?
After troubleshooting this over and over and reading online forums about it and getting nowhere, for shits and giggles, I tried running this command on my disconnected system, thinking it would find the modules on my profile or at lease an error I could follow:
Install-Module -Name VMware.PowerCLI
Instead I get an message saying I need to get that latest nuget. What?
I was curious, I decided to click Yes knowingly it will not work, but thought it would give me an error code I could work with:
No file information but it did give me a link....
http://go.microsoft.com/fwlink/?LinkID=627338
I go to my internet connected PC type in that link. It takes me down the rabbit hole of the azure cloud
I get redirected to: https://az818661.vo.msecnd.net/providers/providers.masterList.feed.swidtag
Which then I find the link for Nuget: https://oneget.org/nuget-2.8.5.208.package.swidtag
That link takes me to the actual dll: https://oneget.org/Microsoft.PackageManagement.NuGetProvider-2.8.5.208.dll
Down the rabbit hole I go....
Based on this I search where this dll's get installed at on my connected system:
C:\Program Files\PackageManagement\ProviderAssemblies\nuget\2.8.5.208\Microsoft.PackageManagement.NuGetProvider.dll
Cool. I copied the dll over to my disconnect system (using the same folder structure). Then I re-ran just to see if I get prompted again:
Install-Module -Name VMware.PowerCLI -Verbose
No nuget message but now all I get is it can't find the repository. Great....not
Obviously I'm not connected to the internet so the repository its looking for is not available. What now?
Lets install PowerCLI manually. After trying to manually importing the VMware.PowerCLI.psd1;
Install-Module $home\Documents\WindowsPowershell\Modules\VMware.PowerCLI\6.5.2.6268016\VMware.PowerCLI.psd1
It came back with dependencies that weren't install.
I import the module VMWare.VimAutomation.Sdk, success!
Run the import again...another dependencies....there are 17 more to go....
The PowerCLI does have 18 other modules that are required to be loaded first. But which one first? If you try to import the each dependencies one by one (alphabetically it will not work), they too have dependency errors. If you open the VMware.PowerCLI.psd1 file in notepad (or ISE) you will see the dependencies with their version numbers:
I thought that by running this it would auto install the modules for me...Nope
Install-Module $home\Documents\WindowsPowerShell\Modules\VMware.PowerCLI\6.5.2.6268016\VMware.PowerCLI.psd1
If I run through each module in the order it specifies, they all install just fine calling each psd1 file. However Vmware.VIMAutomation.PSCloud dependency is Vmware.VIMAutomation.Cloud and Vmware.VIMAutomation.Storage requires Vmware.VIMAutomation.SotrageUtility, yet they are not in that order. I could change the order in the psd1 file, but I didn't want to mess with what VMware release.
Instead I wrote my own installer ps1 file. I wrote it to parse the required module in VMware.PowerCLI.psd1, then add it to a hashtable with its version, then find those folders and look in their psd1 file for sub dependency, then install in the appropriate order.
These are the features added to the script:
- Find the latest downloaded PowerCLI version folder, and copy the files to the users profile Powershell directory
- Include a progress bar for coping
- Copy Nuget folder (located in PowerCLI version folder) to C:\Program Files\PackageManagement\ProviderAssemblies
- Disable CEIP
- Copy a modified version of Initialize-PowerCLIEnvironment.ps1 to the users profile PowerCLI directory
- Copy a icon to the users profile PowerCLI directory
- Create PowerCLI desktop shortcuts, x86 and x64 (like the installer did, pointing to Initialize-PowerCLIEnvironment.ps1 and using the icon)
- Load PowerCLI when done.
The difference between old installer, it used to copy the modules to the C:\Program Files (x86)\VMware\Infrastructure\PowerCLI\Modules, add Initialize-PowerCLIEnvironment.ps1 to theC:\Program Files (x86)\VMware\Infrastructure\PowerCLI\Scripts folder, a a startmenu and desktop shortcuts to that scripts for 32-bit and 64-bit Powershell and add an entry into the PSModulePath system environment variable.
You will also need to have a copy of nuget with the saved version of PowerCLI. The folder structure should look like this:
![](https://1.bp.blogspot.com/-DXm6yjI9B8M/WcKCm6t-QOI/AAAAAAAAJpk/CkZj4FxMB2ktV4TuFo8fM23wyUQl8aCcgCLcBGAs/s1600/folder.png)
If there is a later version that comes out, the script does detect that folder or you can update the variable (line 4)
$LatestModuleVersion = '6.5.2.6268016'
You can get the PowerShell script on github (updated 2/8/2019): PowerCLIInstaller
Coming soon...version 10
![](https://1.bp.blogspot.com/-DXm6yjI9B8M/WcKCm6t-QOI/AAAAAAAAJpk/CkZj4FxMB2ktV4TuFo8fM23wyUQl8aCcgCLcBGAs/s1600/folder.png)
$LatestModuleVersion = '6.5.2.6268016'
You can get the PowerShell script on github (updated 2/8/2019): PowerCLIInstaller
Coming soon...version 10
Is there a following link to 10.2.0 or will this version cover all the changes?
ReplyDeleteWere u able to test this with vmware.powercli 10.2.0-x or figure out the necessary tweaks?
ReplyDeleteNew update for later versions of PowerCLI is here: https://github.com/PowerShellCrack/PowerCLI-ModuleInstaller/tree/v2
ReplyDeletethanks richard...I'll give that a go in our DoD environment. Did you meet any challenges running up against McAfee HBSS suite in your environment? I believe we have on-access scanning trying to hinder/block scripts running thus taking forever to execute unfortunately. working on them exempting directories for $env:PSModulePath variables like $pshome\Modules & $home\Documents\WindowsPowerShell\Modules
ReplyDeleteIt may be worth noting for clarity in the documentation (readme.md & overall instructions) & in your custom script header pre-requisites that the end user must download files & pre-stage them in the directories.
ReplyDelete1st) download the VMware.PowerCLI version module(s) desired & place them in your script's Modules directory
2nd) download the Microsoft.PackageManagement.NuGetProvider.dll file for your /Bin /NuGet folder which can be found within the latest PackageManagement PowerShell Gallery https://www.powershellgallery.com/packages/PackageManagement/1.1.0.0
Also a good reference for folks to trust the NuGet process is to read the "Manually bootstrapping the NuGet provider on a machine that is not connected to the Internet" section under Microsoft's article "Bootstrap the NuGet provider and NuGet.exe" available at https://docs.microsoft.com/en-us/powershell/gallery/how-to/getting-support/bootstrapping-nuget