addPSSnapIn action failed with View snapin or PowerCli snapin...

[bzjeurd]

Hello,

I would like to use the vCO Powershell plugin to manage vCenter and View Pools and desktops.

But when I launch the action called addPSSnapIn in order to use View cmdlets the process failed with this error:

PowerShellInvocationError: Errors found while executing script Add-PSSnapin : No snap-ins have been registered for Windows PowerShell version 2.

My Powershell host is a W2K8R2 server.

If I start a powershell 2 console on the server, and do the adsnapin manually, I get the same message.

If I start a powershell 1 console (using a different powershell executable, in fact the same used by VMware VIew Powershel shortcut), loading the View snapin is successful.

The problem seems to be related to the powershell version. So how can I tell/force the vCO Powershell plugin to use the powershell 1.0 executable ?

Or is there way to load the View PS plugin in powershell 2.0 (though the PowershellServiceCmdlets.dll or any other solution) ?

Thank you in advance for your help.

Bz.

[bzjeurd]

I would like to rectify some informations provided above.

After some extended tests, It seems to be not a question of powershell version, but related to wich the powershell executable is used.

The VMware View Powershell shortcut use this one:

C:\Windows\system32\windowspowershell\v1.0\powershell.exe

And all works fine.

If I use the 32bit Powershell shortcut:

%SystemRoot%\syswow64\WindowsPowerShell\v1.0\powershell.exe

Add snapin failed with this error:

PowerShellInvocationError: Errors found while executing script Add-PSSnapin : No snap-ins have been registered for Windows PowerShell version 2.

So my conclusion is: the vCO Powershell session uses the 32bits environment instead of the 64bits.

Could it be related to my OpenSSH server that is win32 application ?

[igaydajiev]

Yes I believe it is because of 32 bit OpenSSH.

In 64 bit environment you have both 32 and 64 bit powershell. When you start the powershell from 32 bit windows application it will use the 32 bit version of powershell. You can actually check which version (32 or 64 bit) is picked with the following script

# Is this a 64 bit process
function Test-Win64() {
    return [IntPtr]::size -eq 8
}

# Is this a 32 bit process
function Test-Win32() {
    return [IntPtr]::size -eq 4
}

Have you considered to use the WinRM protocol?  I believe it will pick up the 64 bit powershell..

[bzjeurd]

Hello igaydajiev,

Thank you for your help.

I confirme the OpenSSH session is running under Win32 environment.

I chose the OpenSSH solution because I was unable to add an Host with the WinRM connection.

I got this error when launching the Add a Powershell host workflow:

Can't validate host:  Invocation of script $host threw exception (Dynamic Script Module name : addPowerShellHost#15)

Using Http or Https connexion flavour doesn't change the result.

When using Https, the host certificate is correctly imported into the vCO certificate store. But the validation failed.

Someone could help me to add host to this plugin?

Thanks a lot in advance.

Bz

[igaydajiev]

I would first configure the HTTP. And after that continue with the HTTPS.

Here is a step by step procedure how to configure it using HTTP.

http://blogs.vmware.com/orchestrator/2011/12/vco-powershell-plug-in.html

[bzjeurd]

Hello igaydajiev,

Finally I won through, partially....

In fact I used a Domain account in order to open the WinRM session instead of a local one.

With a local account WinRM in HTTP or HTTPS work fine, and I was able to add finally my Powershel Host.

If I'm now able to add View snapin in Workflows, I can't launch View cmdlets because the local account used to open the session have no rights to manage View object as there are no possibilities to add local account in the Global Administrators View.

Is it a way in powershell to execute cmdlet with a diffrerent account from the one that openned the session ?

Or another solution.

Thanks a lot for your help

Bz