Random "Pending Session Expired" issue with View v5.0 & PCoIP

[Makian]

Hello Everyone,

We have gone through the VMWare documentation & forums but unfortunately have had no luck with finding fix to this problem so far...

We have recently established a 300 seat VMware View v5.0 environment for a student environment at a university.

The system is generally running pretty well. However, we have been encountering a significant number of the following warning message in our View Console. These errors seem to occur randomly (maybe for about 10% of all login attempts);

• "The pending session on machine XXXXX for user XXXXX has expired"
  

Further investigation has revealed that

• The View Mgt console shows that the user has successfully authenticated and been assigned a VM... but after 15mins "pending session expired"
  
• If another user is later assigned the same VM by the View broker they are able to login and use it OK.
  
• Doesn't seem to be linked to the physical location/network of the client. All our clients are located in same few locations/subnets.
  

When i look at the console of an affected VM though vSphere Mgt Client;

• No logon event recorded in event viewer & no local profile folder has been created for the relevant user.
  

• I can't see anything obvious that provides a clue about the problem in the PCoIP or View logs on the VM... Some sample logs are attached (the relevant time is around 2:49PM today 17th April).

  
  

• The following Windows application event log entries of VMWare View (in order)
  
  • Immediately after user connection assigned to the VM by broker
    
    • Needed to disconnect existing PCoIP connection during requestConnection
      
    • PCoIP requested disconnect while busy !
      
    • Closed PCoIP value doesn't match global value
      
  • 15mins after broker assignment.
    
    • Pending portal logon timed out for user XXXX, wssm may have failed to start correctly, of the user was not able to connect and log in. Pending count left = 0
      
    • Closed PCoIPvalue doesn't mathcn global value
      

Some additional details about our environment that may be relevant;

• We are using PCoIP protocol exclusively.
  
• Windows version of the View Client (running on Win7 ThinPC edition on re-purposed desktops).
  
• An F5 BIG-IP virtual appliance is being used to load balance connection requests between two connection brokers.
  
• We aren't using secure tunnel mode for the PCoIP connections (once connected the Client and Agent are talking directly).
  
• The golden master in Win7 x64.
  
• We are using linked clones... pool is setup to refresh VM on logout.
  

I was hoping someone might have some ideas or suggestions about this weird problem please ?.

Thanks !

[B0N3201110141]

Looks like I'm a little late to the party, but the issues you have described are pretty close to what I am experiencing after upgrading to 5.0.1

Did you ever resolve this issue?

Thanks

[Makian]

Hello,

In the end we suspect this problem was partly caused by a third-party screensaver being used on our Win7 soft clients.

If a user logged into the View Client soon after it was launched on the local Win7 workstation then it always seemed to work fine.

However, if the user started View client then left it idle for a long period before actually logging in (around 40mins) then these problems seemed to occur frequently. As the screensaver was kicking in at around 30mins we suspect a memory leak and/or some other weird interaction with the View Client ??. Removing this third party sceensaver seemed to greatly reduce the number of instances of this behaviour in our environment (around 300 seats).

Cheers.

[epa80]

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 Ex...  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.