We are noticing this error a lot The pending session on machine xxxxxxx for user xxxx has expired .
When we did some search few blogs point to DNS issue.
I would like to know the cause of this warning.
Please Advice
Regards
We used to experience this. What we found was that the session was typically hung logging off in the VDI while the connection brokers thought it was still active. The user would try to reconnect and the connection server would try to connect the user but since it was still logging off they could not connect.
Hi Ben,
Thanks for the response. Did you find a solution for it.
Please advice.
If you're running Horizon Agent 7.7 the issue might be related to an outdated Vmware Horizon Client. I'd recommend updating the Client on the endpoint.
I just ran into this this morning as well. We updated an app-stack for a desktop pool recently and this users are getting kicked out before they login completely on some cases. I'd review any logs like if your using UEM the flexegnine log to see the login process, thats probably where my day is going today.
We started seeing this on Horizon Agent 7.4.0. We opened a ticket with support and at their request we've upgraded to 7.7.0. It seems to have helped but we continue to see it. We are still troubleshooting with VMware.
I have been seeing this as well for the past year. It is worse as we ramp up the number of users we have. I opened a ticket with VM Ware support and they had me do the following:
Remove all VM Ware software (agents and tools)
Install order for gold images-
1)Upgrade VM Ware tools to 10.2.5-Custom install without SVGA driver. Reboot
2)Horizon Agent Install, reboot
3)UEM Agent Install
4)App Volumes Agent Install, reboot
5)Check that the VM Ware Tools, Horizons Agent, UEM Agent, and App Volumes Agents are running.
6)If we have them, the NVIDIA drivers.
7)Check the SSL thumprint in the registry and make sure it matches the *.domain.com SSL cert thumbprint.
The following registry keys should be set in the gold image (the 5000 number is arbitrary and can be changed to fit our environment)-
Hive HKEY_CURRENT_USER
Key path Control Panel\Desktop
Value name AutoEndTasks
Value type REG_SZ
Value data 1
Hive HKEY_CURRENT_USER
Key path Control Panel\Desktop
Value name HungAppTimeout
Value type REG_SZ
Value data 5000
Hive HKEY_CURRENT_USER
Key path Control Panel\Desktop
Value name WaitToKillAppTimeout
Value type REG_SZ
Value data 5000
I have also looked at upgrading to 7.7, but support said that 7.8 was coming.
I fixed it a similar way, but this applies too
if there userinit string is incorrect it will cause this error, it doesn't seem to effect users though, as no one ever reported an issue to me
@sillej Did this procedure work in your environment? Is it fixed?
robsisk1972,
Not completely resolved but better that it was. I have two cases where this still occurs. One of them is from users who have an appstack and it appears that the appstack does not get completely removed so I have to manually remove those machines. The second case if is I allow the connection servers to run beyond two weeks without a reboot then these errors start to ramp up.
Thanks,
James
I used to deal with a similar issue a couple of years back and was able to resolve it by setting these keys at user logon using UEM. Also give that a try and see what happens. The key name is self explanatory
[HKEY_CURRENT_USER\Control Panel\Desktop]
"AutoEndTasks"="1"
We are seeing this as well with a small subset of users. Only seems to impact 5 - 10 out of a couple hundred users. We have these registry keys in place.
It could be a possible load balancing issue but we are still trying to track this down.
Something else I thought I would add. A week ago I changed the NetBIOS settings on our Horizons server from enable to disabled. They are behind F5's and this has shown a drastic drop in this behavior and multiple attempts to connect to a VDI machine.
I'm in a very similar configuration, I'm going to have to try this on our brokers. We forced some users to go directly to an individual connection server to see that that would help, haven't checked yet.
Disabled this on our CS's and it doesn't seem to have helped.
We have a ticket open with VMware so hopefully we can get some traction on that soon.
We use full desktop clones with no profile management for a small group of users. This issue occurred for one of our users, regardless of any VDI desktop he accessed. Tried Win 10 1903 and 1809 along with Horizon Agent 7.7, 7.8, and 7.9, to no avail. His issue was due to the client he used to connect. For whatever reason, connecting via the latest Mac Desktop client 5.1.0 (13920831) as of this writing, resulted in this error message. Once he tried HTML5 access or the full Windows client via another computer, the issue went away.
In the event Log's search for Audit Failure and see if there is a message looking like "Unable to launch from Pool XXXX for user domain\username: No co-management availability for protocol PCoIP"
Next step, look at your connection servers and take a look at your CPU usage.
Lastly, add a few more vCPU to your Connection Server's. This worked for me to alleviate 99% of that issue. Though it still happen's from time to time, i know there is an open Engineering project internal to VMware on the issue.
We haven't seen this in a while. We ran into this a while back on 7.2/7.3 and it turned out to be a problem with the secure gateway process on the connection server causing this issue. I haven't seen this issue on 7.5.2
The solution for the above issue is entirely from user side: which network they are connecting. its blocking user to connect VDI. ask user to connect from different network and try it will get resolve.
I was receiving this issue very frequently, upgraded to 7.11 and the problem was gone.
I have seen this problem when users get to trigger happy with login times and attempt to remove their smartcard and log immediately back in. Our environment didn't like when users tried logging in to quickly after a log off or disconnect.