Home > Blogs > VMware PowerCLI Blog

Welcome PowerCLI to the PowerShell Gallery – Install Process Updates

PowerCLI 6.5.1 has been released and in this release we have made some big changes to the way you install and keep up to date with PowerCLI! This update was all based around Microsoft PowerShell deployment models, listening to you, the customer and ensuring we are making the changes to provide the best PowerShell product going forward.

As of PowerCLI 6.5.1, you no longer have a MSI file to download and install. You can now install directly from the PowerShell Gallery! This update streamlines the install process in multiple ways and allows module based features which PowerShell users will be used to from other PowerShell based additions.

What does this mean for you?

PowerCLI being on the PowerShell Gallery means there are some changes that users should be aware of. The first big change, there is no more MSI to perform the install and therefore you don’t download it from the VMware website!

The install is done completely through PowerShell itself using the PowerShell Gallery via PowerShellGet. This means also means the other items which used to be installed by way of the MSI won’t be installed automatically. These things include the PowerCLI desktop shortcuts and the User Guide.

There are two ways in which you may install PowerCLI with this new method, online and offline. Let’s take a look at how to perform these methods.

Getting Started

The first step in moving to this new release is to uninstall any prior versions of PowerCLI which may be installed on the system by the old MSI installer, this is needed to move to the new distribution model.

It is also worth checking to ensure the “PowerCLI” folder has been removed from the following directory: C:\Program Files (x86)\VMware\Infrastructure\

With the prior version of PowerCLI uninstalled, it’s time for the install!

Online Installation From a Computer with an Internet Connection

For the online install, start by confirming access to PowerShell Gallery and being able to find the PowerCLI module. This can be done by running the following:

Find-Module -Name VMware.PowerCLI

1	Find-Module -Name VMware.PowerCLI

Note: If you have not accessed the PowerShell Gallery before, or perhaps have an out of date version of NuGet, you may receive a message indicating there is a missing or out-of-date NuGet provider. NuGet is a Package Management provider. These are primarily used to install, upgrade, configure, and/or remove software in an automated fashion. To accept the installation of a proper version of NuGet, hit “Y”.

We will now make use of the Install-Module cmdlet to make PowerCLI actually available on the local system. This can be done with the following:

Install-Module -Name VMware.PowerCLI –Scope CurrentUser

1	Install-Module -Name VMware.PowerCLI –Scope CurrentUser

You will notice we’re only installing it for the current user, we do this because it doesn’t require admin access! If you would like it available for all users of the computer, your PowerShell session will have to be running as an administrator, and PowerCLI will automatically be installed for all users by changing the Scope parameter to AllUsers.

Success! We now have the PowerCLI modules installed and available locally!

Offline Install of PowerCLI to a Computer Without an Internet Connection

The following method should be used to install PowerCLI through the PowerShell gallery for those systems which do not have access to the internet. You will need at least one system that has internet access and a way to move the files to the target computer.

While on a system that has internet access, we will find the PowerCLI module with the same command we ran above:

Find-Module -Name VMware.PowerCLI

1	Find-Module -Name VMware.PowerCLI

Then we can download the module for offline consumption with the following command:

Save-Module -Name VMware.PowerCLI -Path C:\Path\To\Desired\Folder

1	Save-Module -Name VMware.PowerCLI -Path C:\Path\To\Desired\Folder

At this point, we’ll want to copy those downloaded folders and place them on the system without internet access in a location where PowerShell can find them, this is the modules folder and can be confirmed by typing $ENV:PSModulePath at the powershell prompt.

Local User: $home\Documents\WindowsPowerShell\Modules
All Users: $pshome\Modules

1 2	Local User: $home\Documents\WindowsPowerShell\Modules All Users: $pshome\Modules

Using PowerCLI

One of the great enhancements in PowerCLI 6.5.1 means we no longer need to load the modules into the PowerShell session as we may have done in the past, as soon as the modules are loaded into the module folder PowerShell will automatically be aware of their existence and you will find the cmdlets registered with the PowerShell session. Normal PowerShell behaviour meanst that as soon as you use the first cmdlet the PowerCLI module will be loaded as needed.

But what about the nice PowerCLI Welcome message and other functions which existed to make PowerCLI easier to use when we launched the old desktop icon?

First, we can mimic the desktop shortcuts by simply running:

Import-Module VMware.PowerCLI

1	Import-Module VMware.PowerCLI

Please note the warning message about joining the Customer Experience Improvement Program (CEIP). We recommend enabling CEIP, as it’s greatly helps us improve our products! In order for the message to not appear, you either have to enable or disable CEIP by way of the Set-PowerCLIConfiguration cmdlet.

The other option to load the cmdlets, simply use the cmdlets as you normally would. The modules will auto-populate as necessary!

Here’s an example of using a new PowerShell session and connecting to a vCenter Server:

We can see the session begins without any PowerCLI modules being imported. After typing in the Connect-VIServer cmdlet (tab complete is fully operational as well), we can see the VMware.VimAutomation.Core module has been imported automatically! The other modules won’t be imported until they’re referenced.

Re-Creating The Desktop Shortcut

I know there are quite a few fans of the Desktop shortcut, so I’ll briefly describe how to set that up. First, create a shortcut that points to the PowerShell executable and place it on the desktop. Next, right click the newly created desktop shortcut and select properties. You should find yourself on the “Shortcut” tab. Enter the following values:

Target: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noe -c "Import-Module VMware.PowerCLI"
Start In: C:\
Shortcut Key: None
Run: Normal Window
Comment: Launch VMware PowerCLI

Target: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noe -c "Import-Module VMware.PowerCLI"

Start In: C:\

Shortcut Key: None

Run: Normal Window

Comment: Launch VMware PowerCLI

In the end, we should have something quite similar to the following:

Summary

