Exiting RemoteApp session leaves disconnected RDP session

[Bob H]

We are utilizing RemoteApp Tool to deploy a RemoteApp to our CRM server app.  I used the Tool to create an RDP file and remote clients utilize it to launch the app remotely.  Occasionally, the app has hung and the user can't even exit the RemoteApp, except via Task Manager (Win 10).  This doesn't help since when the user restarts the RemoteApp, they are right back where they were before - a hung RemoteApp.

The problem is that when the users exit the RemoteApp, their session is showing on the server as 'disconnected'.  Is there any way to have the session properly 'log out' when the RDP session is exited?  I checked RDP settings and/or preferences in the Tool and was unable to see any option for that.

[Bob H]

Oops, in the Tool UI, I did see Host Options settings that appear to allow a workaround - set 'timeout for disconnected session' along with 'logoff sessions when time limits are reached'.  I have 2 questions on this

1) Does this setting take effect immediately or does it require a reboot or restart of Remote Desktop Services service?  Under Host Options it does mention 'some settings may require a reboot', but not which settings require the reboot.

2) Does this affect other users who connect to the server with ordinary RDP sessions (not using the RemoteApp Tool RDP file).  Will their disconnected RDP sessions get logged off with these Host Options?

[Aaron Mason]

Hi Bob

On Wednesday, June 30, 2021 at 1:06:12 AM UTC+10 fort...@gmail.com wrote:

Oops, in the Tool UI, I did see Host Options settings that appear to allow a workaround - set 'timeout for disconnected session' along with 'logoff sessions when time limits are reached'.  I have 2 questions on this

1) Does this setting take effect immediately or does it require a reboot or restart of Remote Desktop Services service?  Under Host Options it does mention 'some settings may require a reboot', but not which settings require the reboot.

If it's anything like making this change in the Remote Desktop Session Host Configuration (RDSHC), it'll take effect on a new session.  I can't say for sure, but that's the impression I get.

 

2) Does this affect other users who connect to the server with ordinary RDP sessions (not using the RemoteApp Tool RDP file).  Will their disconnected RDP sessions get logged off with these Host Options?

If it's anything like making the change in the RDSHC, yes, but see my previous caveat.

[Bob H]

I tried another cycle starting with the following:

- Log off user from orphaned (disconnected) RemoteApp session

- User runs RemoteApp, then exits RemoteApp

- Now for some randomness - user (RDP) session on server does NOT show as disconnected (before making the Host Option changes, it did show as 'disconnected'), now it remains as 'active', so those new RemoteApp Tool Host Option settings cause the user session to stay open and active when user exits RemoteApp

- other RDP user that had a disconnected session remains as 'disconnected'

- repeated above - same behavior

- restored Host Options to default (prior) settings (no boxes checked), now when user exits RemoteApp, it shows 'disconnected', as before

Conclusion:

- What you had stated regarding RDSHC appears to be true - changes seemed to take effect with new RDP/RemoteApp sessions.

- The Host Options settings I tried have completely random effects and can't be used.  Still looking for a way to ensure that user sessions get properly logged off when exiting RemoteApps since this is causing issues with users getting hung in the RemoteApps after re-launching the RemoteApp (with the prior session in a 'disconnected' state).

[B. Gale]

I think this blog post may help:

https://www.windows-security.org/4740ad8f47f0973820094a8a7fccb3be/set-time-limit-for-logoff-of-remoteapp-sessions

Basically, you can modify a registry setting (or through a GPO) so that remoteapp logoff timeout is shorter.

I ran into a similar problem on one of my terminal servers a few years back and fixed it by adjusting the timeout to 1 minute.

I do not believe this is a problem with the RemoteApp Tool, but is how Windows Server is configured to handling the timeout.

