Vmware Horizon View Protocol Failure

17-08-2021 admin

Vmware Horizon View Protocol Failure Symptoms
Vmware Horizon View Protocol Failure Rate
Vmware Horizon View Protocol Failure

Vmware horizon view protocol failure symptoms

Attempting to connect to VMware Horizon View virtual desktop through the security server throws the error: “Unable to connect to desktop: There is no available gateway for the display protocol. Try again, or contact your administrator if this problem persists.”. Restart the VMware Horizon View Connection Server service. VMware Horizon View and HTML access (Blast protocol) VMware vCenter Server Appliance (VCSA) 5.5 deployment tips and tricks. Everything is green but the destination Server red – Down! We opened Firewall completly to be sure, ther is no failure config. But it stays still red.

Make sure that the View Agent is installed and that the firewall ports are open (4172, 32111, 443). Reboot machine or check service 'View Agent Connect' through RDP (User Portal) if possible. Unable to Connect to Desktop. The View Agent installer will normally set up the firewall rule to allow this port to be open. If you manually configure the firewall rules to block this port or choose not to enable Remote Desktop Access, View Administrator will show the desktop's status as Protocol Failure and users will not be able to connect to the desktop. VMware Blog Post Deep Dive into VMware Horizon Blast Extreme Adaptive Transport – Blast Extreme Adaptive Transport is enabled by default in VMware Horizon View 7.1 and Horizon Client 4.4. If the clients are connecting from outside the demilitarized zone (DMZ), you would also need to have VMware Unified Access Gateway (not Security Server) to.

Recently I went through the process of upgrading a VMware Horizon 6.1.1 VDI environment to 7.3.1 which was just released, and apart from some small teething issues with licensing during the upgrade due to a slight oversight in the VMware documentation everything else appeared to go smoothly.

As this environment uses View Composer Linked-Clones for non-persistent desktop pools part of the upgrade involves installing the new Horizon 7.3.1 agent onto the gold master VM template for each desktop pool then performing a recompose of the VMs in those pools.This is where I ran into an issue.

After upgrading the agent and performing a recompose operation on the VMs within each desktop pool they then displayed a Protocol failure” status within Horizon Administrator although I could still login to them as normal through the Horizon Client.

On doing a bit of research it appears this error can be generated if the firewall ports for a particular display protocol aren’t opened between the Horizon guest VM agent and Horizon Connection servers – in the case of Horizon this can be the Remote Desktop Protocol or PCoIP (PC over Internet Protocol) depending on how you have configured your desktops. In my case PCoIP was being used and all required ports between the guest VM agent and Horizon Connection servers were opened.

Verifying that everything within the environment was how it should be I then turned my attention back to the Horizon agent on the gold master VM template. Thinking that perhaps the upgrade from 6.1.1 to 7.3.1 had affected something I decided to completely uninstall the agent, reboot and install 7.3.1 again from fresh then recompose the VMs in desktop pools from the new snapshot.

This time after the VMs had passed their customizing stage and I was then presented with the “Available” status as normal. Success!

So with that here are some takeaways from this after doing some extensive reading.

If you have VMs displaying a “Protocol failure” status within Horizon Administrator do one or more of the following;

Verify the required TCP ports are opened on the guest VMs with the Horizon Agent installed – a list of these can be found here
Verify the Horizon Agent services are running on the guest VMs – a list of these can be found here
Check for a “ghosted” network adapter on the gold master template VM and remove it – more info can be found here
Uninstall the previous version of the Horizon Agent first if upgrading to a newer version.

Update: There is a new way to pull the event information without having to enter the sql password please see this post about it.

So two weeks ago I had a nice little post about talking to Horizon View using PowerCLI. I also promised to be digging a bit more into PowerCLI by grabbing the script posted on the VMware blog and editing it a little to my taste. It’s a very useful script they have on there but still I prefer to know what might have caused the issues. I decided I needed to know who the last user was that used the desktop and the last entry into the eventlog and the time of that log. So actually most code used talks to the eventlog database, something already available pre PowerCLI 6.5 but what I hardly ever used.

The basics for connecting I won’t post but we do need an extra connection and that is to the event database:

As with the Horizon View connection it’s best to put this into a variable so it can be used later on. The $hvedbpassword should be the password for the user that View uses to connect to the database server in plain text! Earlier in the script I read the password from hashed contents in a text file.The request has been dropped to be able to pass encrypted credentials and/or creta a credentialstore for this.

Next up is grabbing the events for a certain Desktop

This could use some rework since I would prefer the time period to be a variable based on the current date but if the event is older then a day it will be hard to find anything on it anyway.

This grabs the latest event, the time it happened and the user it happened to. This can be anything including a logoff. It might be able to help you why a lot of desktops are ending up in a rotten state.