This new install method is a very exciting improvement for PowerCLI. As seen above, this definitely streamlines the process of getting PowerCLI installed and accessible!

To find out more about the other fantastic improvements that are available with VMware PowerCLI 6.5.1, please see the following blog: New Release – PowerCLI 6.5.1

72 thoughts on “Welcome PowerCLI to the PowerShell Gallery – Install Process Updates”

Pingback: New Release: PowerCLI 6.5.1 - VMware PowerCLI Blog - VMware Blogs
Damien Solodow April 20, 2017 at 7:04 pm

Yay!!!
Excellent to see. 🙂
One note; since VMware.vimautomation.core contains -cluster cmdlets, if you have the FailoverClusters module installed you’ll need to add the -AllowClobber parameter to the Install-Module command.

Reply ↓
Pingback: New Release: PowerCLI 6.5.1 – VMpro.at
Gabrie van Zanten April 20, 2017 at 10:10 pm

Hi, when using the desktop shortcut, would that mean it won’t get loaded in other PowerShell windows? Because there are some overlaps like Get-VM between VMware PowerCLI and Hyper-V, we really need the different windows to work in.

Reply ↓
1. LucD April 20, 2017 at 10:50 pm
  
  Dear Gabrie,
  No you don’t need a separate window (that’s so 20th century btw)
  
  You have some options
  1) If you have conflicting cmdlets, add the module name in front
  
  VMware.VimAutomation.Core\Get-Cluster
  
  2) Use the Prefix parameter
  
  Import-Module -Name VMware.VimAutomation.Core -Prefix Pcl
  Get-PclCluster
  
  3) Unload the module you are not using
  
  Remove-Module -Name FailOverClusters
  
  Reply ↓
Thomas Møller April 20, 2017 at 11:06 pm

Do you still need to import https://github.com/vmware/PowerCLI-Example-Scripts/tree/master/Modules/VMware.Hv.Helper or is this now a part of the current installer?

Reply ↓
1. Jake Robinson April 21, 2017 at 7:48 am
  
  Hi Thomas, these advanced functions are not in the Horizon module. You’ll still need to import them.
  
  Reply ↓
Pasquale Lantella April 21, 2017 at 12:18 am

I have successfully installed the module locally, but what to publish it on our internal Repository (based on DFS file share) using:

Publish-Module -Name VMware.PowerCLI -Repository MyRepo -verbose -Force

and get an Error about dependencies issues for ‘VMware.VimAutomation.Sdk’

what is the best Method to publish powerCLI to an internal Repository?