The reason for this setting is that the login process in windows is a slow operation.  When a remoteapp is being run instead of the full windows UI, it is a faster process, but it is still slow.  If a user is going to be running the remote app, closing it, and starting it up again, it is nice to have a faster startup time.  If the user is going to be starting it once per day, it may not make sense to leave it in a disconnected state.

[Bob H]

Unfortunately, that didn't work.  Now, when the user exits the RemoteApp, the RDP session is left in an 'active' state and after 1 minute (or several minutes), it remains in an active state. 

I made the policy change via gpme.msc.  This is a cloud server where the DC/server is the same computer (had to use AD to allow multiple RDP sessions and licensing to work properly).  I checked the registry and the change showed under HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services and the value name RemoteAppLogoffTimeLimit was set to DWORD 60000 (which I assume is 60 sec)

[Bob H]

One other thing - if the user signs out or reboots their own computer, then the RemoteApp state changes from 'active' to 'disconnected'.

[B. Gale]

I am honestly not sure what unit the RemoteAppLogoffTimeLimit is, so I am not sure if "60000" is 60 seconds or 60 hours.  My approach when I set this up on my system was to set the number to 0.  I did this on both my load balancer AND the servers hosting the remoteapp.

My reason being that when the end user closes the app, I want them to log off of the server immediately.  Logon times were fast enough that reusing the session had little benefit for me.

That being said, changing that setting should NOT have caused the RDP sessions to be stuck in an "active" state.  If it is in an active state, it means that the server didn't see the client disconnect (ie close the app) and it still has the RemoteApp running server side.  

I would verify that the end user closed ALL of the remote apps they opened.  What I mean is, if you start up Excel as a RemoteApp and use that to open a Word document, both Excel and Word will be running as remote apps and closing Excel will leave the session "active" as Word is still running.  I would look at the active sessions and make certain that all remote apps are closed which should put the session in a disconnected state.

Your next reply about the user signing out or rebooting the computer makes me suspect that they had more than 1 RemoteApp running.  A reboot/sign out would result in all open apps being closed and thus switch from active to disconnected.

Another thing to watch for is if the end user is running the remote app more than once.  I have seen some users think that since they need to double click to run it, if it doesn't pop up immediately, they will double click it again starting a second instance.  I've also seen users think that since they need to double click on their desktop, they need to double click on the task bar to start things.  Or press enter twice to start a highlighted application.

TL;DR - if the server says the session is "Active", it has an open connection between the server and the client so something is running between them.

[Bob H]

1) I'm guessing that 60000 is very likely 60 seconds.  There are many other registry settings that use milliseconds as DWORD values.  I will try setting the number to 0, but based on the other issues, it probably wouldn't make any difference.
2) I tested these scenarios myself, remotely connecting to the computer that launched the RemoteApp.  There is only 1 RemoteApp available to this user (CRM app called ACT). I've checked Task Manager on the server and under that user, no other apps get launched.  In Task Mgr/User tab, the Status column never shows anything unless session is 'disconnected' or session is at 'console'.  Active sessions show no status.

3) After I exited the only instance of the RemoteApp, the only remaining tasks are related to RDP (see attached screenshot).  Nothing there to prevent a proper logoff after the user exits the RemoteApp.

4) The user never had more than 1 RemoteApp running and that's confirmed by checking Task Mgr on the server.

[B. Gale]

To me, I see some things in there that look like they are likely configured incorrectly, but I am just guessing here.

What I expect is holding the session in an ACTIVE state in your case is the touchscreen and handwriting tools. I have never enabled those on a server before and rarely have them enabled on desktop workstations.  What I expect is happening is that something (ACT) is requesting that those applications start up and windows is being helpful by leaving them running after the application exits (ACT).  Since the server sees applications running that were started by the client and are NOT part of the RDP session/protocol, it assumes the session should remain active.

I would try disabling the handwriting and touchscreen tools on the server and see if that fixes it for you.  Alternately, try killing "CTF Loader" and both "Touch Keybaord and Hand..." for that user and see if they switch to a disconnected state.

