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