Session Expired

[Nehalem7]

I am getting issues where users can't connect to there assigned PC's for a period of time. It clears up after a little but but there is a warning in the vent log that states: "The pending session on machine VM-WIN7-6 for user USERNAME has expired. " Just wondering if anyone knows what this is from. I don't haev a timeout on the pool.

[mittim12]

There is a global session timeout under View Configuration and Global settings.   Did you change that?

[Nehalem7]

Yeh, to 10,000,000 minutes becuase my Wyse V10L's hit the time out and then errored when trying to connect back in until they where rebooted. It's been changed for a while.

[TravisT]

Were you able to fix this issue? I'm having the same problem...

Thank you,

Travis

[Nehalem7]

not yet. I'll probably end up placeing a call to VMWare Support. I'm just not sure without being able to re-produce it what they'll be able to do.

[TravisT]

Here's an update:

I have been working with VMware Support about this issue. One thing we have found is that if you RDP into the desktop that's expired the user's session in Task Manager is in a disconnected state. If you select the user and select Logoff then they are able to login again.

Unfortunately, I have yet to figure out how they are getting in to the disconnected state since they are usually actively working when the get kicked out. There only suggestions so far has been to try a reinstall of the view agent and vmware tools, however I can't do that since I am using Linked Clones with a lot of software and config after they have been provisioned. The other item they have had me look at was the userinit string referencing VMware article http://kb.vmware.com/kb/1028975.

If I find out anything else, I will post it.

-- Travis

[mpryor]

It certainly does sound like wssm is not starting within the user session, which would explain the "pending session expired" log and the disconnect (if they happen at the same time) - did you verify that wssm is actually running or just check the userinit registry entry in the key?

[RJW1975]

Hi Travis,

Have you found anything else yet on this issue and have VMware come back to you yet?

cheers

Rob.

[idle-jam]

i'm keen to know as well as i'm facing something similar too ..

[Nehalem7]

I placed a call to VMWare Support. He collected some logs but we really didn't get anywhere. I'm on 4.5 working on my 4.6 upgrade. Can anyone confirm it also happens in the new version?

In my setup I'mo only using RDP. The VM's are both XP and 7. The clients are Macs, PC's and Wyse V10L's.

I know there is an entry in the Windows Application Log for the Same time on the Virtual PC.

Pending portal logon timed out for user domain\user, wssm may have failed to start correctly, or the user was not able to connect and log in. Pending count left=0

I'm going to call support back today and push the issue. If anyone finds a resolution please keep me posted.

[TravisT]

I'm still working with VMware about this issue. On my last call, we looked through the logs on a VM that had the issue recently. The one thing that seemed to be reocurring is that the users with the problem are locking their desktop before they leave for the day instead of logging off. The session timeout was set for 600 minutes or 10 hours. So we are thinking that it may have been caused by those two events. I have increased the session timeout to be 2 weeks and haven't had the problem since then. I'm also instructing my users to make sure they logoff for the day instead of just locking their desktop.

-- Travis

[TravisT]

I'm in the process of upgrading to 4.6 as well. I have upgraded my servers, however I still need to upgrade our agents. We are waiting for a time that we can recompose.

-- Travis

[Linjo]

Is this not the new SSO timeout described here: (from the release notes)

"New timeout setting for SSO users - With the  single-sign-on (SSO) feature, after users authenticate to View  Connection Server,  they are automatically logged in to their View desktop operating  systems. This new timeout setting allows administrators to limit the  number of minutes that the SSO feature is valid for.

For example, if an administrator sets the time limit to 10 minutes, then  10 minutes after the user authenticates to View Connection Server, the  automatic login  ability expires. If the user then walks away from the desktop and it  becomes inactive, when the user returns, the user is prompted for login  credentials. For more  information, see the View Admin Guide"

// Linjo

[lookandfeel]

Hi,

I have the same problem - "The pending session on machine [...] for user [...] has expired.

In our View 4.6 environment we use a Novell client in the View desktop.

With a scripted start of the View client we deposit the View desktop and the AD-user with his password.

So only the Novell login GUI is shown, when a user starts the View Client.

Now we find out, that a started View client "waits" at the Novell login, but if no user is there and logs in, after approx. 20 minutes the View desktop stops, the View client is closed, and the above described warning message appears in the View Administrator event section.

How can I avoid this behaviour?

The View desktop should show the Novell login "for a long time", and not exit after 20 minutes.

The timeout setting for SSO users I checked already - there is the default option "-1", that means that no SSO limit is set.

Kind regards,

Andre

[mpryor]

lookandfeel:

It's not the same problem, you are hitting a deliberate timeout for connected desktop sessions. If the user isn't logged in locally to the VM within the pending session timeout (15 mins by default), then the session will be torn down which in turn closes the PCoIP connection.

If you want to automatically make the desktop connection and leave it sitting at the login prompt for an extended period of time rather than actually logging in then you need to increase the VdmConnectionTicketTimeout policy value (details are in the View admin guide). Note that extending this timeout means that the VM will be reserved to the user that gets brokered to that VM until login occurs or the time expires, even if the thin client is powered off/disconnected.

[WillFish4Fun]

We had the same issue - turned out to be a semi lobotomized clone that happened to be at the top of the "queue" for the 'next available workstation' for a View client.  (possibly malware had revised the userinit regkey on this particular machine - I didn't look since I could tell it was the machine that was the issue.)  To verify this, review the View Administrator Event log and make sure it isn't the same Virtual machine involved with the immediate connect/disconnects.  Especially if this is a pool that has been working properly in the past.  I recomposed the particular desktop causing the issue and this resolved our issue.

[Skullner]

We had the same error. It is connected to the userinit-Reg-Key as there the wssm.exe will be started. So if the wssm.exe is not running the Connection-time via VIEW is limited to 15 minutes without a reconnection possible. As mentioned above^^ A further behaviour is that it is not possible to track activity in the View-Administration on those defektive clients and the Eventlog auf View-Administration tells: Session expired.

So add the folowing entry to the Template before making the snapshot to distribute:

Path HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon

Keyname: Userinit (must exist already)

Value: c:\windows\userinit.exe, "C:\Program Files\VMware\VMware View\Agent\bin\wssm.exe"

This should be the default for a View-client.

If it is not possible to change this entry as it is in our house, create a new String Registry key as follows:

HKLM\Software\Microsoft\Windows\CurrentVersion\Run

Naming: as you wish

Value: "C:\Program Files\VMware\VMware View\Agent\bin\wssm.exe"

This starts the needed wssm.exe even if the userinit is not a possibility. It works good now.