If the session is not moving from "Active" to "Disconnected", SOMETHING on the server is keeping that session open and based on the screenshot, I expect it is the touch keyboard and handwriting tools...

[Bob H]

1) When the RemoteApp was launched, as server admin was able to go into Task Mgr and kill the Touchscreen/Handwriting Tools tasks, but can't kill the CTF Loader (ctfmon.exe) tasks - it immediately reloads.  After that, I then exited the RemoteApp and the session remains active.

2) I see a service called Touch Keyboard and Handwriting panel (named TabletInputService) and it's currently set as 'manual' and is running.  Option to stop service is grayed out and I even tried the following in an elevated command prompt (logged in as an administrator): net stop TabletInputService and sc stop TabletInputService and both failed (net stop failing with 'stop not valid for this service', sc failed with 'ControlService failed 1052').  This is a cloud (virtual) server, so perhaps there's no way to disable it.  There's no UI setting that I can find (on-screen keyboard is turned off).

3) On an ordinary Win10 PC, you can go into Task Mgr/Startup and disable ctfmon.exe from loading, but this is a cloud/virtual server.  I'm unable to locate ctfmon.exe anywhere when I tried a utility like Autoruns.  Also, I tried going into Task Scheduler, and under Microsoft -> Windows -> TextServicesFramework and disabling the task  MsCtfMonitor, but that had no effect.  The next time the RemoteApp was launched ctfmon.exe was running under that user.

[B. Gale]

I was re-thinking stuff about that screenshot and about what you had said previously and I am having second thoughts on that touchscreen stuff being the problem.  The reason being - your initial problem was that it was stuck in a "Disconnected" state when the application was closed.

Lets try to get back to that point as I am wondering if maybe some of the other changes you did are causing the session to be stuck in Active and we are chasing ghosts.

Can you revert all changes you did up and see if you can get it back to a disconnected state when the remote application is closed.

Once you get there, try to turn on that registry change, and I would set the DWORD value to 0 while doing your testing.  If it goes from active->disconnected->logging off pretty quickly (I found that even with it set to 0, it still takes a few seconds for Windows to process it), then you are good to go.

[Bob H]

I have reversed the 2 changes that I made (the GP change - changed it back to its original setting of 'not configured'), confirmed after gpupdate /force that the registry setting had been removed (the value name was removed).  Also reversed the Task Scheduler change.  Even restarted RDS service - no effect.  RemoteApp Tool Host Options settings had already been reverted to their original default (no boxes checked) back on 6/30.  User exits RemoteApp and RDP state remains active.  Changed registry setting alone (not via gpme.msc/gpedit.msc) to add back that value name RemoteAppLogoffTimeLimit set to DWORD 0 as you had suggested.  Restart RDS, no effect.

Thanks for your assistance with this, but it's looking hopeless at this point.  Too much randomness for me to comprehend and overcome.

[B. Gale]

I'm starting to feel the same way.

I know I set that up on my server ages ago and after setting the registry value, things just worked for me.  Your scenario seems a bit different though as I never had users getting "stuck" in an Active state.

As a thought, what about if you re-create the remoteapp from scratch?  I wonder if something is being written to the .rdp file OR on the server somewhere after changing the checkboxes that doesn't get reset by unchecking them (ie a bug)?

Another thought - do you have a second workstation and new to that server user to try this from?  Basically just thinking that maybe something got written to a user level registry and now all existing users have some flag in the registry set that may need to be manually un-set.  Probably grasping at straws, but trying to be helpful... 

[Bob H]

