ここでの目的は、ログイン時にいくつかの環境変数 (時間、ユーザー名、コンピューター名など) を取得する、私が作成した簡単な .NET アプリケーションを起動することです。この .NET アプリケーションは、Windows の「ユーザー ログアウト」イベントをサブスクライブします。
起動時に、アプリケーションは上記の変数をキャプチャし、データベースにレコードを作成します。ログアウト時 (キャプチャしています) に、同じレコード内の別のフィールドをログアウト時刻で更新します。
上記はまさに私が望んだとおりに動作しています。バイナリを起動すると、最初のログエントリが作成され、ログアウトイベントを待機して同じレコードが更新されます。
制限事項: .NET バイナリは共有ポイント (\server\share\myapp\v1) 上に存在できる必要があるため、アプリケーションを (\server\share\myapp\v2) に更新し、GPO/ログオン スクリプトを更新するだけで済みます。
当初の考えは、\domaincontroller\sysvol\ ディレクトリを使用してバイナリを保存し、すべてのユーザー アカウントを更新してアプリケーションへの呼び出しを含めることでした。このアプローチに欠陥があると思いますか?
私の質問は次のとおりです。まず、上記の私のアイデアに何か問題はありますか? 次に、もしそうなら、サーバー上でセッションが開始されるたびにこのアプリケーションが起動するようにするための最善の方法 (グループ ポリシーなど) は何ですか?
答え1
セッションが開始されるたびに起動するには、グループ ポリシー ベースのログオン スクリプトを使用します。ただし、適用されるコンピュータ オブジェクト GPO で「ループバック処理」がオンになっている場合、ユーザー GPO で指定されたこのようなスクリプトは 2 回実行される可能性があるという注意点があります。結果として、このケースを処理するためにログオン スクリプトを変更する必要がありました。
私は .NET イベント サブスクリプションに詳しくないので、アプリケーション ファイルがセッション全体にわたって開いたままになるかどうかはわかりません。その場合、オープン ロックの問題により、アプリの更新は非常に困難になります。50 のステーションがログインしている場合、アプリには 50 の書き込み拒否ロックが適用され、アプリの更新が困難になります。これは、アプリを sysvol (実際には GPO 自体) に保持すると、そのケースをより適切に処理できるため、役立つ場合があります。
ただし、これは単にログアウト時に再起動するだけなので、共有したままにしておいても問題はありません。
答え2
sysvol から実行しても特に問題はありません。
また、GPO ログオン スクリプトを作成すると、デフォルトでまさにそのように実行され、スクリプトが確実に実行されるようになります。通常、ターミナル サーバーには複数の GPO があり、そのうちの 1 つがログオン スクリプトを実行し、グループ ポリシー ループバック処理モードを指定します。