MDT 2013 で WDS/PXE から起動する WinPE が、Bootstrap.ini に正しいユーザー名・パスワードを設定しているのに、なぜか過去のテスト用資格情報で Deployment Share に接続しようとして失敗する――。この症状の原因と、確実に止血できた解決手順（Share の作り直し）をまとめます。
ここで扱う問題は、WDS（Windows Deployment Services）/MDT（Microsoft Deployment Toolkit）で展開基盤を組んでいる現場で、意外とハマりやすい類です。設定ファイル上は正しいのに、PXE ブートした WinPE が展開用共有へ接続する瞬間だけ「昔のテスト用アカウント」を勝手に使い続け、結果として認証に失敗してタスクシーケンスが止まってしまいます。
症状：正しい設定なのに「古い資格情報」で共有に接続してしまう
前提となる構成は次のようなイメージです。
| 項目 | 内容（例） | ポイント |
|---|---|---|
| 展開方式 | WDS で PXE ブート → MDT 生成 WinPE（boot.wim） | PXE 側の boot.wim が「どの Share で作られたか」が重要 |
| Deployment Share | Production Share（例：\\MDT01\DeploymentShare$） | この Share を元に WinPE が生成される |
| 資格情報の設定 | Bootstrap.ini / CustomSettings.ini に正しいユーザー名・パスワードを記載 | 設定しているのに反映されないのが問題 |
| 現象 | WinPE 起動後、共有接続で「古いテスト用資格情報」を使用して失敗 | 作り直したはずの boot.wim でも再発する |
対処としてよく実施される、以下の「ブートイメージ周りの作り直し」だけでは改善しないケースがあるのが厄介です。
- Deployment Share の Boot ディレクトリを削除してからの再生成（クリーンに作り直し）
- PXE 側（WDS など）に登録した boot.wim を削除→再登録
それでも古い資格情報が使われ続け、展開が止まる。まさにこの状態が今回のテーマです。
まず押さえる：MDT の資格情報が使われるタイミング
MDT の WinPE（LiteTouchPE）は、起動してすぐに Deployment Share へ接続し、タスクシーケンスやスクリプト類を読み込みます。この「最初の接続」に使われるのが、基本的に Bootstrap.ini 側の資格情報です。CustomSettings.ini（Rules）は、Share 接続後に読み込まれる項目が多いため、切り分けの順序を間違えると沼ります。
| 設定ファイル | 主な用途 | 反映されるタイミング | よくある誤解 |
|---|---|---|---|
| Bootstrap.ini | WinPE が最初に Share に接続するための DeployRoot/資格情報 | WinPE 起動直後（Share 接続前） | 「Rules に書けば良い」と思い込みがちだが、最初の接続は Bootstrap が主役 |
| CustomSettings.ini（Rules） | スキップ項目、ドメイン参加、タスクシーケンス選択、各種変数の制御 | Share 接続後～ウィザード/タスクシーケンス実行中 | Rules の資格情報は用途が違う（例：ドメイン参加、追加共有など） |
このため「Share に接続できない」系のトラブルでは、まず WinPE 内に取り込まれた Bootstrap.ini が本当に最新か、そして WinPE が実際にどの資格情報を使って接続を試みているかを確認するのが近道です。
WinPE が使っている資格情報をログで追う
GUI のエラーメッセージだけでは、どのアカウントで認証しようとしたのか分からないことがあります。MDT はログを比較的丁寧に出すので、WinPE 側でログを確認すると一気に状況が見えます。
| ログ名 | 主な役割 | WinPE での典型的な場所 | 見るべき観点 |
|---|---|---|---|
| BDD.log | MDT スクリプト全般のログ | X:\MININT\SMSOSD\OSDLOGS\BDD.log（状況により場所が変わる） | 「DeployRoot へ接続」「認証失敗」「使用ユーザー名」の記録 |
| LiteTouch.log | LiteTouch 実行の流れ | X:\MININT\SMSOSD\OSDLOGS\LiteTouch.log | どの設定ファイルが読まれたか、どの Share に向かったか |
| SMSTS.log | タスクシーケンスのログ（MDT/SCCM 共通） | X:\MININT\SMSOSD\OSDLOGS\SMSTS.log | TS 開始前に落ちる場合でも手掛かりが残ることがある |
WinPE でログを開く定番は、Shift + F10 でコマンドプロンプトを出し、notepad でログファイルを開く方法です。Share 接続に失敗しているなら、BDD.log あたりに「どのユーザーで接続を試みたか」が残っていることが多いです。
ブートイメージを作り直しても直らないときに疑うポイント
「Boot フォルダを消して再生成」「WDS の boot.wim を登録し直した」までやっても、古い資格情報が使われ続ける場合、単純に“作り直しが足りない”というより、どこかが過去の状態を引きずっている可能性が高いです。現場でよくある確認ポイントを、切り分け観点で整理します。
| 疑うポイント | なぜ起きる？ | 確認方法 | 対処の方向性 |
|---|---|---|---|
| WDS が別の boot.wim を配っている | 同名・別アーキテクチャ・古い登録が残り、意図しないイメージが優先される | WDS コンソールで boot image を一覧し、説明・追加日時・ファイルパスを確認 | 不要なブートイメージを整理し、クライアントが取得するイメージを一本化 |
| 生成元 Share が意図と違う | Production と Lab、複数 Share が混在していると、別 Share で作った WinPE を使ってしまう | boot.wim をマウントして Bootstrap.ini の DeployRoot を確認 | Share の統一、WDS 登録の見直し |
| boot.wim 自体に古い Bootstrap.ini が入っている | Update Deployment Share が正しく反映できていない、または生成物が差し替わっていない | WIM をマウントし、X:\Deploy\Scripts などを確認（格納場所は構成により変動） | 生成手順の再確認（それでも残るなら Share の再作成が早い） |
| 端末側の作業領域（MININT）が残っている | 再起動を跨いだときに、以前の情報を参照してしまう議論がある | C:\MININT の残存確認（WinPE/OS 側） | 必要なら削除して再試行（ただし根治策ではないことが多い） |
上記は「よくある」切り分けですが、今回のようにブートイメージも PXE 側も一通り作り直しているのに、なお古い資格情報が出続ける場合、最短で確実なのは次の結論に行き着きます。
結論：Deployment Share を丸ごと作り直す
最終的に効いた解決策はシンプルです。問題の WinPE ISO/WIM を生成している Deployment Share 自体を完全削除し、新規に作成し直す。そして、新しい Share で Update Deployment Share（ブートイメージ再生成）を実行し、生成された boot.wim を WDS に登録し直す。これで「古い（テスト用の）資格情報」を引きずる状態が断ち切れます。
ポイントは、boot.wim を再生成・再登録しても、Share 側に残っている何らかの状態が引きずられていた可能性があることです。MDT の設定は ini だけではなく、Share 配下の複数ファイル（設定や生成物、キャッシュ、DB 連携の有無）にまたがります。目に見える Boot フォルダだけを消しても、想定外の箇所が“古い情報の出どころ”になっていると、結果的に同じ症状が再現し得ます。
もちろん「なぜ Share を作り直すと直るのか」は環境依存で、完全に特定できないことも多いです。ただ、運用現場で重要なのは再現性のある確実な復旧手順です。特に本番展開が止まっているなら、根本原因の追跡に時間を溶かすより、短時間で止血できる手順を持っていることが価値になります。
実施手順：Share 再作成から WinPE 再生成、WDS 再登録まで
「Share を消して作り直す」と言っても、ただ削除すると作業量が増えます。現実的には、必要なものを退避しつつ、新しい Share に移植して復旧する流れが安全です。ここでは実務で困らない粒度で手順を整理します。
事前に退避しておくもの
環境によって必要な範囲は異なりますが、最低限次の要素は整理しておくと復旧がスムーズです。
| 退避対象 | 例 | 理由 | 注意点 |
|---|---|---|---|
| 設定ファイル | Bootstrap.ini / CustomSettings.ini | Share 再作成後に同じ挙動を再現するため | 資格情報は取り扱いに注意（バックアップの保存先も含めて） |
| タスクシーケンス | OS 展開 TS、アプリ導入 TS など | 作り直しコストが大きい | 依存するアプリ、ドライバ、スクリプトの参照先もセットで確認 |
| アプリケーション | Office、ブラウザ、エージェント類 | 導入パッケージの再登録が手間 | UNC パス参照の場合は Share 変更で影響することがある |
| ドライバ | 機種別ドライバ一式 | 再インポートが重い | Selection Profile/DriverGroup の設計をメモしておく |
| 独自スクリプト | CustomScripts、ポスト処理 | 現場固有の差分 | 最新版がどこか分からなくなりやすいので整理しておく |
手順の全体像
| フェーズ | 作業 | 成功判定 |
|---|---|---|
| 1 | 旧 Deployment Share の構成を控える（パス、Share 名、権限、Rules） | 新 Share へ同等に移植できる情報が揃う |
| 2 | 旧 Share を完全削除（必要ならフォルダ名を変えて退避でも可） | 古い状態を参照しないことが担保される |
| 3 | 新規 Deployment Share を作成 | Deployment Workbench で開ける |
| 4 | Bootstrap.ini / CustomSettings.ini を再設定 | DeployRoot と資格情報が意図通り |
| 5 | 必要な TS/アプリ/ドライバ/スクリプトを移植 | タスクシーケンスが通る状態になる |
| 6 | Update Deployment Share を実行（boot.wim 再生成） | 新しい boot.wim が生成される |
| 7 | WDS に新 boot.wim を登録（古いものは無効化/削除） | PXE で新 WinPE が起動する |
| 8 | 動作確認（Share 接続・資格情報・TS 実行） | 古い資格情報が出ず、正常に展開が進む |
Bootstrap.ini の確認ポイント
資格情報の誤反映が疑われる時は、いったん最小構成で考えるのが有効です。Bootstrap.ini の役割は「WinPE が DeployRoot に到達する」ことなので、最低限この要素が正しいことが重要です。
[Settings]
Priority=Default
[Default]
DeployRoot=\\MDT01\DeploymentShare$
UserDomain=CONTOSO
UserID=MDT_Build
UserPassword=********
SkipBDDWelcome=YES
上記は例です。特に DeployRoot が本当に意図した Share か、そして UserID/UserPassword が更新されているかを確認します。さらに、Update Deployment Share 後に生成された boot.wim にこの内容が埋め込まれているか（古い UserID が残っていないか）も合わせてチェックすると、問題の層が「Share なのか、WDS なのか、端末なのか」が分かりやすくなります。
boot.wim に埋め込まれた情報を「目で見て」確認する（DISM でマウント）
「Update Deployment Share を実行した」「Boot フォルダも消した」――それでも直らない時ほど、生成物（boot.wim）に何が入っているかを確認するのが効果的です。設定ファイルは更新した“つもり”でも、WIM の差し替え漏れや別イメージの参照で、古い Bootstrap.ini を起動し続けていることがあります。
代表的な確認手順は次の通りです（パスは環境に合わせて読み替えてください）。
- MDT サーバー上で、新しく生成された LiteTouchPE_x64.wim（または x86）を作業用フォルダにコピーする
- 管理者権限のコマンドプロンプトで、マウント用フォルダを作成する
- DISM で WIM をマウントし、Deploy フォルダ配下の Bootstrap.ini を探す
- UserID/UserPassword/DeployRoot が意図した値になっているかを確認する
- 確認後はアンマウント（確認だけなら破棄で OK）する
mkdir C:\Mount
dism /Mount-Wim /WimFile:"D:\LiteTouchPE_x64.wim" /Index:1 /MountDir:"C:\Mount"
rem 例：Bootstrap.ini を探す（dir /s を使う、エクスプローラー検索でも可）
dir C:\Mount\Bootstrap.ini /s
dism /Unmount-Wim /MountDir:"C:\Mount" /Discard
ここで「WIM 内には新しい資格情報が入っている」のに、PXE 起動すると古い資格情報が出る場合、原因の主戦場は WDS 側（古い boot.wim を配っている、メニューで別イメージが選ばれている）に寄っていきます。逆に、WIM の中身自体が古いなら、Share 側の生成プロセス（Update の種類、生成先、参照している Share）を疑うのが筋です。
WDS 側で「古い boot.wim を配らない」ための整理チェック
WDS は柔軟な反面、運用が長くなるとブートイメージが増えて混在しがちです。意図せず古いイメージが選ばれると、どれだけ Share 側を頑張って更新しても直りません。次の観点で棚卸ししておくと安全です。
| チェック項目 | 確認のしかた | 事故りやすいパターン | おすすめの整理 |
|---|---|---|---|
| ブートイメージの本数 | WDS コンソールの「ブート イメージ」を一覧 | テスト用が残り、本番端末が誤って選択 | 本番は 1 本に集約し、テスト用は明確な名称（TEST/OLD）を付ける |
| x86/x64 の取り違え | ファイル名・説明・アーキテクチャを確認 | 端末によってメニューに出る順が変わり混乱 | 基本は x64 に寄せ、不要な x86 は無効化/削除 |
| 置き換え漏れ | boot.wim の更新日時、説明欄に生成日を入れる | 同名に見えるが実体が古いまま | 登録前にファイルを別名で管理（例：LiteTouchPE_x64_YYYYMMDD.wim） |
| PXE メニューでの選択 | 起動時のメニュー表示を確認 | オペレーターが慣れで古い方を選ぶ | 古いイメージを非表示にする、説明を「使用禁止」にする |
Share 再作成時に見落としやすい「権限」
Share を作り直した直後に「今度は資格情報は正しいのにアクセス拒否になる」ことがあります。これは Share/NTFS 権限がゼロからになるためです。ここでは考え方だけ押さえておきます。
| 対象 | 最低限の考え方 | 例（あくまで一例） | 注意点 |
|---|---|---|---|
| 共有（Share）権限 | Share レベルは大雑把にし、NTFS で締める運用が多い | 読み取りを広め、フルは管理者のみ | 組織ポリシーにより「Share でも強く制限」が必要な場合あり |
| NTFS 権限 | 展開用アカウントが読み取りできることが必須 | MDT_Build：Read、管理者：Full | ドライバ/アプリの格納場所が Share 外 UNC の場合は別途権限が要る |
よくある質問
Share を完全削除するのが怖い場合は？
フォルダを削除せず、いったん別名にリネームして退避し、新規フォルダで Share を作り直す方法でも「古い状態を参照しない」目的は達成できます。重要なのは、WinPE が参照する DeployRoot が新 Share を向いていること、そして WDS が新 boot.wim を配っていることです。
Share 再作成がどうしても難しい場合は？
時間が取れない、移植する要素が多すぎる、といった事情もあります。その場合は、（1）WIM の中身が最新か確認、（2）WDS が配布しているイメージを一本化、（3）Update Deployment Share を「最適化」ではなく「完全再生成」に寄せる、といった順に“状態のリセット度合い”を上げていくのが現実的です。それでも古い資格情報が出続けるなら、結局は Share 再作成が最短ルートになります。
補足：C:\MININT を疑う場合の考え方
議論としてよく出るのが、WinPE の作業領域として使われる C:\MININT（または X:\MININT）の残存です。たとえば、途中で失敗して再起動を繰り返した端末で、MININT 配下に残った情報が次回起動時の挙動に影響するのでは、という話です。
実際、切り分けとして「MININT を削除してから再試行」はやって損はありません。ただし、今回のケースでは最終解決は Share の再作成でした。つまり、MININT を消しても根治しないタイプが存在します。端末側の掃除で直らないなら、生成元（Share）側の状態を疑う、という判断軸を持っておくと時間を節約できます。
それでも不安な人向け：再発を防ぐ運用のコツ
資格情報トラブルは、直った後に「また別の日に再発」すると心理的ダメージが大きいので、運用面のガードも入れておくのがおすすめです。
| 運用のコツ | 狙い | 具体例 |
|---|---|---|
| 専用の展開用アカウントを使う | 権限過多やパスワード変更の影響を最小化 | Share の読み取り＋必要最小限の権限だけ付与。Domain Admin を使わない |
| 資格情報の変更履歴を残す | 「いつからおかしい？」を即答できる | Bootstrap.ini の変更日、変更者、理由をチケットや運用メモに残す |
| WDS のブートイメージを棚卸しする | 古い boot.wim が混在する事故を防ぐ | 本番用は 1 本に集約。テスト用は名前と説明に明確に残す |
| boot.wim の中身で最終確認する | 「設定したつもり」を排除する | 生成後の WIM をマウントし、Bootstrap.ini/DeployRoot を実ファイルで確認 |
| 展開前に Share 接続だけをテストする | タスクシーケンス開始前に問題を潰す | WinPE 起動直後に手動で net use 相当の確認を行い、到達性を確かめる |
まとめ
MDT 2013 の WinPE が「古い（テスト用の）資格情報」で Deployment Share に接続してしまう問題は、Bootstrap.ini / CustomSettings.ini を正しく直しても解決しないことがあります。boot.wim の再生成・WDS 再登録まで試しても改善しないなら、生成元である Deployment Share を丸ごと作り直すのが最も確実な回避策になります。
トラブル時は、まずログ（BDD.log など）で「実際にどの資格情報で接続を試みたか」を確認し、切り分けの軸を作ること。そして、最短で復旧する必要がある局面では、Share 再作成という“確実に状態をリセットする手段”を選べるようにしておくと、運用が安定します。
コメント