I used the RemoteApp Tool to create another RemoteApp 'copy' of the same RemoteApp (calling it ACT2), and created another RDP file for it.  Since all the GPOs related to RemoteApp timeouts had been set to their defaults (not configured), I set the host options that I had originally set (timeout to 10 sec, logoff sessions on timeouts) - I did this prior to creating the ACT2 RemoteApp (but it probably doesn't make a difference).

This time I simply ran the RDP file directly from my own workstation, with RemoteApp login set to the server admin account.  After closing the RemoteApp, it was properly logged out per the Host Options settings.  Now login to the RemoteApp as the previous user that had all these problems and it again fails to logoff (or even disconnect) the RDP session after quitting the RemoteApp.  Now realizing that it's probably due to user privilege on server, logged into RemoteApp as another non-admin user and the same result.

So the problem appears to be launching a RemoteApp as a non-admin user (or GPO/registry settings as you had described ) - settings for both fail with non-admin user but succeed with admin user.  What's the point of GPO and/or Host Options if they can't be used with a non-admin user?  I did notice that the non-admin user can't even launch task manager without getting an elevation prompt - don't know if that's related to the problem, but thought I'd mention it.  On ordinary Windows 10 workstations non-admin users can at least launch Task Manager without requiring elevation.

[B. Gale]

If I had to guess, I would say it is something setup on your server.

Since you can allow multiple people to connect to it, it is likely NOT a Windows 10 install, but a Windows Server 2019 install (not certain on the version, but it would likely be some version around 2019 which has a similar UI to Windows 10).  Windows 10 and Windows Server are completely different OS's.  For example, Windows 10 allows 1 user to be logged in at a time whereas Windows Server allows as many as you have licenses for.

Windows Server is not a desktop OS and as such, it limits a lot of things in it.  Task manager should be able to be run as a non-admin, but you will not be able to see the details such as performance or processes being run by other users.  This is by design as a non-admin should NOT be allowed to see processes being run by other users. Security by Obscurity!

Since it works with an admin user the way you expect, was that a user who had never used that server before?  If so, I have a potential fix - remove the non-admin user profiles from the server and have them try it again.  This will cause them to use the default profile including a fresh registry setup.  Alternately, create a new user on the server who is not an admin and ONLY log in through the remoteapp.  This would at least let you verify if it is an admin issue OR a user profile (likely registry) issue.

Or, to verify your admin theory, give the user you are testing it with admin permissions.

In my test cases with remoteapps, I was using a non-admin account through a load balancing server.  In this scenario, I tested with both a full admin, a partial admin, and a non-admin and in each case the session went to a disconnected state when the app was closed.  That being said, I was doing my work on Windows Server 2012 and Windows 7, as well as testing things out on a Linux box (not sure what version or distribution) and Android (Android 10).  I am not sure if Windows Server 2019 or Windows 10 changes how RemoteApps work behind the scenes that may be causing issues with non-admin users.  I am still leaning towards this being a user profile issue though (registry issue).

On a side note - since it sounds like you are running Windows Server (this is easy to verify by running the command "winver"), you don't really need to use RemoteAppTool and can use the native RemoteApp features of Windows Server.  The advantage to doing it natively is that it is supported by Microsoft and since you are already paying for the Server licenses, might as well get the support you are paying for.  RemoteAppTool is entirely community support and we have no real information about your system, its configuration, or any ability to go in and poke around on your system to give some advice.  And even if we did have the ability to go in and snoop, you really shouldn't trust a random guy on the internet like me.  Never know what harm I may do.  Now, having a Microsoft employee go in and investigate your set things up is going to be a LOT safer and will come with support.

[Bob H]

Thanks again for responding and suggesting ideas.  Hopefully, between your suggestions and what I'm trying, something will work.  :-)

1) It's a cloud server (AWS Lightsail) using Windows Server 2019 v1809.  I believe it's some sort of GPO setting that is preventing non-admin users from even launching Task Manager and other Windows apps without elevation and that's my best guess as to why the RemoteApp Tool (and even the GPO/registry settings you had suggested in an earlier post) is failing to logoff the RDP user.  Every non-admin user has the same limitation with Task Manager and even with other ordinary Windows apps like CCleaner (that also requires elevation, even though on WIndows 10, a non-admin can run CCleaner without elevation).  Also, I took a non-admin user and launched Foxit Reader (PDF) and while in Foxit Reader tried to change a user-level preference (change default handler for PDF) and got elevation prompt.  I'm able to go into Windows Settings/Apps and change the default PDF association without elevation prompt.  Even though I got the elevation prompt in Foxit Reader (and clicked 'no' to decline elevation), it still changed the default PDF handler (?!)
2) As I had stated in my last post, I tried it with 1 additional existing non-admin user with the same results as the original non-admin user.  Neither user experiences any issues with an ordinary RDP desktop session, so it's highly unlikely that it's a user profile issue.

