Proxmoxで学ぶ Windows Server AD #1 最短初期AD構築まで

Ndictです。

Proxmox上にWindows Serverを立てて色々検証していきます。

Proxmox VE上にWindows ServerとWindows 11 Proの検証用VMを構築しました。
本稿はその手順と設定要点を、実際につまずいた箇所や検証ポイントまで含めて丁寧にまとめたものです。
次にActive Directory(AD)の基本構成作業に進みます。

この記事のゴール

• Proxmox VE(9.0.3)上でWindows Server 2008 R2 / 2016 / 2019とWindows 11 Proを安定起動できる。
• 次回のAD構築に向け、DNSと時刻同期などの前提を整理し、検証観点を押さえる。
• VirtIOドライバやUEFI/TPM/SecureBootなど、Windows 11特有の前提を理解する。

VM設定

Proxmox上でWindows 11 Proを扱うのは初めてだったので、その点にかなり時間を要しました。

設定は以下の通りです。

Windows Server 2008 R2

Windows Server 2016

Windows Server 2019

Windows 11 Pro

VM 設定の詳細ポイント

• ハードディスク: VirtIO SCSI + Write back キャッシュを選択。
• CD/DVD ドライブ:
  • 1つ目: Windows 11 ISO（公式配布の 24H2）
  • 2つ目: VirtIO ドライバ ISO（Fedora 公式 virtio-win-0.1.271.isoを採用）
• UEFI/TPM: OVMF（EFIディスク4MB）+ TPM2.0
• SecureBoot: 有効（Windows 11の要件準拠）
• ブート順: Windows ISO → VirtIO ISO → HDD

つまずいたポイントと解決策

• ディスクがインストーラに表示されない
  • 原因: Windows 11 の標準インストーラには VirtIO ドライバが含まれていないため、VirtIO ディスクを認識できない。
  • 解決策: Fedora 公式の virtio-win.iso を用意し、インストーラ中に「ドライバの読み込み」で VirtIO ドライバを追加する。これにより仮想ディスクが表示される。

Fedora 公式 virtio-win.iso の使用方法（具体手順）

1. Fedora 公式サイトから virtio-win.iso をダウンロード。
2. Proxmox のストレージ（例: local/iso）にアップロード。
3. VM 設定で 追加の CD/DVD ドライブ を作成し、そこに virtio-win.iso を割り当てる。
4. Windows セットアップ画面で「ドライバの読み込み」を選択。
5. VirtIO ISO 内のストレージドライバを指定し、仮想ディスクを認識させる。
6. 以降は通常通り Windows 11 のインストールが進行可能になる。

まとめ

• IDE は使わず、SATA または VirtIO SCSI を選択することが必須。
• VirtIO ドライバ ISO（virtio-win.iso）をインストール時に必ず併用する。
• TPM 2.0 と OVMF を有効化し、Windows 11 の要件を満たす。
• ブート順を正しく設定し、Windows ISO を最優先にする。

AD構築

次にAD構築を実施します。

構成と前提

• ドメイン名: test.local(テスト用)
• サブネット: 192.168.1.0/24
  • DC1: 192.168.1.A1/24（優先DNS=自分=A1, 代替DNS=DC2=B1）
  • DC2: 192.168.1.B1/24（優先DNS=自分=B1, 代替DNS=DC1=A1）
  • Windows 11 クライアント: DNS は DC のみ（優先=A1, 代替=B1）
• DNS リゾルバー方針
  • フォワーダー: 192.168.1.1
  • 再帰: 有効（Enable=True）
  • ルートヒント: 有効（フォワーダー不達時にフォールバック）

注: A1/B1 は「ホスト部」のプレースホルダです。実環境の数値で読み替えてください（例: A1=30, B1=40 など）。

1) DC1 構築（新規フォレスト／ドメイン作成）

1. NICを固定（IP=192.168.1.A1、DNS=自分=192.168.1.A1）。
2. 役割追加で、Active Directory ドメイン サービス（AD DS）とDNSサーバーを選択。
3. 構成ウィザードで「新しいフォレストを追加」→ ルートドメイン名にtest.localを指定。完了後に自動再起動。
4. 旧ホスト名由来の不要Aレコードを整理し、dc1とtest.localを正とする（nslookup / Resolve-DnsName で検証）。
5. 外向き解決: フォワーダーに192.168.1.1を設定（上流 DNS）。ルートヒントはフォールバック用途で保持。
6. 時刻同期（PDC エミュレーター）を外部NTPに設定し、同期確認。
   
   w32tm /config /manualpeerlist:"ntp.nict.jp,0x8" /syncfromflags:manual /reliable:yes /update w32tm /resync w32tm /query /status

   1 2 3

   w32tm /config /manualpeerlist:"ntp.nict.jp,0x8" /syncfromflags:manual /reliable:yes /update w32tm /resync w32tm /query /status

7. DNS健全化（不要 A の整理、dc1/test.localの正引き・逆引き、SOA/NSの整合性確認）。
8. 逆引きゾーンの作成: 1.168.192.in-addr.arpaをAD 統合ゾーンで作成し、PTR登録を確認。

2) DC2 準備（メンバー参加 → DC 昇格）

