View 6.2 Windows 7 Ent 64bit fails to log off some users

[EricNichols]

This has the effect of leaving them without a virtual desktop because view reports thtat they are currently logging off.

I was able to remotely look at the event log and I found this:

Log Name:      Application
Source:        Microsoft-Windows-EventSystem
Date:          12/18/2015 4:59:15 PM
Event ID:      4627
Task Category: Firing Agent
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      62-002.OBFUSCATED.local
Description:
The COM+ Event System timed out attempting to fire the Logoff method on event class {D5978630-5B9F-11D1-8DD2-00AA004ABD5E} for publisher  and subscriber .  The subscriber failed to respond within 180 seconds. The display name of the subscription is "Explorer". The HRESULT was 80010002.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-EventSystem" Guid="{899daace-4868-4295-afcd-9eb8fb497561}" EventSourceName="EventSystem" />
    <EventID Qualifiers="32768">4627</EventID>
    <Version>0</Version>
    <Level>3</Level>
    <Task>18</Task>
    <Opcode>0</Opcode>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2015-12-19T00:59:15.000000000Z" />
    <EventRecordID>39306349</EventRecordID>
    <Correlation />
    <Execution ProcessID="0" ThreadID="0" />
    <Channel>Application</Channel>
    <Computer>62-002.OBFUSCATED.local</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="param1">80010002</Data>
    <Data Name="param2">Logoff</Data>
    <Data Name="param3">{D5978630-5B9F-11D1-8DD2-00AA004ABD5E}</Data>
    <Data Name="param4">
    </Data>
    <Data Name="param5">
    </Data>
    <Data Name="param6">Explorer</Data>
    <Data Name="param7">180</Data>
    <Data Name="param8">
    </Data>
  </EventData>
</Event>


Log Name:      Application
Source:        Microsoft-Windows-Winlogon
Date:          12/18/2015 4:57:14 PM
Event ID:      6005
Task Category: None
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      62-002.OBFUSCATED.local
Description:
The winlogon notification subscriber <Sens> is taking long time to handle the notification event (Logoff).
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Winlogon" Guid="{DBE9B383-7CF3-4331-91CC-A3CB16A3B538}" EventSourceName="Wlclntfy" />
    <EventID Qualifiers="32768">6005</EventID>
    <Version>0</Version>
    <Level>3</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2015-12-19T00:57:14.000000000Z" />
    <EventRecordID>39306348</EventRecordID>
    <Correlation />
    <Execution ProcessID="0" ThreadID="0" />
    <Channel>Application</Channel>
    <Computer>62-002.OBFUSCATED.local</Computer>
    <Security />
  </System>
  <EventData>
    <Data>Sens</Data>
    <Data>Logoff</Data>
    <Binary>00000000</Binary>
  </EventData>
</Event>

Any ideas what is causing this?

[chulerico]

Eric,

I have seem the same issue with some desktop pools, other with most

also think your issue is relate to this too

"Urgent Help!!!  one of my client meets -  "the view agent reports that this desktop source is unable..."

desktop is being log off and stays there and you see the error you describe or the above, if you connect via vsphere you might see, windows trying to log off with a prompt specifying if one would want to force a log off as the desktop is waiting for apps to close.

some suggestions have been to implement a force log off script after a set time or trying different versions of the view agent.

good luck.

Sam

[HendersonD]

We are seeing the exact same thing. We have our View environment set to log off users after 10 hours if they have not logged off themselves. This is necessary in a school environment when we have students just "x" out of a View session instead of logging off. Overnight they are logged off and the desktop is refreshed. A few months back we noticed that desktops were not logging off automatically overnight. Through the vSphere client, when we looked at the console connection, the desktop said "Logging Off". These are Win7, 32 bit desktops running under View 6.2. We opened a ticket with VMWare and so far have gotten nowhere. They first said it was lack of resources with each of these desktops having 1 vCPU. The problem is we have been running this way for three years with no issue.

As we work this ticket with VMWare I will update this posting