Reply ↓
1. Jake Robinson April 21, 2017 at 7:50 am
  
  Hi Pasquale! Can you email me details on the error you are receiving? jaker at vmware
  
  Reply ↓
  1. Pasquale Lantella April 24, 2017 at 12:37 am
    
    Hi Jake! Here is the complete verbose output, I am Using a German windows 7 with Powershell 5.1
    
    PS C:\> Publish-Module -Name VMware.PowerCLI -Repository LHSRepo -verbose -Force
    VERBOSE: Repositorydetails, Name = ‘LHSRepo’, Location = ‘\\lhs.stuttgart.de\dfsroot\lhs\scripts\psGallery’; IsTrusted = ‘True’; IsRegistered = ‘True’.
    VERBOSE: Repositorydetails, Name = ‘LHSRepo’, Location = ‘\\lhs.stuttgart.de\dfsroot\lhs\scripts\psGallery’; IsTrusted = ‘True’; IsRegistered = ‘True’.
    VERBOSE: Ort der Veröffentlichung: “\\lhs.stuttgart.de\dfsroot\lhs\scripts\psGallery”.
    VERBOSE: Das Modul “VMware.PowerCLI” wurde in “C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.PowerCLI\6.5.1.5377412” gefunden.
    VERBOSE: Populating RepositorySourceLocation property for module VMware.PowerCLI.
    VERBOSE: Loading module from path ‘C:\Users\u104018\AppData\Local\Temp\605923979\VMware.PowerCLI\VMware.PowerCLI.ps1’.
    VERBOSE: Populating RepositorySourceLocation property for module VMware.VimAutomation.Sdk.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VimAutomation.Sdk\1.0.0.5334677\VMware.VimAutomation.Sdk.ps1’.
    VERBOSE: Populating RepositorySourceLocation property for module VMware.VimAutomation.Common.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VimAutomation.Common\6.5.1.5335010\VMware.VimAutomation.Common.ps1’.
    VERBOSE: Populating RepositorySourceLocation property for module VMware.VimAutomation.Core.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VimAutomation.Core\6.5.1.5374329\VMware.VimAutomation.Core.ps1’.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VimAutomation.Core\6.5.1.5374329\VMware.VimAutomation.ViCore.Cmdlets.dll’.
    VERBOSE: Populating RepositorySourceLocation property for module VMware.VimAutomation.Srm.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VimAutomation.Srm\6.5.1.5374694\VMware.VimAutomation.Srm.ps1’.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VimAutomation.Srm\6.5.1.5374694\VMware.VimAutomation.Srm.Commands.dll’.
    VERBOSE: Populating RepositorySourceLocation property for module VMware.VimAutomation.License.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VimAutomation.License\6.5.1.5375648\VMware.VimAutomation.License.ps1’.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VimAutomation.License\6.5.1.5375648\VMware.VimAutomation.License.Commands.dll’.
    VERBOSE: Populating RepositorySourceLocation property for module VMware.VimAutomation.Vds.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VimAutomation.Vds\6.5.1.5374428\VMware.VimAutomation.Vds.ps1’.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VimAutomation.Vds\6.5.1.5374428\VMware.VimAutomation.Vds.Commands.dll’.
    VERBOSE: Populating RepositorySourceLocation property for module VMware.VimAutomation.vROps.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VimAutomation.vROps\6.5.1.5375723\VMware.VimAutomation.vROps.ps1’.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VimAutomation.vROps\6.5.1.5375723\VMware.VimAutomation.vROps.Commands.dll’.
    VERBOSE: Populating RepositorySourceLocation property for module VMware.VimAutomation.Cis.Core.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VimAutomation.Cis.Core\6.5.1.5374323\VMware.VimAutomation.Cis.Core.ps1’.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VimAutomation.Cis.Core\6.5.1.5374323\VMware.VimAutomation.Cis.Core.Commands.dll’.
    VERBOSE: Populating RepositorySourceLocation property for module VMware.VimAutomation.HA.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VimAutomation.HA\6.0.0.5314477\VMware.HAModule.ps1’.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VimAutomation.HA\6.0.0.5314477\VMware.VimAutomation.HA.Commands.dll’.
    VERBOSE: Populating RepositorySourceLocation property for module VMware.VimAutomation.HorizonView.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VimAutomation.HorizonView\7.1.0.5307191\VMware.VimAutomation.HorizonView.ps1’.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VimAutomation.HorizonView\7.1.0.5307191\VMware.VimAutomation.HorizonView.Commands.dll’.
    VERBOSE: Populating RepositorySourceLocation property for module VMware.VimAutomation.PCloud.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VimAutomation.PCloud\6.5.1.5376282\VMware.VimAutomation.PCloud.ps1’.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VimAutomation.PCloud\6.5.1.5376282\VMware.VimAutomation.PCloud.Commands.dll’.
    VERBOSE: Populating RepositorySourceLocation property for module VMware.VimAutomation.Cloud.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VimAutomation.Cloud\6.5.1.5375799\VMware.VimAutomation.Cloud.ps1’.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VimAutomation.Cloud\6.5.1.5375799\VMware.VimAutomation.Cloud.Commands.dll’.
    VERBOSE: Populating RepositorySourceLocation property for module VMware.DeployAutomation.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.DeployAutomation\6.5.1.5299608\Initialize-VMware_DeployAutomation.ps1’.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.DeployAutomation\6.5.1.5299608\VMware.DeployAutomation.ps1’.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.DeployAutomation\6.5.1.5299608\VMware.DeployAutomation.dll’.
    VERBOSE: Populating RepositorySourceLocation property for module VMware.ImageBuilder.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.ImageBuilder\6.5.1.5299608\VMware.ImageBuilder.ps1’.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.ImageBuilder\6.5.1.5299608\VMware.ImageBuilder.dll’.
    VERBOSE: Populating RepositorySourceLocation property for module VMware.VimAutomation.Storage.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VimAutomation.Storage\6.5.1.5374001\VMware.VimAutomation.Storage.ps1’.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VimAutomation.Storage\6.5.1.5374001\VMware.VimAutomation.Storage.Commands.dll’.
    VERBOSE: Populating RepositorySourceLocation property for module VMware.VimAutomation.StorageUtility.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VimAutomation.StorageUtility\1.0\StorageUtility.psm1’.
    VERBOSE: Populating RepositorySourceLocation property for module VMware.VumAutomation.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VumAutomation\6.5.1.5301639\VMware.VumAutomation.ps1’.
    VERBOSE: Loading module from path ‘C:\Users\u104018\Documents\WindowsPowerShell\Modules\VMware.VumAutomation\6.5.1.5301639\VMware.VumAutomation.dll’.
    VERBOSE: Repositorydetails, Name = ‘LHSRepo’, Location = ‘\\lhs.stuttgart.de\dfsroot\lhs\scripts\psGallery’; IsTrusted = ‘True’; IsRegistered = ‘True’.
    VERBOSE: Der Anbieter “PowerShellGet” wird für die Paketsuche verwendet.
    VERBOSE: Die angegebenen Quellnamen werden verwendet: ‘LHSRepo’.
    VERBOSE: Das Anbieterobjekt für den PackageManagement-Anbieter “NuGet” wird abgerufen.
    VERBOSE: Der angegebene Speicherort ist “\\lhs.stuttgart.de\dfsroot\lhs\scripts\psGallery”, und PackageManagementProvider ist “NuGet”.
    VERBOSE: Total package yield:’0′ for the specified package ‘VMware.PowerCLI’.
    VERBOSE: Repositorydetails, Name = ‘LHSRepo’, Location = ‘\\lhs.stuttgart.de\dfsroot\lhs\scripts\psGallery’; IsTrusted = ‘True’; IsRegistered = ‘True’.
    VERBOSE: Der Anbieter “PowerShellGet” wird für die Paketsuche verwendet.
    VERBOSE: Die angegebenen Quellnamen werden verwendet: ‘LHSRepo’.
    VERBOSE: Das Anbieterobjekt für den PackageManagement-Anbieter “NuGet” wird abgerufen.
    VERBOSE: Der angegebene Speicherort ist “\\lhs.stuttgart.de\dfsroot\lhs\scripts\psGallery”, und PackageManagementProvider ist “NuGet”.
    VERBOSE: Total package yield:’0′ for the specified package ‘VMware.PowerCLI’.
    VERBOSE: Repositorydetails, Name = ‘LHSRepo’, Location = ‘\\lhs.stuttgart.de\dfsroot\lhs\scripts\psGallery’; IsTrusted = ‘True’; IsRegistered = ‘True’.
    VERBOSE: Der Anbieter “PowerShellGet” wird für die Paketsuche verwendet.
    VERBOSE: Die angegebenen Quellnamen werden verwendet: ‘LHSRepo’.
    VERBOSE: Das Anbieterobjekt für den PackageManagement-Anbieter “NuGet” wird abgerufen.
    VERBOSE: Der angegebene Speicherort ist “\\lhs.stuttgart.de\dfsroot\lhs\scripts\psGallery”, und PackageManagementProvider ist “NuGet”.
    VERBOSE: Total package yield:’0′ for the specified package ‘VMware.VimAutomation.Sdk’.
    Publish-PSArtifactUtility : PowerShellGet kann die Modulabhängigkeit ‘VMware.VimAutomation.Sdk’ des Moduls ‘VMware.PowerCLI’ im Repository ‘LHSRepo’ nicht auflösen. Vergewissern Sie sich,
    dass das abhängige Modul ‘VMware.VimAutomation.Sdk’ im Repository ‘LHSRepo’ verfügbar ist. Wenn dieses abhängige Modul ‘VMware.VimAutomation.Sdk’ extern verwaltet wird, fügen Sie es dem
    ExternalModuleDependencies-Eintrag im PSData-Abschnitt des Modulmanifests hinzu.
    At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1190 char:17
    + Publish-PSArtifactUtility -PSModuleInfo $moduleInfo `
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : InvalidOperation: (:) [Publish-PSArtifactUtility], InvalidOperationException
    + FullyQualifiedErrorId : UnableToResolveModuleDependency,Publish-PSArtifactUtility
    
    Reply ↓
    1. Greg Harms May 8, 2017 at 2:20 pm
      
      Publish-Module will not include module dependencies. It expects those modules to already be in the repository. So you’ll need to publish each module that VMware.PowerCLI depends on separately.
      
      By publishing the other VMware modules first, I’ve successfully re-published VMware.PowerCLI 6.5.1 to an internal NuGet repo that I use only for PowerShell modules.
      
      Reply ↓
Pingback: PowerCLI 6.5.1 Released | Virtual Allan
Pingback: VMware PowerCLI 6.5.1 moves to the PowerShell Gallery - How to Code .NET
LucD April 22, 2017 at 1:02 am

If you have modules with conflicting cmdlets (ex. Get-Cluster) on your system, use the -NoClobber switch on the Install-Module cmdlet!

Reply ↓
1. LucD April 22, 2017 at 1:09 am
  
  That should have said -AllowClobber
  
  Reply ↓
snehalat April 23, 2017 at 6:55 am

Thanks for sharing the install process updates . Its really helpful for me .

Reply ↓
Pingback: How to install VMware.PowerCLI for the VMware Connection
Nasko April 24, 2017 at 6:49 am

Hi All,

When I try to install the VMware.PowerCLI module, it fails with the following error :

PackageManagement\Install-Package : Package ‘VMware.VimAutomation.Core’ failed to be installed because: The process cannot access the file
‘C:\Users\UserName\AppData\Local\Temp\acdc2k22\InternalVimService50.dll’ because it is being used by another process.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1772 char:21
+ … $null = PackageManagement\Install-Package @PSBoundParameters
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidResult: (VMware.VimAutomation.Core:String) [Install-Package], Exception
+ FullyQualifiedErrorId : Package ‘{0}’ failed to be installed because: {1},Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPack
age

I have tried with admin and non-admin user. It fails with different *.dll file. I receive the same error when I use save-module.

If I use verbose, I see non-matching hashes:

VERBOSE: Completed downloading ‘VMware.VimAutomation.Cis.Core’.
VERBOSE: Hash for package ‘VMware.VimAutomation.Cis.Core’ does not match hash provided from the server.
VERBOSE: InstallPackageLocal’ – name=’VMware.VimAutomation.Cis.Core’,

My OS is Win7 SP1 x64.

Thanks!
Nasko

Reply ↓
1. Alexander Kolev April 24, 2017 at 10:24 am
  
  Make sure that you’ve uninstalled previous versions of PowerCLI, closed all other PowerShell sessions, the PowerShell ISE, etc.
  
  You may want to see which process is holding a lock on InternalVimService50.dll. (you can use ProcessExplorer for this). That will certainly give a clue into what’s the root cause here
  
  Cheers,
  A
  
  Reply ↓
  1. Nasko April 25, 2017 at 2:42 am
    
    Many thanks for your reply Alex!
    
    I’ve tried on a new PC (Win7SP1,x64) where I have never had any previous PowerCLI versions and Installation failed with the following error:
    
    PackageManagement\Install-Package : Package ‘VMware.VimAutomation.Srm’ failed to be installed because: End of Central
    Directory record could not be found.
    At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1772 char:21
    + … $null = PackageManagement\Install-Package @PSBoundParameters
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : InvalidResult: (VMware.VimAutomation.Srm:String) [Install-Package], Exception
    + FullyQualifiedErrorId : Package ‘{0}’ failed to be installed because: {1},Microsoft.PowerShell.PackageManagement
    .Cmdlets.InstallPackage
    
    When I re-run the install-module, I received a new error:
    
    PackageManagement\Install-Package : Package ‘VMware.VimAutomation.HA’ failed to be installed because: End of Central
    Directory record could not be found.
    At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1772 char:21
    + … $null = PackageManagement\Install-Package @PSBoundParameters
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : InvalidResult: (VMware.VimAutomation.HA:String) [Install-Package], Exception
    + FullyQualifiedErrorId : Package ‘{0}’ failed to be installed because: {1},Microsoft.PowerShell.PackageManagement
    .Cmdlets.InstallPackage
    
    I used Process Monitor this time but captured about 1GB of events. I excluded all SUCESS events and searched for VMware.VimAutomation.HA.
    
    Below are some of the errors I found:
    
    create file – NAME NOT FOUND – powershell.exe and System
    C:\Users\UserName\AppData\Local\Temp\1041739277\VMware.VimAutomation.HA
    C:\Users\UserName\AppData\Local\Temp\1041739277\VMware.VimAutomation.HA\VMware.VimAutomation.HA.nupkg
    
    createfilemapping – FILE LOCKED WITH ONLY READERS – User: NT AUTHORITY\SYSTEM
    C:\Users\UserName\AppData\Local\Temp\1041739277\VMware.VimAutomation.HA\VMware.VimAutomation.HA.nupkg
    
    read file END OF FILE
    C:\Users\UserName\AppData\Local\Temp\1041739277\VMware.VimAutomation.HA\VMware.VimAutomation.HA.nupkg
    
    create file – PATH NOT FOUND
    C:\Users\UserName\AppData\Local\Temp\1041739277\VMware.VimAutomation.HA\VMware.VimAutomation.HA.nupkg
    
    Any Ideas?
    
    Thanks!
    Nasko
    
    Reply ↓
    1. Alexander Kolev May 5, 2017 at 1:13 am
      
      Seems you’re hitting a bug that’s similar to what’s described here: https://msdn.microsoft.com/en-us/powershell/gallery/psgallery/psgallery_status
      
      We will take this with Microsoft to see if they’ve changed anything lately
      
      Cheers,
      Alex
      
      Reply ↓
    2. Daved October 14, 2017 at 3:32 pm
      
      Right-click PowerShell_ISE.exe and Run as administrator.
      
      Reply ↓
2. Andreas Paulsson June 30, 2017 at 2:29 am
  
  I had this problem as well, was solved by disabling Antivirus during installation.
  
  Reply ↓
Jason Boche April 24, 2017 at 7:51 am

I ran into issues with the installation on Windows 7 with POSH 4.0. PowerShellGet module is required. That can be found here: https://msdn.microsoft.com/powershell/gallery/readme

I used the MSI Installer version.

Thanks Kyle.

Reply ↓
John Ludlow April 25, 2017 at 2:14 am

I got the same same error as Pasquale, then started to publish the modules to our private gallery 1 by 1. I got as far as the .Core module and got this error:

Publish-PSArtifactUtility : Failed to publish module ‘VMware.VimAutomation.Core’: ‘Failed to process request. ‘A nuget package’s Tags property may not be more than 4000 characters long.’.
The remote server returned an error: (500) Internal Server Error..
‘.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.1.2.0\PSModule.psm1:1227 char:17
+ Publish-PSArtifactUtility -PSModuleInfo $moduleInfo `
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : FailedToPublishTheModule,Publish-PSArtifactUtility

