GPOでアプリを自動起動する場合は、「Windows起動時」と「ユーザーのログオン時」を分けて選びます。画面を表示する業務アプリは通常、［Run these programs at user logon］、ユーザーログオンスクリプト、またはGroup Policy PreferencesのScheduled Taskで起動します。コンピューター起動スクリプトはサインイン前にSYSTEMとして動くため、対話画面を出すアプリには適しません。本記事ではWindows 10／11とWindows ServerのADドメイン環境を想定し、方式の選択、GPO設定、検証、停止までを安全な順序で説明します。
最初に「いつ・誰として」動かすか決める
- コンピューター起動：OS起動処理中、ユーザーのサインイン前にコンピューターアカウント／SYSTEMの文脈で動く。
- ユーザーログオン：対象ユーザーがサインインした後、そのユーザーのプロファイルと権限で動く。
- 一度だけ：インストール完了など一時処理。RunOnceや一度だけのScheduled Taskを目的に応じて使う。
- 遅延・条件付き：ネットワーク接続後、一定時間後、特定イベント時などScheduled Taskが向く。
- 常駐サービス：UIを必要としない継続処理は、GPO起動アプリではなく正規のWindowsサービスとして製品設計する。
利用者に見える通知ツール、チャット補助、業務ランチャーをコンピューター起動へ登録しても、対話デスクトップへ表示されないことがあります。反対に、端末全体の初期化をユーザーログオンへ置くと、利用者権限では失敗します。アプリの提供元が指定する起動方式、必要権限、複数起動時の動作を最初に確認します。
方式を比較して選ぶ
単純に実行ファイルを毎回開くなら［Run these programs at user logon］が分かりやすい方法です。複数処理、ログ、終了コード、条件分岐が必要ならログオンスクリプト、遅延や再試行、電源条件が必要ならGPP Scheduled Tasksを検討します。RunレジストリをGPPで配布する方法もありますが、実行順序や実行時刻が保証されない点を理解します。
- Run these programs at user logon：短い固定コマンド向け。対象ユーザーまたは対象端末の全ユーザーを選べる。
- Logon script：複数の確認とログを実装できるが、遅延、署名、共有到達性を設計する必要がある。
- Startup script：端末初期化向け。SYSTEMで動き、ユーザーの画面やドライブマッピングを使えない。
- GPP Scheduled Task：トリガー、遅延、実行主体、条件、履歴を設定できる。
- Run／RunOnce：Windowsの標準ログオン起動点だが、順序は不定で、RunOnceは継続運用に使わない。
作業前の確認項目
- 実行ファイル：対象端末の同じパスに存在し、署名・ハッシュ・製品版を確認できる。
- 引数：利用者データ、秘密、特殊文字を含まず、提供元の公式仕様どおりである。
- 実行主体：標準ユーザー、管理者、SYSTEMのどれが必要かを確認する。
- 多重起動：同じアプリが既に動作している場合に安全に終了または再利用できる。
- ネットワーク：オフライン、VPN接続前、低速回線でもログオンを妨げない。
- 停止：GPO解除後にプロセスを止めるか、次回ログオンから起動させないだけかを決める。
実行ファイルをSYSVOLや誰でも書き込める共有へ置き、そこから高権限で実行してはいけません。一般利用者が内容を書き換えられるスクリプトをSYSTEMで動かすと権限昇格につながります。配布はソフトウェア管理基盤で行い、スクリプトは署名、読み取り専用ACL、版管理、変更承認を用意します。
検証用GPOを準備する
- Group Policy Managementを開き、テストユーザーとテスト端末だけの検証OUを確認します。
- 用途が分かる新しいGPOを作成し、検証OUへリンクします。
- セキュリティフィルターで対象を限定し、既存のログオン／起動GPOとの競合を確認します。
- GPOの説明へアプリ名、実行タイミング、担当、開始日、停止条件を記録します。
- 本番OUへ直接リンクせず、再起動やサインインを繰り返せるテスト端末で試します。
コンピューター設定はOS起動時、ユーザー設定はサインイン時に前景処理されます。複数GPOがリンクされている場合、リンク順序、継承、Enforced、Block Inheritanceなどで結果が変わります。自動起動設定だけを見ず、対象端末のgpresultで実際の適用GPOを確認します。
ユーザーごとにログオン時起動を設定する
- GPOを編集し、［User Configuration］、［Policies］、［Administrative Templates］、［System］を開きます。
- ［Run these programs at user logon］を開き、［Enabled］を選びます。
- ［Show］を開き、承認済み実行ファイルの完全パスと必要最小限の引数を入力します。
- 空白を含むパスの引用符と引数形式を製品仕様に合わせ、テスト端末で確認します。
- GPOを保存し、テストユーザーが次にサインインしたときの動作を確認します。
このユーザー構成は、対象ユーザーがどの適用端末へサインインしても起動させたい場合に向きます。ただし、その端末に実行ファイルがなければ何も起動せず、エラーが目立たない場合があります。ソフトウェア配布の検出条件とGPO対象をそろえ、未インストール端末を含めません。
特定端末の全ユーザーで起動する
Microsoftの公式手順では、［Computer Configuration］、［Administrative Templates］、［System］、［Logon］、［Run these programs at user logon］を使うと、対象コンピューターへサインインするユーザーにプログラムを起動できます。共有端末、受付端末、教室端末など、ユーザーではなく端末役割で対象を決める場合に使います。
この設定はコンピューター構成にありますが、プログラムが動くのはユーザーのログオン時です。「Windowsサービス起動直後にSYSTEMとして動く」設定ではありません。管理者、保守ユーザー、キオスクアカウントにも起動する可能性があるため、端末にサインインする全アカウントを確認します。必要ならGPPの項目レベルターゲットなど別方式で条件を限定します。
ログオンスクリプトを使う場合
ユーザー構成の［Windows Settings］、［Scripts (Logon/Logoff)］へログオンスクリプトを登録できます。アプリの存在確認、既に起動済みかの確認、ログ記録などを実装できます。ただしスクリプトが長時間待機するとログオン体験を悪化させます。アプリ本体を同期的に待ち続けず、短時間で終了する設計にします。
Windowsではログオンスクリプトに既定の遅延が生じる構成があります。Microsoftは［Configure Logon Script Delay］で遅延を制御できると説明していますが、速度向上の意図で導入された設定です。アプリを早く開くためだけに全社で遅延を無効化せず、対象GPOと端末性能を限定してログオン時間を測ります。
コンピューター起動スクリプトを使う場合
端末初期化などは［Computer Configuration］、［Policies］、［Windows Settings］、［Scripts (Startup/Shutdown)］のStartupへ登録します。個別ユーザーがまだいない段階で動き、通常はLocal Systemとして実行されます。ユーザーのデスクトップへウィンドウを表示する用途には使いません。
- ユーザーの%USERPROFILE%、HKCU、ネットワークドライブを前提にしない。
- 共有へ接続するなら、ユーザーではなくコンピューターアカウントの権限を確認する。
- ネットワークがまだ利用できない場合のタイムアウトと再試行を設計する。
- 終了コードとイベントログを残し、毎回同じ処理をしても安全な冪等性を持たせる。
- 長時間処理でOS起動を止めず、必要ならScheduled Taskや管理エージェントへ分離する。
Group Policyのスクリプト拡張は背景更新でポリシー情報を処理しますが、個々のStartup／Shutdown／Logon／Logoffスクリプトが動くのは各イベント時です。gpupdateを実行しただけでログオンスクリプトが画面へ出るとは限りません。検証では実際にサインアウト／サインインまたは再起動します。
GPP Scheduled Tasksを使う場合
Group Policy PreferencesはScheduled Tasksを作成・変更・削除できます。ログオンから30秒後、ネットワーク利用可能時、毎日、特定ユーザーなど条件が必要なときに向きます。Task Schedulerのトリガー、Action、Conditions、Settings、実行ユーザーを明示し、パスワード保存が必要な構成を避けます。
ユーザーに画面を見せるアプリは［Run only when user is logged on］に相当する対話実行が必要です。［Run whether user is logged on or not］やSYSTEMで登録すると、バックグラウンドでは動いても画面が見えません。最高権限実行を安易に選ばず、標準ユーザーで動くようアプリを設計します。GPP項目には［Remove this item when it is no longer applied］など解除動作を検討し、検証します。
Run／RunOnceを使う場合の注意
WindowsのRunキーはユーザーがログオンするたびに、RunOnceは原則1回だけプログラムを起動します。HKCUとHKLMにそれぞれRun／RunOnceがあります。Microsoftは同じキー内に複数項目がある場合の実行順を保証せず、RunとStartup groupのプログラムが利用体験のため遅延する場合があると説明しています。厳密な順序や期限が必要ならScheduled Taskまたはサービスを使います。
RunOnceはセットアップ完了のような一時処理向けで、アプリが自分自身を繰り返し登録し続けてはいけません。またHKLMのRunOnceは再起動後にAdministratorsグループのメンバーがログオンした場合に実行される条件があります。単に「次の誰かのログオン」と考えず、公式仕様を確認します。GPP Registryで配布する場合も、直接レジストリを手編集せず、削除時の挙動をテストします。
適用結果を確認する
- テストユーザーと端末でgpresultを取得し、目的のGPOが適用されたことを確認します。
- サインアウト／サインインまたは再起動を行い、想定タイミングを計測します。
- 標準ユーザーで起動し、管理者確認やUACが出ないことを確認します。
- アプリのプロセス、ログ、イベント、Scheduled Task履歴を確認します。
- オフライン、VPN未接続、共有到達不可、アプリ未導入の各状態でログオンを妨げないか試します。
- 2回目以降のログオンで多重起動やRunOnce再作成が起きないか確認します。
起動しないときは、GPOの未適用、実行パス、引用符、ファイルACL、実行主体、アプリのビット数、依存DLL、ログオンスクリプト遅延の順に切り分けます。手動で管理者として実行できることは、標準ユーザーの自動起動が正しい証明にはなりません。同じアカウントと同じ作業ディレクトリで試します。
停止・変更・ロールバック
自動起動を止める変更と、現在動作中のプロセスを終了する変更は分けます。GPOを無効化しても、既に動いているアプリは終了しないのが通常です。強制終了は未保存データを失うため、利用者へ終了を促し、次回ログオンから起動させない段階を先に実施します。
GPPのRegistryやScheduled Taskは、GPOリンクを外しただけでは端末側の項目が残る設計になることがあります。作成時に削除動作を設計し、明示的なDelete項目または旧設定へ戻すGPOを検証します。スクリプトファイルを先に削除すると、端末が存在しない共有を待ってログオンが遅くなるため、GPO解除の反映後に配布物を片付けます。
導入完了チェックリスト
- Windows起動とユーザーログオンのどちらが要件か確認した。
- 実行主体、対話UI、必要権限、ネットワーク依存を確認した。
- 検証OUへ新しいGPOを作り、対象ユーザー／端末を限定した。
- 実行ファイルとスクリプトの格納先を一般利用者の書き込みから保護した。
- オフライン、VPN、低速端末、2回目ログオン、多重起動をテストした。
- gpresult、イベント、Task履歴、アプリログで実行結果を確認した。
- 自動起動停止、現在プロセス終了、端末側項目削除を分けて戻し方を用意した。
自動起動の成否は、プログラムが一度開いたかだけでは判断できません。正しい主体で、適切なタイミングに、ログオンを妨げず、オフラインでも安全に失敗し、解除後に残骸がないことまで確認します。画面を出すアプリはユーザーログオン、端末初期化はStartup、条件付き処理はScheduled Taskという基準から、最小の仕組みを選んでください。
コメント