I noticed after upgrading to VMware Horizon View 7.8 and VMware Unified Access Gateway 3.5, when attempting to log in to a VMware Horizon View Connection Server via the Horizon Client, I would get stuck on “Authenticating”. If using the HTML client, it would get stuck on “Logging in”.
This will either timeout, or eventually (after numerous minutes) finally load. This occurs both with standard authentication, as well as 2FA/MFA/RADIUS authentication.
The Problem
Originally, I thought this issue was related to 2FA and/or RADIUS, however after disabling both, the issue was still present. In the VDM debug logs, you may find something similar to below:
2019-03-19T16:07:44.971-06:00 INFO (1064-181C) UnManagedMachineInformation Wake-on-LAN packet sent to machine comp.domain.com
2019-03-19T16:07:34.296-06:00 INFO (1064-17F0) UnManagedMachineInformation wait ended for startup update, returning false
2019-03-19T16:07:34.296-06:00 INFO (1064-17F0) UnManagedMachineInformation Could not wake up PM comp.domain.com within timeout
The Fix
The apparent delay “Authenticating” or “Logging In” is caused by a Wake On LAN packet being sent to an unmanaged physical workstation that has the VMware View Agent installed. This is occurring because the system is powered off.
After powering on all unmanaged View agents running on physical computers, the issue should be resolved.
Hello,
I happened to find your post while searching for information on the exact same issue with version 7.8. We install the View Agent on several physical machines as part of a DR solution. The fix you described also resolves the issue for us. So thank you very much for sharing that information! That being said, the fact that an unmanaged machine(s) that happens to be powered off or having an issue responding gets in the way of authenticating to View and ultimately connecting to a different machine seems like more of a bug to me. I’m considering opening an SR with VMware.
Glad it helped!
I agree, this shouldn’t be happening. I tried to notify VMware via Twitter, but didn’t hear back.
I noticed in the logs that it’s sending a Wake On LAN packet, which makes sense, but instead of waiting, it should proceed and just mark the Horizon target as unavailable until it comes online.
Either way, glad the post was read!
Cheers!
[…] Also, on a final note… I did find a bug where if any of the physical PCs are powered down or unavailable on the network, any logins from users entitled to that pool will time out and not work. When this issue occurs, a WoL packet is sent to the desktop during login, and the login will freeze until the physical PC becomes available. This occurs during the login phase, and will happen even if you don’t plan on using that pool. More information can be found here: https://www.stephenwagner.com/2019/03/19/vmware-horizon-view-stuck-authenticating-logging-in/ […]
Thanks for this. Spent over an hour trawling logs trying to figure out why it would accept creds then not show the server options. I had several entitlements and only 1 physical one but it stopped me connecting. Life saver.
This was also really helpful to me. Exactly the symptoms I was seeing. Thanks for posting this.
Hello,
I have the same issue with Horizon 7.7, no UAG and 2F/Radius authentication enabled.
The Radius authentication goes straight, but then I got the AD authentication which works but takes a lot of time. Seems to be waiting for a timeout.
I don’t have any unmanaged physical machine with the view agent installed….
Any idea ?
Ok, I found it !
The logs indicates :
2019-07-30T15:34:02.325+02:00 WARN (1148-1988) [RadiusAuthSessionState] (SESSION:3762_***_b351) Received timeout (for accounting)
2019-07-30T15:34:02.325+02:00 WARN (1148-1988) [RadiusAuthSessionState] (SESSION:3762_***_b351) RADIUS start accounting failed for user xxxxxx, with accounting session id10
So simply changing the accounting port in Horizon Radius configuration to 0 instead of the real port solved the issue.
Glad to hear you figured it out, and sorry for not being able to reply sooner!
It seems like any little misconfiguration or issue will cause the authentication process to hang/freeze. Good spot though! 🙂
I’m sure this help numerous others!
Cheers,
Stephen
Thanks – looks like I needed to update the agent on my physical machine. Glad this was just affecting me and not all my users.
So.. in the new admin console, it won’t let you set the port to 0. Have to use the old console to do it.
WOL FFS thanks, fixed the issue i had also.