Digging up an extremely old thread here, but, wanted to, as we are experiencing this issue in our environment. We are using Horizon 7.3.2, linked clones that refresh on logoff. We have 7 connection brokers. We utilize UEM but do not perform the logoff sync, and we're using vSan. Any other infrastructure details please let me know.
This specific event pops up in our event viewer very sporadically. I would not say often at all, maybe tops a couple times an hour. We have 3200 live sessions at any given time, give or take. What we have noticed though, is it almost always on a pool where remote users are connecting to. This of course leaves us in a tough spot, as we don't control home users' networks. If they have poor wireless setups, our hands are tied. I'm just trying to cover any pieces we CAN control. We don't even get any calls, but, we see it in the event viewer, and it's a pet peeve. We're assuming people ARE struggling, but that they eventually get in, and that's that.
I opened a sev3 ticket with VMware just to go over possible causes. The first 2 things they asked me to look at were the userinit registry key (it's correct), as well as disable any screensavers in the VM session. This is already done. With that out of the way, I returned to Google.
I came across this blog: ViewTrivia: Users have to login multiple times to get a View Session and muliple "Pending Session Expired....." events l… Which sounds a lot like what we see exactly. The fix the blogger writes about, to make sure "Always dynamically update DNS A and PTR records" is enabled, I did forward off to my network guy. The pool where we see this issue by and large, is indeed on its own vLan. I had hoped maybe it was misconfigured. I got this reply back from him:
It's not done via a DHCP setting in the traditional sense. Here's the process for for all DHCP clients on our network. When the client makes a DHCP request it sends a broadcast packet with it's mac address, name (usually the windows machine name but varies based on OS), and a list of desired options to set via DHCP, the local router on the subnet forwards this to the DHCP server which sends out an address and the other necessary parameters (mask, gateway, etc), the client receives this and replies again via broadcast to confirm the options. After that the server sends it's confirmation directly via unicast to that client to complete the DHCP transaction. At that point the DHCP server informs the DNS server to update the A and PTR records using the address assigned and the name supplied in the first request.
If the name is not updating it is almost always due to one of two root causes. The first is that the name is already in use and it will not clobber an existing name. If you had named your system itsys01 it wouldn't let you take the name of the departmental file server. The second cause is that there is no name being passed via DHCP discover. It's uncommon but possible and you can verify that by searching the infoblox logs on the name server for messages containing the word "added" to display all DNS name updates.
Am I barking up the wrong tree with the network guys? Is this likely just an issue with end users home network sucks? My next step I guess will be to reach out to the users who APPEAR to be having the issue, and just see what they might be experiencing.
Thanks in advance.