As plataformas Windows Server suportam várias sessões RDP simultâneas - geralmente, até duas - e avisam o usuário se ele está tentando se conectar a um servidor que já está no seu máximo. Portanto, a situação que você descreve poderia ser completamente evitada simplesmente criando contas de usuário separadas para cada pessoa - que é uma prática recomendada de segurança para começar.
Sem contas de usuários individuais, você certamente encontrará problemas de compartilhamento de recursos como este. Mas você também não poderá gerenciar individualmente permissões de usuários, nem será capaz de distinguir uma pessoa de outra em logs de eventos.
Mesmo em uma plataforma que não seja do servidor (por exemplo, Windows 7, Windows 8.1, Windows 10 etc.), seu cenário não seria um problema se você tivesse contas de usuário atribuídas individualmente. Essas plataformas permitem que apenas uma sessão esteja ativa por vez. Quando um usuário do RDP se conecta e já existe uma sessão ativa, uma das três coisas acontecerá:
- Se a conta usada para se conectar for a mesma do proprietário da sessão ativa, a conexão será estabelecida. Conexões RDP pré-existentes para esse usuário serão descartadas. Se a sessão pré-existente do usuário estiver no console local, o console será expulso para a "tela de bloqueio".
- Se a conta usada para conectar não for a mesma que o proprietário da sessão ativa, e a conta não tem permissões de Administrador, a nova sessão será rejeitada. O usuário será informado de que o sistema já está em uso e a conexão será encerrada.
- Se a conta usada para se conectar não for igual ao proprietário da sessão ativa, e a conta tem permissões de Administrador, a sessão ainda não será estabelecida imediatamente. O usuário será informado de que o sistema já está em uso e receberão a opção de forçar o usuário ativo a sair do sistema para que ele possa efetuar login. Dependendo da configuração do sistema, forçar o Uma nova sessão pode fazer com que a sessão do usuário ativo seja desconectada / bloqueada (mas ainda disponível para ser retomada posteriormente) ou, na verdade, pode ser desconectada.
Dito isso, aqui estão alguns comentários sobre as respostas existentes, bem como minha própria sugestão:
TheJulyPlot e Michael Bailey está essencialmente sugerindo a mesma coisa. QWINSTA e QUSER são atalhos para o utilitário QUERY , para as funções SESSION e USER , respectivamente. Eles podem ser executados em um computador remoto com o parâmetro /computer: , para que possam ser usados para verificar o sistema antes de você realmente se conectar.
A sugestão de jas- não é, por si só, útil para você porque exige que você já estar conectado ao sistema remoto e você está querendo verificá-lo antes de fazer isso. No entanto, se você executá-lo com o PsExec (sugerido por Michael Bailey), você poderá realizar o que deseja fazer. No entanto, existem maneiras melhores de fazer o que você precisa, com ferramentas incorporadas, assim como os outros utilitários disponíveis da Microsoft.
Se você já tem o PsTools, sugiro experimentar o PsLoggedOn em vez de usar o PsExec e o Netstat. O PsLoggedOn pode ser executado remotamente e mostra as sessões do RDP e o sistema de arquivos remoto ou as conexões de registro. A sintaxe para executar o PsLoggedOn remotamente é:
PsLoggedOn \servername
Recursos úteis adicionais:
SS64
PsLoggedOn
Query User / Quser
Sessão de consulta / Qwinsta
PsExec - Netstat
TechNet em PsTools