connect-viserver not working and get prompted for credentials

[RNAR]

On one machine, I use the connect-viserver ServerName command and that is enough. It connects. On another machine, I get prompted for credentials and then it fails with "The underlying connection was closed: An unexpected error occurred on a receive."

Does anyone have any idea what I can do to make this work?

machines I'm connecting from that work: Windows Server 2008 R2, Server 2016. That don't work: Windows Server 2012 R2.

PowerCLI versions: 5.1 and 5.8 - I've tried both versions on one of the machines that work and it continues to work and both on the machine that doesn't work and there's no difference.

vCenter Server 5.5 U3

[nachogonzalez]

If you open a web browser and try to log in to that vCenter/ESXi host, are you able to log in?
Is firewall enabled?

Do you know if in the Windows server 2012 the Ignore Certificate SSL is enabled?
https://www.ivobeerens.nl/2018/07/18/quick-tip-powercli-invalid-server-certificate-error/

[scott28tt]

Moderator: Thread moved to the PowerCLI area.

[RNAR]

If I open a web browser and try to connect to the vCenter Server, it tries, but then can't do it because I don't have Flash installed. The vCenter Server is installed on a Windows machine and the Windows firewall is not on. So, if that's what you mean, no.

I just installed PowerCLI and didn't do anything else. So, -InvalidCertificateAction Ignore would not be enabled.

PowerCLI D:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> get-powercliconfiguration

Scope    ProxyPolicy     DefaultVIServerMode InvalidCertificateAction  DisplayDeprecationWarnings WebOperationTimeout Seconds

-----    -----------     ------------------- ------------------------  -------------------------- -------------------

Session  UseSystemProxy  Multiple            Unset                     True                       300

User

AllUsers

Using the set to ignore command makes no difference.

[LucD]

Is there a CredentialStoreItem on the machine that is working?

Do a Get-VICredentialStoreItem.

When you do a Connect-VIServer, did you already add the Verbose switch?

[RNAR]

No, I've never seen Get-VICredentialStoreItem command before. That returns nothing.

I had not tried connect-viserver ServerName -verbose before.... Doing that, first I get prompted for credentials, then

PowerCLI D:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> connect-viserver usocwok001 -verbose

VERBOSE: Attempting to connect using SSPI

VERBOSE: The underlying connection was closed: An unexpected error occurred on a receive.

VERBOSE: Connect using SSPI was unsuccessful

VERBOSE: The underlying connection was closed: An unexpected error occurred on a receive.

connect-viserver : 9/24/2020 2:27:10 PM Connect-VIServer                The underlying connection was closed: An unexpec

ted error

occurred on a receive.

At line:1 char:1

+ connect-viserver Server -verbose

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

    + CategoryInfo          : NotSpecified: (:) [Connect-VIServer], ViError

    + FullyQualifiedErrorId : Client20_ConnectivityServiceImpl_Reconnect_WebException,VMware.VimAutomation.ViCore.Cmdl

   ets.Commands.ConnectVIServer

[LucD]

From which PowerShell version are you running the Connect-VIServer?

Newer PS version don't support TLS 1.0 anymore.

You could try to run the following before the Connect-VIServer

[System.Net.ServicePointManager]::SecurityProtocol =[System.Net.SecurityProtocolType]'Ssl3,Tls,Tls11,Tls12'

[RNAR]

I thought of that, but it works on one machine and not another and they are both running Powershell 5.1.

That ServicePointManager command does not appear to have made any difference.

[LucD]

Then I'm out of ideas I'm afraid.

I would suggest opening an SR, but since 5.5 is out of support, I'm afraid that will not be possible.

[RNAR]

I upgraded vCenter Server 5.5 Update 3b to Update 3k, which now supports TLS 1.2 (according to some VMware article) and now it works. So, I suspect that something on the machine I was trying to connect from was configured to only allow TLS 1.2. I thought I checked that, but maybe not.