About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
A disconnected Remote Desktop session can keep running on the server. Signing out ends the session and its ordinary user applications. Locking protects access to the session without ending it. None of these actions automatically deletes a normal local user profile.
These distinctions matter when setting time limits for shared application hosts. A user closing the remote window may leave a report running, an unsaved document open and memory in use. A later policy-driven sign-out can end that work. Autosave may preserve some data, but it does not exempt a normal application process from session termination.
Identify the actual state
Microsoft's session troubleshooting guide distinguishes active, idle, locked and disconnected sessions. Idle means the user has not interacted for a period; it does not prove the application has finished a long-running job.
| Action or state | Session/application effect | What it does not establish |
|---|---|---|
| Lock | Session remains, with access requiring unlock | Work is saved or memory is released |
| Disconnect | Client connection ends; server session remains | The application has stopped or released a vendor licence |
| Sign-out/logoff | Session ends and normal user applications terminate | The local profile has been deleted or every application saved successfully |
| Profile cleanup | A separate, explicitly configured lifecycle process | A consequence of every sign-out |
A service or separately designed background job has its own lifetime, but an ordinary report process inside the user's session should not be treated as one. Ask the application vendor how unattended work is supported.
The time-limit policies answer different questions
The ADMX session-policy reference describes the named controls; use the corresponding settings supported on the deployed server.
Set time limit for active but idle Remote Desktop Services sessions limits inactivity. Set time limit for active Remote Desktop Services sessions limits the duration of an active session even if the user remains busy. These are duration controls, not a cumulative allowance of hours per calendar day.
By default, reaching an active or idle limit disconnects the session. End session when time limits are reached changes the action to ending the session. Microsoft distinguishes this policy from a network-caused disconnect; it applies to explicitly configured time limits.
Set time limit for disconnected sessions determines how long an already disconnected session can remain before it is ended. This is the control to examine when the objective is to release resources after users leave, but it also determines how much opportunity they have to reconnect and recover unsaved work.
The troubleshooting guide states that policy overrides collection defaults and computer policy takes precedence over user policy. Inspect effective settings before assuming a collection-level value is the one users experience. Gateway timeout settings can add another disconnection boundary for people who use that gateway.
Closing the last RemoteApp is not necessarily sign-out
Microsoft documents that RemoteApps launched from the same client can share a session. After all active application windows and user-launched notification-area icons close, the documented behaviour keeps the session active for another 20 seconds, then disconnects it if no new application starts.
Set time limit for logoff of RemoteApp sessions controls the later logoff delay. Where that delay conflicts with a general disconnected-session logoff limit, Microsoft's guidance says the shorter applicable limit wins. Test the deployed application and policy combination; the last visible window disappearing does not prove the server session ended.
Choose limits with the application owner
For mobile staff who briefly lose connectivity, allow a documented reconnection opportunity. For long reports, establish whether work belongs in a supported background-job facility rather than relying on an indefinitely open user session. For shared kiosks, use locking and sign-out to control access, then separately design and verify profile retention or cleanup.
Windows profile documentation explains that local profiles persist on the computer, whereas temporary and mandatory profiles have different behaviour. Do not promise privacy through profile deletion unless that separate design is actually in place and validated.
An isolated pilot should include an unsaved test document, a harmless long-running task, a brief disconnect and a fresh sign-in. Record warnings, application completion or termination, retained files and profile behaviour. Check vendor licence release separately; RDS session state alone does not define application licensing.
No session limits or profile changes were tested for this article. Warn staff that disconnecting is not saving and forced sign-out can lose unsaved work.
Related service: ThinPoint remote access.
This article was originally published on .