MECM（旧 SCCM）のOS 展開（OSD）タスク シーケンス中に「gpupdate が効かない」「GPO がブロックされる」といった話を見かけます。本記事では“何が起きているのか”を公式情報の読み解きに沿って整理し、OSD 中に同等設定を安全に入れる現実的な設計・手順まで落とし込みます。
結論：OSD タスク シーケンスが GPO を「ブロック」しているわけではない
まず結論から整理します。新規 OS を入れるタイプの OSD では、タスク シーケンスが GPO（グループ ポリシー）や gpupdate を意図的に「禁止／ブロック」している、というよりも「Windows セットアップの完了（セットアップが終わるまでの段階）では、通常の GPO 処理が走りにくい状態になりやすい」というのが本質です。
その結果として、体感的には「タスク シーケンスが終わるまで GPO が反映されない（ように見える）」になり、そこから“ブロック説”が生まれやすい、という構図です。
- 新規 OSD：Windows セットアップの流れにタスク シーケンスが乗るため、GPO は「通常どおりのタイミング」で走りにくい
- ただし「完全に遮断」ではない：条件や操作によって評価が走る可能性はある（例：特定の処理が評価をトリガー）
- 混同注意：OSD 中は「ConfigMgr クライアントのサイト ポリシー処理」が別の理由で止まる（プロビジョニング モード）。GPO と別物
なぜ「OSD 中は GPO が当たらない」に見えるのか
理解の近道は、OSD の中でも「新規 OS を入れる OSD は、Windows セットアップ（Windows Setup）の中でタスク シーケンスが継続する」という点を押さえることです。ConfigMgr のドキュメントには、OSD の中核ステップである Setup Windows and ConfigMgr の挙動として、セットアップ完了時に SetupComplete.cmd 経由でタスク シーケンスが再開され、結果としてタスク シーケンスが Windows セットアップの“内側”で動く旨が説明されています。
| フェーズ | 環境の実態 | GPO が「動かない」に見える主因 | 現場での注意点 |
|---|---|---|---|
| WinPE 区間 | Windows PE（最小環境）で TS 実行 | OS 本体のグループ ポリシー基盤（通常のサービス／CSE）前提ではない | この区間で gpupdate を当てにしない（実装しても“期待どおり”になりにくい） |
| 新規 OS 起動～セットアップ完了まで | Windows Setup が進行し、SetupComplete で TS が継続 | Windows セットアップ完了まで GPO 処理が通常どおり走らない前提になりやすい | 「GPO を待つ」より TS 内で直接設定する設計が安定 |
| TS 完了後（通常起動） | 通常の Windows 起動・ログオンが可能 | スタートアップ／ログオンなど通常トリガーで GPO が処理される | ここでようやく“いつもの GPO”として動きやすい |
SetupComplete.cmd が鍵：ドメイン参加していても「その場で GPO が来ない」理由
Windows の SetupComplete.cmd の公式説明では、インストール中にドメイン参加する場合でも、SetupComplete.cmd が終わるまでドメインの GPO は適用されない旨が示されています。これは「スクリプトと GPO の構成が干渉しないようにする」ための設計として説明されています。
そして ConfigMgr の OSD は、まさにその SetupComplete.cmd を使ってタスク シーケンスを継続させます。よって、“ドメインに参加しているのに GPO が来ない”ように見える現象が自然に起こり得ます。
さらに SetupComplete.cmd の注意点として、スクリプト中の強制再起動は推奨されず、状態を悪化させる趣旨も示されています。OSD 内で再起動が必要なら、スクリプトで shutdown を叩くのではなく、タスク シーケンスの Restart Computer（標準ステップ）側で制御するのが安全です。
「gpupdate がブロックされる」の正体：よくある症状パターン
“ブロックされている”と言われがちな場面は、だいたい次のどれかに収束します。
| よくある症状 | ありがちな原因 | 確認ポイント | 実務的な対処 |
|---|---|---|---|
| TS 中に gpupdate を実行すると「止まったように見える」 | 既定で gpupdate は処理完了待ちをする／GPO 処理が長い／前提条件が揃っていない | 実行したコマンドライン、ログ、待機時間 | 依存がないなら /wait:0 を検討（待たずに返す） |
| ドメイン参加済みのはずなのに GPO が来ない | SetupComplete 実行中はドメイン GPO の適用が遅延される設計 | OSD が新規インストール型か、SetupComplete 区間か | GPO を待たず TS で設定投入。TS 完了後に通常サイクルへ |
| GPO の「ユーザー設定」が反映されない | TS 実行中はユーザー ログオンが無い／SYSTEM 文脈 | ユーザーがログオンしているか | ユーザー系は初回ログオン後に反映させる設計へ（または別手段） |
| “何かの拍子に”評価だけは走る | 特定ステップやスクリプトが評価をトリガーすることがある | どのステップの後に挙動が変わるか | 偶発性に頼らず、必要設定は TS 内で明示的に適用 |
gpupdate を入れるなら「待つ・待たない」を明確化する
gpupdate は待機秒数を指定できます。既定は 600 秒で、0 を指定すると待たずに返す仕様が明記されています。タスク シーケンスを「待ち」で詰まらせたくない場合、まずここを押さえるのが定番です。
gpupdate /target:computer /force /wait:0ただし、“待たない”は「即時に反映されたこと」を保証しません。後続ステップが「GPO 反映済み」を前提にしているなら、そもそも設計が不安定になりやすい点は注意してください。
公式ドキュメントから読み解ける「根拠」まとめ
「本当にブロックなのか？」を判断するには、“ConfigMgr の OSD が Windows セットアップと SetupComplete をどう使っているか”と、“SetupComplete 中の GPO の扱い”を公式文書で押さえるのが最短です。
| 公式資料 | 要点（意訳） | この記事の結論へのつながり |
|---|---|---|
| ConfigMgr: Task sequence steps（Setup Windows and ConfigMgr） | OSD は Windows PE から新 OS に遷移し、セットアップ終盤で SetupComplete 経由で TS を再開する。TS は Windows セットアップの中で動くため、通常の GPO は TS 完了まで処理されにくい。ただし OS/TS が GPO を“遮断”しているわけではなく、特定の処理が評価を起こすことはある。 | 「ブロック」ではなく「セットアップの都合で通常処理が走りにくい」が整理として正しい |
| Windows Setup: SetupComplete.cmd | インストール中にドメイン参加する場合でも、SetupComplete が終わるまでドメイン GPO は適用されない（干渉回避のため）。 | OSD が SetupComplete を使って TS 継続するため、「TS 中に GPO が来ない」が起きやすい |
| Windows: Group Policy processing | コンピューター ポリシーは起動時、ユーザー ポリシーはログオン時が主要トリガー。背景更新もあるが、拡張機能によってタイミングは異なる。 | TS 中に“ユーザー系が来ない”“起動・ログオンが無いので期待どおりにならない”を説明できる |
| ConfigMgr: Provisioning mode | OSD（インプレース アップグレード含む）では ConfigMgr クライアントがプロビジョニング モードになり、サイトからのポリシー処理をしない。 | 「ポリシーが来ない」を GPO と混同しないための重要ポイント（これは ConfigMgr 側の話） |
| Windows: gpupdate コマンド | /wait の既定は 600 秒。0 なら待たない。-1 なら無期限に待つ。 | gpupdate を TS に組み込んだとき「止まった」に見える理由を説明できる |
OSD 中に“同等の設定”を入れたいなら：GPO を待たず TS 内で完結させる
実務的に安定させるコツはシンプルです。「OSD 中に反映されてほしい設定」は GPO に期待せず、タスク シーケンスの中で直接入れる。GPO は TS 完了後の“最終的な整合”として動けば十分、という割り切りです。
とくに次のような設定は、GPO（または GPP）で配りがちですが、OSD 中に必要なら TS での投入が堅いです。
| やりたいこと（GPOでやりがち） | TS での置き換え案 | ポイント |
|---|---|---|
| レジストリ配布（GPP レジストリ等） | PowerShell / reg.exe で明示設定 | “いつ入ったか”が明確。GPO の評価タイミングに依存しない |
| ローカル管理者への追加（GPP ローカルユーザー/グループ等） | ローカルグループ操作（PowerShell など） | OSD の SYSTEM 文脈でも完結しやすい |
| 証明書配布 | 証明書ストアへインポート（TS で実施） | アプリ導入の前提（TLS/コード署名等）を先に作れる |
| Wi-Fi/有線 802.1X など接続プロファイル | プロファイルを TS で登録（XML 適用など） | ドメイン到達性（DC/MP/DP）を確保する設計と相性が良い |
| ファイアウォール例外・FW ポリシー | OSD で必要最低限の例外だけ先に投入 | GPO の最終形に干渉しない“最小限”がコツ |
| プロキシ/WSUS/更新系の設定 | OSD 中は OSD 用の設定に寄せ、完了後に GPO へ委ねる | 更新系は特に競合しやすいので境界を決める |
テンプレ：GPO を前提にしない OSD 設計の考え方
「OSD 完了までに最低限ここまで出来ていれば良い」を設計しておくと、GPO のタイミング問題に振り回されにくくなります。
- ビルド中に必須の前提（ネットワーク到達・証明書・名前解決・時刻）は TS で確実に作る
- セキュリティベースラインの“最終形”は GPO 側に寄せる（ただしビルドを壊す設定は避ける）
- アプリ配布を GPO に依存しない（OSD 中は TS でアプリを入れ、GPO は完了後の運用ルールへ）
- 「OU 位置・セキュリティ フィルタ」が原因で当たらないケースもあるため、ドメイン参加時点で狙う OU を明確化する
それでも「TS 完了直後に GPO を素早く反映したい」場合の現実的な手段
端末の初回起動直後にベースラインを早めに当てたい、という要件はよくあります。ここで重要なのは、TS の途中で無理に gpupdate を待ち合わせしないことです。
ポストアクションで“完了後に実行”へ寄せる
ConfigMgr には、タスク シーケンス完了後にコマンドを起動できる SMSTSPostAction という仕組みがあります（TS マネージャーがコマンドを起動し、待機はしない仕様）。OSD の最後に「再起動」や「軽い後処理」を入れたい場合に設計しやすいポイントです。
例として、完了後に再起動をかける用途が公式の例としても示されています。
SMSTSPostAction の例（概念）:
shutdown.exe /r /t 30 /fもし「完了後に gpupdate を投げたい」なら、待機の扱いも含めて設計します（待たないのか、待つのか）。待たせると“完了後の体感”が悪化しやすいので、まずは待たない運用（/wait:0）から検討し、必要に応じて見直すのが現実的です。
gpupdate を TS に入れるときの最低限ルール
- WinPE 区間では期待しない（環境が違う）
- ユーザー設定は期待しない（ユーザー ログオンが無い）
- ぶら下がる（待ち）を避ける：必要がなければ /wait:0 を使う
- 依存関係を作らない：「gpupdate したら次のインストールが通るはず」を作ると不安定になりやすい
「本当に GPO が当たっていない」のかを切り分けるチェック
“タイミングの問題”と“そもそも適用条件を満たしていない問題”は見た目が似ます。最小限の切り分け観点を表にまとめます。
| 観点 | チェック例 | 意図 |
|---|---|---|
| TS がどの環境で走っているか | タスク シーケンス変数 _SMSTSInWinPE（WinPE なら true） | WinPE 区間で GPO を期待していないか確認 |
| ドメイン参加状態 | コンピューターがドメイン参加済みか、狙いの OU にいるか | 適用対象になっているか確認 |
| DC 到達性・名前解決・時刻 | DC が見つかるか、DNS が正しいか、時刻ずれがないか | GPO 以前の前提条件の確認 |
| GPO の処理ログ | イベントログ（Group Policy Operational など）や gpresult | “処理が走って失敗”か“そもそも走っていない”かを見る |
| TS の実行ログ | smsts.log | gpupdate 実行有無、タイミング、後続への影響を確認 |
GPO の調査で「ログ」を見るときの勘所
GPO のトラブルシュートは、イベントログ（System / Group Policy のオペレーショナルログ）から追うのが基本です。Microsoft のガイダンスでも、イベントを起点にインスタンスを特定して追う流れが整理されています。OSD の議論でも、「GPO が走っていないのか、走って失敗しているのか」を分けるだけで対処方針が変わります。
よくある落とし穴（OSD×GPO で事故りやすいところ）
- “ドメイン参加しただけ”で GPO が即時に入る前提：コンピューター ポリシーは主に起動時がトリガーです。再起動とセットで考えるのが基本です。
- GPO でアプリ配布・スクリプト実行を多用している：OSD のインストールや構成変更と競合しやすく、原因切り分けも難しくなります（OSD は TS 内で明示的に）
- 「ポリシー」という言葉の混同：GPO と ConfigMgr（MECM）のポリシーは別系統です。OSD 中は ConfigMgr クライアントがサイト ポリシーを処理しない仕様があります。
- スクリプト内での強制再起動：SetupComplete の注意点に沿い、OSD の再起動は TS ステップで制御する設計が安全です。
まとめ：ブロックではなく「セットアップの都合」。必要設定は TS に寄せるのが最も安定
MECM（SCCM）の新規 OSD で gpupdate／GPO が効かないように見えるのは、タスク シーケンスが Windows セットアップ（SetupComplete）と密接に連動しており、Windows セットアップ完了まで GPO の通常処理が走りにくい構造が背景にあります。
一方で、OS やタスク シーケンス エンジンが GPO を完全遮断しているわけではなく、条件によって評価が走ることもあります。しかし、そこに依存した設計は不安定になりがちです。OSD 中に必要な構成は TS で完結させ、GPO は完了後の通常運用で効かせる――この方針が、最も事故が少なく、原因切り分けもしやすい現実解です。
参考資料（公式）
- Configuration Manager: Task sequence steps（Setup Windows and ConfigMgr の挙動、Windows Setup と GPO の関係）
- Windows Setup: SetupComplete.cmd（インストール中のドメイン GPO 適用タイミング）
- Windows: Group Policy processing（GPO の処理タイミング：起動時／ログオン時、更新の考え方）
- Configuration Manager: Provisioning mode（OSD 中の ConfigMgr ポリシー処理の抑制）
- Windows コマンド: gpupdate（/wait オプションなど）
- Configuration Manager: Task sequence variables（_SMSTSInWinPE / SMSTSPostAction など）
- Applying Group Policy troubleshooting guidance（GPO のログを使った切り分けの考え方）
コメント