Некий кросс-постинг моего комментария на общеизвестном форуме.

1. Имеется сервер терминалов, где пользователи не ограниченны одним удаленным сеансом, а именно не применена настройка сервера узла удаленных рабочих столов «Ограничить пользователя единственным сеансом» («Ограничить всех пользователей одиночными сеансами», «Restrict each user to a single session»).

2. Отключить эту настройку нет возможности по разным причинам. Например, сотрудники, использующие этот RDP-сервер, открывают несколько удаленных сеансов, с единственной запущенной в нем программой (прописанной при запуске mstsc-клиента), тем самым создавая несколько rdp-сессий на сервере, или открывают несколько полноценных рабочих столов (и такое бывает, да). Особенно это актуально в том случае, когда на клиентских ПК стоит linux.

3. Есть группа сотрудников, которые работают только с одним rdp-сеансом, например, через RemoteApp.

4. Проблема в том, что при неожиданном обрыве связи RemoteApp с сервером удаленных рабочих столов на нем продолжает работать сеанс пользователя, при этом помеченный как активный. При этом настройка пользователя «Завершение отключенного сеанса» («End a disconnected session»), которая должна завершить сеанс через некоторое время — не имеет смысла, т.к. сеанс остается якобы активным на сервере. Внезапно недоступный, но открытый на сервере сеанс может порождать разного рода проблемы, особенно при работе с базами данных. Будь-то захваченная лицензия продукта (например, 1С), будь-то захваченная таблица в БД, открытый файл и так далее.

Итак, идея состоит в том, чтобы при входе определенных пользователей стартовал скрипт, который разлогинивал бы всех одноименных пользователей кроме, конечно же, того сеанса, который пытается зайти последним. Например, на сервере «завис» пользователь user01, и он же пытается войти повторно. Необходимо, чтобы при входе этого пользователя user01 скрипт выполнял logoff всех user01, кроме своей сессии.

Долгие поиски в интернете, в том числе и по забугорному его сегменту ничего не дали, поэтому пришлось на коленке сваять такой скрипт:

@echo off
for /f "tokens=4 delims= " %%G in ('tasklist /FI "IMAGENAME eq tasklist.exe" /NH') do (SET RDP_SESSION=%%G)
for /f "skip=1 tokens=2" %%G in ('query user "%username%"^|findstr /v ">"') do (IF NOT %%G == %RDP_SESSION% (logoff %%G))

Первый цикл получает ID текущей сессии на сервере приложений. Второй делает выборку всех ID пользователей с таким же именем как и у текущего (из-под которого производится запуск данного скрипта) и сразу производит выход из системы всем пользователям с ID отличающемся от текущего. Особенность в том, что данный скрипт отрабатывает под ограниченными правами.

Далее нам необходимо прописать этот скрипт в автозапуск пользователю. Тут варианта два, либо у нас поднят домен (что маловероятно на такого рода малых серверах), либо нет.

Если домен не поднят, а пользователь заходит через обычный rdp-клиент, с прописанным на запуск приложением, то достаточно всего-лишь добавить строковый параметр в ветку реестра [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run] с указанием пути к нашему скрипту. Чтобы скрипт не запускался из-под всех подряд пользователей достаточно предоставить доступ к этому файлу на запуск лишь определенной группе пользователей. Администраторам же можно выставить дополнительное правило с запретом на запуск, которое имеет более высокий приоритет (костыль, да).

Но, как правило этот скрипт нужно запускать как раз для пользователей, работающих через RemoteApp, и тут не все так просто. Дело в том, что оболочка рабочего стола у нас не загружается в принципе и вышеуказанная ветка не отрабатывает вовсе. Тут приходят на помощь групповые политики. А именно скрипты автозапуска. Для этого необходимо:

а) запустить mmc;

б) добавить оснастку «Редактор объектов групповой политики» (Group Policy Object Editor)

в) далее в настройках оснастки либо выбираем каждого пользователя по отдельности и добавляем bat-файл в скрипты входа в систему, либо выбираем группу «Не администраторы» и так же добавляем в скрипты входа в систему, но ограничиваем доступ к скрипту на уровне файловой системы (прописывая доступ только определенной группе пользователей, а группе «Администраторы» добавляя доп. правило на запрет запуска файла) тот же костыль, да.

Если все-таки у нас поднят контроллер доменов, то не нужно городить костыли с доступом на уровне файловой системы, достаточно применить практики из этой статьи про Group Policy Security Filtering.

Те же самые действия можно применить, если RemoteApp не используется, но есть контроллер домена.

Обязательное чтиво к прочтению про скрипты автозагрузки, которые отрабатывают даже в случае использования RemoteApp: https://technet.microsoft.com/en-us/library/cc731758.aspx

Итак имеем некого рода костыль, который тем не менее закрывает целую массу бесполезных звонков от пользователей о том, что их сеанс завис и они не могут получить лицензнию/доступ к таблице/доступ к файлу/etc.