WDSでbootunattend.xmlが効かない原因と解決策｜Windows Server 2019のWinPE無人応答をBIOS/UEFI別に設定

Windows Server 2019 の WDS（Windows Deployment Services）で PXE 展開を自動化しているのに、installunattend.xml は効くのに bootunattend.xml（WinPE 側）だけがまったく適用されない――そんなときは、XMLの中身より先に「WDS のクライアントアーキテクチャ割り当て」を疑うのが最短ルートです。

起きている現象を整理する（「インストール側は動くのに、WinPE側だけ動かない」）

WDS の自動展開でつまずきやすいのが、boot イメージ（WinPE）で使う無人応答ファイルと、install イメージ（OS セットアップ）で使う無人応答ファイルが別物で、しかも適用のされ方が違う点です。

種類	一般的なファイル名	効くタイミング	主な役割	よくある症状
ブート（WinPE）側	bootunattend.xml （WDSクライアント無人応答）	PXE 起動 → WinPE 起動直後	WDS サーバーへのログイン、イメージ選択の自動化、必要ならディスクの選択など	資格情報プロンプトが消えない／イメージ選択画面が出る／何も自動化されない
インストール（OS）側	installunattend.xml	Windows セットアップ開始以降	パーティション構成、プロダクトキー、地域設定、ローカル管理者、ドメイン参加、初期設定など	OS 展開後の初期設定が自動になる（ここは動いている）

質問の状況（installunattend.xml は正常、しかし bootunattend.xml が一切効かない）は、まさに「WinPE が応答ファイルを読んでいない」パターンです。XMLの文法ミスならログに痕跡が出たり、一部だけ効いたりしますが、“まったく適用されない”場合は、そもそも参照されていない可能性が高いです。

結論：原因は「WDS のクライアントアーキテクチャ割り当て先が合っていない」

WDS の「無人応答ファイル（ブート用）」は、端末の起動方式（UEFI/レガシーBIOS）や、PXE のクライアントアーキテクチャとして WDS が認識した種別ごとに、適用先が分かれています。

そのため、想定していた側（例：x64）にだけ bootunattend.xml を割り当てて、実際に PXE 起動してくる端末が別のアーキテクチャ側（例：x86 として扱われる）に分類されると、WinPE 起動時に bootunattend.xml は読み込まれません。

ここがハマりポイントで、特に現場で多いのが次のズレです。

端末の CPU が 64bit でも、PXE 起動がレガシーBIOSだと、WDS 的には「x86 側の設定」が参照されるケースがある
つまり「64bit 端末だから x64 に設定すればいい」という発想が、そのまま通らない

このズレが起きると、installunattend.xml は効くのに、bootunattend.xml だけ効かないという、分かりにくい状態になります（OS セットアップ側は、WDS のクライアントアーキテクチャ設定とは別レイヤーで動くためです）。

なぜズレるのか（WDS の “アーキテクチャ” は CPU ではなく「PXE の申告」寄り）

WDS が「どの無人応答ファイルを使うか」を決めるときに見ているのは、ざっくり言うとクライアントが PXE で申告してくるアーキテクチャです。これは、PC の CPU が 64bit かどうかというよりも、ファームウェア（UEFI/BIOS）がどの方式でブートローダーを取りに来るかの影響を強く受けます。

実務で理解しやすいように、よくある対応関係を表にすると次のイメージです。

端末の起動方式	端末の体感	WDS が参照しがちな側	現象	対策の方向性
レガシーBIOS（非UEFI）	「普通の PXE」	x86 側	x64 にだけ設定した bootunattend.xml が無視される	x86 側にも bootunattend.xml を割り当てる
UEFI（x64）	「UEFI PXE」	x64 側	x64 に設定してあれば適用されやすい	x64 側の割り当てを確認
混在（端末ごとに UEFI/BIOS がバラバラ）	「同じ機種でも設定が違う」	x86/x64 が混在	ある端末だけ効かない、再現性が低い	両方に割り当て、まず切り分け

ポイントは、WDS の “クライアントアーキテクチャ” と、配布している boot.wim（WinPE）のビット数が一致しているとは限らないことです。たとえば「x64 の WinPE を配布しているのに、WDS 側は x86 側の無人応答を見に行く」という状況が、現実に起こり得ます。

まず最初に確認すべきチェックポイント（XMLより先に見る）

「最小構成（ドメイン資格情報だけ）の XML でも効かない」場合、XML の内容をいじり続けるより、次の “WDS 側の割り当て” を先に潰すと早いです。

