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.

Upgrading VMware ESXi 5.5 to ESXi 6

Download and insert the VMware ESXi 6.0 media into the ESXi 5.5 host and boot from the disc drive, you will be presented with the following screen highlight ESXi-6.0.0-2492585-standard Installer and hit Enter.

Hit Enter at the welcome screen.

Hit F11 on the EULA screen to accept the terms.

As ESXi 5.5 was already installed on this host, the setup detected a previous installation. Highlight it and hit Enter.

In this instance, select Upgrade and hit Enter.

Review the confirmation screen and hit F11.

The upgrade process took about 3 minutes installing onto SSD disk.

The upgrade successfully completed for me hit Enter to reboot the host.

VMware vCenter 5.5 (b) "A general system error occurred: 'alias' value should not be empty" when you attempt to login via Administrator@vSphere.local account

When you try to login to vCenter 5.5 (release b.b) you receive the following error "A general system error occurred: 'alias' value should not be empty". this was with the Administrator@vSphere.local account, the master account for vSphere.

I did a bit of Googling about and came across the following link from VMware, unfortunately this did not solve my problems as I had actually not integrated vCenter with Active Directory yet. I was still using Administrator@vSphere.local for day to day admin tasks.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2074760

The next step was to try the vSphere Web Client, I was faced with the following error from it "Client is not authenticated to VMware Invetory Service - https://labvc.company.com:10443 Unable to create the managed object for - urn:vmomi:AuthorizationManager.AuthorizationManager:"

My next thought was to try and integrate vCenter to Active Directory to give a kind of workaround, I clicked on the Single Sign On\Users and Groups pane of the Web Client and it threw the " 'alias' value should not be empty" error again.

As it was clearly related SSO and the Inventory Service, I did some research on the Log Files for these components, do a search on your vCenter Server for the "ssoAdminServer" log file.

Yet again another unhelpful error in the logfile, it then got me thinking that it could be a DNS issue as the vSphere Web Client stated it could not authenticated to the Inventory Service via it's FQDN.

It tried an "nslookup" on the vCenter Server to see the status of DNS. It could not resolve the primary DNS server.

I resolved the DNS server issue and tested so that name resolution was working correctly. Following this I then rebooted the vCenter Server to refresh all of the services.

Once it rebooted and all of the vCenter services had time to start I tried again and it resolved the issue. It also seemed like a good time to integrate my vCenter with Active Directory.

Citrix XenDesktop 7.x Add Connection and Resources (vSphere 5.5) "Cannot connect to the vCenter server due to a certificate error. Make sure that appropriate certificates are installed on the vCenter server"

I was integrating Citrix XenDesktop 7.5 with my lab vSphere 5.5, and at the point I was configuring my first XenDesktop site XenDesktop throws the error "Cannot connect to the vCenter server due to a certificate error. Make sure that appropriate certificates are installed on the vCenter server" when I point it to my vCenter Server 5.5. This halted the configuration of XenDesktop 7.5, whenever I had installed XenDesktop 7.5 before in my lab I had used Citrix XenServer.

I browsed to C:\ProgramData\VMware\VMware VirtualCenter\SSL and copied the cacert.pem file to the NETLOGON file share on one of my Domain Controllers.

I then imported the cacert.pem file into the Trusted Root Certification Authorities\Certificates store on my XenDesktop 7.5 Delivery Controller. You must use the All Files drop down when you point to the cacert.pem file from the Certificate Import Wizard.

When the vCenter certificate appears in the  Trusted Root Certification Authorities\Certificates store, you can retry the XenDesktop site creation wizard. I have found you have to reload the Citrix Studio in order for it to work.

You should probably be looking to use trusted certificates in a production environment, but as this is only a lab self-signed will do for now.

VMware ESXi 5.5 Host Purple Screen with "Exception 14 in World 63445:vmm1:VMNAME IP"

The same ESXi 5.5 host has purple'd screen today returning the same error for two different Virtual Machines.