Reply ↓
Tacos Are Tasty April 25, 2017 at 6:49 am

Can’t even get NuGet to load

PS C:\Users\UserName> Find-Module -Name VMware.PowerCLI

NuGet provider is required to continue
PowerShellGet requires NuGet provider version ‘2.8.5.201’ or newer to interact with NuGet-based repositories. The NuGet provider must be available in ‘C:\ProgramFiles\PackageManagement\ProviderAssemblies’ or ‘C:\Users\UserName\AppData\Local\PackageManagement\ProviderAssemblies’. You can also install the NuGet provider by running ‘Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force’. Do you want PowerShellGet to install and import the NuGet provider now?
[Y] Yes [N] No [S] Suspend [?] Help (default is “Y”): Y
PackageManagement\Install-PackageProvider : No match was found for the specified search criteria for the provider ‘NuGet’. The package provider requires ‘PackageManagement’ and ‘Provider’ tags. Please check if the specified package has the tags.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\PSModule.psm1:6463 char:21
+ $null = PackageManagement\Install-PackageProvider -Name $script:NuGe …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (Microsoft.Power…PackageProvider:InstallPackageProvider) [Install-PackageProvider], Exception
+ FullyQualifiedErrorId : NoMatchFoundForProvider,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackageProvider

PackageManagement\Import-PackageProvider : No match was found for the specified search criteria and provider name ‘NuGet’. Try ‘Get-PackageProvider -ListAvailable’ to see if the provider exists on the system.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\PSModule.psm1:6469 char:21
+ $null = PackageManagement\Import-PackageProvider -Name $script:NuGet …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidData: (NuGet:String) [Import-PackageProvider], Exception
+ FullyQualifiedErrorId : NoMatchFoundForCriteria,Microsoft.PowerShell.PackageManagement.Cmdlets.ImportPackageProvider

