Назад | Перейти на главную страницу

Определите, доступен ли в настоящее время сервер через подключение к удаленному рабочему столу

Например, у меня есть сервер, которым пользуются 4 человека, и на нем есть только одна учетная запись. Мы знаем, что когда кто-то уже обращается к нему, а другой пользователь получил доступ к серверу, текущий пользователь будет отключен.

Есть ли способ определить, осуществляется ли в настоящее время доступ к серверу через подключение к удаленному рабочему столу, чтобы предотвратить нежелательное прерывание работы активного пользователя.

Это применимо к следующим ОС: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 и Windows Vista.

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

Это должно дать следующий результат:

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

Источник

Надеюсь это поможет.

РЕДАКТИРОВАТЬ: Что касается ответа netstat, однако вы бы сказали, что вам определенно лучше запустить qwinsta.

РЕДАКТИРОВАТЬ: qwinsta можно запустить на удаленном сервере. Я бы порекомендовал это выше PsLoggedOn по нескольким причинам.

Вы можете использовать PsExec (из PsИнструменты, это что-то вроде psexec.exe \\remote -u remote_username -p remote_passwd cmd.exe чтобы получить удаленную оболочку и запустить quser или qwinsta для перечисления активных сеансов. Вам нужен администратор, и я считаю, что общий доступ к файлам включен (он использует C $ / ADMIN $ по умолчанию, которого нет в некоторых домашних экземплярах). Это немного раздражает в среде рабочей группы.

Мне, вероятно, не хватает чего-то более простого, например, того факта, что quser можно запускать на другом сервере (может не соответствовать этому варианту использования), или вы могли бы запускать quser напрямую вместо того, чтобы сначала получать оболочку (вы, вероятно, можете), но я добавлю, что однажды кто-то либо протестировал это, либо сообщил мне в комментариях.

Платформы Windows Server поддерживают несколько одновременных сеансов RDP - обычно до двух - и будут предупреждать пользователя, если он пытается подключиться к серверу, который уже находится на максимальном уровне. Таким образом, описанную вами ситуацию можно полностью предотвратить, просто создав отдельные учетные записи пользователей для каждого человека, что является наилучшей практикой безопасности для начала.

Без отдельных учетных записей пользователей вы, конечно, столкнетесь с подобными проблемами совместного использования ресурсов. Но вы также не сможете индивидуально управлять разрешениями пользователей и не сможете отличать одного человека от другого в журналах событий.

Даже на не-серверной платформе (например: Windows 7, Windows 8.1, Windows 10 и т. Д.) Ваш сценарий не будет проблемой, если у вас будут индивидуально назначенные учетные записи пользователей. На этих платформах одновременно может быть активен только один сеанс. Когда пользователь RDP подключается и уже есть активный сеанс, произойдет одно из трех:

  • Если учетная запись, используемая для подключения, совпадает с учетной записью владельца активного сеанса, соединение будет установлено. Существующие ранее подключения RDP для этого пользователя будут отключены. Если ранее существовавший сеанс пользователя был на локальной консоли, консоль будет выведена на «экран блокировки».
  • Если учетная запись, используемая для подключения, не совпадает с учетной записью владельца активного сеанса, и счет не есть права администратора, новый сеанс будет отклонен. Пользователь будет проинформирован о том, что система уже используется, и соединение будет разорвано.
  • Если учетная запись, используемая для подключения, не совпадает с учетной записью владельца активного сеанса, и счет делает есть права администратора, сеанс по-прежнему не будет установлен сразу. Пользователь будет проинформирован о том, что система уже используется, и ему будет предоставлено вариант принудительного отключения активного пользователя от системы, чтобы он мог войти в систему. В зависимости от конфигурации системы принудительный запуск нового сеанса может привести к отключению / блокировке сеанса активного пользователя (но все еще доступному для возобновления позже), или они могут фактически быть не в сети.

Тем не менее, вот некоторые комментарии к существующим ответам, а также мое собственное предложение:

Июльский сюжет и Майкл Бейли по сути предполагают то же самое. QWINSTA и QUSER оба являются ярлыками к QUERY утилита для SESSION и USER функции соответственно. Их можно запустить на удаленном компьютере с /computer: параметр, поэтому их можно использовать для проверки системы перед тем, как вы подключитесь сами.

Предложение жас- Сам по себе не полезен для вас, потому что требует, чтобы вы уже были подключены к удаленной системе, и вы хотите проверить это перед тем, как это сделать. Однако, если вы запустите его с помощью PsExec (предложенного Майклом Бейли), вы сможете выполнить то, что хотите. Однако есть более эффективные способы сделать то, что вам нужно, с помощью встроенных инструментов, а также других утилит, доступных от Microsoft.

Если у вас уже есть PsTools, я бы посоветовал попробовать PsLoggedOn вместо того, чтобы возиться с PsExec и Netstat. PsLoggedOn может запускаться удаленно и показывает как сеансы RDP, так и подключения к удаленной файловой системе или реестру. Синтаксис для удаленного запуска PsLoggedOn:

PsLoggedOn \\servername

Дополнительные полезные ресурсы:

SS64
PsLoggedOn
Запрос пользователя / Quser
Сеанс запросов / Qwinsta
PsExec
Netstat

TechNet
PsИнструменты

Из командной строки.

Обратите внимание на локальный адрес TCP, прослушивающий порт 3306 в состоянии ESTABLISHED на внешний адрес 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