Windows Server 2016 の DHCP でフェールオーバーを構成しようとすると、スコープ選択やパートナー追加までは進むのに「次へ（Next）」がグレーアウトして止まることがあります。本記事では、原因の見分け方と最短の対処、さらに AD DS 承認（Authorize）の確認方法までまとめて解説します。
起きている現象：DHCP フェールオーバー作成ウィザードで「次へ（Next）」が押せない
DHCP フェールオーバー（Windows Server 2016 ↔ 2019 など）を構成する際、ウィザードの途中で「次へ（Next）」が無効（グレーアウト）になり、先に進めなくなるケースがあります。特に次のような状況だと「設定はできていそうなのに進めない」ため、原因が分かりづらくなりがちです。
| ウィザードでできていること | それでも止まるときの見え方 | よくある誤解 |
|---|---|---|
| スコープの選択ができる | 選択済みで、エラー表示もない | 「スコープが壊れている？」と思ってしまう |
| パートナー（例：Windows Server 2019）を追加できる | 名前解決も通り、候補にも出る | 「通信や権限は問題ないはず」と判断してしまう |
| リレーションシップ名も入力済み | 入力欄は埋まっているのに Next が押せない | 「UI の不具合？」と疑ってしまう |
結論から言うと、この症状は “入力が必須なのに未入力” の箇所があるときに起きやすく、しかもその箇所が意外と見落とされます。
最重要ポイント：原因の多くは「メッセージ認証 ON × Shared Secret 未入力」
DHCP フェールオーバー作成ウィザードで「次へ（Next）」が押せない原因として最も多いのが、次の組み合わせです。
- 「メッセージ認証を有効にする（Enable Message Authentication）」にチェックが入っている
- しかし、「共有シークレット（Shared Secret）」が未入力（空欄）
この状態だと、ウィザードは「設定として成立しない」ため Next を有効化できず、結果としてボタンがグレーアウトします。環境や手順によっては、このチェックが初期状態でオンになっていることもあり、「自分でチェックした記憶がないのに詰まる」という形でハマりがちです。
なぜ Shared Secret が必要なのか（簡単な理解）
フェールオーバー構成では、2 台の DHCP サーバー間でリース情報などを同期します。メッセージ認証を有効にする場合は、その同期メッセージが正当な相手からのものかを検証するために共有シークレット（共通のパスワード）が必要になります。チェックだけ入っていてパスワードが空欄だと「認証する前提なのに鍵がない」状態になるため、先に進めません。
対処方法：Next を押せるようにする手順（2 択）
対処はシンプルで、どちらかを行えば OK です。運用方針（セキュリティ重視か、まず動かすか）で選びましょう。
| 対処 | やること | おすすめのケース | 注意点 |
|---|---|---|---|
| 方法A | 「メッセージ認証を有効にする」のチェックを外す | まずは最短で構成を完了したい／閉域ネットワークで運用 | 後から認証を有効にしたい場合は、再設定の手順を考慮 |
| 方法B | チェックを付けたまま、Shared Secret を入力する | 標準的にはこちら（推奨）／同期通信をより安全にしたい | パスワード管理が必要（引き継ぎ・保管・変更手順） |
GUI（DHCP 管理コンソール）での具体的な操作手順
- DHCP サーバーで DHCP 管理コンソール（dhcpmgmt.msc）を開きます。
- 対象の IPv4 → 対象スコープを右クリックし、「フェールオーバーの構成（Configure Failover）」を選びます。
- スコープを選択して進み、パートナー（Windows Server 2019 など）を指定します。
- 設定画面の途中にある 「メッセージ認証を有効にする（Enable Message Authentication）」を確認します。
- 次のどちらかを実施します。
- 方法A：チェックを外す
- 方法B：チェックを入れたまま Shared Secret にパスワードを入力する
- 入力が成立すると、「次へ（Next）」が押せる状態になります。
Shared Secret を設定する場合の“実務で困らない”決め方
Shared Secret は「2 台間で共有する認証用のパスワード」なので、担当者交代や障害対応の場面で分からなくなると復旧が遅れます。強度と運用のバランスを取るのがポイントです。
- 長さ：12〜32 文字程度（短すぎない）
- 種類：英大文字・英小文字・数字・記号を混ぜる
- 保管：パスワード管理ツール or 権限管理された手順書に保管（個人メモは避ける）
- 変更：変更手順（いつ、誰が、どちらのサーバーで、どの順番で）を決めておく
「とりあえず同じ文字列を入れて動けばいい」でも短期的には動きますが、後から監査・引き継ぎで困りやすいので、運用まで含めて決めると安心です。
それでも Next が押せない場合の追加チェック（切り分け表）
Shared Secret を入力しても進めない、あるいは別の場所で詰まる場合は、次の観点で切り分けると解決が早くなります。
| チェック項目 | 確認ポイント | よくある原因 | 対処の方向性 |
|---|---|---|---|
| スコープ選択 | 実際にスコープが選択されているか | 選択が外れていた／対象が意図と違う | 対象スコープを再選択 |
| パートナー指定 | FQDN/ホスト名の解決ができるか | DNS 未整備、hosts 依存、誤入力 | 名前解決を正す（DNS 推奨） |
| 権限 | DHCP 管理権限があるか | ローカル管理者では不足する場面 | DHCP Administrators 等の権限確認 |
| 通信（FW） | サーバー間の必要通信が遮断されていないか | Windows Firewall / NW FW で遮断 | DHCP Failover 関連の許可、管理通信の見直し |
| 役割・サービス | 両方に DHCP 役割が入り、サービスが正常か | 役割未導入、サービス停止、依存関係 | 役割/サービスの状態確認 |
特に通信面は環境差が出やすいポイントです。フェールオーバーの同期はサーバー間通信が前提なので、サーバー間の疎通（名前解決・ルーティング・ファイアウォール）をセットで確認すると、遠回りになりません。
運用設計で差が出る：ロードバランスとホットスタンバイの選び方
ウィザードを進められるようになったら、次は “どう運用するか” を選びます。Windows の DHCP フェールオーバーは代表的に 2 方式があり、要件によって最適解が変わります。
| 方式 | 特徴 | 向いているケース | 注意点 |
|---|---|---|---|
| ロードバランス（Load Balance） | 平常時から 2 台で配布を分担 | 拠点内で 2 台とも稼働させたい／負荷分散したい | 割合（例：50/50）の設計が必要 |
| ホットスタンバイ（Hot Standby） | 通常は主系が配布、障害時に待機系が引き継ぐ | 主系を明確にしたい／運用を単純化したい | 切り替えタイミング（状態遷移）の設計が重要 |
「構成を通す」だけで終わらせず、障害時にどう切り替わるか（誰が何を確認し、いつ復旧判断するか）まで含めると、フェールオーバーの価値が出ます。
補足：DHCP サーバーが AD DS に承認（Authorize）されているかの確認方法
ドメイン環境で DHCP を運用する場合、DHCP サーバーは AD DS 上で承認（Authorize）されていないと、サービスが開始できなかったり、配布が停止したりすることがあります。フェールオーバー構成以前に、両方の DHCP サーバーが承認されているかを確認しておくと安全です。
GUI での確認：DHCP 管理コンソールから一覧を見る
- DHCP 管理コンソールを開きます。
- 左ペイン最上位の 「DHCP」 を右クリックします。
- 「承認済みサーバーの管理（Manage Authorized Servers）」を開きます。
- 一覧に対象サーバー（例：Windows Server 2016 と 2019）が表示されていれば、AD DS 側で承認されています。
ここに表示されない場合、ドメイン上では “未承認 DHCP” として扱われる可能性があります。権限（Enterprise Admin 相当）や AD の複製遅延などの要因も絡むため、承認作業と合わせて状況確認を行うのが現実的です。
PowerShell での確認：サーバー一覧をコマンドで取得する
GUI だと手順が多い、遠隔でまとめて確認したい、という場合は PowerShell が便利です。管理端末または DHCP サーバーで、以下を確認します。
Get-DhcpServerInDC承認済みの DHCP サーバーが一覧表示されます。想定しているサーバーが出てこなければ、承認が未実施か、別ドメイン/別フォレストを見ている可能性があります。
承認が必要で、権限も満たしている場合は次の形式で追加します（例）。
Add-DhcpServerInDC -DnsName "dhcp01.example.local" -IPAddress 192.168.10.10運用上は、承認作業は変更管理の対象にしておくとトラブルが減ります（いつ誰が承認したか追跡できるため）。
「承認済みサーバーの管理」が見当たらないとき
次のような環境では、そもそも AD DS 承認という概念が適用されない、または画面上の見え方が変わることがあります。
- DHCP サーバーがドメイン参加していない（ワークグループ運用）
- 管理コンソールを開いている端末がドメインに依存しない場所にある
- 権限不足でメニューや情報の取得が制限されている
「ドメイン環境で運用しているのに承認状況が追えない」場合は、まずはドメイン参加と権限（どのアカウントで作業しているか）を確認すると早いです。
フェールオーバー設定後に必ずやっておきたい確認（トラブル予防）
ウィザードが完了したら “できたつもり” で終わらず、最小限の動作確認を行うのがおすすめです。障害時に初めて不備が見つかるのが一番つらいパターンです。
確認するポイント
- DHCP コンソール上でフェールオーバー関係が表示されているか（サーバー配下に Failover が見えるか）
- 両サーバーでスコープが有効になっているか（片側だけ無効だと誤解しやすい）
- クライアントで IP 更新が正常に行えるか（更新・再取得でリースが発行されるか）
- イベントログにエラーが出ていないか（DHCP Server のログを確認）
簡易チェックリスト（現場向け）
| タイミング | チェック内容 | OK の目安 |
|---|---|---|
| 構成前 | 両 DHCP サーバーが AD DS で承認済み | 「承認済みサーバーの管理」または Get-DhcpServerInDC に表示 |
| 構成中 | メッセージ認証のチェック状態と Shared Secret | チェック ON なら Shared Secret 入力済み |
| 構成直後 | フェールオーバー関係が作成されている | DHCP コンソールで関係が確認できる |
| 運用開始 | クライアントで更新・再取得テスト | IP が配布され、更新でエラーにならない |
よくある質問（現場で詰まりやすいポイント）
メッセージ認証はオフでも問題ない？
機能としてはオフでもフェールオーバー自体は成立します。ただし、サーバー間同期の認証が弱くなる方向なので、ネットワーク分離が甘い環境や、内部不正・誤接続のリスクを少しでも下げたい場合は、オンにして Shared Secret を適切に管理する運用が無難です。
2016 と 2019 の混在は避けるべき？
混在で動かしている環境は少なくありませんが、運用上は次の方針が安定します。
- 同等の更新レベル（Windows Update の適用状況）を揃える
- ドメイン、DNS、時間同期（NTP）を整備する
- フェールオーバーの設計（負荷分散か待機系か）を先に決める
混在そのものよりも、基盤（DNS・FW・権限）に “揺らぎ” があるとトラブルが出やすい印象です。
Next がグレーアウトする＝バグ？
多くの場合はバグではなく、必須入力が満たされていない状態です。今回のケースでは「メッセージ認証 ON なのに Shared Secret が空」が典型で、これが埋まると進めるようになります。まずはウィザード内の必須項目を疑うのが近道です。
まとめ：最短で解決するなら“Shared Secret”を真っ先に確認
Windows Server 2016 の DHCP スコープでフェールオーバーを構成する際、「次へ（Next）」がグレーアウトして進めないときは、メッセージ認証のチェック状態とShared Secret の未入力を最優先で確認してください。チェックを外す、または Shared Secret を入力するだけで、ウィザードが先へ進むケースが非常に多いです。
加えて、ドメイン環境では DHCP サーバーの AD DS 承認（Authorize）も重要な前提条件です。GUI の「承認済みサーバーの管理」や PowerShell の Get-DhcpServerInDC で、運用開始前に両台が承認されていることを確認しておくと、切り分けが一段ラクになります。
コメント