PackageManagement\Get-PackageProvider : Unable to find package provider ‘NuGet’. It may not be imported yet. Try ‘Get-PackageProvider -ListAvailable’.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\PSModule.psm1:6473 char:30
+ $nugetProvider = PackageManagement\Get-PackageProvider -Name $script …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Microsoft.Power…PackageProvider:GetPackageProvider) [Get-PackageProvider], Exception
+ FullyQualifiedErrorId : UnknownProviderFromActivatedList,Microsoft.PowerShell.PackageManagement.Cmdlets.GetPackageProvider

Find-Module : NuGet provider is required to interact with NuGet-based repositories. Please ensure that ‘2.8.5.201’ or newer version of NuGet provider is installed.
At line:1 char:1
+ Find-Module -Name VMware.PowerCLI
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Find-Module], InvalidOperationException
+ FullyQualifiedErrorId : CouldNotInstallNuGetProvider,Find-Module

Reply ↓
STGdb April 26, 2017 at 8:39 am

I had the same issue. Turned out to be my AV client installed on my system (Trend Micro OfficeScan). I unloaded the AV client and was able to install PowerCLI successfully.

Reply ↓
agonzalez April 26, 2017 at 2:17 pm

Got error:

PS C:\Windows\system32> Install-Module -Name VMware.PowerCLI –Scope AllUsers

