Windows Server 2008 R2（Server Core）で稼働中のDHCPを、Windows Server 2019（Server Core）へ移行し、最終的に旧サーバーと同じIPアドレスで運用したい――この要件は現場でよくあります。本記事では「承認（Authorize）が自動で付くのか？」という落とし穴を押さえつつ、事故を起こさない切替手順を具体的なコマンド付きで整理します。
まず結論：同一IPで切り替えるなら「旧を止めてから新を承認」が安全
質問のポイントに対する結論を、先に短くまとめます。
- 新サーバーは自動では承認されません。ドメイン参加していても、DHCPサーバーとして配布を開始するにはAD DS上での承認（Authorize）が必要です。
- 基本の安全フローは、旧DHCPを停止（可能なら承認解除）→ 新サーバーへ旧IPを付け替え → 新サーバーを承認（Authorize）→ サービス開始です。
- 一時IPで先に構築するのは問題ありませんが、本番ネットワークに接続した状態でDHCPが2台有効になると、意図しない払い出しや競合が起きます。検証目的で起動したい場合は隔離VLAN／NIC未接続／スコープ無効化などで安全策を必ず入れます。
DHCPの「承認（Authorize）」とは何か：なぜ自動で付かないのか
Active Directoryドメイン環境では、DHCPは“勝手に動かない”ように制御されています。これは、社内に持ち込まれたPCや誤設定サーバーがDHCPとして動き、ネットワーク全体を混乱させるのを防ぐためです。
承認ができていないDHCPサーバーは、サービス自体が起動していても配布を開始しない／イベントログに「承認されていない」旨が記録されるといった挙動になりがちです。移行当日に「設定は入っているのに払い出しが始まらない」原因の上位が、この承認忘れです。
| よくある誤解 | 実際 | 現場で起きる症状 |
|---|---|---|
| ドメイン参加していれば自動承認される | 自動では承認されない（管理者操作が必要） | サービスは動いているように見えるが配布しない |
| 旧サーバーと同じIPにすれば承認も引き継がれる | AD上の承認情報はDNS名とIPの組み合わせで管理される前提。移行時は「旧を外して新を承認」が確実 | 承認済みのつもりでも配布しない／承認追加がエラー |
| 承認は最後にやればいい | 本番切替では最後でOK。ただし検証でDHCPを起動したいなら承認が必要になる | 検証で起動できずにハマる |
一時IPで先に承認してよいか：判断基準（推奨は「本番では承認しない」）
新サーバーを一時IPで構築する段階で、承認（Authorize）をしてよいかは検証のやり方で変わります。結論として、本番ネットワークに接続している状態なら切替まで承認しないのが最も安全です。
| 方式 | 承認タイミング | メリット | デメリット／注意 | おすすめ度 |
|---|---|---|---|---|
| 本番で安全第一（推奨） | 旧停止→旧IP付け替え後に承認 | 二重DHCP事故を避けやすい。承認情報の整合性も取りやすい | 切替当日の作業が増える（ただし手順化で解消可能） | ◎ |
| 隔離環境で事前検証 | 一時IPでも承認して検証（隔離必須） | 事前にサービス起動・配布テストができ、当日のリスクを下げられる | 隔離が甘いと本番に誤配布する。IP変更後は承認の更新（Remove→Add）が必要になり得る | ○（条件付き） |
もし一時IPで承認するなら、次の“二段ロック”をおすすめします。
- DHCPサービスは停止のまま（検証で起動するなら隔離環境でのみ起動）
- インポート後のスコープをInactive（無効）にしておく（誤起動しても配布されない）
同一IPで切り替えるメリットと注意点
「旧サーバーと同じIPで運用したい」には、現場目線で大きなメリットがあります。
| 項目 | 同一IPで切替えるメリット | 注意点 |
|---|---|---|
| ルータ／L3スイッチ（DHCP Relay） | ip helper（DHCPリレー）の転送先IPを変えずに済む | そもそもリレーが旧IPを指していることを事前に確認（例外がないか） |
| クライアントの更新 | 既存リースの更新要求（ユニキャスト）が同じIPへ向くため、切替後の更新がスムーズになりやすい | 切替直後にARPキャッシュが残って一時的に不安定になることがある |
| 運用ドキュメント | 監視や手順書の「DHCPサーバーIP」記載を大きく変えなくてよい | サーバー名は変わるケースが多いので、管理系（DNS/監視/運用手順）だけ更新が必要 |
一方で注意点はシンプルで、IP競合を絶対に起こさないこと。旧サーバーを停止したつもりでも、誰かが誤って起動すると即事故につながります。切替直後しばらくは、旧サーバーを電源OFF＋ネットワーク切断で保管するのが安心です。
移行前に必ずやる棚卸し：スコープ／予約／オプション／リース期間
DHCP移行は「エクスポートしてインポートすれば終わり」に見えて、実際は周辺要素（DNS更新、リース期間、ルータのIPヘルパー、スイッチのDHCPスヌーピング）でつまずきます。移行前に、最低限以下を棚卸ししておくと、切替後の確認が速くなります。
| 棚卸し項目 | 確認ポイント | メモ例 |
|---|---|---|
| スコープ | ネットワーク、配布範囲、除外範囲、リース期間、状態（有効/無効） | 192.168.10.0/24、配布100-200、除外1-50、8日 |
| 予約 | 固定割当（MAC、IP、用途） | プリンタ、AP、監視カメラなど |
| オプション | 既定GW(3)、DNS(6)、DNSドメイン(15)、NTP(42)、PXE(66/67)など | GW=192.168.10.1、DNS=192.168.10.2/3 |
| DNS動的更新 | DHCPがDNSにA/PTRを登録しているか、資格情報の有無 | “常に動的更新”＋資格情報あり など |
| 配布経路 | 同一セグメントか、ルータのIP helper/Relayを使うか | 拠点ルータでip helper設定 |
| ネットワーク制御 | DHCP Snooping、ACL、FWでDHCPサーバーが許可されているか | スイッチportをtrusted化が必要 |
全体像：Server Core同士での安全な移行フロー
今回の要件（最終的に同一IPで運用）に合わせた、現場で事故を避けやすい流れを先に示します。
- 新サーバー（2019 Core）を一時IPで構築（ドメイン参加、DHCP役割追加、サービスは停止のまま）
- 旧サーバー（2008 R2 Core）からDHCP設定/DBをエクスポート
- 新サーバーへインポートし、スコープ・予約・オプションが揃っているか検証
- 切替タイミングで旧DHCPを確実に停止（可能なら承認解除）
- 新サーバーのIPを旧サーバーと同じIPに変更（必要ならDNS更新）
- 新サーバーをADで承認（Authorize）してDHCPサービス開始
- 配布テスト、リース状況、DNS更新を確認
Server CoreでのDHCP管理：何をどこから操作するか
Server CoreはGUIがない分、「管理端末からリモートで触る」設計にしておくと運用が楽になります。
| 管理方法 | できること | 向いている場面 |
|---|---|---|
| PowerShell（DHCPコマンドレット） | スコープ/予約/オプション/承認の操作、状態確認 | 手順書化、作業自動化、ログ取得 |
| 別PC/別サーバーのDHCP MMC（dhcpmgmt.msc） | GUIでの設定閲覧・変更 | 設定の見落とし防止、スポット対応 |
移行作業はコマンド中心になりますが、切替後の設定確認はGUIが速いこともあります。運用方針に合わせて使い分けるのが現実的です。
新サーバー（Windows Server 2019 Core）の準備：一時IPで構築する
Server Coreでも、PowerShellでほとんど完結できます。代表的な手順例を示します（環境に合わせて読み替えてください）。
ネットワーク設定とドメイン参加
Server Coreでは sconfig での設定が定番です。GUIがない分、作業ミスを防ぐために「作業前に現在値を確認→変更→再確認」を徹底します。
sconfig
メニューから、ホスト名変更、IP設定（一時IP）、DNS設定、ドメイン参加、更新適用などを行います。
PowerShellで設定する場合の例（インターフェース名は環境で異なります）。
# IP（例：一時IP）を設定
New-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress 192.168.10.250 -PrefixLength 24 -DefaultGateway 192.168.10.1
# DNSサーバーを設定
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 192.168.10.2,192.168.10.3 DHCP役割の追加（サービスはまだ本番稼働させない）
# DHCP Server 役割を追加
Install-WindowsFeature DHCP -IncludeManagementTools
# DHCP セキュリティグループを作成（ポストデプロイ相当）
Add-DhcpServerSecurityGroup
# 反映のためサービス再起動（作成直後の反映用）
Restart-Service DHCPServer
# 本番切替までは停止しておく（事故防止）
Stop-Service DHCPServer この段階では「起動できる＝配布してよい」ではありません。本番ネットワークで二重DHCPにならないよう、切替まではDHCPサービスを停止しておく、またはスコープを無効化しておきます。
| 事故防止策 | 方法 | おすすめ |
|---|---|---|
| DHCPサービス停止 | 切替まで Stop-Service DHCPServer のままにする | ◎ |
| スコープ無効化 | インポート後に全スコープを Inactive にしておく | ○ |
| NIC未接続／隔離VLAN | 検証時のみ接続する | ○（検証向け） |
旧サーバー（Windows Server 2008 R2 Core）からエクスポートする
Windows Server 2008 R2では、DHCPサーバーの移行にnetshがよく使われます。スコープ、予約、オプションなどをまとめてエクスポートできます。
エクスポート前のワンポイント
- 切替当日に慌てないため、事前に一度エクスポート→インポートのリハーサルをしておくと安心です（隔離環境推奨）。
- 本番直前のエクスポートは、変更差分を減らすためにDHCP設定変更（予約追加など）を凍結してから実施すると整合が取りやすいです。
- 念のため、エクスポートファイルとは別にDHCPデータベースのバックアップも取っておくとロールバックが楽です。
netshでエクスポート
netsh dhcp server export C:\temp\dhcp-export.txt all
作成されたファイル（例：C:\temp\dhcp-export.txt）を、新サーバーへ安全な方法でコピーします（管理共有、USB、ファイルサーバー等）。
追加でバックアップも残す（任意だが推奨）
netsh dhcp server backup C:\temp\dhcp-backup
新サーバー（2019 Core）へインポートして事前検証する
新サーバー側でもnetshを使ってインポートできます。PowerShellのDHCPモジュールが使える環境でも、2008 R2由来のエクスポートを素直に取り込むならnetshインポートはシンプルです。
インポートの実行
netsh dhcp server import C:\temp\dhcp-export.txt all
インポート後に確認する項目
| 確認項目 | 確認の観点 | 補足 |
|---|---|---|
| スコープ一覧 | 数が合う、各スコープの配布範囲・除外が合う | 複数拠点があるほど差分が出やすい |
| 予約 | 重要端末（サーバー、プリンタ等）が欠けていない | MACの桁間違いも要注意 |
| オプション | GW/DNS/ドメイン名/NTP/PXEなどが期待通り | スコープ固有とサーバー共通の両方を見る |
| リース期間 | 切替設計に合う（短縮するなら計画的に） | 短すぎると更新トラフィックが増える |
| DNS動的更新 | DHCPがDNS更新する設計なら設定が維持されている | 資格情報を使う構成は特に確認 |
この段階で本番ネットワーク上の事故を防ぐため、DHCPサービスは停止のまま、または全スコープを無効のままにします。
切替当日の手順：旧停止→旧IP付け替え→承認→開始
ここが本番の山場です。ポイントは「二重DHCPを作らない」「承認の整合性を取る」「切替後に検証できる状態を作る」の3つです。
切替チェックリスト
| 手順 | 作業内容 | 完了条件 | メモ |
|---|---|---|---|
| 旧DHCPを停止 | Stop-Service DHCPServer（または net stop dhcpserver） | サービス停止を確認 | 可能なら旧サーバーのNICを抜く/シャットダウン |
| 旧DHCPを承認解除（推奨） | 2019側のPowerShell等で旧をRemove | AD上の一覧から旧が消える | 後片付けにもなる |
| 新サーバーへ旧IPを設定 | 一時IP→旧IPへ変更 | 重複なしで疎通OK | ゲートウェイ/DNSも合わせて確認 |
| 新DHCPを承認 | Add-DhcpServerInDCを実行 | AD上で承認済み | ここを忘れると配布しない |
| DHCPサービス開始 | Start-Service DHCPServer | サービス稼働 | 必要ならスコープ有効化 |
| 配布テスト | テスト端末で更新 | 正しいIP/オプション | 複数セグメントがあるなら各所で確認 |
旧DHCPの承認解除と新DHCPの承認（2019 Core側で実施）
2019ではPowerShellのDHCPコマンドレットが便利です。まず、現在ADに登録されている承認済みDHCPサーバーを確認します。
Get-DhcpServerInDC
旧サーバーを承認解除します（DNS名とIPは環境に合わせてください）。
Remove-DhcpServerInDC -DnsName "DHCP2008.example.local" -IPAddress 192.168.10.10
次に、新サーバーを承認します。ここで指定するIPは切替後に実際に使う旧IPを入れるのが確実です。
Add-DhcpServerInDC -DnsName "DHCP2019.example.local" -IPAddress 192.168.10.10
最後にDHCPサービスを開始します。
Start-Service DHCPServer
IP付け替え後に起きやすい“見えない問題”：ARPと名前解決
同じIPを別マシンに付け替えると、ネットワーク機器や端末に古いMACアドレスのARPキャッシュが残り、一時的に疎通が不安定になることがあります。多くは時間で解消しますが、影響が出る場合は、ルータ／L3スイッチ側でARPクリアを検討します。
また、DHCPの配布自体はブロードキャスト/リレーで動くためDNSに依存しませんが、運用上は「管理用の名前解決（Aレコード）」が必要です。旧サーバー名のDNSレコードをどう扱うか（残す/削除する/新サーバー名へ切替える）は、運用ルールに合わせて決めます。
切替後の確認：配布・スコープ状態・バインド・リース
切替後は「配布できているか」だけでなく、「想定外のインターフェースにバインドしていないか」「DNS動的更新が止まっていないか」なども確認します。
サービス稼働と承認状態
Get-Service DHCPServer
Get-DhcpServerInDC
スコープとリースの確認（IPv4例）
# スコープ一覧
Get-DhcpServerv4Scope
# 予約一覧
Get-DhcpServerv4Reservation -ScopeId 192.168.10.0
# 現在のリース（上位だけ見る例）
Get-DhcpServerv4Lease -ScopeId 192.168.10.0 | Select-Object -First 20 DHCPがどのNICで待ち受けているか（バインド）
複数NICや複数IPを持つサーバーでは、意図したインターフェースで待ち受けているかが重要です。
Get-DhcpServerv4Binding
よくあるトラブルと対処（移行当日に効く）
| 症状 | 原因の典型 | 対処 |
|---|---|---|
| 新DHCPが配布を開始しない | 承認（Authorize）されていない／旧の承認情報が残っている | Get-DhcpServerInDCで確認し、旧をRemove→新をAdd。サービス再起動も実施 |
| 特定セグメントだけ更新できない | ルータのip helperが旧IP/別IPを向いている、ACLで遮断 | 同一IP切替なら基本不要だが、機器側設定・疎通（UDP 67/68）を確認 |
| 予約端末が別IPを取る | 予約が欠けている／MACが異なる（NIC交換、仮想化移行） | 予約一覧を再確認し、MACアドレスを正しい値に修正 |
| DNSのA/PTRが更新されない | DHCPのDNS更新設定や資格情報が引き継がれていない | DNS動的更新の設定と資格情報（必要なら再設定）を確認 |
| 切替直後だけ疎通が不安定 | ARPキャッシュ残り | 時間で解消。必要に応じてルータ/L3SWでARPクリア、端末側更新 |
ロールバック設計：最悪の時に戻せる形にしておく
DHCP移行は影響範囲が広い一方で、切替自体は短時間で戻せるケースも多いです。ポイントは旧サーバーをすぐ戻せる状態で残すことです。
| 観点 | おすすめの考え方 |
|---|---|
| 旧サーバー | 切替直後もしばらくは電源OFFで保管（IP競合防止）。戻すなら新停止→旧を起動して再開 |
| 新サーバー | 切替後の変更（予約追加など）は、戻す可能性がある期間は控えめに。変更したら必ず記録 |
| 承認情報 | ロールバック時は、AD上の承認も「新を外す→旧を戻す」をセットで実施 |
| バックアップ | エクスポートファイル＋DHCPバックアップを別媒体に保持 |
運用としてさらに安全にする小技
移行そのものだけでなく、現場の“事故率”を下げる工夫をいくつか紹介します。
切替前にリース期間を一時的に短縮する
同一IP切替なら必須ではありませんが、切替後に早く新サーバーへ更新させたい場合、数日前からリース期間を短縮し、切替後に元へ戻す方法があります。短縮しすぎると更新トラフィックが増えるため、規模に応じて調整します。
切替当日は「旧の停止」を物理的に担保する
- 旧サーバーを停止するだけでなく、NICを抜く、または仮想NICを切断して、誤起動しても配布されないようにします。
- 可能なら旧サーバーのIP設定を退避IPへ変更してから停止すると、二重IP事故のリスクがさらに下がります。
監査ログを有効化し、切替後の状況把握を早くする
DHCPの監査ログは、切替直後の「どの端末が更新できているか」「エラーが出ていないか」を追うのに役立ちます。移行後も監査ログの保存方針（容量、保管期間）を決めておくと運用が安定します。
参考になる情報（追加で深掘りしたい場合）
今回の手順はServer Coreを前提に整理しましたが、考え方の近い移行例として、次のようなコミュニティ記事も参考になります（サイト名＋DHCP migrationで検索すると見つけやすいです）。
- theITBros：DHCPサーバー移行（2008系→2016系の例）
- Spiceworks：2008→2019の移行ディスカッション／手順例
まとめ：同一IP移行は「承認」と「二重DHCP回避」が核心
Windows Server 2008 R2 Coreから2019 CoreへのDHCP移行で、最終的に同じIPアドレスを使う場合、ネットワーク機器側の設定変更を最小化できる一方、切替手順を誤ると影響が広範囲に及びます。旧を確実に止めてから新へ旧IPを付け替え、ADで承認してから稼働――この基本を守り、事前検証とチェックリストで当日のリスクを潰しておけば、安定して移行できます。
コメント