I didn't get around to installing, just yet (I was turned off by some of the documented Known Issues).
I know certain components are now proper PowerShell Modules, instead of PSSnapins.
Depending on the location of the module directory, that may be dictating why only an elevated prompt can access those cmdlets.
In PowerCLI 5.8 R1, Get-PowerCLIVersion was part of the vmware.vimautomation.core PSSnapin.
What does running: Get-Command -Name Get-PowerCLIVersion yield, as far as module name?
You could then do: Get-Module -Name $ModuleName and see where the module is located. (Where $ModuleName is the name of the module found in the previous step.)
I had the exact same issue, and found the solution.
Basically the PowerCLI installer puts the PowerCLI modules directory in the PSModulesPath variable of the user that runs the installer rather than the machine wide variable.
If you add 'C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\Modules' to the machine wide PSModulesPath environment variable, PowerCLI should launch without error.
During the installation of PowerCLI v6, the registry is updated to reflect the new modules folder.
In HKCU\Environment\PSModulePath the PowerCLI modules folder is added.
You can see this when you display $env:PSModulePath.
Could it be that you installed PowerCLI v6 with another account as the one you are trying to use it with ?
Is the registry key updated during the installation ?
Yes, I ran the installer as a different user (I don't run as a local admin).
And yes, the installer added the directory to the PSModulesPath of the installing user, but it seems like it should put it in the HKLM version of the variable.
My opinion is that there should be an option, like For this user or For all users during the installation
I installed this as my account, over the top of an existing install (installer asks to remove/upgrade)
After a reboot I can seem to run this as non admin user, this only extra thing I did when testing was to manually run the XML serializes for 6/5/4 version of powercli
Cheeers for your time
1 person found this helpful
if you want to modify PS module path for all users, you can run powershell as administrator and run something like this:
$CurrentValue = [Environment]::GetEnvironmentVariable("PSModulePath", "Machine")
[Environment]::SetEnvironmentVariable("PSModulePath", $CurrentValue + ";C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\Modules", "Machine")
Had this same issue and your power shell solution fixed the issue - many thanks.
Works like a charm. Thanks
I'm having the same problem after installing 6.0.0 R2 (released last week). The installer appears to be updating the PSModulePath machine environment variable, but PowerShell still wasn't picking up the change (even with launching a new process). I had to log off and log back in to get it working.
The script fixed my issue too..
Fixed the problem...
FYI - a different user will most likely beused - As most people aint running in the context of admin anymore.
So if I ran powercli as admin, no problem (elevated rights), but as my user (the one I installed it with), I get the error.
@VMware This must be consideret a bug - Just installed PowerCli 6.0 R3 clean install, and the problem is there.
Are you sure about that, the issue was there in PowerCLI 6R1, but afaik it was fixed in PowerCLI 6R3.
Or is the problem perhaps, that you ran the install with an account that can't update the machine environment variable ?