Windows Server 2019 を新しいフォレストの最初のドメインコントローラーにする手順です。先に固定IP、DNS設計、ドメイン名、時刻、バックアップ、障害時の復旧担当を決め、AD DS役割を追加してからサーバーを昇格します。画面の「次へ」だけで進めると、後で名前変更やDNS修正が必要になるため、構築前の設計と構築後の検証を同じくらい重視します。
既存環境へ追加する場合と、新規フォレストを作る場合では選択肢が異なります。実運用中のドメインで試さず、復元可能な検証環境と変更計画を用意してください。
構築前に決める項目
- サーバー名、固定IPv4/IPv6、デフォルトゲートウェイ、参照DNS
- 登録済みドメイン配下など、長期間変更せず使えるAD DNS名
- NetBIOS名、フォレストとドメインの境界、管理責任者
- DNS、グローバルカタログ、追加DC、サイトとサブネットの配置
- DSRMパスワードの保管先、System Stateを含むバックアップと復元試験
- 管理用アカウントと通常業務用アカウントの分離、監査と更新の方針
最初のDC自身がDNSを担う構成では、昇格前の参照DNSをどう置くか、昇格後にどこへ向けるかを記録します。既存ドメインへ追加するDCは、まず正常な既存AD DNSを参照させます。一般公開用DNSとAD内部DNSを混同せず、クライアントがADのSRVレコードを引ける設計にします。
サーバー名とIPアドレスは昇格前に確定します。最新の品質・セキュリティ更新を適用し、時刻同期、NIC、ストレージ、イベントログに異常がないことを確認します。仮想マシンならスナップショットだけをADのバックアップと見なさず、サポートされるSystem StateまたはAD対応バックアップを別系統へ保存します。
AD DS役割を追加する
- Server Managerで「役割と機能の追加」を開き、役割ベースまたは機能ベースのインストールを選びます。
- 対象のWindows Server 2019を選び、「Active Directory Domain Services」をチェックします。提示された管理ツールも追加します。
- 確認画面で対象サーバーと役割を再確認してインストールします。この段階ではまだDCではありません。
- 完了後、Server Managerの通知から「このサーバーをドメイン コントローラーに昇格する」を開きます。
PowerShellなら役割追加までは次のように確認できます。コマンドは管理者権限で実行し、対象サーバーと実行結果を記録します。昇格コマンドはドメイン名や資格情報を含むため、コピー実行せずMicrosoftの現行パラメーターを確認して組み立てます。
Get-WindowsFeature AD-Domain-Services
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
新しいフォレストとして昇格する
- 「新しいフォレストを追加する」を選び、確定したルートドメイン名を入力します。既存ドメインへの追加なら該当する選択肢へ変更します。
- ドメインコントローラーオプションでDNSとグローバルカタログ、機能レベル、DSRMパスワードを確認します。
- DNS委任の警告は構成により表示されます。内容を読み、親DNSで委任が必要な設計かを判断します。
- NetBIOS名、NTDSデータベース、ログ、SYSVOLのパスを確認します。性能・バックアップ・容量要件がある場合は既定値を機械的に採用しません。
- 前提条件チェックを実行し、警告とエラーを保存します。未解決のエラーがある状態ではインストールしません。
- インストールと再起動後、ドメイン管理者として入り直して検証します。
DSRMパスワードはドメイン管理者の通常パスワードとは別に生成し、組織の秘密情報管理庫へ保管します。手順書やPowerShell履歴、チケットへ平文で残しません。機能レベルは「新しいOSだから最大」と決めず、参加予定のDC、移行計画、アプリケーション要件に合わせます。
昇格後の確認
- Active Directoryユーザーとコンピューターでドメイン、既定コンテナー、Domain Controllers OUを確認
- DNS Managerで前方参照ゾーン、SRVレコード、動的更新、逆引き設計を確認
- Active Directoryサイトとサービスでサイト、サブネット、DCの所属を確認
- イベントビューアーのDirectory Service、DNS Server、DFS Replication、Systemを確認
- dcdiagでDNSを含む診断を実行し、警告を「よく出るもの」として放置しない
- テスト端末でDNS取得、ドメイン参加、サインイン、グループポリシー適用を確認
dcdiag /v
dcdiag /test:dns /v
Get-ADDomain
Get-ADForest
dcdiagの出力には環境依存の警告も含まれます。テスト名、対象DC、時刻、終了コード、イベントログをセットで保存し、Microsoftの説明と照合します。DNSテストに失敗したままユーザーやGPOの作成へ進むと、後続の症状が複雑になります。
本番投入の前に
最初の管理作業として、OU設計、委任、管理者アカウント分離、監査、パスワードとロックアウト方針、時刻同期の上位ソースを決めます。Default Domain Policyへ何でも詰め込まず、目的別GPOを検証OUへリンクして段階展開します。Domain Admins等の高権限グループは常用アカウントを入れず、定期棚卸しします。
単一DCのままでは、更新、ハードウェア障害、VM基盤障害、誤操作が認証とDNSの同時停止につながります。別障害ドメインへ追加DCを構築し、レプリケーションと復元を試します。追加DCがあっても削除・暗号化・論理破損は複製されるため、オフラインまたは別資格情報で守られたバックアップは必要です。
切り戻しと記録
昇格前に、失敗時にサーバーを再構築する条件、DNSを元へ戻す手順、予約した名前とIPを解放する判断者を決めます。途中失敗したDCを手作業で使い続けず、ログを採取してサポート手順に従います。既存ドメインへの追加時は、強制削除やメタデータクリーンアップを通常の切り戻しにしません。
構築台帳にはOSビルド、更新日、役割、IP、DNS、サイト、GC、FSMO、バックアップ、DSRM保管確認、検証結果を残します。パスワードそのものは台帳へ書きません。数か月後に別担当者が、なぜその設定なのかと正常性を再現できる状態が完成です。
新規フォレストと既存ドメイン追加を間違えない
新規フォレストは組織に新しい認証境界とDNS名前空間を作る操作です。既にADがある会社で、単に2台目のDCを増やしたい場合は「既存のドメインにドメインコントローラーを追加する」を選びます。誤って新しいフォレストを作ると、同じ利用者名でも別のセキュリティ主体になり、既存端末や共有をそのまま管理できません。
ラボでは本番と重複しないドメイン名、ネットワーク、資格情報を使います。本番DNSへテスト用SRVレコードを混ぜず、検証VMをスナップショットから複製する場合はSIDやDC複製のサポート条件を確認します。完成後は検証用の管理者資格情報とDSRM秘密を適切に廃棄します。
本番移行日には、開始前のdcdiagとイベントログ、変更担当、連絡先、利用者影響を記録します。昇格後の再起動だけで正常と判断せず、別端末から新規サインインとGPO取得を試し、DNSキャッシュに依存しない名前解決を確認してから完了を宣言します。

コメント