3) I had previously tried to use the native RemoteApp feature of RDS, but it has considerable overhead, including forcing the use of IIS and requiring remote computers to join the domain (which causes nasty side effects for the remote user).  I had to set this server up as a DC to enable 'user CALs' for RDS.  This is why I tried to utilize this RemoteApp Tool to simply the process.

[B. Gale]

First, I think the reason that tools like CCleaner are asking for extra permissions on a Windows Server is that the changes it makes apply to ALL users on the system.  Since multiple users are logged in (or are able to log in), it makes complete sense to me that it would require elevation.  Same thing with Fixit Reader - you are changing a system level default hence you'd need to be an admin.  So to me, those elevation requests are expected and required.  Now on a desktop workstation, you can only have a single user logged in at any time, so there is little risk of hitting permission issues when changing defaults or cleaning stuff.  On that note, I haven't used CCleaner in YEARS on my systems and I would refrain from using it on a Server system as I don't trust those automated cleanup tools on a server environment.  They USUALLY are not designed or supported on a server environment and if it kills the server, you have no support to fix it.  On top of that, when the tools ARE supported on a server environment, it usually comes with a license that needs to be purchased.

On top of this, a server system has different permissions set on folders than a desktop workstation.  Due to this, it could be CCleaner is asking for permissions to a folder where elevated permissions are required on Server, but not on Desktop. 

With point number 2, you said that it was with "Existing" users, and I was saying to try with "new" users to that system.  The reason being that you could verify then if the default user profile has the appropriate settings.  If it does, a solution to this problem could be to blow out the user profiles and have them re-created from default.  As a random thought - are any of the users logged in to the server at the same time as trying to run the remote apps?  Having 2 sessions open at once may be causing some hiccups.  That is also another fun thing - if you RDP into the server AND start a remoteapp session, that will use 2 CALs, so you will need to watch your licenses.

As for it being a user profile issue, I still don't see how either of your examples rule that out.  The scenarios you have tested are:

existing non-admin user

existing admin user

Scenarios that were not tested:

new non-admin user

new admin user 

If an existing non-admin user has issues AND has a registry value set incorrectly in the HKCU section of the registry hive, that setting is going to persist no matter what you do UNLESS you change or remove the bad setting.  If the admin user doesn't have that setting set in the registry, it may be that things work as expected.

Now how that value got set, it may have been by accident, could be intentional, could be to fix a different bug, could be a bug that existed when the user first logged in (in the default user profile) that was corrected in a patch to server 2019, could be cosmic radiation flipping bits on the drive... Creating a new user would result in a fresh copy of the HKCU registry hive being copied from the default user profile which could result in the problem being "fixed".

Having no issues with regular RDP doesn't mean you have no issues with remote apps.  They are the same protocol, but different implementations.

With point number 3, the part that I find terrifying is that you have regular end users logging into a domain controller.  A domain controller should be a locked down system with very few people having access to it.  I would never let a regular end user log into a domain controller, but that is just me.  My work environment we have roughly 10 people in the company of over 500 that have permissions to log into the DC's and I am not one of them.  On top of that, I would not want additional tools (like an ERP system) being installed on a DC.  Auditors are likely also not going to approve that setup and are going to request that you change it.

