VMware Horizon Community
NickTT
Enthusiast
Enthusiast

Horizon Client 8.6 Drops Connection Through Gateway

We have been testing the 8.6 client running through the Horizon Unified Access Gateway v21.11.1 to 2111 server. There is no load balancing setup. Just using DNS Traffic management steering policies to handle failover if a gateway goes down. I have found with the 8.6 Client, the user session will disconnect exactly at 3 hour intervals. I have tested it with 5 other users on various company and user own windows machines. It is consistent... 8.5 version of the client sessions stay active all day.... if on the 8.6 client the connection will drop and you will have to re-authenticate. This will happen regardless if the user is idle, actively working or in a Teams Meeting. The connection will just drop out. Is there something different with how 8.6 client is handing the network session vs 8.5 client?

Internally, everything works fine regardless of the client you are using.

 

Labels (3)
Reply
0 Kudos
7 Replies
SurajRoy
Enthusiast
Enthusiast

I need below info to understand the step up:

  1. How many UAGs are there ( 1 or 2)?
  2. Are we using DNS Round Robin to Load balance between UAGs?

 

 

 

Reply
0 Kudos
NickTT
Enthusiast
Enthusiast

We have 3 UAG all same versions.

  • <Published Horizon URL for Clients>
    • 2 in Production
      • These operate with DNS Round Robin and a basic availability check to make sure the host is up. I use the same icon file check in the Horizon LB setup guide to check for system availability so I can take a unit offline for maintenance if needed. Only one record is ever returned in the DNS response.
    • 1 in DR
      • Will only get traffic if both production units are down.

Oracle calls this Traffic Management Steering Policies and is a DNS feature. Think of it like load balancing light.

 
"Traffic Management Steering Policies enable you to configure policies to serve intelligent responses to DNS queries, meaning different answers (endpoints) may be served for the query depending on the policy logic."

 

Network traffic is 100% healthy. Oracle tool checks availability every 30 seconds and has great reporting to show any possible traffic issues. We also monitor with ThousandEyes eternally for redundancy monitoring and traffic is clean. Finally, I can confirm traffic flow through gateway monitoring and see no sessions are going through DR site.

Something is different with the 8.6 client and how it is handling the network sessions. I was reading the release notes for it and see they introduced custom timeout warning messages. I am wondering if that is hardcoded or not tracking correctly and forcing the connection closed after 3 hours. The drop is EXACTLY 3 hours though. I can set a stopwatch to it. 🤓 

Reply
0 Kudos
SurajRoy
Enthusiast
Enthusiast

Is the is issue reproducible if the traffic goes directly to one of the issue.

NOTE:

Client send "Set Last User Activity" at specific time set and expect that it goes to the same UAG or Connection server who initially received the request when user tried to login.

If LB/VIP or DNS RR failed to send the request to same UAG/Connection server, the session will expired and end user need to login.

Refer to https://kb.vmware.com/s/article/56636 

Action Plan:

Map UAG1 > Connection server 1

Map UAG2 > Connection server 2 and then test.

The above is recommended deployment option.

 

Also if the issue is not reproducible if we use specific UAG URL or IP address and we may need to look at DNS RR or View Client log.

 

Reply
0 Kudos
NickTT
Enthusiast
Enthusiast

Yep... I have DNS records that I use for testing that go to each gateway directly... with 8.6 client the connection will still drop. 8.5 client it stays up all day long.

Reply
0 Kudos
SurajRoy
Enthusiast
Enthusiast

Could you please share the below logs:

  • Client Log
  • UAG Log bundle ( Debug enable)
  • Connection server
  • Time Stamp when issue happen.

 

Reply
0 Kudos
NickTT
Enthusiast
Enthusiast

I will have to turn on debugging and do some more testing to get the actual logs from the client but while looking through my Enterprise Log aggregation tool, I spotted this message from someone else that has the 8.6 Client.

HORIZON_SESSION:TERMINATED:Horizon Session terminated due to inactive

I see that same message for everyone that drops. So it seams the 8.6 client isn't reporting back that the session is still active.

 

This was my session at the exact time I dropped, I was chatting in Teams.

uag-esmanager: [pool-7-thread-1]INFO utils.SyslogManager[terminateSession: 497][108.51.115.200][nthoman][Horizon][5c24-***-d1bc-***-16f1-***-6d0b] - HORIZON_SESSION:TERMINATED:Horizon Session terminated due to inactive - Session count:615, Authenticated sessions: 18

 

This in the release notes for 8.6 has me wondering....

https://docs.vmware.com/en/VMware-Horizon-Client-for-Windows/2206/rn/vmware-horizon-client-for-windo...

  • Support for timeout warning and timer

    You can configure the warning to be displayed and set the timer at which the warning is displayed before a user is forcibly disconnected from a remote desktop or published application. You can also configure the message that is displayed when the user is forcibly disconnected.

  • Display timeout message before forced disconnect

    You can configure a message and timeout warning to be displayed before a user is forcibly disconnected from a remote desktop or published application.

 

Reply
0 Kudos
SurajRoy
Enthusiast
Enthusiast

Thanks for the finding.

Yes, from the event it seems the heart beat either not being send to the connection or not to the correct connection server.

if the issue is not happening with older view client with same setup but happening with new 8.6, would recommend to open ticket with VMware support to file bug if any.