MENU

MECM/SCCMのOSD中にコンピューターGPOは適用される？制限GPOをタスクシーケンス完了後に効かせる方法

Active Directory

Microsoft Endpoint Configuration Manager（MECM／旧SCCM）のOSDタスクシーケンスでWindows 10を展開していると、ドメイン参加後に“制限GPO”が想定より早く効き、アプリ導入や設定が途中で失敗することがあります。ここでは、OSD実行中にコンピューターGPOが適用される条件と、OSD完了後にだけ確実に効かせるための現実的な設計をまとめます。

目次

結論：OSD（タスク シーケンス）実行中でも「コンピューターGPO」は適用され得る

まず結論から整理すると、コンピューター（デバイス）対象のGPOは「ユーザーがログオンしないと適用されない」ものではありません。ドメイン参加済みで、ネットワーク的にDCへ到達でき、Group Policy Client（gpsvc）を含む前提が揃えば、タスク シーケンス実行中でも（少なくとも仕組み上は）適用され得ます。

そして重要なのは、MECM/SCCMのタスク シーケンス エンジンが「GPOを自動的にブロックする」標準機能は基本的にないという点です。つまり「OSD中はGPOが当たらないはず」と決め打ちすると、環境差や再起動のタイミング次第で想定外の失敗につながります。

ただし現場では「OSD中は効かないように見える」ことがある理由

新規OS展開のOSDで「制限GPOがOSD中は効いていないように見えて、完了後にまとめて効き始める」現象が起きることがあります。これは“GPOが無効化されている”というより、次のような要因が重なって通常のGPO処理が走りにくい期間が存在し得るためです。

  • まだドメイン参加していない（WinPE中、OS適用直後など）
  • ドメイン参加はしているが、DCに到達できない（ネットワーク未確立、DNS未安定、802.1X、プロキシ、FW、時刻ずれなど）
  • GPOの「前景（起動時）処理」が走る条件が揃っていない（初回ブートの状態、セットアップ段階、再起動の挙動）
  • OSDの再起動が多く、適用タイミングが“たまたま遅延”している

このため、経験的に「OSD中は大丈夫だったから、今後も大丈夫」とは言い切れません。特に、同じタスク シーケンスでも新規OS展開とスタンドアロンメディア、インプレース アップグレードなどで条件が変わり、GPOの影響が出やすくなることがあります。

OSDのフェーズ別：いつ「ドメインGPO」が効き始める可能性があるか

整理のため、OSDを大まかなフェーズに分けて、ドメインGPO（コンピューター構成）が影響し得るポイントを見える化します。

フェーズ端末の状態ドメインGPO（コンピューター構成）の影響現場で起きがちなこと
WinPEWindows PE上でTS実行基本的に影響なし（ドメイン参加していない）ネットワーク制御や証明書の影響は別途あり得る
OS適用直後〜初回起動新OSへブート、TS継続ドメイン参加前なら影響なしローカル設定のみ、ここは比較的安全
ドメイン参加後（再起動含む）コンピューターアカウントが作成/参加済み影響が出始める可能性がある（起動時/更新時）制限GPOの内容によってはアプリ導入が失敗する
ConfigMgrクライアント導入後CcmExec稼働、アプリ導入が進むGPO適用が進むとサービス/FW/スクリプト実行に影響「途中から急に失敗が増える」症状になりやすい
TS完了後〜次回起動通常運用に近い状態へGPOが通常どおり安定して適用され始めるOSD中に抑えていた制限がここで表に出る

ポイントは、「ドメイン参加した時点」ではなく「ドメイン参加後に、GPO処理が成立する起動・更新タイミングを迎えた時点」で影響が出るということです。

OSDを邪魔しやすい“制限GPO”の典型例

「当たるだけならいいが、OSDの途中で当たると困る」制限には傾向があります。特にアプリ導入・スクリプト・コンテンツ取得と相性が悪いものは要注意です。