As for setting up RemoteApps with the overhead of IIS, IIS is not actually required if I remember correctly. I was just double checking my setup and it is an option, but it isn't required.  It is only required if you need RD Web Access.

I set my system up with 3 servers - 1 load balancer and 2 application hosts.  None of them have IIS running right now.  I installed IIS as I thought I may want to do RD Web Access, but it is disabled as we haven't had a need for RD Web access.

I personally like having all of my computers on the same domain in the network as then I can access the computers by their friendly name rather than needing their FQDN to access them and worrying about odd firewall rules and/or VPN to access the servers.  I also like having an AD server for a centralized authentication protocol.

I do agree that RemoteAppTool is MUCH easier to configure and maintain than the Microsoft approach, but if I am paying for support on a tool, I would much rather use a supported method for a task.  That way I can reach out to the software provider and get a solution rather than reaching out to the community and crossing my fingers someone has run across this issue before.  

On top of this, if you set up a remote app server natively, you can have a lot more configuration options and restrictions and load balancing.  If you only have a single server for your ERP and it dies (ransomware for example), you are relying on the backups.  We had ransomware hit one of our servers and it sat idle for about 6 months before it encrypted everything that user had access to.  Restoring from a 6+ month old backup was unreasonable.  Our solution - shut off the VM and remove it.  We had at that time 6 servers set up with a load balancer, so having 1 go down was annoying, but we had 5 spares.

[Bob H]

Thanks again for your assistance.  A little background on this cloud server...it was originally a physical Windows 10 Pro workstation utilizing a patched version of Remote Desktop.  It was working fine with the CRM and Document Management apps with up to 12 users logged in via RDP.  I knew this was not sustainable based on a non-server limit of up to 20 simultaneous network connections, plus the the potential reliability problems of a physical server located in a less than ideal environment (but had great bandwidth, better than what I get).  Also, the number of users may increase beyond 20.  A Dynamic DNS service (dyn.com) was utilized to make the server address appear to be static (with a URL), so that made RDP connections and other server connections reliable.  Due to these issues, I converted to a cloud server (AWS Lightsail) utilizing Windows Server 2019.  No need for domain controllers as all users connect via RDP, but was forced into it to allow for user CALs (instead of device CALs, which would not work well with remote users likely to use different devices, making maintenance of device CALs difficult).  To properly separate DC from application servers would be a difficult and costly task (and would involve much higher monthly fees to AWS).  I regularly take 'snapshots' (as AWS calls system images)  and utilize online backups for essential data.

1) Thanks for explaining the need to create a new non-admin user.  That was the problem.  With a new non-admin user, the RemoteApp properly logged out after exiting the app.  I guess I will have to create a whole new profile for the RemoteApp user (fortunately, only 2 so far, the others are using standard RDP).  This new user was getting the same elevation prompts as the others, so that had nothing to do with the RemoteApp problem.  I can only guess that migrating parts of the user profile (from the old physical server to the cloud server), may have caused the problem (although no registry settings were migrated, just some %appdata% and user folders).  I will continue to try to recreate the remainder of this test user's profile to match the problem user's profile so that will hopefully will yield a clue as to what is causing the problem.

2) You make a really good point about ransomware - nowadays, they can stay dormant for days, even weeks and then suddenly strike.  I try to avoid using online backup solutions that hook into the Windows file API's (appear as folders in File Explorer).  Ransomware can easily find these and infect the online backup as well.

3) I'm sure you're correct about the native Windows Server RemoteApp and IIS - I didn't really pursue that aspect a lot, but I'm not sure about being able to avoid having remote user's computers join the domain.  I had tested this and it created a whole new user profile on the remote user's computer (based on domain membership).  A massive overkill for a remote user to have to switch profiles to simply run a RemoteApp.  If I couldn't get RemoteApp Tool to work, I probably would have had them use standard Remote Desktop to run the CRM app.