Цель здесь — запустить простое приложение .NET, написанное мной, которое захватывает некоторые переменные среды (время, имя пользователя, имя компьютера и т. д.) при входе в систему. Это приложение .NET подписывается на событие Windows «Выход пользователя».
При запуске приложение фиксирует указанные выше переменные и создает запись в моей базе данных. При выходе из системы (который я фиксирую) я обновляю другое поле в той же записи, указывая время выхода из системы.
Вышеприведенный код работает именно так, как мне и хотелось: когда я запускаю двоичный файл, он делает первоначальную запись в журнале, затем ждет события выхода из системы и обновляет ту же запись.
Ограничения: двоичный файл .NET должен иметь возможность размещаться в общей точке (\server\share\myapp\v1), чтобы я мог обновить приложение до (\server\share\myapp\v2) и просто обновить сценарий GPO/Logon.
Моя первоначальная мысль была использовать каталог \domaincontroller\sysvol\ для хранения двоичного файла, а затем обновить все учетные записи пользователей, чтобы включить вызов моего приложения. Видите ли вы какие-либо недостатки в этом подходе?
Мой вопрос таков: во-первых, есть ли что-то неправильное в моей идее выше? Во-вторых, если да, то какой лучший способ (через групповую политику или иным образом) обеспечить запуск этого приложения при каждом запуске сеанса на сервере?
решение1
Для запуска при каждом запуске сеанса подойдет сценарий входа на основе групповой политики. Единственное замечание, которое мы обнаружили, заключается в том, что такие сценарии, указанные в пользовательском GPO, по-видимому, выполняются ДВАЖДЫ, если для любых применяемых объектов GPO компьютера включена «обработка обратной связи». В результате нам пришлось изменить наши сценарии входа, чтобы обработать этот случай.
Я не знаком с подписками на события .NET, поэтому не знаю, означает ли это, что файл приложения остается открытым в течение всего сеанса. Если это так, то обновление приложения будет очень сложным из-за проблемы открытой блокировки. Если в систему вошли 50 станций, то приложение будет иметь 50 блокировок deny-write, и это усложнит обновление приложения. Это один из случаев, когда сохранение приложения в sysvol (в самом GPO, на самом деле) может помочь, поскольку оно лучше справляется с этим случаем.
Однако это означает, что он просто перезапускается при выходе из системы, и сохранение его в общем ресурсе должно быть в порядке.
решение2
Нет ничего страшного в запуске его из sysvol.
И создание сценария входа в систему gpo сделает именно это по умолчанию, а также обеспечит его запуск. Обычно терминальные серверы имеют несколько gpo, и один из них запустит ваш сценарий входа и укажет режим обработки циклической групповой политики.