Disconnects after 15 minutes

[jfmoots]

I've been chasing a disconnect problem. I have about 200 View clients connecting in 5 different pools. They will only stay connected for about 15 minutes (almost exactly 15 minutes). This leads me to believe there's a timer or something kicking me out. During the 15 minutes the session works perfectly. It's a PCOIP session. I just had one do it and after reviewing the log-2010-09-02.txt log in the c:\documents and settings\all users\application data\vmware\vdm\logs directory of the VM running the View agent I see this...

13:45:26,714 INFO <2916> Log for VMware View Agent, version=3,1,0,3178:soft_pcoip_rc_3_1, pid=1372

13:45:26,714 INFO <2916> hostname=NVLAB_11.mevsd.marysville.k12.oh.us

13:45:26,714 INFO <3132> Program 'pcoip_server_win32 - PCoIP Server' started, version=3,1,0,3178:soft_pcoip_rc_3_1, pid=1372, buildtype=release

13:45:29,340 INFO Client/agent channel pending wssm to start

13:45:29,761 INFO Program 'wssm - VDM Framework Session Manager' started, version=4.0.1 build-233023, pid=2928, buildtype=release

13:45:29,855 INFO <656> __WlxLoggedOutSASDlgProc::WM_INITDIALOG: Setting username and password for SSO.

13:45:35,590 INFO Session created in PENDING state: id=0, winStation=Console

13:45:37,199 INFO <3504> Program 'TPAutoConnect - TPAutoConnect User Agent' started, version=7,17,512,1, pid=2828, buildtype=release

14:00:29,864 WARN Pending portal logon timed out for user MEVSD\navinlib, wssm may have failed to start correctly, or the user was not able to connect and log in. Pending count

left=0

14:00:31,458 WARN Unable to locate route for response queue [[3e1c4ff0-8488-46a7-865f-19a903a49100]MessageFrameWork_1.

14:00:31,458 INFO <2108> Program 'winlogon' started, version=, pid=2992, buildtype=release

14:00:31,458 INFO <2108> Authentication Manager successfully installed.

I logged in at 1:45 and it kicked me out at almost exacty 2:00. I see a message there but I don't know what that means.

Any suggestions as to the root of the problem would be appreciated.

[TSher]

Hi Jfmoots,

Are your users in an active session using the VM or is the session logged in to but idle?

Thanks.

[jfmoots]

They can be active... So I'm told but I've not duplicated that. My tests have been with inactive workstations. I'll test tomorrow and induce some activity 10 minutes in to see what happens.

[jamesbowling]

Is this happening on all of the clients or just a subset of them?




If you found this at all helpful please award points by using the correct or helpful buttons! Thanks!

[jfmoots]

There are some that stay connected. I can't put my finger on which ones. They're all in the same pool. I think it's actually certain Thin Clients that stay connected but I'm not positive on that.

Forcing RDP corrects the issue. So, it definitely PCOIP related.

Talked with support today and they're saying 4.5 should fix the issue but my Wyse units run Suse and I'll need to wait for Wyse to post a 4.5 compatible client that supports PCOIP. And for 4.5 to actually come out...

[TSher · Accepted solution]

Hi, pcoip does have a 15 minute disconnect if idle timer. Have you used the following reg entry? If not give it a go, I had a similar issue to yours and this solved it.

“HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VDM\Agent\Configuration\VdmConnectionTicketTimeout

You need to create a dword with a value of around 8000 initially. If it solves your problem then adjust the dword accordingly if you do want an idle session to disconnect.

Thanks

[jfmoots]

I'll try that in the morning and follow up. I hope that's it...

It sure seems like it's doing it on purpose and your theory sounds good

[James_Moots]

The registry tweak fixed it. I also see that setting is available in the GPO ADM templates they supply. In my opinion, the description of this setting is vauge and needs better clarified. Thank you guys very much for the help!

I'm unable to to mark this thread as answered or award points. Sorry...

[TheTer]

So this tweak goes on the virtual desktop's registry?

[jfmoots]

Yep! There's also ADM files for group policy to push that setting out. It's not very descriptive as to it's purpose. I saw it but I had no idea it was in relation to idle PCOIP session timeouts. It needs more clearly documented but it works like a charm.

[bwallace]

Can someone clarify the purpose of the underlying key value?

The description in the ADM (vague) is:

"Specifies the time in seconds for which the View connection ticket is valid. The connection ticket is used by View clients when connecting to View Agent and is used for verification and single sign-on purposes. For security reasons, these tickets are only valid within the specified time period. If this property is not explicitly set, a default of 900 seconds applies."

When using PCoIP from a Wyse P20, I needed to bump this value for my VDI instances on the domain; however, for non-domain members (workgroup) it does not need to be set. Can anyone comment on why this is the case, shouldn't the View connection ticket auto-renew? Will users get dropped when the new higher value expires (86400 - 1 day)? If so, will I be able to reconnect immediately? (I can't when this value is not defined).

Also, I didn't like the fact that I had to modify the ADM template to allow a value of &gt;900 to be entered. The fix (if it stands the test of time) is kludgy at best and likely not supported. I'm going to follow up with my VM rep on Monday.

Thanks.

[bwallace]

Ok... I found my issue. One of my apps had overwritten the following reg key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit

You need to ensure that userinit contains the following path (in addition to any others)

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

Without this executable loaded, the SSO process never completes and you are disconnected at the defined timeout.

[sm4rtins]

Nice!!! I've checked and compare the problematic desktop with another normal desktop, than I observed that key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit" was different.So I've just readd "C:\Program Files\VMware\VMware View\Agent\bin\wssm.exe" and it works.

Thank you bwallace!