Tuesday 28 April 2015

VMware vSphere 6.0 Console "Unable to connect to the MKS: Could not connect to pipe \\.\pipe\vmware-authdpipe within retry period" & "Unable to connect to the MKS: Internal error"

When you try to console to a server on your vSphere 6 platform using the traditional client, it throws the following error "Unable to connect to the MKS: Could not connect to pipe \\.\pipe\vmware-authdpipe within retry period" and you cannot make a console session. 


The first place I checked for details was the VMware Client log files, which can be found at %temp% and then the vmware-%username% folder on the computer you are getting the pipe error on. I opened the log file with the latest date stamp and noticed the following line immediately "HostDeviceInfo: Failed to enumerate host parallel ports via the registry. Could not open device map parallel port registry key."


My first thought was to remove any devices that are not required by the VM, so I down powered the VM and edited the settings. I happened to be getting the error on my vCenter Server therefore I had to open a new vSphere Client session to the host running the VM. My first step was to remove the CD/DVD drive, which already had an ISO attached to it.


From there I then started the VM again, and tried to open a Console session and the error "Unable to connect to the MKS: Could not connect to pipe \\.\pipe\vmware-authdpipe within retry period" had disappeared.


I have another issue that was similar, but the error message was "Unable to connect to the MKS: Internal error" the problem here was DNS related, I was trying to use the vSphere console across a Cisco VPN connection, which in theory should be fine. But due to a number of changes on the client site, the VPN client IP pool was still assigning clients the old DNS server details. Once I hard coded the vCenter and ESXi hosts details in to the admin workstations hosts file, it all started working. 

That being said, one machine still kept giving me issues. And the fix for that one was to down power it and remove it from the vCenter Inventory, then re-add it using the VMX file. It then worked correctly.