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.
I need below info to understand the step up:
We have 3 UAG all same versions.
Oracle calls this Traffic Management Steering Policies and is a DNS feature. Think of it like load balancing light.
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. ⏱🤓
Is the is issue reproducible if the traffic goes directly to one of the issue.
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
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.
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.
Could you please share the below logs:
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][188.8.131.52][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....
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.
You can configure a message and timeout warning to be displayed before a user is forcibly disconnected from a remote desktop or published application.
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.