Sessions not logging out after VDA 2206 installed

[Mike_B]

I have a machine catalog with Server 2019 VDAs, onto which I recently installed VDA 2206 in order to be able to take advantage of Shellbridge and publish Office365 applications.  However, since upgrading to the new VDA, I noticed that after closing the last published application the sessions no longer log out properly, but instead sit there with a status of 'Application Not Running'.

 

If I revert the machine catalog to an older snapshot with VDA 1912 on it, then the session logs out quickly after the last published app is closed, as it should.   So it definitely seems to be related to the new VDA.

 

Has anyone else noticed this behaviour, and found a fix?   Typically I would be looking at LogoffCheckSysModules, but nothing has changed apart from the VDA upgrade.  Whilst there are definitely more processes running under the user's account than with the older VDA, I have tried closing a few processes down from Monitor but can't find any specific one that might be causing it.

[Mike_B]

OK, found something new - the problem seems to be Shellbridge related, rather than the VDA itself.  If I set the registry to enable Shellbridge, sessions don't log out.  If I set the registry to disable it, then sessions log out as soon as the last open published app is closed.

 

I'll raise a ticket and see what Citrix Support have to say...

[Paul Brown1709152452]

On 7/20/2022 at 5:35 AM, Michael Burnstead1709159565 said:

Has anyone else noticed this behaviour,

Seeing the same on Server 2016 with VDA 2203 and 2206.  Shellbridge fixes do not apply to that OS.

Only reliable VDAs seems to be 1912 CU3 or CU5.

[Akira Huot]

Hi 

When you enable shellbridge,  it will  launch all programs that are usually executed by explorer shell in desktop session, such as programs listed in user's Run key (MS page), I suspect those processes are blocking the session logoff.  With shellbridge disabled, those processes won't be launched.

You can either remove the executable from startup process (e.g. from Run key) or you can add the process in LogoffCheckSysModules as a workaround.

In any case, the first step is identifying the process name that is blocking.

[Mike_B]

OK, making some progress - there was nothing in Run or RunOnce on either the user or machine registry keys, so I looked more at the processes again.   It turns out the culprit is the Workspace App being installed on the server.  The sessions would reliably log out if I used Task Manager (from an admin account logged into the same server) to quickly close all the processes with a blue Workspace App icon in the stuck session.

 

I have now added the following string to logoffchecksysmodules in the master image:

                analyticssrv.exe,concentr.exe,receiver.exe,selfserviceplugin.exe

 

and it seems to be logging out reliably now.   I'm not sure why Workspace processes were starting actually, I can't see it listed as a startup app in either the Run keys or Startup folders, but presumably something is calling it somewhere.  If shellbridge calls these startup processes, then that must be why it wasn't logging out properly.

 

The other way would be to uninstall the Workspace App, probably not really needed on a server used only for published apps.

[Richard Castillon]

On 7/22/2022 at 1:38 PM, Michael Burnstead1709159565 said:

OK, making some progress - there was nothing in Run or RunOnce on either the user or machine registry keys, so I looked more at the processes again.   It turns out the culprit is the Workspace App being installed on the server.  The sessions would reliably log out if I used Task Manager (from an admin account logged into the same server) to quickly close all the processes with a blue Workspace App icon in the stuck session.

 

I have now added the following string to logoffchecksysmodules in the master image:

                analyticssrv.exe,concentr.exe,receiver.exe,selfserviceplugin.exe

 

and it seems to be logging out reliably now.   I'm not sure why Workspace processes were starting actually, I can't see it listed as a startup app in either the Run keys or Startup folders, but presumably something is calling it somewhere.  If shellbridge calls these startup processes, then that must be why it wasn't logging out properly.

 

The other way would be to uninstall the Workspace App, probably not really needed on a server used only for published apps.

 

Hi Michael,

 

I have the same issue.
Did you found another fix ? I tried to add the 4 exe to logoffchecksysmodules that you mentionned but it doesn't change anything for me.

Regards,

[Cedric Brady1709158943]

Try the PVS Statustray.exe. closing that process for me closed out my session with shellbridge enabled.

 

Edit: added ",StatusTray.exe" to the end of the existing Logoffchecksysmodules via GPO. Deleted profile, opened Office successfully (which didnt work w/o Shellbridge enabled). Exited Outlook, and the session succesfully logged off from Director.

[lagermax]

we had the same issue and found the solution for us, we added msedgewebview2.exe to the logoff key and now the sessions logoff smoothly :)

[Mike_B]

That's interesting about Edge Webview.  I know that Workspace calls that (it's what is used to display the icons) so that's entirely plausible.

 

I will give it another go when I get a moment to try it - thank you.

[Michael Bartholin]

I solved my issue by removing apps from the Starup Apps section.

There are two keys in the registry for this:

 

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run

 

I had some apps that auto started when the users launched a published application. I removed them from those keys.

Also remove the systray item, since they also keep the session running. So things like PVS Systray icon etc

[TD134322]

While that may fix it, this is a Citrix issue that needs to be addressed. Shellbridge is likely your problem. Statustray.exe and workspace app should NOT run in a seamless published application.