1. NIC固定（IP=192.168.1.B1）。DNSは一時的にDC1(A1)のみを指定。
2. ドメイン参加（test.local）→ 再起動。
3. DC追加ウィザードで昇格（ローカル専用ドメインでの委任警告は継続可）。
4. 昇格前にDNS/SRV解決とDC検出（nslookup/nltest）で前提確認。
5. 時刻同期をドメイン階層へ、セキュアチャネル確認、必要ポート疎通確認。
   
   w32tm /config /syncfromflags:domhier /update w32tm /resync nltest /sc_reset:test.local nltest /sc_verify:test.local Test-NetConnection dc1.test.local -Port 135 Test-NetConnection dc1.test.local -Port 389 Test-NetConnection dc1.test.local -Port 445

   1 2 3 4 5 6 7

   w32tm /config /syncfromflags:domhier /update w32tm /resync nltest /sc_reset:test.local nltest /sc_verify:test.local Test-NetConnection dc1.test.local -Port 135 Test-NetConnection dc1.test.local -Port 389 Test-NetConnection dc1.test.local -Port 445

6. 昇格実行（優先=自分、代替=相手DC。127.0.0.1は残さない）。
   
   # 例: DC2側の最終設定 Set-DnsClientServerAddress -InterfaceAlias "イーサネット" -ResetServerAddresses Set-DnsClientServerAddress -InterfaceAlias "イーサネット" -ServerAddresses ("192.168.1.B1","192.168.1.A1")

   1 2 3

   # 例: DC2側の最終設定 Set-DnsClientServerAddress -InterfaceAlias "イーサネット" -ResetServerAddresses Set-DnsClientServerAddress -InterfaceAlias "イーサネット" -ServerAddresses ("192.168.1.B1","192.168.1.A1")

3) ヘルスチェック（レプリケーション／DNS／SYSVOL）

• レプリ状態

• DC検出: nltest /dsgetdc:test.local
• 逆引きゾーン（AD 統合）: 1.168.192.in-addr.arpa（=192.168.1.0/24）
• サイトとサブネット: 192.168.1.0/24 を適切なサイトへ割当。
• SYSVOL（DFSR）: dfsmgmt.msc／イベントログでエラーなしを確認。

4) DCのDNSクライアント設定

• 方針: 優先=192.168.1.A1、代替=192.168.1.B1。127.0.0.1 は残さない。
  
  # 例: DC2 側の最終設定 Set-DnsClientServerAddress -InterfaceAlias "イーサネット" -ResetServerAddresses Set-DnsClientServerAddress -InterfaceAlias "イーサネット" -ServerAddresses ("192.168.1.B1","192.168.1.A1")

  1 2 3

  # 例: DC2 側の最終設定 Set-DnsClientServerAddress -InterfaceAlias "イーサネット" -ResetServerAddresses Set-DnsClientServerAddress -InterfaceAlias "イーサネット" -ServerAddresses ("192.168.1.B1","192.168.1.A1")

• 後片付け: 旧A/PTR、重複 SRV、孤立 NS の整理。

5) クライアント（Windows 11 Pro）をドメイン参加

1. クライアントのDNSをDCのみに設定（優先=A1、代替=B1）。外部DNSは混在させない。
2. sysdm.cpl →［コンピューター名］→［変更］→ ドメイン test.local → test\Administrator → 再起動。
3. 動作確認：
   
   whoami /fqdn $env:LOGONSERVER

   1 2	whoami /fqdn $env:LOGONSERVER

   ※ログオン先がサイト/応答速度に応じて適切なDC（DC1/DC2）になっていることを確認。

検証ポイント（押さえどころ）

• DC1/DC2 の昇格とレプリが 失敗 0／エラー 0 で安定。
• クライアントは、サイト/SRV/応答速度で最寄り DC を選ぶため、$env:LOGONSERVER が DC1/2 いずれでも正常。
• 逆引き・サイト/サブネット・DNS フォワーダーは運用前に確定。

よくあったつまずきと回避策

• 「ドメインが見つからない」: 昇格や参加時の資格情報は ローカル.\Administratorではなく、test\Administrator（ドメイン管理者）。
• DC2 の DNS に 127.0.0.1 が残る → Set-DnsClientServerAddress で明示再設定（優先=自分, 代替=相手）。
• クライアントの DNS に外部 DNS を混在させない: ドメイン参加/ログオン不安定化の典型要因。常に DC のみ を指定。

まとめ

本稿では、Proxmox VE上で Windows Server（2008 R2 / 2016 / 2019）と Windows 11 Pro を安定起動させるための土台を整えました。
要点は、ディスクを VirtIO SCSI とし、インストール時に virtio-win.iso を読み込んでストレージドライバを適用すること、そして Windows 11 では OVMF（UEFI）+ TPM 2.0 + Secure Boot を満たしたうえで、適切なブート順を設定することです。
また、AD構築の際にはまず、DNS（フォワーダー／逆引き） と 時刻同期（PDC Emulator → 外部NTP） を先に明確化することで、DCの昇格やレプリケーション、クライアント参加まで問題なく進めることができると思います。

次回は、クライアント視点のフェイルオーバー検証をし、運用に役立つ知見へ落とし込んでいきます。