Impersonate change/issue in PowerCLI 4.1.1

[vrm]

After upgrade PowerCLI to version 4.1.1credentials aren't impersonate when connecting a vCenter 2.5.

"[System.Management.ImpersonationLevel]::Impersonate" was working correct before the PowerCLI to version 4.1.1. After the upgrade I'll be asked for credentials when connecting a vCenter 2.5 server.

When I connect to an vCenter 4.1 server impersonate credentials work correct.

I'm experience the same issue with scheduled jobs when using the following code:

$USER= $env:username

$APPPATH = "C:\Documents and Settings\" + $USER + "\Application Data"

SET THE APPDATA ENVIRONMENT WHEN NEEDED

if ($env:appdata -eq $null -or $env:appdata -eq 0)

{

     $env:appdata = $APPPATH

}

Is this a known issue or is there something changed in the use of impersonate credentials?

Vincent

[harkamal]

PowerCLI 4.1 works good with vSphere 4.1 environments, as to my experience is concerned.

It is designed to phase out all previous versions, same as how PowerCLI replaced VI Toolkit.

If I see the release notes vCenter 2.5 up6 is supported. And I think not many folks use update 6.

See the article

http://www.vmware.com/support/developer/PowerCLI/PowerCLI41/powercli41-201007-releasenotes.html

And as far as Impersonation is concerned, I think it is powershell /os related ?

[vrm]

Before the upgrade to PowerCLI 4.1.1 impersonation works with vCenter 2.5u6 and vCenter 4.1. So there must something changed in PowerCLI 4.1.1..

[vrm]

I uninstall VMware-PowerCLI-4.1.1-332441.exe and install VMware-PowerCLI-4.1.0-264274.exe.

Now the impersonation with vCenter 2.5 update6 is working correct. After this I've upgrade PowerCLI again to VMware-PowerCLI-4.1.1-332441. Impersonation with vCenter 2.5 update6 doesn't work correct and displays the logon window. In the release notes I can't find anything about this?

[andrey_anastaso]

Hi Guys,

Investigation confirmed that this is a PowerCLI bug - Connect-VIServer does not connect through SSPI to VC 2.5 u6. We plan to fix the problem in a future release.

@vrm, thank you for taking the time to research and report the problem! A possible workaround (if acceptable from security perspective) is the credential store - use New-VICredentialStoreItem to add the user/pass for the VC and Connect-VIServer will use these instead of asking for credentials.