チェック項目	見る場所	狙い	よくある落とし穴
無人インストールの有効化	WDS サーバーのプロパティ →［クライアント］	そもそも WDS が無人応答を使う設定か確認	有効化しても “片側のアーキテクチャだけ” に設定している
アーキテクチャごとの割り当て	同上（x86/x64 それぞれの欄）	端末が参照する側にファイルが割り当てられているか	UEFI 想定で x64 にだけ割り当て、実機が BIOS 起動
ファイルの配置場所	RemoteInstall 配下（推奨は WdsClientUnattend）	WDS が参照できる場所にあるか	別ドライブや別パスに置いて参照できていない
ファイル名の運用	運用ルール	x86/x64 の取り違えを防ぐ	bootunattend.xml を 1 つだけ置いて、何に割り当てたか分からなくなる

ここまで見て、「x64 側には設定しているけど x86 側が空」で、しかも端末が BIOS（非UEFI）起動の可能性があるなら、原因はほぼこれです。

対処手順：該当するアーキテクチャすべてに bootunattend.xml を割り当てる

対処はシンプルで、WDS 側で “端末が参照する（可能性のある）アーキテクチャ” に対して bootunattend.xml を設定するだけです。混在環境や切り分け段階では、迷ったら x86/x64 両方に割り当てるのが確実です。

手順（WDS 管理コンソールでの設定）

WDS サーバーで Windows Deployment Services（wds.msc）を開く
サーバーを右クリック → ［プロパティ］
［クライアント］タブを開く
「無人インストールを有効化」にチェック
アーキテクチャごとの欄（例：x86、x64）それぞれで、bootunattend.xml を指定する
混在・不明な場合は、まず x86 と x64 の両方に同等の内容のファイルを割り当てて再テストする

このとき、ファイルの置き方を整理しておくと、後から自分も他の担当者も迷いません。

推奨フォルダ例	ファイル例	意図
RemoteInstall\WdsClientUnattend\x86\	WDSClientUnattend_x86.xml	x86 側に割り当てるものを明確化
RemoteInstall\WdsClientUnattend\x64\	WDSClientUnattend_x64.xml	x64 側に割り当てるものを明確化
RemoteInstall\WdsClientUnattend\common\	WDSClientUnattend_common.xml	切り分け用に同一設定を流す（運用で使うなら注意）

「RemoteInstall 配下に置いたのに効かない」という場合でも、実際は “置き場所” より “割り当て先” が外れていることが多いです。WDS の設定画面で、該当アーキテクチャの欄にファイルが入っているかを最優先で確認してください。

実務的に効く「切り分けのコツ」（最小 XML でも効かないときの進め方）

現場では、いきなり完全自動（ログイン・イメージ選択・ディスク・プロダクトキー…）まで作り込むより、最小の目的から順番に “効いているか” を確認した方が早いです。

切り分けの順番（おすすめ）

段階	やること	成功のサイン	失敗時に疑う場所
Step 1	WDS で x86/x64 両方に bootunattend を割り当てる	どの端末でも WinPE の挙動が変わる	割り当て先ミス、別サーバー見ている、別 WDS から起動
Step 2	最小構成（資格情報だけ）でテスト	ログイン画面がスキップされる/自動入力される	アーキテクチャ不一致、ファイル参照不可、XML 破損
Step 3	イメージ選択の自動化を追加	対象のイメージが自動選択される	ImageGroup 名や ImageName の取り違え
Step 4	installunattend と接続し、OS 側の自動化へ	OS セットアップが無人で進む	イメージ側の unattend 割り当て、パス、コンポーネント

Step 1 の時点で挙動が変わらないなら、XML の内容以前に “WDS がファイルを使っていない” 可能性が高いです。逆に Step 1 で変化が出れば、以降は XML の設計・値の調整に集中できます。

「両方に同じファイルを割り当てる」場合の注意点（意外とここで再ハマりする）

切り分け目的なら、x86/x64 両方に同じ bootunattend.xml を割り当てるのは有効です。ただし、bootunattend.xml の中には processorArchitecture が関係するコンポーネントが登場します。ここがズレると、今度は「読み込まれているのに効かない」状態になります。

運用を安定させるなら、次のどちらかが安全です。

方式A：x86 用と x64 用にファイルを分ける（最も分かりやすく、事故が少ない）
方式B：1つの XML に x86/amd64 の両方の component を入れて共存させる（ファイルは 1 つで済むが、編集時の注意が必要）

WDS 側の表記	unattend.xml 側の processorArchitecture の代表	メモ
x86	x86	レガシーBIOS 端末がここに寄るケースがある
x64	amd64	UEFI x64 の端末はここが参照されやすい

「両方に同じファイルを割り当てたのに効かない」となったら、“WDS が参照する側は合ったが、XML 内の component 側のアーキテクチャが合っていない”という二段構えの可能性も出てきます。切り分けの初期段階では、ファイルを分けてしまうのが最短です。

最小構成の bootunattend.xml 例（資格情報だけを入れて動作確認する）

