Identify if a server is currently accessed via Remote Desktop Connection

Question

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.

Answer 1

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

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

This should give output like the following:

C:\>query session
 SESSIONNAME    USERNAME       ID STATE  TYPE   DEVICE
>console        Administrator1  0 active wdcon
 rdp-tcp#1      User1           1 active wdtshare
 rdp-tcp                        2 listen wdtshare
                                4 idle
                                5 idle

Source

Hope this helps.

Answer 2

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.

Answer 3

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:

SS64
PsLoggedOn
Query User / Quser
Query Session / Qwinsta
PsExec
Netstat

TechNet
PsTools

Answer 4

From a command prompt.

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

C:\Users\foo>netstat -anp tcp

Active Connections

  Proto  Local Address          Foreign Address        State
  TCP    0.0.0.0:135            0.0.0.0:0              LISTENING
  TCP    0.0.0.0:445            0.0.0.0:0              LISTENING
  TCP    0.0.0.0:554            0.0.0.0:0              LISTENING
  TCP    0.0.0.0:3306           0.0.0.0:0              LISTENING
...
  TCP    10.0.0.248:3306        192.168.2.205:48156    ESTABLISHED 
...
  TCP    192.168.130.1:139      0.0.0.0:0              LISTENING
  TCP    192.168.233.1:139      0.0.0.0:0              LISTENING