Attempting to use VMware vSphere PowerCLI’s Connect-VIServer to a vCenter instance fails with: “The underlying connection was closed: An unexpected error occurred on a send.”

Problem

You have VMware vSphere PowerCLI version 5.1.0.4977 installed:

You attempt to connect to a vSphere vCenter 6.7:

… using the Connect-VIServer cmdlet but it immediately fails with:

PowerCLI C:Program Files (x86)VMwareInfrastructurevSphere PowerCLI> Connect-VIServer vCenter.contoso.local

Connect-VIServer : 2/22/2019 11:41:37 AM Connect-VIServer The underlying connection was closed: An unexpected error

occurred on a send.

At line:1 char:1

+ Connect-VIServer vCenter.contoso.local

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

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

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

ets.Commands.ConnectVIServer

PowerCLI C:Program Files (x86)VMwareInfrastructurevSphere PowerCLI>

Solution

The reason why this error is thrown is because vCenter 6.7 only has TLS 1.2 enabled while TLS 1.0 and 1.1 is disabled by default so the older PowerCLI version installed, which attempts to connect via a one of the lower TLS versions will fail. The proper method of resolving this issue is to upgrade the old PowerCLI version to the latest one with the cmdlet Install-Module -Name VMware.PowerCLI as shown in the following PowerShell Gallery:

https://www.powershellgallery.com/packages/VMware.PowerCLI/11.1.0.11289667

The alternate solution is to force the .NET to use the appropriate TLS version for connecting to the vCenter:

Enabling the TLSv1.1 and TLSv1.2 protocols for PowerCLI (2137109)
https://kb.vmware.com/s/article/2137109

· For 32-bit processes, change the following registry key value to 1.

Key: HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFramework[.NET_version]
Value: SchUseStrongCrypto (DWORD)

· For 64-bit processes, in addition to the above registry key, change the following registry key value to 1.

Key: HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoft.NETFramework[.NET_version]
Value: SchUseStrongCrypto (DWORD)

This workaround was handy for the project where the environment did not allow me to download or install any binaries on the endpoint I was using but I did find that the workaround with vSphere PowerCLI 5.1.0.4977 would only work with the 32-Bit version:

Adding the two registry keys in did not allow the 64-Bit version to connect.

Additional information – Invalid server certificate

Note that if you attempt to use the IP address of the vCenter to connect then you will receive the following error indicating that the certificate being presented is invalid:

PS C:userstlukDownloadsvCheck-vSphere-mastervCheck-vSphere-master> Connect-VIServer 10.10.10.24

Connect-VIServer : 2/22/2019 3:47:15 PM Connect-VIServer Error: Invalid server certificate. Use

Set-PowerCLIConfiguration to set the value for the InvalidCertificateAction option to Prompt if you’d like to connect

once or to add a permanent exception for this server.

Additional Information: Could not establish trust relationship for the SSL/TLS secure channel with authority

‘10.10.10.24’.

At line:1 char:1

+ Connect-VIServer 10.10.10.24

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

+ CategoryInfo : SecurityError: (:) [Connect-VIServer], ViSecurityNegotiationException

+ FullyQualifiedErrorId : Client20_ConnectivityServiceImpl_Reconnect_CertificateError,VMware.VimAutomation.ViCore.

Cmdlets.Commands.ConnectVIServer

It is best practice to have a trusted certificate installed and to connect with the FQDN of the vCenter but if you do not meet either of the criteria then you can configure PowerCLI to ignore the certificate error with the following cmdlet:

Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -Confirm:$false

Scope ProxyPolicy DefaultVIServerMode InvalidCertificateAction DisplayDeprecationWarnings WebOperationTimeout

Seconds

—– ———– ——————- ———————— ————————– ——————-

Session UseSystemProxy Multiple Ignore True 300

User Ignore

AllUsers

Alternatively, if you want to install the self-signed certificate on the device that you are initiating the connection from so you can connect via the FQDN, you can use the same instructions I provided in the solution of one of my previous blog posts to download and install the certificate into the trusted store:

Attempting to upload a file onto a datastore with vSphere Client 6.5 fails with: “The operation failed.”
https://blog.terenceluk.com/2018/11/attempting-to-upload-file-onto.html