Untrusted repository
You are installing the modules from an untrusted repository. If you trust this repository, change its
InstallationPolicy value by running the Set-PSRepository cmdlet. Are you sure you want to install the modules from
‘PSGallery’?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is “N”): y
PackageManagement\Install-Package : A command with name ‘Export-VM’ is already available on this system. This module
‘VMware.VimAutomation.Core’ may override the existing commands. If you still want to install this module
‘VMware.VimAutomation.Core’, use -AllowClobber parameter.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1772 char:21
+ … $null = PackageManagement\Install-Package @PSBoundParameters
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (Microsoft.Power….InstallPackage:InstallPackage) [Install-Package],
Exception
+ FullyQualifiedErrorId : CommandAlreadyAvailable,Validate-ModuleCommandAlreadyAvailable,Microsoft.PowerShell.Pack
ageManagement.Cmdlets.InstallPackage

Reply ↓
1. agonzalez April 26, 2017 at 2:21 pm
  
  I think there is some conflict with MS hyperv Export-VM cmdlet in windows 10. https://technet.microsoft.com/en-us/itpro/powershell/windows/hyper-v/export-vm
  
  Reply ↓
Pingback: Welcoming PowerCLI to the PowerShell Gallery - Wahl Network
Pankaj May 4, 2017 at 6:15 am

Looks like I am been blocked at proxy when I am trying to install packageprovider NuGet. Is there any alternate to upgrade powrcli to latest with MSI ?

Install-PackageProvider -Name NuGet -force -verbose
VERBOSE: Using the provider ‘Bootstrap’ for searching packages.
VERBOSE: Using the provider ‘PowerShellGet’ for searching packages.
VERBOSE: Finding the package ‘Bootstrap::FindPackage’ ‘NuGet’,”,”,”’.
VERBOSE: The -Repository parameter was not specified. PowerShellGet will use all of the registered repositories.
VERBOSE: Unable to download from URI ‘https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409’ to ”.
VERBOSE: Cannot download link ‘https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409’, retrying for ‘2’ more times
VERBOSE: Unable to download from URI ‘https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409’ to ”.
VERBOSE: Cannot download link ‘https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409’, retrying for ‘1’ more times
VERBOSE: Unable to download from URI ‘https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409’ to ”.
VERBOSE: Cannot download link ‘https://go.microsoft.com/fwlink/?LinkID=627338&clcid=0x409’, retrying for ‘0’ more times
WARNING: Unable to download the list of available providers. Check your internet connection.
Install-PackageProvider : No match was found for the specified search criteria for the provider ‘NuGet’. The package provider requires ‘PackageManagement’ and ‘Provider’ tags. Please check if the
specified package has the tags.
At line:1 char:1
+ Install-PackageProvider -Name NuGet -force -verbose
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (Microsoft.Power…PackageProvider:InstallPackageProvider) [Install-PackageProvider], Exception
+ FullyQualifiedErrorId : NoMatchFoundForProvider,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackageProvider

Reply ↓
1. Jatin February 12, 2019 at 1:49 am
  
  I have had the same issue and upon checking it seems to be happening because FIPS encryption was enabled. disable the FIPS and you won’t face any issue with Nuget Package provider.
  
  Reply ↓
Ray Holtz May 4, 2017 at 11:29 am

Is it possible to get a copy of the icon file to use for our desktop shortcuts? when I uninstalled the old Powercli, it deleted the old icon.

Reply ↓
1. Andreas Paulsson June 30, 2017 at 2:30 am
  
  This! Yes, please give us an icon!
  
  Reply ↓
Holger May 4, 2017 at 11:52 pm

Good Morning,

i have a 32Bit process using the (old=6.5.0) PowerCLI, after migrating to 6.5.1 the module is only available for 64Bit process (Modules in C:\Program Files\WindowsPowerShell\Modules\…), i copied the files from said director to C:\Program Files (x86)\WindowsPowerShell\Modules, and it seems to work, is this the recommended way to make PowerCLI available für 32Bit processes?

Thanks
Holger

Reply ↓
David May 8, 2017 at 4:42 pm

Are we going to be able to install and run PowerCLI this way sometime in the future on the cross-platform PowerShell for macOS and Linux?

Reply ↓
Pingback: PowerCLI 6.5.1 インストール方法 – cjnotes
Peter May 12, 2017 at 5:45 am

Hi all,

i tried to install the newest Powercli on a Windows 2016 Server (used for Remote Desktops Apps)
This Server has no Internet Connection.
The following VMware “programs” are installed:

VMware Client Integration Plug-in 6.0.0
VMware Remote Console (Version 9.0.0)
VMware Tools (Version 10.1.5.5055683)
VMware Vsphere Client 6.0.0.7236

I downloaded PowerCLI as described above and copied the files to “c$\Windows\System32\WindowsPowerShell\v1.0\Modules” of that Server…
Connecting to Vcenter works fine…
other commands also work fine as far as I tested them…

But one very important one fails:

Open-VMConsoleWindows -vm xxxxx
…brings up: The procedure entry point could not be located in the dynamic link library c:\windows\system32\WindowsPowerShell\v1.0\Modules\VMware.VimAutomation.Core\6.5.1.5374329\VMware Remote Console\vmrc.exe.

If I try to deinstall the “older” VMware remote console it will get even worse… Several Errors occur like this one: The program can’t start because vmapputil.dll is missing from your computer. Try reinstalling the program to fix this Problem.
The same Errors come up with vmdbCOM.dll, glib-2.0.dll, sigc-2.0.dll….

Any ideas how I can get OpenVMConsoleWindows to work?

Thanks

Peter

Reply ↓
Mordock May 17, 2017 at 4:46 pm