According to the following VMware link;

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2059053 this is a known issue related to using the E1000/E1000E Virtual Network adapter. Although in a production deployment I alwasy use VMNET3 (VMware Tools req'd) for Windows Server 2012 R2 Servers as this was only a lab server I never paid much attention to the network adapter when I created my first template.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1001805

VMXNET 3: The VMXNET 3 adapter is the next generation of a paravirtualized NIC designed for performance, and is not related to VMXNET or VMXNET 2. It offers all the features available in VMXNET 2, and adds several new features like multiqueue support (also known as Receive Side Scaling in Windows), IPv6 offloads, and MSI/MSI-X interrupt delivery. For information about the performance of VMXNET 3, see Performance Evaluation of VMXNET3 Virtual Network Device. Because operating system vendors do not provide built-in drivers for this card, you must install VMware Tools to have a driver for the VMXNET 3 network adapter available.

VMXNET 3 is supported only for virtual machines version 7 and later, with a limited set of guest operating systems:

·         32- and 64-bit versions of Microsoft Windows 7, 8, XP, 2003, 2003 R2, 2008, 2008 R2, Server 2012 and Server 2012 R2

·         32- and 64-bit versions of Red Hat Enterprise Linux 5.0 and later

·         32- and 64-bit versions of SUSE Linux Enterprise Server 10 and later

·         32- and 64-bit versions of Asianux 3 and later

·         32- and 64-bit versions of Debian 4

·         32- and 64-bit versions of Debian 5

·         32- and 64-bit versions of Debian 6

·         32- and 64-bit versions of Ubuntu 7.04 and later

·         32- and 64-bit versions of Sun Solaris 10 and later

·         32- and 64-bit versions of Oracle Linux 4.9 and later

I change all of the Windows Server 2012 R2 vmnic's to use VMET3, and so far so good there has been no purple screens. Obviously in a production environment you would maybe go to the effort of patching the server.

The other thing that was clear to check was the build of ESXi 5.5 that was installed on the server, the physical hardware is a HP ProLiant. Therefore it should have a HP opptomized build of ESXi, with all the integrated driver for that hardware. http://www8.hp.com/us/en/products/servers/solutions.html?compURI=1499005#tab=TAB4 it turns out in this case it was a base ESXi 5.5 install, therefore I also reinstalled ESXi to ensure the HP build supplied all the correct drivers.

VMware vSphere 5.5: Installing vSphere Web Client "Error 29102. Unable to Contact Lookup Service. Check vm_ssoreg.log in the System Temporary folder for more details."

I was reinstalling the VMware vSphere Web Client in my lab and the installation was halted "Error 29102. Unable to Contact Lookup Service. Check vm_ssoreg.log in the System Temporary folder for more details.", the setup would then rollback any changes made.

 

In my lab the issue was because I did not have a Reverse Lookup Zone created from the subnet. I logged into a Domain Controller, created it with the zone and manually created the PTR Record. Once I tried to rerun the installation of the Web Client it completed successfully.

Ping "General Failure" Intermittent Issue (vSphere 5.0 VM, Port Group, EST) Multi-Homed RRAS on Windows Server 2012 R2

There are intermittent issues with your Windows Server 2012 R2 VM, with Routing and Remote Access installed. The VM is running on vSphere v5.0 and it is connected to a Port Group, connected to a dedicated vSwitch. Extensible Switch Tagging (EST) is in place therefore the physical switch stack is doing all the VLAN tagging.

The network interface are configured to support a multi-homed RRAS server to provide L2TP/IPsec VPN to clients, one interface is external which is configured behind a Cisco ASA firewall. Due to L2TP/IPsec being utilized NAT-T is configured to forward external traffic to this interface. The internal interface is connected to the Production subnet.

When the server is booted, you can ping resources both internal and external without issue, if you use the ping 8.8.8.8 -t command to send continuous ICMP packets, it begins to fail with General Failure.

 

It turned out to be, and you guest it an issue with Microsoft Routing and Remote Access. The fix was to disable the Inbound and Outbound Filters, although this may seem to be a security risk in this instance the RRAS server is behind a Cisco ASA Firewall therefore the software filters on RRAS are not required.

To disable the filters expand IPv4 and General, then right click on each of the interfaces and select Properties.

Click Inbound Filters...

 

Click Receive all packets except those that meet the crtieria below click OK to commit the changes.

 

Do the same for the Outbound Filters but ensure Transmit all packets except those that meet the criteria below, again click OK.

 

Now if you attempt to try the ping the resources both externally and internally you will probably find it now works successfully. Yet another fix that would encourage you to deploy a proper hardware VPN concentrator such as a Cisco ASA, Juniper, NetScaler etc.

 

 

 

 

Using VMware Workstation 10 to Run Hyper-V 2012 R2 Nested Instances

In order for this to work correctly there is a small hack that must be put in place. For every Virtual Machine created under VMware Workstation there is a (.vmx) file which contains configuration settings for the guest machine. This files is stored along with the virtual hard disk files by default.

You can open the (.vmx) file with Notepad and edit it freely provided the Virtual Machine is powered off. The following lines must be added to the (.vmx) file;

 

hypervisor.cpuid.v0 = "FALSE"

mce.enable = "True"

 

Save the changes to the (.vmx) file.

You must also edit the Processors setting on the VM, set the Preferred Mode to Automatic and ensure Virtualize Intel VT-x/EPT or AMD-V/RVI and Virtualize CPU performance counters are ticked.

 

 

Now start the machine and you will now be able to run "nested" Virtual Machines inside Hyper-V. The hypervisor.cpuid.v0 = "FALSE" line tricks the guest operating system into thinking it’s not running as a virtual instance.