Field note: the remote desktop user who kept getting kicked off

A remote user connected to her office desktop over VPN and remote desktop kept getting dropped, several times a day. Everyone, including me, assumed the VPN was the problem.

Chasing the network first

My first round of fixes was network-focused: VPN tunnel MTU and fragmentation, forcing remote desktop to use TCP only, and keepalive settings. When I realized the target was an ordinary office desktop rather than a server, I also checked power management and network adapter power saving, which can drop a connection on a workstation that thinks it’s idle.

None of it fixed the problem.

The log that changed everything

On the desktop, the TerminalServices-LocalSessionManager event log showed a pattern of disconnect and reconnect events (IDs 24, 40, and 25). Event 40 includes a reason code explaining why the session disconnected.

The code was 5, which means the session was disconnected because another connection replaced it. In other words, the network wasn’t dropping her. Something else was logging in to the same desktop and taking over her session.

Finding who

Two ways to see who’s connecting:

• Live: the Users tab in Task Manager, or qwinsta /server:COMPUTERNAME from another machine, shows current sessions.
• After the fact: the Security log records remote desktop logons as logon type 10, including the source computer and address. Matching those against the times she got kicked off identifies the competing connection.

What I took away from it

• Read the disconnect reason code before tuning the network. It can save hours.
• “Getting kicked off” isn’t always the connection. Another user, a scheduled task, or a second device of the same user’s can take over a session.
• The Security log (logon type 10) is the paper trail for who connected, when, and from where.