[chulerico]

HendersonD,

thanks, please do let us know of any news, will open a case too.

Never really seem the issue as bad as now, to me it feels it started around view version 6.1./6.1.1, since the agent seems to help it must be something with the new versions.

thanks

Sam

[EricNichols · Accepted solution]

We kept getting this and opened a support request. VMware blames the OS or some misbehaving application. No help there. They wanted us to create some additional reg keys that were already OS defaults built in. Plus we already had AutoEndTasks set to 1 AutoEndTasks

These are the ones they suggested we add but they are of no help even if you change the default value.

https://technet.microsoft.com/en-us/library/cc978614.aspx

https://technet.microsoft.com/en-us/library/cc978624.aspx

I put a few of these "logging off" vm's into maintenance mode, force rebooted them and then RDP'd into them and looked at the event logs. In all cases, this event was present:

"The winlogon notification subscriber <Sens> is taking long time to handle the notification event (Logoff). "

Solution:

Create a scheduled task with a custom event viewer trigger that queries the EventData Data array. Using the EventID alone is not enough because logon and logoff have the same EventID of 6005. You could probably use the COM+ event with "<Data Name="param2">Logoff</Data> " instead. Use an action that reboots the machine, this reboot does the trick in telling the connection server that the session is over and it will get deleted\recomposed. Im not sure if there is any profile loss but at least the user can now log back in to another VM. Here is the XML that you can use to import the task, it has a 2 minute delay that could probably be left out.:

Reboot if logoff fails with Sens and Logoff in event data.xml

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.3" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Date>2016-09-30T09:31:03.3167339</Date>
    <Author>NT Authority\System</Author>
  </RegistrationInfo>
  <Triggers>
    <EventTrigger>
      <Enabled>true</Enabled>
      <Subscription>&lt;QueryList&gt;&lt;Query Id="0" Path="Application"&gt;&lt;Select Path="Application"&gt;*[System[Provider[@Name='Microsoft-Windows-Winlogon'] and EventID=6005]] and *[EventData[(Data[1]='Sens') and (Data[2]='Logoff')]] &lt;/Select&gt;&lt;/Query&gt;&lt;/QueryList&gt;</Subscription>
      <Delay>PT2M</Delay>
    </EventTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">
      <UserId>S-1-5-18</UserId>
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
    <AllowHardTerminate>true</AllowHardTerminate>
    <StartWhenAvailable>false</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <IdleSettings>
      <StopOnIdleEnd>true</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <AllowStartOnDemand>true</AllowStartOnDemand>
    <Enabled>true</Enabled>
    <Hidden>true</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <DisallowStartOnRemoteAppSession>false</DisallowStartOnRemoteAppSession>
    <UseUnifiedSchedulingEngine>false</UseUnifiedSchedulingEngine>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>P3D</ExecutionTimeLimit>
    <Priority>7</Priority>
  </Settings>
  <Actions Context="Author">
    <Exec>
      <Command>cmd</Command>
      <Arguments>/c shutdown /f /r /t 0</Arguments>
    </Exec>
  </Actions>
</Task>

[a_p_]

Just a quick note. I had the same issue with a customer (Horizon View 7), and the solution was indeed the "AutoEndTasks" registry key. Please note that although the values are "0" or "1", it's a "REG_SZ" type (rather than REG_DWORD).

André

[EricNichols]

Yes we have the REG_SZ and still get the "The winlogon notification subscriber <Sens> is taking long time to handle the notification event (Logoff). ". The scheduled task solves our issue.

[madmanc]

Thanks for this Eric...
I am going to be trying this out as we see the exact same problem.

James

[madmanc]

After several weeks, can confirm this resolved the issues we were having

Happy days once again! EricNichols‌

[madmanc]

And the problem has returned for me...

[HendersonD]

‌I should have posted this a few months back. After working my ticket with VMWare for over 6 weeks, the told this was a bug in ESXi 6 and would be fixed in Update 3. Not sure when this update will be released or if ESXi 6.5 has this bug