制限の種類OSDで困ることよくある症状代替/設計のコツ
サービス無効化（BITS / Windows Installer / WMI など）ダウンロードやMSIインストール、検出が止まるアプリが0x87D…系で失敗、検出不一致、ログが薄いOSD完了後に適用、またはGPP＋ターゲティングへ
Windows Defender / FWの強硬設定社内ツール・インストーラ・通信がブロックされるインストール途中で停止、通信不可、タイムアウトOSD用例外・段階適用（まず許可→後で絞る）
PowerShell / スクリプト実行制限TSのスクリプトやGPPが動かない「実行ポリシー」関連、スクリプトが即終了OSD中は許容、完了後に制限へ
ローカル管理者権限やUAC周辺の過度な固定セットアップや構成変更が失敗しやすいインストーラが途中で失敗、レジストリ反映しないOSD中は標準値、完了後にベースラインで締める
証明書/プロキシ/WinHTTPの強制DP/MP/社内配布基盤へ到達できないコンテンツ取得失敗、WinHTTPエラーOSDネットワーク要件を満たす順序で適用

制限内容の良し悪しではなく、“いつ効かせるか”が設計の肝です。

「コンピューターGPOを初回ユーザー ログオンまで待たせる」は基本できない

質問で多いのが、「OSD完了後、できれば初回ユーザー ログオン後にだけ制限を効かせたい」という要望です。ここは割り切りが必要で、コンピューター構成のGPOはユーザー ログオンを前提にしていないため、Windows標準の考え方として“ログオンするまでコンピューターGPOを止める”仕組みは基本ありません。

ただし、目的が「制限を“ログオン後にだけ”発動させたい」なのであれば、次のように“設計で実現”するのが現実的です。

  • 制限の性質がユーザー向けならユーザー構成へ寄せる（必要ならループバックも検討）
  • どうしても端末側の制限が必要なら、OU/スコープでOSD中は当てない（最も確実）
  • GPOの「設定」ではなく、GPP＋項目レベル ターゲティングや起動時スクリプトで“条件成立後に適用”へ作り替える

対策の基本方針：GPOそのものを疑うのではなく「当て方」を分ける

OSDと運用の両方を安定させるには、次の2点を最初に決めるとブレません。

  • OSD中に必要な機能（インストール/通信/スクリプト）が止まらないことを最優先にする
  • 端末ハードニングはOSD完了後に段階的に適用し、影響範囲を把握しながら締める

この方針に沿った“定番かつ確実”な実装が、次の3つです。

対策1：ステージングOU方式（いちばん確実で説明しやすい）

「OSD中の端末は制限GPOがないOUへ入れておき、OSD完了後に本番OUへ移動する」方法です。GPOはOUスコープで効くものが多いため、管理しやすく、原因切り分けもしやすいのが利点です。

ステージングOU方式が向くケース

  • サービス無効化など、当たった瞬間にOSDが止まり得るGPOがある
  • 制限GPOが複数あり、何が効いているか追うのが大変
  • 現場運用（説明・引き継ぎ）を考えて、シンプルにしたい

実装イメージ（流れ）

  1. Active Directoryにステージング用OUを作成（例：OU=Staging,OU=Computers,DC=contoso,DC=com）
  2. ステージングOUには制限GPOをリンクしない（または不要なGPOが当たらないようにブロック/設計）
  3. OSDのドメイン参加で最初からステージングOUへ参加させる（タスク シーケンスの「Apply Network Settings」でOU指定）
  4. アプリ導入や設定が完了したら、TSの終盤で本番OUへ移動
  5. 最後に再起動（または次回起動）で、本番OUのGPOが適用

OU移動をタスク シーケンス内で行うときの注意点

コンピューターアカウント（端末自身）にOU移動権限がない場合が多いため、OU移動は権限を持つ専用アカウントで実行するのが一般的です。

  • 推奨：OSD用サービスアカウントを用意し、ステージングOU内の作成/移動のみを委任する
  • 避けたい：ドメイン管理者権限の流用、パスワードの平文埋め込み

OU移動のサンプル（PowerShell／ADモジュール不要の例）

RSAT（ActiveDirectoryモジュール）が入っていない端末でも動かしやすいように、DirectoryServicesを使う例です。タスク シーケンスの「Run PowerShell Script」などで、“このステップを次のアカウントとして実行”を利用し、OU移動権限のあるアカウントで実行する想定です。

