VMware VDI (Horizon View) Troubleshooting - Part V

 

 As I promised, I want to deep dive into some tricks of VMware Horizon View in every section of the VMware VDI deployment. So in continuous of the following troubleshooting series, I will mention some of the important considerations:

VMware VDI (Horizon View) Troubleshooting - Part I

VMware VDI (Horizon View) Troubleshooting - Part II

 VMware VDI (Horizon View) Troubleshooting - Part III

VMware VDI (Horizon View) Troubleshooting - Part IV

1. Agent Restriction: While the Horizon Agent has been connected to the Connection Server through the Virtual Desktop/App if you monitor the status of the network connection (via simple commands like netstat) you can watch the only established session is on the JMS-SSL (TCP 4002). However, if you want to limit the permitted port via an External/Internal Firewall to the mentioned port, whenever the corresponding VM of that v-Desktop is in the recovery process, you will certainly encounter the provisioning issue. The error shows the Agent is "Unreachable" while before the desktop re-provisioning operation, you could reach this one through the Horizon. In this state (recovering the VM) we should be aware it needs running the JMS (TCP 4001) in the background too. Then by changing the firewall policies and permitting both 4001/4002 TCP ports, the Agent status is “Available” once more again.

By the way, if any vDesktop stuck on "Unknown" state, you can remove the object from the Directory Services ADSIEdit console connected to the (I explained how to connect in the Part 1).

2. New Certificate Generation: If you generate or provide a new valid certificate for the Horizon environment and for example, want to create a PFX certificate file, you should select the “Mark this key as exportable” checkbox in the *.pfx generation wizard to make the private key exportable. If you don’t choose this option or even use another certificate extension (like *.cer) which is without the Private Key cause the following error, so the Connection Server cannot handle any secured communication.

At last, never forget to set the "vdm" value as the "Friendly Name" of the chosen certificate.

 

3. UAG DNS Setup: At the beginning of UAG (Unified Access Gateway) deployment, while you setup the TCP/IP setting through the OVF wizard it's possible to not accept the NIC setup. So, you can run the following CLI to setup the networking:

 

/opt/vmware/share/vami/vami_config_net

 In 2103/2106 versions, although you configured the DNS servers it will not show them truly in CLI or GUI (still is the same as local caching value: 127.0.0.53). If you are in the initial steps of deployment and the Name Resolution system is not ready yet, you can edit the /etc/hosts file temporarily with an editor like vi and set the FQDN of External Load-Balancer, all UAG Appliances, and Connection/Replica Servers until the DNS permanent configuration has been done because of modifying the "hosts" file is not a stable solution.

4. End-to-End communication: Regardless of connection between the Horizon Servers and Virtual Desktops, you should consider the required ports for the secure channel between the Horizon Clients or Web Access to the provisioned VMs, especially through the UAG. When you connect to your Desktop via the Blast Extreme protocol, regardless of port 443 your client requires to establish a session on TCP 8443 to the UAG appliance and also UDP/TCP 22443 for accessing to the Virtual Desktop or RDS host.

In the next chapter, I will describe and explain more deeply the UAG configuration, especially about how to import the Certification Chain.