A remote desktop session that drops after a fixed interval of inactivity is almost never a network fault. It is a policy \u2014 either a Group Policy timeout on the server, a session limit on a Remote Desktop Session Host, or a stateful firewall that forgets an idle TCP flow. Each cause leaves a different trace, and the fix is different for each.<\/p>\n\n\n\n
This walks through the diagnostics in the order that eliminates possibilities fastest, from the server-side policy that is easiest to check to the network layer that is hardest to prove. It assumes a standard Windows Server host rather than an RDS farm, though the same event IDs apply when our Windows VPS comparison table<\/a> is used to pick a session-capable instance.<\/p>\n\n\n\n The three outcomes look similar to a user and are configured separately. A disconnect<\/em> leaves the session alive on the server and reconnecting resumes it exactly. A lock<\/em> keeps the session connected but requires the password again. A logoff<\/em> destroys the session and any unsaved work with it. If users complain about lost work, you are dealing with a logoff, and the relevant settings are time limits rather than idle detection.<\/p>\n\n\n\n Values are in milliseconds. If the registry keys above exist under RDP sends periodic keep-alive traffic so stateful devices do not expire the flow. If the interval is longer than the idle timeout on a NAT device or load balancer in the path, the flow is silently dropped and the client sees a disconnect even though the server never timed out.<\/p>\n\n\n\n Confirm the direction of the fault by watching the server’s own event log for session disconnects at the moment the client drops. If the server logs a normal disconnect at the same timestamp, the server believes the client went away; if it logs nothing, the client lost the path. That single check splits policy problems from network problems reliably.<\/p>\n\n\n\n Two channels carry the evidence. Microsoft-Windows-TerminalServices-LocalSessionManager\/Operational<\/em> logs session creation, reconnection, and disconnection with the event IDs you need. Microsoft-Windows-TerminalServices-RemoteConnectionManager\/Operational<\/em> logs the connection attempts themselves.<\/p>\n\n\n\n Event ID 24 is a disconnect, 25 a reconnection, and 21 a successful logon. A pattern of 24 with no 25 means the client stopped reconnecting, which is usually a network path or a client-side sleep setting rather than a server policy. Event 39 and 40 relate to session logoff and removal, and they confirm whether a timeout ended the session for good.<\/p>\n\n\n\n An interactive administrator session benefits from generous idle limits because a human steps away. A shared RDS host with many users needs tighter limits to release resources, but the limit should be measured against real usage rather than copied from a hardening baseline. If a session must survive a laptop sleeping, lengthen the disconnected-session timeout and confirm the firewall does not expire the flow before the timeout fires.<\/p>\n\n\n\n Test the change with the actual client devices rather than a single workstation performance test. A setting that works on a wired desktop with a keep-alive every minute can still drop on a mobile hotspot that reassigns addresses between towers.<\/p>\n\n\n\n Work through that order and the drop-outs either stop or turn into a specific, fixable defect. Reviewing the settings in that sequence is faster than guessing, and it leaves a documented reason for whatever value you finally set. If the disconnects trace back to an undersized instance rather than a policy, see the full specs and pricing<\/a> to see which tiers support the concurrent session count you need.<\/p>\n","protected":false},"excerpt":{"rendered":"Separate disconnect from lock from logoff<\/h2>\n\n\n\n
# Per-session timeout policy on the local machine \/ RDS host\nGet-ItemProperty 'HKLM:\\SOFTWARE\\Policies\\Microsoft\\Windows NT\\Terminal Services' |\n Select-Object MaxIdleTime, MaxDisconnectionTime, MaxConnectionTime, fResetBroken<\/code><\/pre>\n\n\n\nMaxIdleTime<\/code> is the setting that produces the classic drop-after-twenty-minutes behaviour. A value of 0 means no limit; an absent property means the policy is not applied at all, which points you toward the Group Policy object instead of the local registry.<\/p>\n\n\n\nCheck Group Policy before editing the registry<\/h2>\n\n\n\n
SOFTWARE\\Policies<\/code>, something is enforcing them, and the local machine will overwrite your manual edits at the next policy refresh. Trace the setting to its source in the GPO that applies to the server, and change it there or link a policy with the intended value. Common culprits are an RDS session-collection policy template that was applied during setup and then forgotten.<\/p>\n\n\n\nRule out the keep-alive and the network path<\/h2>\n\n\n\n
# Inspect and shorten the keep-alive interval\nGet-ItemProperty 'HKLM:\\SYSTEM\\CurrentControlSet\\Control\\Terminal Server' |\n Select-Object KeepAliveEnable, KeepAliveInterval\n# Typical values: KeepAliveEnable = 1, KeepAliveInterval = 1 (minutes)<\/code><\/pre>\n\n\n\nRead the event log properly<\/h2>\n\n\n\n
Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-LocalSessionManager\/Operational' -MaxEvents 40 |\n Where-Object { $_.Id -in 21,22,23,24,25,39,40 } |\n Select-Object TimeCreated, Id, Message<\/code><\/pre>\n\n\n\nSet values that match how the server is used<\/h2>\n\n\n\n
A diagnostic order that converges<\/h2>\n\n\n\n