MDT（Lite Touch）で Windows 10 Enterprise のクリーンインストールは完走するのに、タスク シーケンス展開だけ途中で失敗する――そんな時は、PowerShell スクリプトより先に MDT と Windows ADK/WinPE のバージョン不整合を疑うべきです。原因の切り分けから、確実に直す手順、再発防止までまとめます。
MDT（Microsoft Deployment Toolkit）の Lite Touch 展開では、同じ Windows 10 Enterprise でも「何も足さない新規インストール（いわゆるクリーンインストール）は最後まで通る」のに、「特定のタスク シーケンス（TS）だけが途中でエラーになって落ちる」ことがあります。特に、TS 内で既定（組み込み）アプリ削除の PowerShell スクリプト（例：RemoveApps.ps1）を追加している場合、ついスクリプト原因を疑いがちです。
しかし実務では、スクリプトそのものより前に「MDT と Windows ADK（必要なら WinPE アドオン）のバージョン不整合」が刺さっているケースが少なくありません。ADK/WinPE はブートイメージ（LiteTouchPE）や DISM、展開時のコンポーネントに直結し、組み合わせがズレると“いかにもスクリプトで落ちたように見える”失敗を引き起こします。
現象を整理する（再現条件を言語化すると切り分けが速い）
まずは状況を整理します。ここが曖昧だと、ログを読んでも「何が違うのか」が見えません。
| 項目 | クリーンインストール（成功） | タスク シーケンス展開（失敗） |
|---|---|---|
| OS | Windows 10 Enterprise | Windows 10 Enterprise（同一イメージ/同一ビルド想定） |
| 展開方式 | 標準手順（追加カスタマイズなし） | MDT Lite Touch の TS で展開 |
| 差分 | なし | RemoveApps.ps1（既定アプリ削除）を TS 内で実行 |
| 落ちるタイミング | なし | WinPE／OS 適用／State Restore／PowerShell ステップなど、どこかの途中 |
ポイントは「同じ OS なのに TS だけ失敗する」こと。MDT の TS は、WinPE 起動→ディスク準備→WIM 適用→ドライバー/パッケージ適用→セットアップ→各種スクリプト…と工程が多く、“OS 自体が正常でも、ツールチェーンの相性で落ちる”余地があります。
結論：原因の本命は MDT と Windows ADK/WinPE のバージョン不整合
結論を先に言うと、今回のタイプのトラブルはMDT と Windows ADK（＋WinPE アドオン）の組み合わせがズレていると起きやすく、正しい組み合わせへ揃えると解消することが多いです。
なぜ「不整合」で TS だけ失敗しやすいのか
- LiteTouchPE（ブートイメージ）は ADK/WinPE から生成されるため、ADK が違うと WinPE 内の DISM/ドライバースタック/スクリプト実行環境が変わります。
- TS は「WinPE フェーズ」と「フル OS フェーズ」をまたぐため、フェーズ間の引き継ぎ（ディスク、ドライバー、パッケージ、レジストリ、ネットワーク）で差が出ます。
- ADK 由来のコンポーネントは、Windows 10/11 の世代差や更新に影響されやすく、“動いていたものがある日突然壊れる”典型パターンになりがちです。
不整合が疑わしい代表症状
ログ上はさまざまな形で現れますが、現場でよく見るのは次のようなパターンです。
| 症状 | よくある見え方 | 疑うべきポイント |
|---|---|---|
| TS が途中で突然失敗する | 0x80004005 など汎用エラー、SMSTS.log の最後が曖昧 | ADK/WinPE の世代違い、Boot Image が古いまま |
| PowerShell ステップで落ちたように見える | スクリプトの戻り値が -1/1、または実行前後で環境が崩れている | WinPE/フルOS切替、ExecutionPolicy、PowerShell バージョン差 |
| WIM 適用やドライバー適用で失敗 | DISM の適用エラー、ストレージ/ネットワークが途切れる | WinPE 側のドライバー互換、ADK が新旧混在 |
| 同じ TS なのに機種によって成功/失敗が揺れる | 特定モデルだけ落ちる、UEFI/RAID/NVMe 周りが怪しい | WinPE に入っているドライバー・ストレージスタック・署名 |
最短で直す：MDT／Windows ADK（＋WinPE）を「正しい組み合わせ」に揃える
対処はシンプルで、やることは大きく 3 つです。
- MDT／Windows ADK／WinPE アドオンを対象 OS に合う組み合わせへ更新・入れ替え
- Deployment Share を更新し、ブートイメージ（LiteTouchPE）を再生成（可能なら完全再生成）
- PXE（WDS）や USB/ISO メディア側のブートイメージも必ず差し替えて再実行
手順の全体像（作業漏れが起きやすいので一覧化）
| 手順 | やること | 目的 | よくある落とし穴 |
|---|---|---|---|
| 1 | 現在の MDT/ADK/WinPE のバージョンを棚卸し | ズレの有無を把握する | 「ADK は入っている」だけで安心し、WinPE アドオンの世代が違う |
| 2 | 対象 OS（Windows 10 Enterprise）のビルドに合わせて、正しい ADK/WinPE を用意 | 互換性を担保する | Windows 11 向け ADK を流用して混在させる、複数世代を共存させる |
| 3 | Deployment Share を Update（完全再生成推奨） | LiteTouchPE を作り直す | 更新だけで済ませ、実際に起動しているブートイメージが古いまま |
| 4 | WDS/PXE・USB・ISO の boot.wim を差し替え | 現場端末が新しい WinPE で起動するようにする | WDS の既存イメージを削除せず、古い方で起動してしまう |
| 5 | 同一条件で TS を再実行し、ログを保存 | 改善の確認 | 成功した端末だけ見て「直った」と判断し、再現しやすい端末で確認しない |
棚卸しで最低限確認したいポイント
GUI だけでも確認できますが、チームで共有するなら PowerShell で“記録に残る”形にするのがおすすめです。
# 例：ADK のインストール状況や、主要コンポーネントの存在をざっくり確認
Get-ChildItem "C:\\Program Files (x86)\\Windows Kits\\10" -ErrorAction SilentlyContinue | Select-Object FullName
# 例：MDT のインストール確認（インストール済みプログラムでも可）
Get-ItemProperty "HKLM:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\*" |
Where-Object { $_.DisplayName -match "Microsoft Deployment Toolkit" } |
Select-Object DisplayName, DisplayVersionここで重要なのは「バージョン番号を覚えること」よりも、MDT・ADK・WinPE が同じ世代として揃っているかを確認することです。揃っていない場合、まずは揃えるのが最短ルートになります。
“ブートイメージの再生成”が本体：Deployment Share 更新と PXE/メディア差し替え
ADK/WinPE を入れ替えただけでは直りません。MDT は Deployment Share から LiteTouchPE を生成して配布するため、ブートイメージを作り直し、さらに端末がそれで起動する状態まで持っていく必要があります。
- MDT Workbench で Deployment Share を右クリック → Update Deployment Share
- 可能なら Completely regenerate the boot images（完全再生成）を選ぶ
- 生成された LiteTouchPE_x64.wim / LiteTouchPE_x64.iso を、運用している配布経路に合わせて反映する
| 配布経路 | 差し替えるもの | 確認ポイント |
|---|---|---|
| WDS（PXE） | LiteTouchPE_x64.wim（Boot Images） | PXE 起動時に表示されるブートイメージ名が想定どおりか |
| USB メディア | ISO から作り直す／boot.wim を差し替える | 古い USB が現場に残っていないか（事故率が高い） |
| ISO 配布 | LiteTouchPE_x64.iso | 配布場所・ファイル名が変わっていないか |
現場でありがちなのが「Deployment Share は更新したのに、WDS の boot.wim を差し替え忘れて旧 WinPE で起動している」パターンです。端末が“どの WinPE で起動したか”を確認できる仕掛け（背景のバージョン表示、起動時のメッセージ、ログ保存のルール化）を持っておくと、再発時の切り分けが速くなります。
ログで切り分ける：ADK/WinPE 不整合か、スクリプト失敗か
同系統のトラブルでは、まず MDT のログ（例：BDD.log / SMSTS.log）で、失敗箇所が「PowerShell ステップ」なのか「WinPE/適用フェーズ」なのかを見て、原因の当たりを付けるのが近道です。
見るべきログと“置き場所”の目安
| ログ | 主な内容 | よくある保存先（目安） | 最初に探すキーワード |
|---|---|---|---|
| SMSTS.log | TS 実行の中心ログ（成功/失敗の起点） | X:\\MININT\\SMSOSD\\OSDLOGS または X:\\SMSTSLog（WinPE） C:\\MININT\\SMSOSD\\OSDLOGS または C:\\_SMSTaskSequence\\Logs（OS 適用後） | Return code / Failed / ZTI / DISM |
| BDD.log | MDT 全体の処理ログ（設定・Gather・スクリプト連携） | X:\\MININT\\SMSOSD\\OSDLOGS または C:\\MININT\\SMSOSD\\OSDLOGS （完了後に C:\\Windows\\Temp\\DeploymentLogs へコピーされる構成も多い） | ERROR / ZTIGather / ZTIConfigure |
| ZTIGather.log | CustomSettings.ini や DB からの設定取得 | 同上 | Property / Failed to find / Warning |
| ZTIUtility.log | 共通ユーティリティ（再起動/ファイル操作など） | 同上 | Exit / Return / Copy |
ログ閲覧はメモ帳でもできますが、行数が多いので CMTrace のようなログビューアを使うと「エラー行の前後」を追いやすくなります。TS の失敗は“最後の 20 行だけ見ても分からない”ことが多いので、失敗時刻の少し前から追いかけてください。
切り分けの考え方（最初の 15 分で当たりを付ける）
- WinPE フェーズ（OS 適用前後）で落ちる → ADK/WinPE、ストレージ/ネットワークドライバー、WIM 適用（DISM）を優先的に疑う
- フル OS フェーズの PowerShell ステップで落ちる → RemoveApps.ps1 の戻り値、権限、対象アプリ、実行タイミングを疑う（ただし WinPE 起因で環境が崩れている可能性も残す）
- 同じステップ名で落ちたり落ちなかったりする → 依存関係（ネットワーク共有、サービス起動待ち、UAC、再起動タイミング）やバージョン不整合を疑う
RemoveApps.ps1 を TS に入れている場合の注意点（“二次障害”を防ぐ）
今回の結論は「MDT と ADK/WinPE の不整合」ですが、環境を揃えたあとに RemoveApps.ps1 が新たな失敗要因になることもあります。特に“既定アプリ削除”は、Windows の更新や SKU によって対象が変わりやすいので、TS へ組み込むなら設計のコツがあります。
TS 内で実行するなら、最低限ここを押さえる
| チェック項目 | 推奨 | 理由 |
|---|---|---|
| 実行フェーズ | フル OS（State Restore 以降）で実行 | WinPE では AppX 系の操作が制限され、ログも追いにくい |
| 実行方法 | powershell.exe -NoProfile -ExecutionPolicy Bypass -File | ExecutionPolicy やプロファイル影響で失敗しにくい |
| 削除方式 | 「ユーザーに入っている AppX」だけでなく、Provisioned（新規ユーザー向け）も削除 | 新規ユーザー作成で復活する“あるある”を防げる |
| 戻り値 | 失敗時でも要件に応じて 0 を返す設計を検討 | 「削除できなかった＝OS 展開停止」にするかは運用次第 |
| ログ | スクリプト内で ログファイルへ追記する | SMSTS.log だけだと何を消したか追えない |
コマンド例（TS の「コマンド ラインの実行」で呼び出す）
powershell.exe -NoProfile -ExecutionPolicy Bypass -File "%SCRIPTROOT%\\RemoveApps.ps1"スクリプトの“止まり方”を制御する例（要件に合わせて調整）
「アプリが見つからない」「既に削除済み」などは、運用上は正常系として扱いたいことがあります。TS を止める/止めないの判断が曖昧だと、端末ごとに成功率が揺れます。
# 例：RemoveApps.ps1 内の考え方（概念例）
# - 失敗させたい条件だけ exit 1
# - それ以外はログして exit 0
try {
# 削除処理...
# Remove-AppxProvisionedPackage / Remove-AppxPackage など
exit 0
}
catch {
# “致命的な失敗”にしたい場合だけ exit 1 へ
# 例：必要な管理ツールが無い、権限が無い、DISM が壊れている等
exit 1
}安定運用のコツ：既定アプリ削除は“参照イメージ側”に寄せる
既定アプリ削除は、TS 実行中に毎回やるよりも、参照イメージ（リファレンス イメージ）を作る段階で削除 → 新しい OS イメージを作成 → 新しい TS で展開の方が安定しやすいです。理由は単純で、TS の可動部が減り、失敗点が減るからです。
代表的な 3 方式（メリット/デメリットで選ぶ）
| 方式 | タイミング | メリット | デメリット | 向くケース |
|---|---|---|---|---|
| 参照イメージで削除してキャプチャ | Build & Capture（事前） | 展開が速い／失敗点が減る／検証しやすい | 参照イメージの管理が必要（更新/再キャプチャ） | 台数が多い、標準化が強い現場 |
| オフライン WIM に対して削除（DISM） | イメージ整備（事前） | ユーザー作成前に Provisioned を削除できる | 作業ミスで WIM を壊すリスク、手順の自動化が必要 | “このアプリだけ絶対いらない”が明確な現場 |
| TS 後（初回ログオン後）に削除 | 展開後（事後） | TS をシンプルに保てる／柔軟に制御できる | 初回起動時に処理が走る／ユーザー体験に影響 | 端末ごとに削除方針が異なる現場 |
オフライン削除のイメージ（Provisioned Appx を消す考え方）
“インストール済みアプリ（ユーザー単位）”を消すだけだと、新規ユーザーで復活することがあります。そこで、OS イメージ側の Provisioned Appx を消す考え方が有効です。ここでは概念が伝わる範囲で例を示します（実運用では対象アプリを厳選し、検証環境での確認が必須です）。
# オンライン（展開後）で Provisioned を確認する例
Get-AppxProvisionedPackage -Online | Select-Object DisplayName, PackageName
# オンラインで Provisioned を削除する例（対象 PackageName を指定）
Remove-AppxProvisionedPackage -Online -PackageName "（PackageName をここに）"削除対象を増やし過ぎると、ストア更新や一部の機能（依存関係）に影響することがあります。「何を消すか」より「何を残すか」を先に決め、業務要件（社内アプリ、ストア利用有無、UWP 依存の機能）とセットで設計するのが安全です。
それでも直らないときの追加チェック（現場で効く順）
ADK/WinPE を揃えてブートイメージも更新したのに落ちる場合、次の順で見ていくと詰まりにくいです。
TS を“最小構成”にして原因を絞る
- RemoveApps.ps1 を一旦外し、標準の「OS 適用＋基本設定」だけで完走するかを見る
- 完走するなら、RemoveApps.ps1 を戻して「落ちるならどのアプリがトリガーか」を追う
- 完走しないなら、スクリプトではなく WinPE/ドライバー/ネットワーク/ディスク周りへ戻る
ストレージ/ネットワークドライバー（WinPE 側）の見直し
- UEFI/RAID/NVMe を使う端末では、WinPE がストレージを正しく認識できないと、途中で“見えたり見えなかったり”します。
- モデル混在環境では「OS 側のドライバー」だけでなく、WinPE に注入されているドライバーも要チェックです。
共有フォルダ到達性と権限（地味に多い）
- TS 中のスクリプトやアプリ配布がネットワーク共有に依存している場合、認証・SMB 設定・証明書・名前解決の揺れで落ちます。
- 特に “途中で” 落ちる場合は、ネットワーク断や NIC ドライバーの再初期化が絡むことがあります。
再発防止：バージョン整合を運用ルール化する
今回の原因がバージョン不整合だった場合、直した瞬間は快適でも、半年〜1年後に同じ形で再発しやすいです。運用ルールとして次を決めておくと、トラブル対応の時間が大幅に減ります。
- OS のビルド更新（例：機能更新/大型更新）と同じタイミングで ADK/WinPE の見直しを行う
- ADK/WinPE を更新したら、必ずDeployment Share の完全再生成→WDS/メディア差し替えまでをセットで実施
- 成功端末のログを保管し、失敗時は差分比較できるようにする
- RemoveApps.ps1 などのカスタムは、対象 OS ビルドごとにテストし、対象アプリ一覧もバージョン管理する
運用メモとして残すと便利な項目
| 項目 | 記録例 | 理由 |
|---|---|---|
| MDT のバージョン | DisplayVersion | ADK との組み合わせ検討の起点になる |
| ADK/WinPE のバージョン | インストール日＋製品バージョン | 「いつから壊れたか」を追える |
| LiteTouchPE の更新日 | WIM のタイムスタンプ | 端末が新しい WinPE で起動しているか確認できる |
| TS の変更履歴 | RemoveApps.ps1 追加/変更日 | “何を変えたら壊れたか”が一目で分かる |
まとめ：最初に疑うのはスクリプトより「MDT×ADK/WinPE の組み合わせ」
「クリーンインストールは成功するのに、タスク シーケンス展開だけ失敗する」ケースは、PowerShell の 1 行よりも、まずMDT と Windows ADK/WinPE のバージョン整合が鍵になることが多いです。
- MDT／ADK（＋WinPE）を対象 OS に合う組み合わせへ揃える
- Deployment Share を更新し、LiteTouchPE を完全再生成する
- PXE/メディア側のブートイメージまで差し替え、“新しい WinPE で起動している”状態で再実行する
- 既定アプリ削除は参照イメージ側に寄せると、展開の安定度が上がる
この 4 点を押さえるだけで、同種の MDT トラブルは“根本から”収束しやすくなります。ログ（BDD.log / SMSTS.log）を味方に、まずはどのフェーズで落ちているかを特定し、再現性のある形で改善していきましょう。
コメント