Windows Server 2019 のドメインコントローラーが突然故障すると、「とりあえず早く復旧させたい」「でも Active Directory を壊したくない」という板挟みになりがちです。本記事では、レジストリ改変や危険な裏技に頼らず、現場ですぐ使えるシンプルかつ安全な復旧方針と具体的な手順を整理します。
Windows Server 2019 ドメインコントローラー障害の基本的な考え方
まず最初に押さえておきたいのは、「AD にはサポートされた安全な“近道”は存在しない」という事実です。Active Directory は複数のドメインコントローラー（DC）でレプリケーションされる分散データベースであり、1 台だけをレジストリ書き換えや独自スクリプトで無理やり戻そうとすると、次のようなリスクが一気に高まります。
- レプリケーション不整合（オブジェクトの片寄り・競合）
- USN ロールバックによるレプリケーション停止
- 削除済みオブジェクトの“ゾンビ”復活
- メタデータが残留したまま再構築されることによる長期的な不具合
よくある誤解と実際の姿を整理すると、次のようになります。
| よくある考え方 | 実際の姿 |
|---|---|
| レジストリやファイルを直接いじれば手っ取り早く復旧できる | AD は分散 DB。部分的な変更は整合性を壊し、長期的なトラブルの原因になる |
| プライマリ DC だけが特別で、そこだけ守ればよい | Windows Server 2019 では基本的に全ての DC が書き込み可能で対等な存在 |
| 「ベストプラクティス」は手順が多いので、現実運用には向かない | ベストプラクティス通りに復旧方針を絞り込んでおけば、結果的に安全かつ短時間で終わる |
重要なのは、「復元」か「作り直し」かを素早く決めることです。どちらも Microsoft がサポートする正当なアプローチであり、シナリオに合わせて選び切ることができれば、結果的に「簡単で失敗しにくい復旧」に近づきます。
短時間かつ安全に復旧するための二択戦略
現実的な運用フローは、次の 2 パターンに集約できます。
| パターン | 概要 | 向いているケース | イメージ |
|---|---|---|---|
| A：バックアップからの非権威的復元 | システム状態バックアップを用いて DC を元の状態に戻し、他 DC から最新情報をレプリケーションで取り込む | 正常なバックアップがあり、障害原因を明確にできる場合 | 整合性・安全性重視。多少時間がかかっても確実に戻したい |
| B：故障した DC を捨てて新規構築 | 故障した DC を AD から削除し、新しいサーバーを DC として追加する | バックアップがない／古い、あるいは OS/ハード障害が重い場合 | RTO（復旧時間）重視。DC を“使い捨て可能なサーバー”として扱う |
どちらのパターンを選んでも、最後にやるべきことは同じです。
repadminでレプリケーション状態を確認dcdiagで DC の健全性を確認- SYSVOL 共有・GPO 配布・クライアント認証・名前解決の一通りの動作確認
以下では、A・B それぞれの手順を Windows Server 2019 を前提に具体的に解説します。
A：故障した DC をバックアップから非権威的復元する
前提条件と事前チェック
非権威的復元（Non-Authoritative Restore）は、「バックアップから戻した DC を、あくまでレプリカの 1 台として扱う」復元方法です。復元後に他の健全な DC から最新のデータがレプリケーションされるため、古いデータでドメイン全体を上書きしてしまうリスクを避けられます。
実施前に以下を確認します。
| 確認項目 | ポイント |
|---|---|
| バックアップの種類 | 必ずシステム状態バックアップまたはアプリケーション整合な VM バックアップを使用する |
| Tombstone Lifetime 内か | オブジェクト削除情報の保持期間内（多くの環境で既定 180 日）である必要がある |
| 他の DC の状態 | 少なくとも 1 台以上の健全な DC が稼働しており、FSMO 役割を保持していること |
| 障害原因 | ハード障害ならハード交換後、論理障害なら OS の整合性を確認するなど、再発を防ぐ対処を事前に実施 |
非権威的復元の標準手順
1. DSRM（ディレクトリ サービス修復モード）で起動
- Windows Server の起動時に F8 / 回復メニューから「ディレクトリ サービス修復モード」を選択
- セットアップ時に指定した DSRM パスワードでログオン
DSRM は AD DS サービスが起動しない特別なモードであり、ここでシステム状態を安全に復元します。
2. システム状態バックアップを復元（非権威的）
Windows Server 標準の wbadmin を利用する例です。
wbadmin get versions -backuptarget:F:
wbadmin start systemstaterecovery -version:日付-時刻 -backuptarget:F: -quiet
-versionで使用するバックアップを指定- 「復元後にこのドメインコントローラーを権威サーバーにしますか？」のような選択肢が出ても、ここでは非権威的復元を選ぶ（特別な理由がない限り権威的復元は行わない）
バックアップ製品によって手順は異なりますが、必ず「Domain Controller 向けにサポートされた復元手順」に従ってください。
3. 通常モードで再起動し、レプリケーションを待つ
復元が完了したら、サーバーを通常モードで再起動します。起動後に DC として稼働し、他の DC からレプリケーションが実施されます。イベントログ（Directory Service / DFS Replication）にエラーがないか確認しつつ、しばらく様子を見ます。
4. レプリケーション・健全性の確認
他の DC からレプリケーションが正常に行われているか、以下のコマンドで確認します。
repadmin /replsummary
repadmin /showrepl
dcdiag /q
dcdiag /test:sysvolcheck /test:advertising
| コマンド | 目的 |
|---|---|
repadmin /replsummary | 全 DC 間のレプリケーション成否を一覧で確認 |
repadmin /showrepl | 対象 DC ごとの詳細なレプリケーション状況を確認 |
dcdiag /q | 主要な AD テストを実行し、問題があればエラーのみ出力 |
dcdiag /test:sysvolcheck /test:advertising | SYSVOL の公開状態・ドメインコントローラーとして広告されているかを確認 |
5. SYSVOL（DFSR）の非権威的復元が必要な場合
Windows Server 2019 では SYSVOL のレプリケーションに DFSR を利用しているケースが多くなっています。SYSVOL のレプリケーションに問題がある場合、DFSR 専用の非権威的復元手順が必要となります。
- 該当 DC 上で DFSR の状態を確認（イベントログ /
dfsrdiagなど） - MS のドキュメントに従い、SYSVOL の DFSG 非権威的復元を実施
ここまで完了すれば、「元の DC を安全に復元し、他 DC と整合のとれた状態で再参加させた」状態になります。
非権威的復元後によくあるトラブルと対策
| 症状 | 原因候補 | 対処のヒント |
|---|---|---|
| クライアントがログオンできない | DNS のレコード不整合、時間同期ずれ、DC が正しく広告されていない | DNS ゾーンのレコード確認、dcdiag /test:advertising、時刻同期設定の見直し |
| GPO が配布されない | SYSVOL のレプリケーション不良、GPO オブジェクトとファイルの不整合 | SYSVOL の内容確認、DFSR イベントログの確認、必要に応じて DFSR 非権威的復元 |
| 一部の OU / グループが最新でない | 他 DC のレプリケーション遅延、バックアップが古すぎる | repadmin で元となる DC を特定し、全 DC 間レプリケーションを再確認 |
B：故障した DC を捨てて新規構築する（RTO 重視）
多くの現場では、実はこのパターンが一番シンプルで速く、運用への影響も少なく済みます。ポイントは「DC を特別視せず、使い捨て可能な役割サーバーとして設計しておく」ことです。
この方法が向いている典型パターン
- ハードウェア障害で OS が起動せず、物理ホストも古い
- 直近のバックアップがない、または Tombstone Lifetime を超えている可能性がある
- DC に他の重要サービス（ファイルサーバー等）を同居させていない
- 他に 1 台以上の健全な DC が稼働している
このパターンでは、故障した DC を「なかったことにする」ために、FSMO の移譲／奪取とメタデータ クリーンアップを正しく実行することが重要です。
ステップ 1：FSMO を健全 DC に寄せる
まずは健全な DC 側で FSMO（操作マスター）を集中させます。すでに全 FSMO を他の DC が保持している場合は、このステップは不要です。
健全な DC 上の PowerShell から次を実行します。
Move-ADDirectoryServerOperationMasterRole -Identity "HEALTHY-DC01" `
SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster
netdom query fsmo
HEALTHY-DC01は FSMO を集中させたい正常な DC 名に置き換えます。netdom query fsmoで、5 つの FSMO 役割が意図した DC に移っていることを確認します。
完全に故障して二度と起動しない DC から FSMO を奪取する場合は、Move-ADDirectoryServerOperationMasterRole に -Force を付ける、または ntdsutil を使用して「Seize」（奪取）を実施します。
一度奪取した FSMO を、同じ DC にバックアップから復元して再度稼働させることは避けてください。
ステップ 2：故障 DC のメタデータ クリーンアップ
次に、故障した DC の痕跡を AD から正しく削除します。Windows Server 2012 以降では、PowerShell で一括して行えます。
Remove-ADDomainController -Identity "DEAD-DC01" -MetadataCleanup
DEAD-DC01は故障した DC のコンピューター名に置き換えます。- このコマンドは、従来
ntdsutilで行っていたメタデータ クリーンアップを PowerShell ベースで実行します。
併せて、次の要素も必ず確認・削除します。
| 対象 | 確認・削除内容 |
|---|---|
| DNS | 故障 DC の A レコード、SRV レコード（_msdcs / _sites / _tcp / _udp）を削除 |
| サイトとサービス | 該当 DC の NTDS 設定オブジェクト、サーバーオブジェクトが消えているか確認 |
| コンピューターアカウント | ドメインコントローラー用コンピューターアカウントが削除済みか確認 |
ポイント：「オフライン DC の降格」はできません。GUI で降格ウィザードを進めても途中で失敗します。
オフライン DC を「いなかったことにする」正しいやり方が、このメタデータ クリーンアップです。
ステップ 3：新しいサーバーを DC として昇格
クリーンな状態になったら、新しい Windows Server 2019（または互換バージョン）を準備し、DC に昇格します。
- OS インストール後、最新の累積更新プログラムを適用
- 固定 IP の設定、DNS を他の DC に向ける
- ドメインに参加（通常のメンバーサーバーとして参加）
その上で、次のコマンドで AD DS をインストールして昇格します。
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
Install-ADDSDomainController -DomainName "contoso.local" -InstallDns `
-Credential (Get-Credential)
contoso.localを実際のドメイン名に置き換えます。- DNS 役割も兼任させる場合は
-InstallDnsを付けます。 - グローバルカタログにしたい場合は、GUI か追加オプションで GC に設定します。
DC 昇格完了後は再起動が要求されます。再起動後、しばらくレプリケーションを待ったうえで、健全性を確認します。
ステップ 4：repadmin / dcdiag / クライアントでの動作確認
最後に、環境全体の健全性をテストします。
repadmin /replsummary
dcdiag /q
dcdiag /test:sysvolcheck /test:advertising
| 確認項目 | 具体的な確認方法 |
|---|---|
| レプリケーション | repadmin /replsummary でエラーがないこと |
| DC の健全性 | dcdiag /q でエラーが出力されないこと |
| SYSVOL 共有 | \\新DC名\SYSVOL にアクセスでき、既定のポリシーが存在すること |
| GPO 配布 | テスト用クライアントにポリシーを適用し、想定通り反映されること |
| 認証 | 複数ユーザーでドメインログオンを試し、エラーがないこと |
| DNS 解決 | クライアントから nslookup でドメイン名、DC 名、外部名が解決できること |
ここまで問題がなければ、「故障した DC をサポートされた手順で捨てて、新しい DC を正しく追加できた」状態です。必要に応じて FSMO を再配置し、冗長構成ポリシーに沿った役割配置に調整します。
復旧を「簡単＆安全」にするための事前整備
ここまでの手順は、あくまで障害発生後にできることです。復旧を本当にシンプルにする鍵は、障害が起きる前にどこまで準備できるかにあります。
| 施策 | 具体例 | 効果 |
|---|---|---|
| DC の仮想化 + アプリ整合バックアップ | Hyper-V / VMware 上に DC を構築し、Generation ID 対応の VM バックアップ製品で定期取得 | DC OS 障害時に VM 単位で迅速復元。スナップショット起因の USN ロールバックを回避 |
| DC の“薄化” | DC 上にファイルサーバーやアプリケーションを同居させない | DC を「壊れても作り直せるサーバー」にできるため、B のパターンが取りやすくなる |
| PowerShell 自動化スクリプト | FSMO 移譲／奪取、メタデータ クリーンアップ、新 DC 昇格のスクリプト化 | 障害時の手順抜け・タイプミスを防ぎ、作業時間を短縮 |
| 複数書き込み可能 DC + GC | 最低 2 台以上の DC を用意し、そのうち 1 台以上をグローバルカタログに | 単一障害点を排除し、どちらが落ちてもドメイン運用を継続可能にする |
| バックアップ＆リストア演習 | 検証環境で定期的に DC の復旧リハーサルを実施 | 「手順どおりやったのに戻らない」を本番で初めて経験しないですむ |
| IFM（Install From Media）の活用 | 帯域の細い拠点向けに、メディアからの DC 昇格を準備 | 巨大な AD を WAN 越しにフルレプリケーションせずに DC を追加できる |
| AD リサイクル ビンの有効化 | 誤って削除したユーザーや OU を簡単に復元可能にする | オブジェクト単位のトラブルで「DC 復元」が不要になり、大がかりな復旧作業を減らせる |
PowerShell による半自動化のイメージ
障害時の操作を完全自動化することは推奨されませんが、「毎回同じコマンドをミスなく実行する」ための半自動化は有効です。以下は、FSMO 保持状況を確認し、特定の DC に集約する処理のイメージです。
# FSMO を集約したい DC 名
$TargetDc = "HEALTHY-DC01"
Write-Host "現在の FSMO 役割保持 DC を確認します..."
netdom query fsmo
$answer = Read-Host "FSMO を $TargetDc に移譲しますか？ (y/n)"
if ($answer -ne "y") {
Write-Host "処理を中止しました。"
exit
}
Move-ADDirectoryServerOperationMasterRole -Identity $TargetDc `
SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster -Confirm:$false
Write-Host "FSMO 移譲後の状態を確認します..."
netdom query fsmo
このようなスクリプトを複数用意しておくことで、障害時に PowerShell の履歴を見ながら手打ちする必要がなくなり、作業時間とヒューマンエラーを大幅に削減できます。
やってはいけない NG パターン
短時間で復旧したいあまり、次のような“時短テクニック”に手を出すと、後から回収できないレベルのトラブルを招くことがあります。
| NG 行為 | 何が起こるか | 代わりにやるべきこと |
|---|---|---|
| レジストリ直接編集による「お手軽復旧」 | 一見動いているように見えても、レプリケーション不整合や将来の更新失敗の原因になる | 必ず DSRM + システム状態バックアップによる復元、または DC の再構築を選択 |
| 古いスナップショットへのロールバック | USN ロールバックが発生し、レプリケーション全体が止まる | Generation ID 対応のアプリケーション整合バックアップを用いた復元を行う |
| Tombstone Lifetime を超えたバックアップでの復元 | 削除済みオブジェクトが復活せず、整合性が取れない環境になる | バックアップが古すぎる場合は、復元ではなく DC を作り直す方針に切り替える |
| オフライン DC の「降格」を GUI で実行 | 途中で失敗し、メタデータが中途半端に残る | オンラインで降格できない DC は「メタデータ クリーンアップ」で削除する |
| 1 台しか DC がない環境での気軽なスナップショット操作 | その 1 台が壊れると、ドメイン全体の再構築が必要になる | 最低 2 台の DC を用意し、バックアップと復旧手順を事前に検証しておく |
中小規模環境での現実的な設計例
中小企業や小規模拠点では、「DC 2 台も要らない」「バックアップもコストが…」という声が上がりがちです。しかし、障害が起きてからの復旧コストを考えると、次のような最低限の構成を検討する価値があります。
推奨構成の一例
- 書き込み可能 DC を 2 台（どちらも Windows Server 2019）
- 両方に DNS と GC を構成
- 少なくとも 1 台は仮想化し、アプリケーション整合なバックアップを取得
- 両 DC を別ホストに配置（同じ物理マシンにまとめない）
この構成であれば、片方の DC が完全に壊れても、以下の流れで短時間に復旧できます。
- 健全 DC に FSMO を集中（または既に集中していることを確認）
- 故障 DC のメタデータ クリーンアップ
- 新しいサーバーを準備し DC に昇格
- repadmin / dcdiag で確認して終了
逆に、DC が 1 台しかない環境でその 1 台が壊れると、「ドメインの新規構築」レベルのインパクトが発生します。ユーザーアカウントやグループポリシーを一から作り直すコストを考えると、DC 2 台＋バックアップの投資は決して高くありません。
用語の整理
最後に、記事中で登場した主要な用語をもう一度整理しておきます。
| 用語 | 概要 |
|---|---|
| DSRM（Directory Services Restore Mode） | AD DS を起動せずにサーバーを立ち上げ、システム状態復元などを行うための特別な起動モード |
| 非権威的復元（Non-Authoritative Restore） | バックアップから DC を復元した後、他の DC から最新データで上書きさせる復元方式 |
| FSMO（Flexible Single Master Operation） | Schema、Domain Naming、PDC、RID、Infrastructure の 5 つの操作マスター役割 |
| メタデータ クリーンアップ | 故障した DC の情報を AD / DNS / サイト情報から正しく削除して「なかったことにする」作業 |
| Tombstone Lifetime | 削除済みオブジェクトの情報を保持しておく期間。この期間を過ぎたバックアップでの復元は危険 |
| USN ロールバック | スナップショットなどからの不正なロールバックで発生するレプリケーション障害の一種 |
まとめ：迷わず「復元」か「作り直し」を選べるようにする
Windows Server 2019 のドメインコントローラー障害時に「簡単で安全」な復旧を実現するには、魔法のような裏技やレジストリ改変ではなく、次の 3 点に集約されます。
- 復元可能なら A（非権威的復元）を選ぶ
正常なバックアップがあり、Tombstone Lifetime 内であれば、DSRM + システム状態バックアップで堅実に復元し、他 DC から最新データをレプリケーションさせる。 - 復元が重い／間に合わないなら B（作り直し）を選ぶ
FSMO を健全 DC に寄せ、メタデータ クリーンアップで故障 DC を正しく「なかったことに」したうえで、新しい DC を追加する。 - 事前整備で作業を“普通の運用作業”に落とし込む
複数 DC 構成、バックアップ、PowerShell スクリプト、定期的なリハーサルを通じて、「手順書どおりにやれば誰でも復旧できる」状態を作る。
どのパターンを選んだ場合でも、repadmin / dcdiag / SYSVOL の 3 点セットで数値と結果を確認してから「復旧完了」と判断することが重要です。
この運用に整えておけば、Windows Server 2019 のドメインコントローラー障害が発生しても、落ち着いて安全かつ短時間の復旧を実現できるようになります。
コメント