Just a quick note to let you all Know PowerCLI 6.5 is out now and remember it works with previous versions so don't delay, enjoy today!
New Release: PowerCLI 6.5 R1 - VMware PowerCLI Blog - VMware Blogs
Thanks Alan!!! You're the man!
Does saying, "you're the man" qualify as the CORRECT RESPONSE?!
From what I heard, it's "you're the Senior man" now! Congrats by the way, well deserved!
André
Not so sure he wants to be known as a SENIOR man... He's not gone grey yet!
But, I like version v 1.0. Does this mean I have not been paying attention?!
Just wondering why the file size is so much smaller than 6.3 ?
6.3 = 82MB
6.5 = 37MB
looks like this package is broken, its missing the assemblies creation and it gets errors when trying to load the modules.
Works for me on multiple machines.
Can you give us the errors you are getting (during install and when trying to run)?
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
first of all, powercli 6.3 installs and works without an issue,
after upgrade to 6.5 (or even standalone install) I get the following error when launching the powercli shortcut:
Unable to find type [VMware.VimAutomation.Sdk.Util10.ProductInfo].
At C:\Program Files (x86)\VMware\Infrastructure\PowerCLI\Scripts\Initialize-PowerCLIEnvironment.ps1:71 char:28
+ ... iendlyVersion = [VMware.VimAutomation.Sdk.Util10.ProductInfo]::PowerC ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (VMware.VimAutom...l10.Product
Info:TypeName) [], RuntimeException
+ FullyQualifiedErrorId : TypeNotFound
Hi,
it seems you've hit this weird MSI bug
If you still reproduce the error can you check your $env:PSModulePath variable contains the PowerCLI install path 'C:\Program Files (x86)\VMware\Infrastructure\PowerCLI\Modules'. If it doesn't try to log off then log on, then everything should be fine. Another option is to update the $env:PSModulePath variable manually.
In more details the problem is that sometimes because of the above mentioned bug PowerCLI's installer fails to update the PSModulePath environment variable with the path to the PowerCLI modules. It is typically rarely reproduced bug and we have it for a number of releases, it is not new bug in 6.5R1, but the symptoms in the past were different.
-Dimitar Milov
Hi Dimitar,
Isn't the issue also related to the fact that extensions to PSModulePath should be inserted at the beginning of the string, and that an MSI doesn't know what user context is already there?
See PSModulePath discrepancies
PS: another argument to have the PowerCLI module in one of the "standard" module folders :smileygrin:
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
its the same on 3 different computers two of them are windows7 and another one is windows 10.
all experience the same issue.
also the powercli6.5 install file is significantly smaller that 6.3 and I noticed it installs differently.
What is the result of $env:PSModulePath in a fresh PowerShell session?
The 6.5 installer is significantly smaller because 6.5 stopped supporting vSphere 5.0 and vSphere5.1 and thus a set of binaries was removed.
Hi Luc,
I don't think the described discrepancies matters in this case. The problem that we are facing with the MSI is not related to the specifics of PSModulePath variable construction. PowerCLI is adding the custom modules' path at the end though, but it updates the SYSTEM value, so I expect this is safe.
About the deployment in standard folder, yep, let's wait for the next release