Welcome to 1965. Let’s all get out our DOS manual and figure out how to do everything from the command line, including how to even install things. So we will no longer be able to download anything like a recognizable install file from the primary location that we get absolutely everything VMware from. What moron thought this was a good idea? For those people that have no interest in security and have no firewalls, I suppose this might seem like something interesting. But I am behind multiple firewalls with strong anti-virus and frankly there is no way that I am going to be able to install this package as intended. From just these few posts above, this is going to create a major headache. I can guarantee you that I will have every one of the problems listed above trying to get this 1965 atrocity to work. Just why are you fixing something that was not broke?????? An MSI is a perfectly viable tool for installing and distributing software. It is easily distributable with tools like System Center, or HPSA, or any number of other enterprise management tools from the 20th century. When you get this back to a point ( at least year 2000) where I can download it from a recognized VMware source, double click on it to install it, call me.

Reply ↓
1. Christopher Gray May 23, 2017 at 4:12 pm
  
  Because moving to install-module allows for cross-platform compatibility for management, something they’ve been saying they wanted to support for quite some time. This coincides with the near future removal of a Windows server for vCenter, and the removal of the Windows thick client. Everything’s going to OS agnostic.
  
  Reply ↓
Wu May 18, 2017 at 8:10 pm

The “tab complete” function doesn’t work for parameters on Windows 2016.
For example, I input ‘get-vmhost -‘ then hit tab key, nothing reflect here.

Reply ↓
alessio May 19, 2017 at 4:43 am

so the new installation trough powershell’s gallery seems a part of what we call (in Italy) OfCST (office for complicating simple things)
while an MSI would have solved all the troubles at once now to use an ISO customization PSscript I have to install your powerCli, Nuget and files to use PowershellGallery -which doesn’t work and I have to waste time to check why.
a bit disappointed, sorry!

Reply ↓
James May 22, 2017 at 9:04 am

Can I install this on a workstation that has Hyper-V role installed along with powershell commandlets associated with it?
I thought I could use the -AllowClobber switch, but worried it will affect my Hyper-V commandlets?

Reply ↓
1. Kyle Ruddy Post authorJune 9, 2017 at 1:24 pm
  
  Yes, using the -AllowClobber switch will allow both sets of modules to co-exist even with though they have overlapping (name-wise) cmdlets.
  
  Reply ↓
Chris June 8, 2017 at 12:41 pm

I just installed the new version on my laptop and it is sweet! I am going to update my PowerShell Web Access server with the new version and really kick things up a notch! Thanks again Kyle!!!

Reply ↓
Adam Granatella June 9, 2017 at 12:45 pm

Seems like this is impossible to install on Windows 7. I’ve moved to Windows 10 but most of my team is still on 7. Find-Module and Install-Module are not available in PowerShell 3.0. I can’t upgrade to PowerShell 5.1 because 3.0 is installed. The uninstall of 3.0 fails. I can’t install 4.0 or 5.0 as they fail at the end of the installation with no useful information. I’ve tried this on a Win7 VM and a Win7 laptop that were created with two separate builds. Am I stuck with PowerCLI 6.3?

Reply ↓
1. Kyle Ruddy Post authorJune 9, 2017 at 1:22 pm
  
  Have you tried installing PowerShellGet? That will install and make available the *-module cmdlets.
  
  It’s available here: https://www.microsoft.com/en-us/download/details.aspx?id=51451
  
  Reply ↓
david zemdegs June 22, 2017 at 4:53 pm

Did a save-module as we don’t have direct internet access.
Copied all the folders beginning with VMware to C:\Windows\System32\WindowsPowerShell\v1.0\Modules
did get-module -listavailable and they aint there
Normal modules have files beneath the folder name – VMware doesn’t – VMware folders have another folder with the version number and files under there.
Tried copying the files from under the version number folder into the root. The modules are then listed but cannot be imported.
How do I make these modules available please?

Reply ↓
1. Daniel July 27, 2017 at 12:56 am
  
  Update to Windows Management Framework 5.x solved this problem
  
  Reply ↓
Sathish June 27, 2017 at 3:11 am

Thanks. That was good to integrate the PowrCLI into Powershell. After Importing Module 6.5, when i am trying to add Additional NiC Card for 10+ Servers and run the script, I used to get error “New-NetworkAdapter : Cannot process argument transformation on parameter ‘VM’. This parameter no longer accepts an Array. As an alternative you may pass multiple values by pipeline (if supported by the parameter).

Script contains the below lines.
Connect-viserver VCname
$vmname = gc D:\Scripts\Add-NIC\Servers.txt
New-NetworkAdapter -VM $vmname -Type Vmxnet3 -NetworkName “NetWork Label -WakeOnLan:$true -StartConnected:$true -Confirm:$false

Reply ↓
Jason Sandler July 16, 2017 at 11:49 am

PS C:\WINDOWS\system32> Install-Module -Name VMware.PowerCLI -Scope AllUsers

Untrusted repository
You are installing the modules from an untrusted repository. If you trust this repository, change its
InstallationPolicy value by running the Set-PSRepository cmdlet. Are you sure you want to install the modules from
‘PSGallery’?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is “N”): a
PackageManagement\Install-Package : The module ‘VMware.VimAutomation.Sdk’ cannot be installed or updated because the
authenticode signature of the file ‘VMware.VimAutomation.Sdk.cat’ is not valid.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1809 char:21
+ … $null = PackageManagement\Install-Package @PSBoundParameters
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (Microsoft.Power….InstallPackage:InstallPackage) [Install-Package],
Exception
+ FullyQualifiedErrorId : InvalidAuthenticodeSignature,ValidateAndGet-AuthenticodeSignature,Microsoft.PowerShell.P
ackageManagement.Cmdlets.InstallPackage

Reply ↓
Rahul Kumar September 14, 2017 at 4:39 am

Could not even save module in specified path and getting below error.