ここでは、まず “効いているかどうか” を確認するために、WDS へのログイン資格情報だけを入れた最小例を載せます。環境に合わせて、ドメイン名やユーザー名を置き換えてください。

注意：無人応答ファイルに資格情報を入れることは、運用上のリスク（情報漏えい）を伴います。切り分けが終わったら、権限の最小化（展開専用アカウント、OU/権限の制限）や、運用ルール（ファイルのアクセス制御、保管方法）を必ず見直してください。

&lt;?xml version="1.0" encoding="utf-8"?&gt;
&lt;unattend xmlns="urn:schemas-microsoft-com:unattend"&gt;
  &lt;settings pass="windowsPE"&gt;

    &lt;!-- x64(amd64) 用：UEFI x64 など --&gt;
    &lt;component name="Microsoft-Windows-Setup"
               processorArchitecture="amd64"
               publicKeyToken="31bf3856ad364e35"
               language="neutral"
               versionScope="nonSxS"&gt;
      &lt;WindowsDeploymentServices&gt;
        &lt;Login&gt;
          &lt;Credentials&gt;
            &lt;Domain&gt;CONTOSO&lt;/Domain&gt;
            &lt;Username&gt;wdsdeploy&lt;/Username&gt;
            &lt;Password&gt;P@ssw0rd&lt;/Password&gt;
          &lt;/Credentials&gt;
        &lt;/Login&gt;
      &lt;/WindowsDeploymentServices&gt;
    &lt;/component&gt;

    &lt;!-- x86 用：レガシーBIOS 端末が参照することがある --&gt;
    &lt;component name="Microsoft-Windows-Setup"
               processorArchitecture="x86"
               publicKeyToken="31bf3856ad364e35"
               language="neutral"
               versionScope="nonSxS"&gt;
      &lt;WindowsDeploymentServices&gt;
        &lt;Login&gt;
          &lt;Credentials&gt;
            &lt;Domain&gt;CONTOSO&lt;/Domain&gt;
            &lt;Username&gt;wdsdeploy&lt;/Username&gt;
            &lt;Password&gt;P@ssw0rd&lt;/Password&gt;
          &lt;/Credentials&gt;
        &lt;/Login&gt;
      &lt;/WindowsDeploymentServices&gt;
    &lt;/component&gt;

  &lt;/settings&gt;
&lt;/unattend&gt;

この状態で PXE 起動し、これまで資格情報入力が必要だった画面が変化するなら、bootunattend.xml が読み込まれ始めたと判断できます。次にイメージ選択の自動化やインストール先ディスクの指定へ進むのが安全です。

「UEFI のつもりだったのに BIOS だった」問題を潰す（現場で一番多い）

今回の本筋である「割り当て先アーキテクチャ違い」は、根っこを辿ると端末が実際にどの方式で PXE 起動しているかの認識違いで発生します。特に、次のような現場あるあるが重なると、かなり高確率でハマります。

キッティング手順書は UEFI 前提だが、実機の BIOS 設定が工場出荷状態のまま
同一機種でも、部署や拠点ごとに BIOS 設定がバラついている
「UEFI PXE」と「Legacy PXE」が似た名前で並び、作業者が選び間違える
USB/LAN アダプタ経由の PXE で、UEFI 対応状況が混在する

対策としては、WDS の設定だけでなく、端末側の “起動方式の統一” もセットで考えると、後からのトラブルが減ります。

目的	おすすめ	理由
運用を安定させたい	UEFI（可能なら Secure Boot 方針も含めて）に統一	新しい機種ほど UEFI が前提になり、トラブルシュートが単純化しやすい
混在で当面は回したい	x86/x64 両方に bootunattend を割り当てて吸収	端末側の差分に引きずられず、WDS 側でまず自動化を成立させられる
原因の切り分けを急ぎたい	まずは同一端末で UEFI/BIOS を切り替えて挙動比較	“WDS の割り当て先が変わる” ことを体感でき、再発防止の理解が深まる

ログで裏取りする（「本当に読み込まれていない」の確証を得る）

設定変更を繰り返していると、「効いていないのか／効いたけど別の理由で止まったのか」が曖昧になりがちです。確証を持って進めたい場合は、次の観点でログを確認すると整理しやすいです。

WDS サーバー側のイベントログ：PXE でどのアーキテクチャとして処理されたか、どのブートプログラムが返されたかの手がかりになる
クライアント（WinPE）側の挙動：WDS クライアント UI がどこまで自動化されているか（ログイン・イメージ選択の有無）で判断する

特に「割り当て先アーキテクチャ違い」が原因の場合は、XML の誤りというより参照されるはずの設定に到達していないので、サーバーログの方がヒントになりやすいです。

この症状のときにやりがちな遠回り（先に知っておくと時間が浮く）

