本社に単独DC（Windows Server 2012 R2／192.168.100.101）がある環境で、VPNで接続された支店にWindows Server 2016の追加ドメインコントローラー（支店DC）を新設し、支店でローカル認証できるようにするための具体的な手順と設計ポイントをまとめます。
前提とゴール整理
今回の構成は「本社（Site A）に既存の単独ドメインコントローラー」「支店（Site B）に新規サーバーを1台追加しDC化」「VPN越しに双方向レプリケーション」「支店ユーザーは支店DCで優先的に認証」という要件です。まず、状況を表で整理します。
| 拠点 | 役割 | OS | IP例 | 現状 |
|---|---|---|---|---|
| 本社（Site A） | 単独DC（DNS / DHCP / SQL Serverも同居） | Windows Server 2012 R2 | 192.168.100.101 | 稼働中 |
| 支店（Site B） | 追加DC（支店DC） | Windows Server 2016 | 192.168.200.100 | これから構築 |
ゴールは次の3点です。
- 支店サーバーを既存ドメインに参加させ、追加ドメインコントローラーとして昇格できる
- VPNを介してADレプリケーションが安定して動作する
- 支店端末が「支店のサブネット」として認識され、支店DCを優先して参照・認証する
構築フロー全体像
作業手順を全体で見ると、次の順番がもっともトラブルが少なくなります。
| フェーズ | 作業場所 | 目的 | 失敗しやすい点 |
|---|---|---|---|
| 設計 | 本社/支店 | サイト・サブネット・DNS・VPN要件を決める | 支店のIPレンジ誤認、VPN経路/FW要件の見落とし |
| ADサイト/サブネット作成 | 本社DC | 支店端末が支店サイト扱いになる土台を作る | サブネット未登録で支店端末が本社DCへ行く |
| 支店サーバーのドメイン参加 | 支店サーバー | 追加DC昇格前の前提条件を満たす | 昇格前DNSの設定ミスで参加/昇格が止まる |
| AD DS役割追加→昇格 | 支店サーバー | 支店DCとしてレプリケーション開始 | 権限不足、SYSVOL複製方式の問題、VPNのRPC遮断 |
| DNS/クライアント最適化 | 本社/支店 | 支店端末が支店DC優先で認証 | DHCPのDNS配布順が本社優先のまま |
| 検証/運用 | 本社/支店 | repadmin/dcdiagで健全性を維持 | 作って終わりで監視・バックアップが弱い |
なぜ「ADサイトとサブネット」を先に作るのか
支店DC構築で最重要なのが、ADサイト（Site）とサブネット（Subnet）の設計です。ADは「端末のIPがどのサブネットに属するか」を見て、どのサイトにいるかを判断します。サイト判断が正しいと、端末は同一サイト内のDCを優先して探すため、支店端末が本社DCへ毎回VPN越しに認証しに行く…という状態を避けられます。
逆に、サブネット割り当てが未設定/誤設定だと、支店端末が「既定のサイト」に所属した扱いになり、支店にDCがいても本社DCを掴みに行くケースがよく起きます。手戻りを防ぐためにも、サイト→サブネット→DC昇格の順番が基本です。
事前準備チェックリスト
支店DCの昇格は「ADの内部を変更する作業」です。作業前に、次の項目を最低限チェックしてください。
| チェック項目 | 目安 | 確認例 |
|---|---|---|
| 本社DCのバックアップ | 作業直前の世代がある | System Stateを含むバックアップ |
| VPN経路 | 双方向到達できる | 支店→本社DCへping、名前解決 |
| 時刻同期（Kerberos対策） | ずれが数分以内 | w32tm /query /status |
| DNS名前解決 | ADのSRVが引ける | nslookup -type=SRV _ldap._tcp.dc._msdcs.<ドメイン> |
| SYSVOLの複製方式 | 可能ならDFSR | dfsrmig /getmigrationstate |
支店サーバー（Windows Server 2016）は固定IPにし、ゲートウェイやDNSを正しく設定します。特に「昇格前のDNS」を誤ると、ドメイン参加や昇格の途中で詰まりやすいので注意してください。
昇格前の支店サーバーDNS設定（推奨）
- 優先DNS：本社DC（192.168.100.101）
- 代替DNS：空欄（または構築方針により後述の支店DCへ）
まずは「既存ドメインを確実に引ける」状態を作り、DC昇格後に支店DC自身を優先DNSに切り替える流れが安定します。
仮想環境の場合の注意（スナップショットの扱い）
DCを仮想化している場合、安易なスナップショット取得・巻き戻しは避けます。ADはマルチマスター複製で整合性を取るため、巻き戻しはレプリケーション不整合の原因になります。バックアップはAD対応の仕組み（System Stateなど）で取得し、復元手順を事前に確認しておくのが安全です。
本社側でADサイトとサブネットを作成する
作業は本社DC（192.168.100.101）で行うのが分かりやすいです。権限はDomain Admin相当が必要です。
- 本社DCで「Active Directory サイトとサービス」を開く
- Sitesを右クリックし、新しいサイトを作成（例：Site-B）
- サイトリンクは、基本は既存のDEFAULTIPSITELINKを選択（後で最適化可能）
- Subnetsを右クリックし、新しいサブネットを作成（例：192.168.200.0/24）
- 作成したサブネットをSite-Bに関連付ける
ここで重要なのは「支店の端末が実際に使うIPレンジ」を正しく登録することです。/24ではない場合（/23や/25など）は、現地のアドレス設計どおりに入力します。
サイトリンクの基本設定（VPN越しのレプリケーションを安定させる）
サイト間レプリケーションは、回線品質に合わせて調整します。VPNが不安定な場合は、短すぎる間隔よりも「確実に通る設定」を優先します。
| 項目 | 推奨の考え方 | 例 |
|---|---|---|
| コスト（Cost） | WAN/VPN側を高めにして意図しない経路を避ける | Site間リンクを100など |
| 間隔（Replication interval） | 回線が細い/混雑するなら長め、安定なら短め | 30〜180分 |
| スケジュール | 業務時間に帯域が逼迫するなら夜間中心も検討 | 夜間のみ許可 |
支店サーバーをドメイン参加させる
支店サーバー（192.168.200.100）で以下を実施します。
- サーバー名を命名（例：BR-DC01）し再起動
- NICを固定IPに設定（IP/マスク/ゲートウェイ/DNS）
- 本社DCのDNSが引けることを確認（nslookupでドメイン名が解決できる）
- ドメインに参加し再起動
確認コマンド例：
ipconfig /all
nslookup yourdomain.local
nltest /dsgetdc:yourdomain.localAD DS役割の追加とドメインコントローラー昇格
ドメイン参加ができたら、支店サーバーにAD DS役割を追加し、既存ドメインの追加DCとして昇格します。
- サーバーマネージャーで役割と機能の追加を開く
- Active Directory ドメイン サービスを選択（必要機能は追加）
- インストール後、通知フラグからこのサーバーをドメイン コントローラーに昇格するを実行
- 既存のドメインにドメイン コントローラーを追加を選択し、ドメイン/資格情報を指定
- オプションでDNSサーバー、グローバルカタログ（GC）を有効化（一般的には有効）
- サイト選択画面が出た場合はSite-Bを選択
- 前提条件チェックでエラーがないことを確認してインストール→再起動
スキーマ更新（adprep）で止まらないために
Windows Server 2016のDCを追加する際、フォレスト/ドメインのスキーマが古いと拡張が必要です。多くの場合、昇格ウィザードが自動的に実行しますが、実行できる権限（Schema Admins / Enterprise Admins）がないと失敗します。作業アカウントの権限を事前に確認し、本社DCのバックアップを取ってから進めてください。
FSMO（役割）をどこに置くべきか
本社が単独DCから始まっている場合、通常は本社DCが全FSMOを保持しています。支店DC追加後も、まずは本社に保持したままで問題ありません。支店に役割を移すかどうかは、回線断時に何を優先するか（運用体制・障害時の手順）で決めるのが現実的です。
SYSVOLがFRSのままだと詰まるケース
古い環境からアップグレードしている場合、SYSVOL複製がFRSのまま残っていることがあります。Windows Server 2016のDC追加で警告やエラーになることがあるため、次で状態確認しておくと安全です。
dfsrmig /getmigrationstate
dfsrmig /getglobalstateDFSRへ未移行の場合は、影響範囲が大きい作業になるため、別途計画して段階的に移行（状態1→2→3）するのが定石です。
支店DC昇格後のDNS設定（ここが成否を分ける）
DC昇格が完了したら、DNS設定を「ADとして正しい形」に揃えます。よくある失敗は、支店DCが自分自身のDNSを参照しておらず、レプリケーションやSRV登録が不安定になるパターンです。
DC（DNSサーバー）自身の推奨設定
| サーバー | 優先DNS | 代替DNS | 狙い |
|---|---|---|---|
| 本社DC（192.168.100.101） | 127.0.0.1（または自身IP） | 192.168.200.100 | 自分のDNSを最優先、相互に冗長化 |
| 支店DC（192.168.200.100） | 127.0.0.1（または自身IP） | 192.168.100.101 | 支店はローカル解決を最優先 |
ポイントは「DCは自分自身を優先DNSにする」です。これにより、SRVレコード登録や内部参照が安定しやすくなります。VPNが不安定で代替DNSが遠隔になる場合、名前解決が遅くなることがあるため、運用方針として“代替DNSを設定しない”判断もあり得ます（ただし冗長性は下がります）。
DNSの登録・反映を早める小技
DNS設定を直したのにすぐ反映されない場合は、DC側でSRV登録を促してから確認すると切り分けが早くなります。
ipconfig /registerdns
net stop netlogon
net start netlogon支店クライアントのDNS配布（DHCP運用の場合）
支店端末が支店DCを優先して掴むには、クライアントのDNS設定が重要です。支店でDHCPを使うなら、DHCPオプションでDNSサーバー（オプション006）を支店DC優先で配布します。
- DNSサーバー（オプション006）：192.168.200.100（支店DC）, 192.168.100.101（本社DC）
- DNSドメイン名（オプション015）：yourdomain.local
VPN越しレプリケーションに必要な通信要件
「ドメイン参加はできたのにレプリケーションが失敗する」原因の多くは、VPNやFWで必要ポートが通っていないことです。特にRPCの動的ポートが落とし穴になりがちです。
| 用途 | プロトコル/ポート | 備考 |
|---|---|---|
| DNS | TCP/UDP 53 | 名前解決がすべての前提 |
| Kerberos | TCP/UDP 88、TCP/UDP 464 | 時刻ずれにも注意 |
| LDAP/AD Web | TCP/UDP 389、TCP 636、TCP 9389 | 環境により使用 |
| SMB | TCP 445 | SYSVOL/NETLOGON |
| RPC | TCP 135 + 動的ポート（49152-65535 など） | サイト間レプリケーションで詰まりやすい |
| グローバルカタログ | TCP 3268/3269 | 他ドメインがある場合は特に重要 |
| DFSR（SYSVOL） | TCP 5722 | DFSR利用時 |
| NTP | UDP 123 | ドメイン階層で同期 |
疎通確認の例（支店サーバーから本社DCへ）：
Test-NetConnection 192.168.100.101 -Port 53
Test-NetConnection 192.168.100.101 -Port 389
Test-NetConnection 192.168.100.101 -Port 445
Test-NetConnection 192.168.100.101 -Port 135WindowsのFWが原因の場合は、まずは「ドメイン」プロファイルでAD DS/DNS/DFSR関連の既定ルールが有効かを確認します。VPN側の対向FW（UTM）で止めている場合は、ポート要件を満たすルールを作る必要があります。
支店端末が「支店DCでローカル認証」できているか確認する
構築後の確認は「レプリケーションが正常」「支店端末が支店サイト扱い」「ログオン先DCが支店DC」の3点で見ます。
支店端末での確認コマンド
echo %logonserver%
nltest /dsgetsite
nltest /dsgetdc:yourdomain.local期待値としては、logonserverが支店DC（例：\\\\BR-DC01）になり、dsgetsiteがSite-Bを返します。本社DCが返る場合は、次を疑います。
- 支店サブネット（192.168.200.0/24）の登録がない、またはSite-Bに割り当てていない
- 支店端末のDNSが本社DCを優先している（DHCP配布や手動設定の誤り）
- 支店DCのDNSサービスが正常でない（SRV登録不備、ゾーン複製設定など）
RODC（読み取り専用DC）を検討すべきケース
支店に「書き込み可能DC」を置くと、支店回線断でもユーザー作成・パスワード変更・GPO更新などがしやすい反面、物理的に持ち去られるリスクも増えます。支店の入退室管理が弱い、サーバーを施錠できない、といった条件ならRODCが現実的です。
| 観点 | 書き込み可能DC | RODC |
|---|---|---|
| 認証（ログオン） | 可能 | 可能（パスワードキャッシュ方針に依存） |
| AD変更（ユーザー作成/変更） | 支店で完結可能 | 本社へ転送が基本 |
| 情報漏えい耐性 | 低い（全体の機密を持つ） | 高い（資格情報の保持を制御） |
| 運用難易度 | 一般的 | パスワードレプリケーションポリシー設計が必要 |
よくあるトラブルと切り分け
| 症状 | ありがちな原因 | 対処の方向性 |
|---|---|---|
| 支店DCがSite-Bに入らない | サブネット未登録/誤登録 | サブネットを正しくSite-Bへ関連付け→Netlogon再起動 |
| repadminでエラー（RPC不可） | 動的RPCポートがFWで遮断 | 必要ポート許可、またはRPCポート範囲の制限設計 |
| ログオンが本社DCになる | 端末DNSが本社優先、またはサイト判定ができていない | DHCPのDNS配布を支店DC優先に修正、サブネット登録確認 |
| DNSが不安定（SRVが引けない） | DC自身のDNS設定が不適切 | DCは自分自身を優先DNSにし、dcdiagでDNSテスト |
| SYSVOL/NETLOGONが見えない | DFSR/SMB/レプリケーションの不具合 | イベントログ確認、TCP445/5722、dcdiag/repadmin |
健全性チェックで使えるコマンド
dcdiag /v
dcdiag /test:DNS /v
repadmin /replsummary
repadmin /showrepl
Get-ADDomainController -Filter * | Format-Table Name,Site,IPv4Address,IsGlobalCatalog本社DCがDNS/DHCP/SQL同居の場合に知っておくと得する話
本社DC（192.168.100.101）がDNS/DHCPに加えてSQL Serverも稼働している場合、追加DCを建てることで「AD/DNSの冗長化」という面では大きく前進します。一方で、将来的には次の観点で分離も検討すると運用品質が上がります。
- 性能：SQL負荷でDCの応答が遅いと、認証・GPO・DNSへ波及しやすい
- セキュリティ：DCは攻撃対象になりやすく、役割を増やすほど管理面が複雑になる
- 障害切り分け：役割が多いほど原因特定が難しく、復旧手順も長くなる
ただし、現時点で無理に構成変更する必要はありません。まずは支店DC追加とレプリケーション安定化を優先し、運用が落ち着いたタイミングで段階的に改善するのが現実的です。
構築後にやっておきたい運用・セキュリティ
- バックアップ方針：本社/支店それぞれでSystem Stateを定期取得。復元手順（権限・媒体）も文書化
- パッチ運用：DCは業務影響が大きいので計画停止。再起動後にrepadminで必ず健全性確認
- 物理セキュリティ：支店設置ならBitLocker、管理者権限の最小化、ローカルログオン制限
- 役割の増やしすぎに注意：DCへ追加アプリ（特にDB/業務アプリ）を安易に同居させない
- 監視：イベントログ（Directory Service/DNS Server/DFS Replication）とレプリケーション状態を定期点検
まとめ
VPN接続の支店に追加DC（Windows Server 2016）を建てるときは、ADサイトとサブネットを先に作成し、支店端末が支店サイトとして認識される土台を作ることが最短ルートです。昇格自体はウィザードで進みますが、成功の鍵はDNS設計とVPN越しの通信要件にあります。構築後は、repadmin/dcdiagで健全性を見ながら、支店端末が支店DCへログオンしていることまで確認して運用に乗せてください。
コメント