For instance I have a server that is used by 4 people and there is only one account in that server. We know that when someone is already accessing it and another user accessed the server, the current user will be disconnected.

Is there any way to identify if a server is currently accessed via Remote Desktop Connection to prevent unwanted interruption of the active user.


This applies to the following OS: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012and Windows VistaTry this command

query session [<SessionName> | <UserName> | <SessionID>] [/server:<ServerName>] [/mode] [/flow] [/connect] [/counter]

This should give output like the following;

C:\>query session
>console        Administrator1  0 active wdcon
 rdp-tcp#1      User1           1 active wdtshare
 rdp-tcp                        2 listen wdtshare
                                4 idle
                                5 idle


Hope this helps.

| improve this answer | |
  • Additionally this may also be of use: qwinsta /server_name:SERVERIP eg. qwinsta /server_name: – TheJulyPlot Aug 26 '15 at 7:52

EDIT: Regarding the netstat answer, however you'd run that you're definitively better off running qwinsta.

EDIT: qwinsta can be run on a remote server. I'd recommend that above PsLoggedOn for a few reasons.

You could use PsExec (from PsTools, it's something like psexec.exe \\remote -u remote_username -p remote_passwd cmd.exe to gain a remote shell and run quser or qwinsta to enumerate the active sessions. You need admin and I believe file sharing on (it uses the default C$/ADMIN$, which certain home instances don't have). It's a little more annoying on a workgroup environment.

I'm probably missing something simpler, like the fact that quser can be run on another server (might not fit this use case) or you could run quser directly instead of getting a shell first (you probably can) but I'll add that in once someone has either tested it or tells me in comments.

| improve this answer | |
  • As long as you're bringing up PsTools already, why not PsLoggedOn? It's designed for exactly this sort of situation. – Iszi Aug 26 '15 at 18:09
  • Also, qwinsta can be run against a remote computer as well without having to use PsExec. – Iszi Aug 26 '15 at 18:20
  • I'll edit both in. I was expecting something like that, I just don't like recommending without testing and I don't have the required environment in front of me @Iszi – Michael Bailey Aug 26 '15 at 18:28
  • Would be interesting to know your reasons against PsLoggedOn. It's been my preferred method for awhile, though I've never tried the QUERY tool myself. – Iszi Aug 26 '15 at 18:30
  • I'm curious as to how qwinsta works, but my guess is it isn't dependent on file sharing being up. – Michael Bailey Aug 27 '15 at 1:54

Windows Server platforms support multiple concurrent RDP sessions - usually, up to two - and will warn the user if they're trying to connect to a server that is already at its maximum. Therefore, the situation you describe could completely be averted by simply creating separate user accounts for each person - which is a security best practice to begin with.

Without individual user accounts, you'll of course run into resource sharing issues like this. But you'll also not be able to individually manage user permissions, nor will you be able to tell one person apart from another in event logs.

Even on a non-Server platform (e.g.: Windows 7, Windows 8.1, Windows 10, etc.), your scenario would not be a problem if you had individually-assigned user accounts. These platforms allow only one session to be active at a time. When an RDP user connects, and there's already an active session, one of three things will happen:

  • If the account used to connect is the same as the active session owner, the connection will be established. Pre-existing RDP connections for that user will be dropped. If the user's pre-existing session was on the local console, the console will be kicked out to the "lock screen".
  • If the account used to connect is not the same as the active session owner, and the account does not have Administrator permissions, the new session will be rejected. The user will be informed the system is already in use, and the connection will be terminated.
  • If the account used to connect is not the same as the active session owner, and the account does have Administrator permissions, the session still will not be immediately established. The user will be informed that the system is already in use, and they will be given the option of forcing the active user off the system so that they can log in. Depending on the system configuration, forcing the new session may result in the active user's session being disconnected/locked (but still available to be resumed later) or they may actually be logged off.

That said, here's some commentary on existing answers as well as my own suggestion:

TheJulyPlot and Michael Bailey are essentially suggesting the same thing. QWINSTA and QUSER are both shortcuts to the QUERY utility, for the SESSION and USER functions respectively. These can be run against a remote computer with the /computer: parameter, so they can be used to check the system before you actually connect yourself.

The suggestion by jas- is not, on its own, useful for you because it requires you to already be connected to the remote system and you're wanting to check on it before you do so. However, if you run it with PsExec (suggested by Michael Bailey), you could accomplish what you're looking to do. There's better ways to do what you need though, with built-in tools as well as the other utilities available from Microsoft.

If you already have the PsTools, I'd suggest trying PsLoggedOn instead of mucking about with PsExec and Netstat. PsLoggedOn can be run remotely, and shows both RDP sessions and remote file system or registry connections. Syntax to run PsLoggedOn remotely is:

PsLoggedOn \\servername

Additional useful resources:

Query User / Quser
Query Session / Qwinsta


| improve this answer | |

From a command prompt.

Note the TCP Local Address listening on port 3306 in the ESTABLISHED state to Foreign Address

C:\Users\foo>netstat -anp tcp

Active Connections

  Proto  Local Address          Foreign Address        State
  TCP                LISTENING
  TCP                LISTENING
  TCP                LISTENING
  TCP               LISTENING
  TCP              LISTENING
  TCP              LISTENING
| improve this answer | |
  • 1
    I'm pretty sure this doesn't answer the user's question - they seem to be concerned about checking the server remotely, so they don't try to log in and interrupt a user already connected. Netstat is only useful after you've logged in. – Iszi Aug 26 '15 at 18:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.