bootunattend.xml が効かないと、つい次の方向に時間を使ってしまいがちです。しかし今回のように “割り当て先違い” が原因だと、これらをいくら直しても状況は変わりません。

やりがちなこと	なぜ遠回りになりやすいか	先にやるべきこと
XML を最小化して何度も入れ替える	そもそも参照されていなければ、最小化しても結果は同じ	x86/x64 の割り当て欄を両方埋める
RemoteInstall 配下の置き場所を変え続ける	配置より “割り当て先” が外れていると意味がない	WDS コンソールで割り当て先の欄を確認
installunattend を疑って調整する	install 側が動いているなら論点が違う	WinPE 側（WDS クライアント）の設定に集中
ブートイメージ（boot.wim）の再生成	WinPE 自体の問題ではなく、WDS の適用先問題のことが多い	まず割り当て先を正し、それでもダメなら boot.wim を疑う

再発防止：WDS の運用で “取り違え” を起こさない設計にする

一度解決しても、端末更新・拠点追加・担当交代のタイミングで同じ罠に戻ることがあります。再発防止としては、「どの端末がどの方式で PXE 起動しても、最低限の自動化が効く」状態を設計しておくのが強いです。

まとめ：WinPE 側だけ効かないときは「割り当て先アーキテクチャ違い」を最優先で疑う

WDS の無人展開で、installunattend.xml は動くのに bootunattend.xml（WinPE 用）がまったく効かない場合、原因は XML の内容ではなく、WDS の「クライアントアーキテクチャ（BIOS/UEFI を含む分類）」に対する割り当てミスであることが少なくありません。

迷ったらまずはx86/x64 の両方に bootunattend.xml を割り当てて挙動が変わるかを確認し、そこから最小構成→イメージ選択→完全自動化の順に積み上げるのが、最も短く・再現性の高い進め方です。

この記事を書いた人

佐藤健司

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

WDSでbootunattend.xmlが効かない原因と解決策｜Windows Server 2019のWinPE無人応答をBIOS/UEFI別に設定

起きている現象を整理する（「インストール側は動くのに、WinPE側だけ動かない」）

結論：原因は「WDS のクライアントアーキテクチャ割り当て先が合っていない」

なぜズレるのか（WDS の “アーキテクチャ” は CPU ではなく「PXE の申告」寄り）

まず最初に確認すべきチェックポイント（XMLより先に見る）

対処手順：該当するアーキテクチャすべてに bootunattend.xml を割り当てる

手順（WDS 管理コンソールでの設定）

実務的に効く「切り分けのコツ」（最小 XML でも効かないときの進め方）

切り分けの順番（おすすめ）

「両方に同じファイルを割り当てる」場合の注意点（意外とここで再ハマりする）

最小構成の bootunattend.xml 例（資格情報だけを入れて動作確認する）

「UEFI のつもりだったのに BIOS だった」問題を潰す（現場で一番多い）

ログで裏取りする（「本当に読み込まれていない」の確証を得る）

この症状のときにやりがちな遠回り（先に知っておくと時間が浮く）

再発防止：WDS の運用で “取り違え” を起こさない設計にする

おすすめの運用ルール

まとめ：WinPE 側だけ効かないときは「割り当て先アーキテクチャ違い」を最優先で疑う

この記事を書いた人

コメント

コメントするコメントをキャンセル

WDSでbootunattend.xmlが効かない原因と解決策｜Windows Server 2019のWinPE無人応答をBIOS/UEFI別に設定

起きている現象を整理する（「インストール側は動くのに、WinPE側だけ動かない」）

結論：原因は「WDS のクライアント アーキテクチャ割り当て先が合っていない」

なぜズレるのか（WDS の “アーキテクチャ” は CPU ではなく「PXE の申告」寄り）

まず最初に確認すべきチェックポイント（XMLより先に見る）

対処手順：該当するアーキテクチャすべてに bootunattend.xml を割り当てる

手順（WDS 管理コンソールでの設定）

実務的に効く「切り分けのコツ」（最小 XML でも効かないときの進め方）

切り分けの順番（おすすめ）

「両方に同じファイルを割り当てる」場合の注意点（意外とここで再ハマりする）

最小構成の bootunattend.xml 例（資格情報だけを入れて動作確認する）

「UEFI のつもりだったのに BIOS だった」問題を潰す（現場で一番多い）

ログで裏取りする（「本当に読み込まれていない」の確証を得る）

この症状のときにやりがちな遠回り（先に知っておくと時間が浮く）

再発防止：WDS の運用で “取り違え” を起こさない設計にする

おすすめの運用ルール

まとめ：WinPE 側だけ効かないときは「割り当て先アーキテクチャ違い」を最優先で疑う

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

結論：原因は「WDS のクライアントアーキテクチャ割り当て先が合っていない」

コメントするコメントをキャンセル