VMware vSphere PowerCLI 6.0 Release 1 build 2548067 - Get-PowerCLIVersion fails

[Softsource]

Just installed the 6.0 version of powercli

If I launch PowerCLI as administator (i.e. elevated permissions) all is fine (x64 and x32)

If I launch PowerCLI as default user (i.e. Not elevated permissions) not all the modules load

"

Get-PowerCLIVersion : The term 'Get-PowerCLIVersion' is not recognized as the name of a cmdlet,

function, script file, or operable program. Check the spelling of the name, or if a path was

included, verify that the path is correct and try again.

At C:\Program Files (x86)\VMware\Infrastructure\vSphere

PowerCLI\Scripts\Initialize-PowerCLIEnvironment.ps1:38 char:12

+ $version = Get-PowerCLIVersion

+            ~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : ObjectNotFound: (Get-PowerCLIVersion:String) [], CommandNotFoundExce

   ption

    + FullyQualifiedErrorId : CommandNotFoundException

          Welcome to VMware vSphere PowerCLI!

Log in to a vCenter Server or ESX host:              Connect-VIServer

To find out what commands are available, type:       Get-VICommand

To show searchable help for all PowerCLI commands:   Get-PowerCLIHelp

Once you've connected, display all virtual machines: Get-VM

If you need more help, visit the PowerCLI community: Get-PowerCLICommunity

Copyright (C) VMware, Inc. All rights reserved.

but  none of the powercli commands run

and get-module show no vmware modules

Is this a new feature? needing to run as admin, previous version i didnt need to run elevated

Anyone else have the same issue?

[jlbarahona]

Hi,

I have exactly the same problem. Do someone has a solution for it?

Cheers

[vScripter]

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.)

[DamienS20111014]

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.

[LucD]

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 ?

[DamienS20111014]

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.

[LucD]

My opinion is that there should be an option, like For this user or For all users during the installation

[Softsource]

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

[Anonymous]

Hi,

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")

M.

[tehkuhnz]

Had this same issue and your power shell solution fixed the issue - many thanks.

[v12n]

Works like a charm. Thanks

[Hossy923]

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.

[jguajardo]

The script fixed my issue too..

Thanks,.

[MichaelRyom]

Thx Mike

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.

[LucD]

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 ?

[bugblatterbeast]

I just ran into this issue and just for the record I installed R3 with a non-elavated account, which does have local admin access to the Windows 7 machine it was installed on.....but this maybe wasnt enough! 

The powershell script from an admin powershell did fix my issue so thanks for that!

Danny

[alhmami]

Just run it as administrator it will work

[rogersm]

Running the script as admin is not the solution.  As mentioned previously, adjusting the PsModulePath environmental variable is a valid work around, but the source of the problem lies elsewhere. 

The command get-PowerCliVersion comes from the snapin "VMware.VimAutomation.Core".  The file 'C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\Scripts\Initialize-PowerCLIEnvironment.ps1' contains two functions - LoadModules and LoadSnapins.  These functions both reference the file 'C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\vim.psc1'.  vim.psc1 contains the list of PSSnapIns and PSModules that need to be loaded in order for PowerCLI to function.  If you look, you will find VMware.VimAutomation.Core in the list of PSModules.  this is a problem, as it is still a PSSnapIn.

The solution - perform the following on the file 'C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\vim.psc1'

1. Delete the line '<PSModule Name="VMware.VimAutomation.Core" /> ' from the PSModules section
2. Add the line '<PSSnapIn Name="VMware.VimAutomation.Core" />' to the PSSnapIns section
3. Launch PowerCLI

*NOTE* PowerCLI will function, but you will still receive an error when launching it.  If you wish to remove the error you will have to move the LoadSnapins function and call above the LoadModules call in the file 'C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI\Scripts\Initialize-PowerCLIEnvironment.ps1' (move lines 56-78 above line 34). 

This is a bug that needs to be fixed by VMware.  I assume they are working on converting PowerCLI from utilizing PSSnapins to using Modules and someone jumped the gun in the initialization script. 

[LucD]

You can in fact automate that fix, see Fixing a (minor) PowerCLI 6 R1 issue

But then again, why would one still use PowerCLI 6R1 ?

[ugryrd]

Thanks mike it worked.