param(
  [Parameter(Mandatory=$true)]
  [string]$TargetOU,  # 例: "OU=Workstations,OU=Prod,DC=contoso,DC=com"

  [Parameter(Mandatory=$true)]
  [string]$DomainDN   # 例: "DC=contoso,DC=com"
)

$computerName = $env:COMPUTERNAME
$rootPath = "LDAP://$DomainDN"

$root = New-Object System.DirectoryServices.DirectoryEntry($rootPath)
$searcher = New-Object System.DirectoryServices.DirectorySearcher($root)
$searcher.Filter = "(&(objectClass=computer)(sAMAccountName=$computerName`$))"
$searcher.PageSize = 1

$result = $searcher.FindOne()
if (-not $result) {
  throw "Computer object not found in AD: $computerName"
}

$computerEntry = $result.GetDirectoryEntry()
$targetEntry = New-Object System.DirectoryServices.DirectoryEntry("LDAP://$TargetOU")

$computerEntry.MoveTo($targetEntry)
$computerEntry.CommitChanges()

Write-Host "Moved $computerName to $TargetOU"

OU移動の直後にGPOを反映させたい場合は、次のようにして“反映のタイミング”をコントロールできます。

  • 本当に必要な場合のみ：gpupdate /force＋再起動
  • 基本：次回起動で自然に適用させる（OSDを安定させる）

対策2：GPOの適用範囲で「展開中端末」を除外する（セキュリティ フィルター）

OUを分けるのが難しい場合や、本番OUの構造を変えたくない場合は、GPOのセキュリティ フィルターで“当てる端末だけに限定”する方法が有効です。

基本パターン：対象グループにだけGPOを当てる

  1. ADのセキュリティ グループを作る（例：GPO-Hardening-Target）
  2. 制限GPOの「セキュリティ フィルター」をAuthenticated Usersから置き換え、そのグループだけにする
  3. OSD完了後に端末をグループへ追加（自動化 or 運用）

この方式の強みは、OSD中にグループに入れなければ絶対に当たらないことです。OUのリンク構造に左右されにくく、段階展開にも向きます。

OSD完了後にグループへ追加する方法の例

  • タスク シーケンス終盤で、権限のあるアカウントでPowerShellを実行して追加
  • OSD完了後、MECMのコレクション（例：OSD完了端末）に対してスクリプトで追加
  • 運用フロー（受け入れチェック）に組み込み、検収後に追加

「自動化したいが、OSDの中で権限処理を増やしたくない」場合は、OSD完了の目印（後述）を作っておき、別ジョブで追加する構成が安定します。

“Denyで除外”は慎重に

「OSD中端末グループにDeny（適用拒否）を付ける」設計も可能ですが、Denyは強力で事故の元になりやすいため、基本は“当てたい端末だけに限定する”（Allowベース）がおすすめです。

対策3：GPP（グループ ポリシーの基本設定）＋項目レベル ターゲティングで“OSD完了後だけ”にする

「制限をGPOの“ポリシー設定”で直接やるとOSDに効いて困る」場合、制限の一部をGPP（Group Policy Preferences）で実装し、項目レベル ターゲティング（Item-level targeting）で条件付きにするのが実務で効きます。

特に強いのが、OSD完了を示す“マーカー”を端末に作り、マーカーが存在するときだけGPPを適用する方式です。

マーカー方式が向く例

  • サービスのスタートアップ種類変更（GPPの「サービス」で管理）
  • レジストリの投入、ファイルコピー、ショートカット配布など
  • 「OSD中は触りたくないが、完了後は確実に入れたい」設定全般

実装例：タスク シーケンスの最後に“OSD完了レジストリ”を作る

タスク シーケンスの終盤に「Run Command Line / Run PowerShell Script」で次を実行します。

reg add "HKLM\SOFTWARE\Company\OSD" /v Completed /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Company\OSD" /v CompletedAt /t REG_SZ /d "%DATE% %TIME%" /f

そして、GPO側（GPP）では対象の設定項目に対して項目レベル ターゲティングを設定します。

  • 条件：レジストリ値が存在する（HKLM\SOFTWARE\Company\OSD\Completed = 1）

これにより、GPO自体はリンクされていても、OSD完了マーカーが無い間は“何も実行されない”ため、OSDへの影響を最小化できます。さらに、トラブル時にはマーカーを消すだけで一時的に適用を止められるのも運用上のメリットです。

