Windows Server 2019 を既存の Active Directory ドメインに追加し、ドメインコントローラーへ昇格しようとしたら「An Active Directory Domain Controller for the domain could not be contacted」と出て先に進まない――。DNS だけを疑う前に、機能レベルと SYSVOL 複製方式（FRS/DFSR）を含めて短時間で切り分ける手順を整理します。
症状の整理：このエラーが意味すること
「An Active Directory Domain Controller for the domain could not be contacted」は、昇格ウィザード（または Server Manager / PowerShell）が既存ドメインの DC を検出できない、あるいは検出できても必要な通信（LDAP/RPC/Kerberos/DNS など）が成立しないときに出る、かなり幅の広いエラーメッセージです。表示だけ見ると DNS だけが原因に見えますが、実際には次のどこかで詰まっていることが多いです。
- 新サーバーがドメイン名を正しく名前解決できない（DNS 設定・SRV レコード・フォワーダー）
- 新サーバーから既存 DC へ必要なポートが塞がっている（Windows Firewall / NW-FW / セグメント間制御）
- Kerberos が成立しない（時刻ずれ、重複コンピューターアカウント、Secure Channel 破損）
- 既存 AD の健全性が壊れていて前提条件チェックで弾かれている（レプリケーション、DNS 整合性、SYSVOL）
- 古い環境からの移行で SYSVOL がFRS のまま（2019 追加の強い阻害要因）
まずは「追加できない根本原因」を最短で潰すために、次の優先順位で確認します。
最優先で確認する前提条件
ここを外していると、DNS をいくら眺めても時間だけが溶けます。特にドメイン機能レベルとSYSVOL の複製方式は、2019 を入れる前に必ず押さえてください。
| 確認ポイント | 目安（結論） | 主な確認方法 | 詰まると起きやすい症状 |
|---|---|---|---|
| ドメイン／フォレスト機能レベル | 少なくとも Windows Server 2008 以上 | GUI（Active Directory ドメインと信頼関係）/ PowerShell（Get-ADDomain, Get-ADForest） | 昇格前提チェックで失敗、互換性エラー |
| SYSVOL の複製方式 | DFSR（FRS は不可） | dfsrmig /getmigrationstate、イベントログ、サービス（NTFRS の有無） | 「DC に接続できない」などの汎用エラーで停止 |
| 既存 DC の健全性 | dcdiag/repadmin で致命的エラーが無い | dcdiag / repadmin / Event Viewer | 昇格・レプリケーションが不安定、DNS 登録が欠ける |
| 新サーバーの DNS/時刻/ネットワーク | DNS は既存 DC を参照、時刻差は数分以内 | ipconfig, nslookup, w32tm, Test-NetConnection | DC 検出不可、Kerberos 失敗、RPC 失敗 |
ドメイン／フォレスト機能レベルを確認する
古いドメイン（例：元は Windows Server 2003 R2）を段階的に移行していると、「現在の DC は 2012 なのに、機能レベルが上がり切っていない」ケースがあります。Windows Server 2019 の DC を追加するためには、少なくともドメイン機能レベルが 2008 以上であることが前提です（移行途中のまま放置していると落とし穴になります）。
PowerShell で確認する例です（RSAT が入っている端末、または DC で実行）。
Get-ADDomain | Select-Object DNSRoot, DomainMode
Get-ADForest | Select-Object ForestModeGUI なら「Active Directory ドメインと信頼関係」からドメインのプロパティで確認できます。もし機能レベルが想定より低い場合は、旧 DC の撤去が完了していることや互換性要件を確認したうえで引き上げます（“上げられるのに上げていない”ことが意外と多いです）。
SYSVOL が FRS のままなら DFSR へ移行する（最重要）
結論から言うと、SYSVOL レプリケーションが FRS（File Replication Service）のままのドメインには Windows Server 2019 を DC として追加できません。エラーメッセージが DNS っぽく見えても、裏では「前提条件が満たせない」ために昇格が止まっていることがあります。
まずは「今どちらか」を確実に判定します。
- dfsr が使われている：DFSR サービスが稼働し、SYSVOL の複製が DFSR で行われている
- frs が使われている：NTFRS サービス（File Replication Service）が関与している
状態確認の代表例が dfsrmig です（PDC エミュレーター上で実行するのが基本）。
dfsrmig /getmigrationstate移行状態は段階的に進みます。ざっくり理解するために、状態と意味を表にまとめます。
| 状態 | 名称 | 何が起きるか | チェックのコツ |
|---|---|---|---|
| 0 | Start | FRS で SYSVOL を複製している状態 | NTFRS 関連のイベントが中心になりやすい |
| 1 | Prepared | DFSR 側に複製の準備領域（SYSVOL の複製先）が作られる | 全 DC が 1 になったことを確認してから次へ |
| 2 | Redirected | SYSVOL 参照先が DFSR 側に切り替わる（実質 DFSR 運用） | \\<dc>\\SYSVOL の内容が DFSR 側になっているか確認 |
| 3 | Eliminated | FRS が無効化され、DFSR のみで SYSVOL を複製する最終状態 | “全 DC が 3” を確認して完了 |
移行そのものはコマンドがシンプルですが、実務では「進んでいるか」「止まっていないか」「レプリケーション健全性が担保できているか」が重要です。標準的な流れは次の通りです。
- 既存 DC 全台で AD の健全性を確認（後述の dcdiag/repadmin）
- 全 DC のシステム状態バックアップを取得（単一 DC 構成なら特に重要）
- PDC エミュレーターで移行を段階的に実行
dfsrmig /setglobalstate 1
dfsrmig /getmigrationstate
dfsrmig /setglobalstate 2
dfsrmig /getmigrationstate
dfsrmig /setglobalstate 3
dfsrmig /getmigrationstate各段階は「全 DC が同じ状態になった」ことを確認してから次に進めます。途中で停滞する場合は、まずレプリケーションエラーや DFSR/FRS 関連イベントを潰すのが先決です。焦って次へ進めると SYSVOL の不整合が起き、ログオンスクリプトや GPO が配布されない事故につながります。
DNS だけを見ない：新サーバー側で先に潰すべき設定
“DC に接続できない”系の多くは DNS が絡みますが、ポイントは「DNS サーバーのレコード」より先に新サーバー自身の参照先 DNS が正しいかです。昇格前のサーバーはまだ DNS をホストしないので、自分自身（127.0.0.1 や 自分の IP）を DNS に設定すると、ドメイン名を引けずに詰まります。
新サーバー（2019）でよくある NG 設定
- 優先 DNS が「社外 DNS（8.8.8.8 など）」になっている
- 優先 DNS が「自分自身」になっている（昇格前）
- 複数 NIC で DNS 登録がブレている（管理用 NIC と業務用 NIC の混在）
- VPN/仮想 NIC が優先され、意図しない経路で DC へ向かっている
まずは以下で現状を確認します。
ipconfig /all期待する形（例）としては、昇格前は優先 DNS = 既存 DC（2012）の IP、代替 DNS = もう1台 DC がいるならその IP、単一 DC 構成なら一旦空欄（または将来追加する DC の IP を後で設定）という形が安全です。
SRV レコードで “DC 発見” を確認する
ドメイン参加しているかに関わらず、DNS さえ正しければ DC を発見できます。昇格前に SRV レコードの解決ができるかを確認しましょう。
nslookup -type=SRV _ldap._tcp.dc._msdcs.<ドメインFQDN>
nslookup -type=SRV _kerberos._tcp.<ドメインFQDN>ここで DC のホスト名が返らない、別拠点の古い DC だけが返る、タイムアウトする場合は、DNS のゾーン構成やレコードの欠損、参照先 DNS の誤りを疑います。特に 2003 由来のドメインでは、_msdcs 周りの設計が複雑になっていることがあります。
ドメイン コントローラー検出コマンドで裏取りする
nltest /dsgetdc:<ドメインFQDN>
nltest /dclist:<ドメインFQDN>nltest が DC を返せないなら、昇格ウィザードも高確率で失敗します。逆に nltest が正しく返るのに昇格だけ失敗する場合は、次の「AD 健全性」と「SYSVOL（FRS/DFSR）」が濃厚です。
昇格前の AD 健全性チェック（dcdiag / repadmin）
移行途中のドメインでは、見た目は動いていても内部的にはエラーが積み上がっていることがあります。2019 を追加する前に、既存 2012 DC の状態を数値とログで把握しておくと、切り分けが一気に楽になります。
最低限これだけは見る
dcdiag /v
repadmin /replsummary
repadmin /showreplエラーが出たら“とりあえず再実行”で流さず、原因を潰してから先へ進めます。特に次の項目は、昇格・レプリケーション・DNS 連携に直結します。
| チェック観点 | 代表的な兆候 | よくある原因 | 優先度 |
|---|---|---|---|
| DNS テスト | dcdiag の DNS テストで失敗 | ゾーンの複製範囲、動的更新、SRV レコード欠損 | 高 |
| レプリケーション | repadmin に失敗が並ぶ | ネットワーク断、名前解決、サイト/サブネット不備 | 高 |
| SYSVOL/NETLOGON | 共有が無い、GPO が配布されない | FRS/DFSR の不整合、ジャーナルラップ | 高 |
| 時刻同期 | Kerberos 関連エラー | NTP 未設定、仮想基盤の時刻ソース競合 | 中 |
| 古い DC の残骸 | “存在しない DC” へ接続しに行く | メタデータ残り、DNS レコード残り | 中 |
「旧 2003 は撤去済みのはず」でも、DNS や Sites and Services にオブジェクトが残っていることがあります。レプリケーションがその残骸を参照すると、DC 探索が遠回りになりタイムアウトして昇格が失敗する要因になります。
推奨手順：Windows Server 2012 のドメインへ 2019 を追加して DC 昇格する
現場で事故が少ない“王道の流れ”を、チェックポイント付きでまとめます。単純に「役割追加して昇格」ではなく、前提条件の整理 → 健全性 → 追加 → 検証 → 移行の順で進めるのがコツです。
既存 DC（2012）の事前チェック
- dcdiag / repadmin でエラーを潰す
- ドメイン／フォレスト機能レベルが 2008 以上であることを確認
- SYSVOL が FRS の場合は DFSR へ移行（Eliminated まで）
- 単一 DC 構成ならシステム状態バックアップと復元手順の確認
新サーバー（2019）の準備
- 最新の累積更新プログラム（CU）まで適用（昇格直後の不具合回避）
- サーバー名確定、固定 IP、不要 NIC の無効化
- DNS は既存 DC を参照（昇格前に自分自身を向けない）
- 時刻同期の確認（w32tm /query /status）
- ドメイン参加（再起動）
AD DS 役割追加と昇格
Server Manager で「AD DS」役割を追加し、ウィザードで「既存ドメインにドメイン コントローラーを追加」を選びます。一般的には次を推奨します。
- グローバル カタログ（GC）を有効化（複数 DC 運用の基本）
- DNS サーバー役割も同時に追加（小規模なら特に有効）
- レプリケーション元 DC を明示（トラブル時の切り分けが楽）
昇格が失敗した場合は、ウィザードの表示だけで判断せず、ログを必ず確認します。
- C:\Windows\debug\dcpromo.log
- C:\Windows\debug\dcpromoui.log
- イベントビューアー（Directory Service, DNS Server, DFS Replication など）
昇格後の検証（ここで“安心”しない）
dcdiag /v
repadmin /replsummary
repadmin /showreplさらに、共有が出ているかを確認します。
net share通常は SYSVOL と NETLOGON が見えます。見えない場合は、SYSVOL 複製や DNS 登録がまだ追いついていない、あるいは DFSR の問題を抱えている可能性があります。
DNS 設計の“落とし穴”を避ける（昇格後の推奨設定）
DC を複数台にしたら、DNS の参照先も冗長化しておくと、障害時に連鎖ダウンしにくくなります。例として、2 台の DC（DC1=2012、DC2=2019）構成を想定した目安です。
| 対象 | 優先 DNS | 代替 DNS | 補足 |
|---|---|---|---|
| DC1（既存 2012） | DC2 の IP | DC1 の IP | 自己参照だけに固定しない（名前解決不能の連鎖を避ける） |
| DC2（新 2019） | DC1 の IP | DC2 の IP | 昇格後は自己参照を代替側に入れておく |
| クライアント/サーバー | DC1 の IP | DC2 の IP | 社外 DNS は基本入れない（必要ならフォワーダーで解決） |
「社外 DNS を入れたい」要件がある場合は、クライアントに直接入れるのではなく、AD 統合 DNS のフォワーダーでインターネット向け解決を逃がす設計が安全です。
ネットワーク/ファイアウォールが原因のときに見るべきポイント
名前解決ができているのに DC を検出できない、検出できても途中で失敗する場合は、ポート制御や経路制御が疑わしいです。特に拠点間やセグメント間で“必要最小限ポートだけ許可”している環境では、AD の必須ポートが漏れていることがあります。
| 用途 | プロトコル/ポート（代表） | 備考 |
|---|---|---|
| DNS | TCP/UDP 53 | DC 発見の入口。ここが塞がるとほぼ全滅 |
| Kerberos | TCP/UDP 88、TCP/UDP 464 | 認証。時刻ずれでも失敗する |
| LDAP | TCP/UDP 389、TCP 636（LDAPS） | ディレクトリ参照。LDAPS 必須環境は証明書も確認 |
| SMB | TCP 445 | SYSVOL/NETLOGON アクセスに関与 |
| RPC Endpoint | TCP 135 | この後に動的ポートへ展開される |
| RPC 動的ポート | TCP 49152-65535（既定） | 制限している場合は範囲設計が必要 |
| GC | TCP 3268、TCP 3269 | フォレスト内検索。複数ドメイン構成で重要 |
| DFSR | TCP 5722 | SYSVOL の DFSR 複製で使用 |
切り分けには、PowerShell の疎通確認が便利です。
Test-NetConnection -ComputerName <既存DCのFQDN> -Port 53
Test-NetConnection -ComputerName <既存DCのFQDN> -Port 389
Test-NetConnection -ComputerName <既存DCのFQDN> -Port 445“Ping は通るのに DC に接続できない”は珍しくありません。Ping は ICMP が通るだけなので、必須ポートが塞がれていないかを必ず確認してください。
それでも解決しないときの追加チェックリスト
ここまでを満たしても解消しない場合、原因は「複合要因」になっていることが多いです。現場で刺さりやすい順に、追加の確認項目を並べます。
| 観点 | 確認ポイント | 対処の方向性 |
|---|---|---|
| 時刻 | w32tm /query /status で時刻ソースとオフセット | PDC の外部 NTP 設定、仮想基盤の時刻同期の整理 |
| サイト/サブネット | 新サーバー IP のサブネットが AD Sites and Services に登録されているか | サブネット定義を追加し、近い DC を選ばせる |
| NIC 多重 | 複数 NIC の DNS 登録、ルーティング、メトリック | 不要 NIC を無効化、DNS 登録を限定 |
| IPv6 | 無効化していないか、無効化しているなら影響範囲を把握しているか | 原則は有効のまま運用。やむを得ない場合は設計を見直す |
| 資格情報 | Enterprise Admin / Domain Admin 権限で実施しているか | 権限を確認。昇格は通常より強い権限が必要 |
| 残骸 | 撤去済み DC の DNS/Sites オブジェクトが残っていないか | メタデータクリーンアップ、DNS レコード整理 |
旧 DC を降格・撤去する前にやるべきこと
新 2019 DC が安定したら旧 DC を降格しますが、撤去前の確認不足で「ログオンできない」「GPO が来ない」などの障害が出ることがあります。最低限、次を満たしてから進めると安全です。
- 新 DC の dcdiag / repadmin がクリーン（重大エラーがない）
- クライアントが新 DC の DNS を引ける（DHCP の配布先確認含む）
- SYSVOL/NETLOGON 共有が両 DC で正常
- FSMO 役割の所在を把握し、必要なら計画的に移行
- PDC エミュレーターの時刻同期設計（外部 NTP）を確定
FSMO 役割は「とりあえず全部移す」ではなく、運用設計に合わせて移す方が事故が減ります。目安として、最初は既存 2012 に残し、2019 の安定確認後に移行する方法が無難です。
| FSMO 役割 | 影響が出やすい領域 | 移行判断の目安 |
|---|---|---|
| PDC エミュレーター | 時刻同期、パスワード変更の整合性 | 最優先で設計。外部 NTP とセットで移行する |
| RID マスター | SID/RID 払い出し | 通常は安定後でよい |
| インフラストラクチャ マスター | 参照整合性 | 単一ドメインなら神経質になりすぎなくてよい |
| スキーマ マスター | スキーマ更新 | 頻度は低い。必要時に意識すればよい |
| ドメイン名前付けマスター | ドメイン追加/削除 | 頻度は低い。必要時に意識すればよい |
まとめ：最短で解決するための考え方
Windows Server 2019 の DC 昇格で「An Active Directory Domain Controller for the domain could not be contacted」が出ると、DNS に目が行きがちです。しかし、2003 系由来の移行ドメインでは、SYSVOL が FRS のままという“2019 では致命傷”が隠れていることがあります。
次の順で確認すれば、遠回りしにくくなります。
- ドメイン/フォレスト機能レベルが 2008 以上か
- SYSVOL 複製が DFSR か（FRS なら先に移行）
- 既存 DC の健全性（dcdiag/repadmin）を数値で確認
- 新サーバーの DNS 参照先・SRV レコード解決・時刻同期を確認
- 必要ポートが塞がっていないかを疎通で確認
この順番で潰していけば、原因が DNS であっても、それ以外（FRS/健全性/ネットワーク）であっても、確実に切り分けられます。結果として、2019 追加後の運用も安定しやすくなります。
コメント