We run Horizon Agent for remote access in multiple labs in a University setting. We have noticed that some connections stay listed in the sessions list as disconnected indefinitely, making it so that we have to clear them manually with the "log off session" or else no one can use these computers until such manual action is taken.
Under "Desktop Pool Settings", we have "Log Off After Disconnect" set to "After 30 minutes" (we have tried immediately too). Under "Global Settings" tab and "General Settings" we have "Forcibly Disconnect Users" set to "After 1440" minutes, "Forcibly Disconnect Warning Time" set to "Before 1" minutes, and the "After warning, Logoff after" set to "5" minutes. Even with all of these settings, we still have those sessions that stay disconnected (and stuck) indefinitely until manual action is taken.
I've also tried the "FixLogOff.adm" which adds the "Auto End Tasks" setting to GPO. I tried this on a local PC and as a deployed GPO for the entire lab. This made no difference and we still have those same sessions.
Please advise how can we fix this issue. Thanks
8.7.0 build - 20649599
Version 2209
Hi, @CEDCHelp
Have you checked the AutoEndTasks registry to force logoff?
Horizon View Desktops hanging on logoff preventing composer operations, or users from logging in (2151503)
https://kb.vmware.com/s/article/2151503
The AutoEndTasks registry was used heavily mainly for link clones, but it is also effective for instant clones.
Yes, sadly we have tried the "AutoEndTasks" registry key on all computers in the lab (using Group Policy aka GPO to deploy to all lab computers at once) but it does not work. I also checked to make sure it is there, and I see AutoEndTasks = 1 in HKCU\Control Panel\Desktop, as well WaitToKillAppTimeout = 5000 in HKLM\SYSTEM\CurrentControlSet\Control. We also use DeepFreeze which means all computers go back to their last imaged state when restarted. While DeepFreeze use doesn't affect the "AutoEndTasks" key, it does make it harder to get crashdump logs.
I will again check the event viewer of a problematic PC and see if there is any signs of apps hanging. Last time I checked there were no logs.
Below is the "FixLogOff.adm" file we used. ADM files are template files that are used by Group Policies to describe where registry-based policy settings (Like AutoEndTasks) are stored in the registry
; Created by Jeramy Thompson
; Custom Group Policy
; To force applications to close
; On logoff
; in VDI enviornments
; that have issues with
; forced log offs
;
;
CLASS USER
CATEGORY !!FixLogOffIssues
KEYNAME "Control Panel\Desktop"
POLICY !!AutoEndTasks
EXPLAIN !!AutoEndTasksExplain
VALUENAME "AutoEndTasks"
VALUEON 1
VALUEOFF 0
END POLICY
POLICY !!HungAppTimeout
EXPLAIN !!HungAppTimeoutExplain
PART !!HungAppTimeout_Text TEXT
END PART
PART !!HungAppTimeout_Value EDITTEXT
VALUENAME "HungAppTimeout"
END PART
END POLICY
POLICY !!WaitToKillAppTimeout
EXPLAIN !!WaitToKillAppTimeoutExplain
PART !!WaitToKillAppTimeout_Text TEXT
END PART
PART !!WaitToKillAppTimeout_Value EDITTEXT
VALUENAME "WaitToKillAppTimeout"
END PART
END POLICY
END CATEGORY
[strings]
FixLogOffIssues="Force Logoff Settings"
AutoEndTasks="Auto End Tasks"
HungAppTimeout="Hung App Timeout"
WaitToKillAppTimeout="Wait To Kill App Timeout"
AutoEndTasksExplain="Determines whether user processes end automatically when the user either logs off or shuts down. \n\nIf policy is disabled or not configured: \nProcesses do not end automatically. The system waits until the process ends, and, if the process takes more time than the value of the HungAppTimeout entry, the End Task dialog box appears, stating that the application cannot respond to the End Task request.\n\nIf Policy is Enabled: \nProcesses end automatically.\n\nFor more information see Microsoft article\nhttps://technet.microsoft.com/en-us/library/cc978604.aspx "
HungAppTimeoutExplain="Specifies how long the system waits for user processes to end after the user clicks the End Task command button in Task Manager.\nIf this threshold is exceeded, the End Task dialog box appears, stating that the process did not respond.\n\nFor more information see Micorosft article\nhttps://technet.microsoft.com/en-us/library/cc978614.aspx"
WaitToKillAppTimeoutExplain="Determines how long the system waits for services to stop after notifying the service that the system is shutting down. This entry is used only when the user issues a shut-down command by clicking the Shut Down button on the Windows Security dialog box or by selecting Shut down from the Shut Down Windows dialog box.\nWhen the value of this entry expires, the system notifies the user that the service has not stopped. The user can either force the service task to stop or continue to wait. If the user waits, this value specifies the interval between repeated user notices that the service has not stopped.\nIf all services stop before this value expires, the system shuts down; it does not wait for this value to expire.\n\nFor more information see Microsoft article\nhttps://technet.microsoft.com/en-us/library/cc976045.aspx "
HungAppTimeout_Text="Set the timeout in Milliseconds Default is 5000 (5 seconds)"
WaitToKillAppTimeout_Text="Set the timeout in Milliseconds Default is 20000 (20 seconds)"
HungAppTimeout_Value="Hung App Timeout Value"
WaitToKillAppTimeout_Value="Wait To Kill App Timeout Value"
HI, @CEDCHelp
Thanks for reply.!
We think we should look at Windows events first. Because if there is still a session in Horizon, I believe it is recorded as ERROR-CODE=AGENT_ERR_LOGOFF_IN_PROGRESS in the debug-yyyy-mm-dd-hhmmss.txt of the Horizon Agent.
ERROR-CODE=AGENT_ERR_LOGOFF_IN_PROGRESS is a record that the OS is processing the logoff.
Therefore, after reproducing the event, it is recommended to look for the logoff operation in System-log.evtx , Application-log.evtx around the date and time of the logoff operation from the Windows event.
For keywords and such in the event log,
"Application Hang" or something like that?
If it is too difficult to check by yourself, you can submit the event log to Microsoft for confirmation, and if it is caused by a VMware module, identify the library name and present Microsoft's view to VMware, which may lead to a quick reinvestigation procedure on the development side If the problem is caused by a VMware module, you can identify the name of the library and present Microsoft's opinion to VMware, which may lead to a quick reinvestigation procedure on the part of the developer.
Currently, to fix AGENT_ERR_LOGOFF_IN_PROGRESS,
Currently, the most effective way to fix AGENT_ERR_LOGOFF_IN_PROGRESS may be to restart the virtual machine where the problem occurred.
Thanks for this information.
While I did not have an "agent_err_logoff_in_progress in any of the vmware logs (including the debug-2023-04-##-######.txt logs, log-2023-04-##.txt, system.evtx (windows event viewer) as well as the vmware-MKSVchanServer TsdrUserSErver log files, that does not mean that is not the issue. I am not able to login a specific machine specifically, only randomly, so to pull these logs I sat at a physical computer with issues and pulled... meaning I did not have access to the "C:\Program Files\VMware\VMware View\Agent\DCT\support.bat" file to generate logs. In fact that DCT folder does not exist when logging in locally.
I still need to pull logs from a few more affected computers, as the one I tried could have been a fluke. Also, I will try to remote into an affected one and pull logs (and hopefully the DCT folder and support.bat will be there then).
I will follow up if anything changes in the meantime. Thanks!
One thing I noticed in the logs (%programdata\VMWare\VDM\logs) is when it disconnects correctly I see:
2023-09-25T12:48:43.895-06:00 INFO (0628-0D9C) <SessionCleanupQueue> [vmware-vvc] VVC_Uninit done
2023-09-25T12:48:43.897-06:00 INFO (1180-1338) <4920> [wsnm_desktop] Session DISCONNECTED: sessionId=10, user DOMAIN\USER, client=DESKTOP-R6SLG9C, connectionId=1EE23DF2_500B_4B7C_9DAE_81A13CE14EE3, userDn=cn=s-1-5-21-3931225680-1871015619-2963001510-1913793,cn=foreignsecurityprincipals,dc=vdi,dc=vmware,dc=int
2023-09-25T13:14:45.374-06:00 INFO (1180-1338) <4920> [wsnm_desktop] Delay JMS ENDED notification until fully logged out for sessionId=10 (timeout = 1800 seconds)
2023-09-25T13:14:46.375-06:00 INFO (1180-120C) <TimerService> [wsnm_desktop] Session ENDED: sessionId=10 (delayed logoff)
particularly noticing the "delayed logoff" part.
but when it doesn't disconnect and leaves a permanent state of disconnected (where other users can't use the PC until we manually logoff disconnected sessions or possibly reboot the PC) it looks like this:
2023-09-25T13:59:05.639-06:00 INFO (1180-1338) <4920> [wsnm_desktop] Session DISCONNECTED: sessionId=11, user DOMAIN\USER, client=DESKTOP-8KOO4AR, connectionId=8EF4A30E_F9BC_4463_BDEA_71587F810591, userDn=cn=s-1-5-21-3931225680-1871015619-2963001510-1594758,cn=foreignsecurityprincipals,dc=vdi,dc=vmware,dc=int
2023-09-25T14:15:00.258-06:00 INFO (3BCC-3EFC) <16124> [LogonUI] Program 'LogonUI - Windows Logon User Interface Host' started, version=10.0.19041.1 (WinBuild.160101.0800), pid=0x3BCC, buildtype=release, usethread=0, closeafterwrite=0, sessionId=12
2023-09-25T14:15:00.259-06:00 INFO (3BCC-3EFC) <16124> [LogonUI] vmlm - wscredf Sending WSCREDF_ATTACHED_NOTIFY
2023-09-25T14:15:05.013-06:00 INFO (1180-1338) <4920> [wsnm_desktop] vmlm - wsnm_desktop Sending CREATE_SESSION_BEGIN
2023-09-25T14:15:05.014-06:00 INFO (1180-1338) <4920> [wsnm_desktop] Session created in PENDING state: sessionId=12, winStation=RDP-Tcp#78
2023-09-25T14:15:05.014-06:00 INFO (1180-1338) <4920> [wsnm_desktop] vmlm - wsnm_desktop Sending CREATE_SESSION_END
2023-09-25T14:15:05.231-06:00 INFO (7780-4B94) <19348> [MessageFrameWork] Program 'wssm - VMware Horizon Session Manager 64-bit' started, version=8.5.0 build-19564166, pid=0x7780, buildtype=release, usethread=1, closeafterwrite=0, sessionId=12
2023-09-25T14:15:05.233-06:00 INFO (7780-4A14) <logloaded> [MessageFrameWork] Plugin 'ws_applaunchmgr - VMware Horizon Application Launch Manager 64-bit' loaded, version=8.5.0 build-19564166, buildtype=release
2023-09-25T14:15:05.236-06:00 INFO (7780-780C) <logloaded> [MessageFrameWork] Plugin 'ws_winauth - VMware Horizon Windows Authentication Support 64-bit' loaded, version=8.5.0 build-19564166, buildtype=release
2023-09-25T14:15:05.237-06:00 INFO (7780-3934) <logloaded> [MessageFrameWork] Plugin 'wssm_desktop - VMware Horizon Agent Session Manager Desktop Plugin 64-bit' loaded, version=8.5.0 build-19564166, buildtype=release
2023-09-25T14:15:05.237-06:00 INFO (7780-4B94) <Main Thread> [wssm_desktop] User profile customization is disabled.
2023-09-25T14:15:05.243-06:00 INFO (7780-4B94) <Main Thread> [wssm] Session Manager started for sessionId=12
2023-09-25T14:15:05.243-06:00 INFO (7780-5984) <logloaded> [MessageFrameWork] Plugin 'wssm_helpdesk - VMware Horizon Agent Session Manager Helpdesk Plugin 64-bit' loaded, version=8.5.0 build-19564166, buildtype=release
2023-09-25T14:15:05.247-06:00 INFO (1180-4E04) <MessageFrameWorkDispatch> [wsnm_desktop] vmlm - wsnm_desktop Sending SESSION_CONNECT_BEGIN
2023-09-25T14:15:05.248-06:00 INFO (1180-6898) <sessionConnectedThread> [wsnm_desktop] Session CONNECTED non-portal user: sessionId=12, user UNIVERSITY\statena, client=CEDC-NC2612A-L3
2023-09-25T14:15:05.248-06:00 INFO (1180-4E04) <MessageFrameWorkDispatch> [wsnm_desktop] vmlm - wsnm_desktop Sending SESSION_CONNECT_END
2023-09-25T14:15:05.276-06:00 INFO (7780-409C) <MessageFrameWorkDispatch> [wssm] vmlm - wssm Sending PROCESS_SCRIPTS_BEGIN
2023-09-25T14:15:05.276-06:00 INFO (7780-409C) <MessageFrameWorkDispatch> [wssm] vmlm - wssm Sending PROCESS_SCRIPTS_END
any reasoning as to why delayed logoff only works on certain sessions and others it doesn't kick in automatically?
I might have found a workaround, which still doesn't explain why the admin interface settings about force logging off (global and local) don't work with the pools, but the Group Policy version (found in "computer config> policies> admin templates> VMware View Agent Configuration> Agent Configuration) works. This was "Disconnected Session Time Liit (VDI)" and "Idle Time Until Disconnect", as well as a change to one of RDP's settings for good measure. Then I added an automatic reboot at 12:30 am.
Here's the fix:
The RDS Session Time Limits group policy settings let users set policies for time limits to sessions on RDS hosts.
The Horizon 7 RDS group policy settings are installed in the Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits folder.
The Horizon 7 RDS group policy settings are also installed in the User Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits folder.
All you have to do is configure the "Set time limit for disconnected sessions" Group Policy found in the above location and that will do the trick. Still sad the global and local VM settings don't work as they should, nor the VMWare group policy settings which supposedly do the same thing.
