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.
QUSER are both shortcuts to the
QUERY utility, for the
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:
Additional useful resources:
Query User / Quser
Query Session / Qwinsta