注意：GPPは「ポリシー」ではなく「基本設定」

GPPは柔軟ですが、ポリシー設定と比べて「管理の強制力」が異なります。とはいえ、サービス設定などは“更新（Update）”や“置換（Replace）”で継続的に寄せる運用ができます。強制力が必要な項目は、OU方式やセキュリティ フィルターと併用して設計すると堅いです。

対策4：そもそもドメイン参加を“遅らせる”という選択肢

環境によっては、OSDの大部分をワークグループのまま進め、最後にドメイン参加することで、ドメインGPOの影響を根本的に避けられる場合があります。

  • メリット：ドメインGPOがOSDに干渉しない
  • デメリット：ドメイン参加が前提の処理（社内リソース、証明書、自動構成など）が難しくなる

「アプリはすべてDPから入れる」「ドメイン前提の設定は完了後に寄せる」など、OSD設計が整理できる組織では有効ですが、一般的にはステージングOU方式の方が適用範囲をコントロールしやすいことが多いです。

現実的なおすすめ構成（迷ったらこれ）

制限GPOがOSDを邪魔しそうなら、次のどちらかに寄せると安定します。

おすすめA：ステージングOU＋OSD終盤で本番OUへ移動

  • 制限GPOは本番OUに集約
  • OSD中は“OSDに必要な最低限”だけを当てる
  • アプリ導入が終わったら移動して、次回起動で制限を開始

おすすめB：制限GPOは「対象グループ限定」にして、完了後にグループ追加

  • OUを変えられない場合に強い
  • 段階展開が簡単（対象を増やすだけ）
  • OSDと運用の境界が明確

“OSD完了後に効かせたい”を実現する設計チェックリスト

最後に、設計・実装時に見落としやすい点をチェックリスト化します。

チェック項目確認ポイントありがちな落とし穴対策
ドメイン参加OUOSD開始時点でどのOUに作成されるか意図せず本番OUに入って制限が当たるApply Network SettingsでOUを明示
制限GPOの内容OSDに必要なサービス/機能を止めていないかBITS/Installer/WMI/FirewallがOSDを阻害OSD中は当てない、または段階適用
反映タイミング再起動の直後に影響が出ていないか「途中から急に失敗する」OU移動やグループ追加の順序を最終盤へ
トラブルシュート手段どのGPOがいつ適用されたか追えるか原因がGPOと気づかないgpresult、イベントログ、OSDログを組み合わせる
運用の説明性引き継ぎで理解できる構造になっているか「なぜこの端末だけ制限が効かない？」が頻発ステージングOU/対象グループを標準化

トラブルシュートの実践（OSD中にGPOが疑わしいとき）

「突然アプリ導入が失敗し始めた」「同じTSなのに環境で差がある」など、GPOが絡んでいそうなときは、次の順で確認すると早いです。

  • 端末が所属しているOU（ドメイン参加直後にどこにいるか）
  • 適用されるGPOの一覧（OSD中でも gpresult /r や gpresult /h が取れるタイミングがある）
  • GroupPolicyのイベントログ（処理失敗や遅延の痕跡）
  • OSD関連ログ（SMSTS.log で失敗直前に何が変わったか）

原因がGPOだと判明したら、個別設定の調整よりも先に、「OSD中に当たらない構造」へ寄せる方が、再発防止として効きます。

まとめ：OSDの成功率を上げる鍵は“GPOの遅延”ではなく“スコープ設計”

コンピューターGPOはユーザー ログオンを条件にしないため、OSD中でも条件が揃えば適用され得ます。「OSDが終わるまで待ってほしい」という要求は、OSの標準機能としては叶えにくい一方、OU（ステージング）やセキュリティ フィルター、GPP＋ターゲティングを組み合わせれば、OSDを邪魔しない形で“完了後にだけ効かせる”運用は十分に実現できます。

迷ったら、まずはステージングOU方式で「OSD中は制限を当てない」を確実にし、必要に応じて対象グループ限定やOSD完了マーカーを足していくのが、最も事故が少ない進め方です。

Active Directory
グループポリシー SCCM タスクシーケンス MECM OSD

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次