C:\windows\system32> Save-Module -Name VMware.PowerCLI -Path “C:\studies\PowerCLI 6.5.2”
ARNING: Could not get response from query
https://www.powershellgallery.com/api/v2/package/VMware.VimAutomation.Core/6.5.2.6234650‘.
ARNING: MSG:SourceLocationNotValid «https://www.powershellgallery.com/api/v2/»
ARNING: Package ‘VMware.VimAutomation.Core’ failed to install.
ARNING: Dependent Package ‘VMware.VimAutomation.Core’ failed to install.
ARNING: Package ‘VMware.PowerCLI’ failed to install.
ackageManagement\Save-Package : Unable to save the module ‘VMware.PowerCLI’.
t C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\1.0.0.1\PSModule.psm1:1561 char:21
$null = PackageManagement\Save-Package @PSBoundParameters
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (Microsoft.Power…ets.SavePackage:SavePackage) [Save-Package], Exce
+ FullyQualifiedErrorId : ProviderFailToDownloadFile,Microsoft.PowerShell.PackageManagement.Cmdlets.SavePackage

Reply ↓
Amit September 15, 2017 at 9:59 pm

VMWare.Vim.dll is not strongly named and hence can’t be added to GAC as a result our .Net application is not able to found dependent DLL’s while trying to make a connection to vCenter server. Should’t powercli installation from powershell gallery take care of automatically adding the dll’s to GAC for .NET based applicaiton to work fine.

Reply ↓
Pingback: PowerCLI Installation and Update using PowerShell Gallery Memo
Pingback: PowerCLI - Obtenir les différents OS - vRan
Jono January 9, 2018 at 12:05 am

I have an issue updating PowerCLI

Find-Module VMware.PowerCLI | Update-Module -RequiredVersion 6.5.4.7155375 -Verbose
VERBOSE: Checking for updates for module ‘VMware.PowerCLI’.
VERBOSE: Repository details, Name = ‘PSGallery’, Location = ‘https://www.powershellgallery.com/api/v2/’; IsTrusted = ‘False’;
IsRegistered = ‘True’.
VERBOSE: Using the provider ‘PowerShellGet’ for searching packages.
VERBOSE: Using the specified source names : ‘PSGallery’.
VERBOSE: Getting the provider object for the PackageManagement Provider ‘NuGet’.
VERBOSE: The specified Location is ‘https://www.powershellgallery.com/api/v2/’ and PackageManagementProvider is ‘NuGet’.
VERBOSE: Searching repository ‘https://www.powershellgallery.com/api/v2/FindPackagesById()?id=’VMware.PowerCLI” for ”.
VERBOSE: Total package yield:’1’ for the specified package ‘VMware.PowerCLI’.
VERBOSE: Skipping installed module VMware.PowerCLI 6.5.4.7155375.

I am currently on VMware PowerCLI 6.5.1 build 5377412 and PSVersion 5.1.15063.786

Reply ↓
iniciar sesiom May 18, 2018 at 2:25 am

¡Quiero agradecerles por esta maravillosa lectura! Definitivamente, me gusto cada parte de ello. Te tengo marcado para ver las cosas nuevas que publicas …

Reply ↓
norton.com/setup August 29, 2018 at 10:03 am

Yes i Agree. Great article emi thanks for sharing.

Reply ↓
duoclieuthaison.com November 14, 2018 at 11:20 pm

Hi Thank You For sharing this it helps me alot like these:

Reply ↓
cayxaden.com.vn November 14, 2018 at 11:20 pm

thank you very much

Reply ↓
neet syllabus November 16, 2018 at 11:14 pm

adding the dll’s to GAC for .NET based applicaiton to work fine.
more to work on it visit https://neet365.in

Reply ↓
office setup November 27, 2018 at 10:48 am

Here in Atlanta, we appreciate it:

Reply ↓
norton.com/setup November 29, 2018 at 7:15 am

Thanks for information , its really helpful..

Reply ↓
Pingback: VMware alert monitoring with PRTG and PowerShell - IT-Admins
ketogenic diet ratio December 8, 2018 at 10:12 am

Nice tutorial

Reply ↓
Pingback: DSCR for VMware and you! - LucD notes
Chris January 19, 2019 at 10:57 am

Wouldn’t it be better to depreciate this article in favour of the PowerShell Gallery PowerCLI module, now currently running at v11.1 ?

Running this old EXE cause problem when people discover the new PowerCLI module. It also is the top most article when you search for PowerCLI. Even if you just added a note to the top of the article, that would be good.

Reply ↓
KAPIL January 22, 2019 at 11:39 am

Hi All,

Why I am getting below error in psake script

Invoke-XmlPreprocess “$releaseArtifacts/$webName/Web.Config” $configurationEnvi …
11:28:35.280 + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [<>] Exception: Cannot validate argument on parameter ‘private:configFile’. The ” Test-Path $_ -PathType Leaf ” validation script for the argument with value “D:\GoAgent\pipelines\EMSWeb.Deploy.Dev\ReleaseArtifacts/MS/Web.Config” did not return a result of True.

Reply ↓
KAPIL January 22, 2019 at 11:41 am

I am using below code for web.config deployment in deploy.ps1 file, Please help.

Task PublishWeb {
Invoke-XmlPreprocess “$releaseArtifacts/$webName/Web.Config” $configurationEnvironmentVariables.Keys

Publish-WebApplication "$releaseArtifacts/$webName"
“$webservicesPath/$webName/$uniqueDeploymentPath” "$webName.$env:ConfigurationEnvironment"
-IdentityType LocalSystem `
-IdleTimeout ([TimeSpan]::FromDays(1))
}

Reply ↓
Pingback: vSphere Upgrade Saga: PowerCLI 10 - AstroArch Consulting, Inc
Yeh Rishta Kya Kehlata Hai February 17, 2019 at 11:55 pm

Excellent article. I’m experiencing a few of these issues as well..

Reply ↓
Pingback: VMware wi/ PowerShell: Output specific VM's - How to Code .NET

VMware PowerCLI Blog

PowerCLI is the best tool for automating management and configuration of VMware vSphere