Windows Server 2022 のドメインコントローラーで「システム状態バックアップを別サーバーに復元したら、OS は起動するのに設定アプリや ADUC が動かない」という相談は非常に多いですが、これは設計上ほぼ必ず壊れます。本記事では、その理由と正しい移行・復旧パターン、誤ってやってしまった場合のリカバリー手順、今後のバックアップ戦略の考え方まで、運用者視点で詳しく解説します。
Windows Server 2022 のシステム状態バックアップとは何か
まず前提として、「システム状態バックアップ」とは何を守るためのバックアップなのかを整理します。特にドメインコントローラー（DC）では、ここにAD の心臓部がほぼ全て含まれます。
| コンポーネント | システム状態に含まれる例 | 別サーバーに復元した場合の問題 |
|---|---|---|
| Active Directory データベース | NTDS.DIT、トランザクションログ | 別サーバー上でも「元サーバーとしての DC」として動こうとする |
| SYSVOL | GPO、ログオンスクリプト | DFSR 情報が元 DC 前提のためレプリケーションが破綻 |
| レジストリ | OS／役割の構成、サービス設定 | 元サーバーのデバイス情報・サービス構成が別サーバーへ丸ごと上書き |
| ブート構成 | BCD、起動ドライバー情報 | ハード構成の違いによっては起動エラーや不安定な状態になる |
| COM+ カタログ | COM+/DCOM の設定 | COM ベースの管理ツールやアプリがエラーを起こす |
| マシンアカウント／SID | ドメイン内のコンピューターアカウント、SID 関連情報 | ホスト名・SID・SPN の不整合で Kerberos／RPC 通信が崩壊 |
つまりシステム状態バックアップは、「そのマシンそのもの」を丸ごと保存するイメージに近く、同一マシン（同一ホスト名・同一 SID・同一コンピューターアカウント）への復元を前提としています。別サーバーにそのまま戻すことは、設計の想定外かつサポート外相当です。
別サーバーに復元すると何が起こるのか
今回のケースのように、「OS は起動するが、設定アプリや ADUC が動かない」場合、内部では次のようなことが起きています。
| 表面上の症状 | 想定されるエラー例 | 裏で起きていること |
|---|---|---|
| 設定アプリ（Settings）が開けない／クラッシュする | RPC エラー、グループポリシー適用エラー | GPO 格納先 DC 情報や COM コンポーネント設定が元サーバー前提で矛盾 |
| 「Active Directory ユーザーとコンピューター（ADUC）」が起動しない | 「指定されたドメインが存在しない」「ログオン失敗」など | ローカル DC のマシンアカウント／SPN とドメイン側の情報が一致せず Kerberos 失敗 |
| グループポリシーが適用されない | イベントログに「The processing of Group Policy failed」 | SYSVOL／DFSR の状態が壊れており、ポリシーを取得できない |
| ドメイン参加クライアントからの認証失敗 | 時計ずれ・セキュアチャネルエラー・Kerberos エラー | マシン SID・秘密情報の不整合でセキュアチャネルが破綻 |
| DNS 管理ツールも不安定 | ゾーンの読み込みエラー | DNS サービス構成・AD 統合ゾーンの情報が元 DC フォレスト前提で復元されている |
特にドメインコントローラーの場合、「マシンアカウント」「SPN」「Kerberos 秘密情報」「USN（更新シーケンス番号）」といった、ID とレプリケーションの整合性が非常に重要です。別サーバーにシステム状態を戻した時点で、これらが「元サーバーとして振る舞う DC」に書き換わるため、ほぼ確実に壊れた DC が出来上がります。
なぜ「別サーバーへのシステム状態復元」はやってはいけないのか
考え方としてはシンプルで、次のような状態になるためです。
- 物理・仮想マシンとしては新しいサーバー
- AD 上の情報としては元の DC として振る舞おうとするサーバー
結果として、次のような矛盾が発生します。
- AD 上のコンピューターアカウントは「旧サーバー名・旧 SID」のまま
- 現実のサーバーは新しいハード／新しい VM／別の SID
- DNS 名や SPN、Kerberos チケット発行先の整合性が取れない
- DFSR や USN の情報も旧サーバー前提のため、レプリケーションが壊れる
ここにさらに、仮想環境（Hyper‑V や VMware）でありがちな「DC のスナップショット復元」「一般的なクローン作成」を組み合わせると、USN ロールバックなど致命的な AD 障害に直結します。
まとめると：
- システム状態バックアップは同一マシンへの復元専用
- 別サーバーへの直接復元はサポート外相当であり、AD を壊しやすい
- DC を新サーバーに移行したい場合は「DC の追加 → レプリケーション → FSMO 移譲 → 旧 DC 降格」が基本パターン
正しい移行手順：旧 DC から新 Windows Server 2022 へ切り替える
ここからは、同等構成の新サーバーへ「安全に」役割を移すための標準パターンを整理します。重要なのは「システム状態を丸ごと別サーバーへ戻さない」ことです。
ステップ1：新サーバーをドメインに参加させる
- Windows Server 2022 をクリーンインストール
- IP アドレス・DNS 設定を構成（DNS は既存 DC を指す）
- サーバー マネージャーまたは PowerShell からドメイン参加
Add-Computer -DomainName example.local -Restart
ステップ2：AD DS（＋DNS）役割を追加し、DC に昇格
サーバー マネージャー GUI でも構いませんが、PowerShell でまとめて実行すると再現性が高くなります。
Install-WindowsFeature AD-Domain-Services,DNS -IncludeManagementTools
Install-ADDSDomainController `
-DomainName "example.local" `
-InstallDns `
-Credential (Get-Credential) `
-NoGlobalCatalog:$false `
-SiteName "Default-First-Site-Name"昇格後、自動再起動を待ってから、次のポイントを確認します。
- イベントビューアー（Directory Service／DNS／File Replication Service）に重大エラーがないこと
- DNS ゾーンに新しい DC の NS レコードが登録されていること
ステップ3：レプリケーション状態の確認
レプリケーションに問題があると、後続の FSMO 移譲や旧 DC 降格でつまずきます。代表的な確認コマンドは次の通りです。
repadmin /replsummary
repadmin /showrepl
dcdiag /vエラーが出る場合は、サイトとサービスの設定・DNS レプリケーション・ファイアウォールなどを丁寧に確認してから次に進みます。
ステップ4：FSMO 役割の移譲
フォレスト／ドメインのキーロール（FSMO）が旧 DC に残っている場合は、順番に新 DC へ移譲します。PowerShell では次のようにまとめて移譲できます。
Move-ADDirectoryServerOperationMasterRole `
-Identity "NEWDC01" `
-OperationMasterRole SchemaMaster,DomainNamingMaster, `
PDCEmulator,RIDMaster,InfrastructureMaster移譲後は、必ず確認コマンドを実行します。
netdom query fsmoステップ5：旧 DC の降格とクリーンアップ
新 DC が安定して動作していることが確認できたら、旧 DC を降格します。
- 旧 DC 上で Server Manager または次のコマンドを使用
Uninstall-ADDSDomainController -DemoteOperationMasterRole:$true - 降格後、ドメインからコンピューターアカウントを削除
- DNS ゾーンから、旧 DC の A レコード／NS レコード／SRV レコードなど不要なものを整理
万が一、降格に失敗して強制的にシャットダウンしてしまった場合は、別途メタデータクリーンアップが必要です（後述）。
ステップ6：SYSVOL（DFSR）の正常性確認と GPO テスト
Windows Server 2022 では、SYSVOL レプリケーションは DFSR が標準です。DFS の状態を次のコマンドで確認します。
dfsrdiag ReplicationState
dfsrdiag Backlog /RGName:"Domain System Volume" /RFName:"SYSVOL Share" `
/SendingMember:OLDDC01 /ReceivingMember:NEWDC01 /Smem:OLDDC01 /Rmem:NEWDC01その上で、クライアントから GPO が正常に適用されているかを確認します。
gpresult /rステップ7：クライアント側 DNS 設定と参照順の見直し
最後に見落としがちなのがクライアント側 DNS です。次のようなポイントを確認します。
- DHCP サーバーで配布している DNS サーバー IP が新 DC を指しているか
- 固定 IP を持つサーバーが、旧 DC の DNS を参照したままになっていないか
- 優先 DNS／代替 DNS の順序が適切か（新 DC が優先になっているか）
ここまで実施できていれば、システム状態を別サーバーに復元しなくても、新 DC への移行は完了します。
帯域が厳しい場合のテクニック：IFM（Install from Media）
拠点間の帯域が細い場合、DC の初期同期に時間がかかりすぎることがあります。このような場面では、既存 DC から作成したメディアを使って新 DC を昇格する「IFM（Install from Media）」が有効です。
代表的な流れは次の通りです。
- 既存 DC 上で IFM メディアを作成
ntdsutil activate instance ntds ifm create sysvol full C:\IFM quit quit - 作成した C:\IFM を新 DC にコピー（物理持ち込みや一時ストレージ経由など）
- 新 DC 昇格時のウィザードで「既存メディアから（Install from media）」を選択し、C:\IFM を指定
IFM を使うことで、最初の大容量レプリケーションをローカルコピーに置き換えられます。ただし、あくまで「新 DC を追加」する仕組みであり、今回のように「別サーバーにシステム状態を丸ごと戻す」のとは根本的に異なります。
誤って「別サーバーにシステム状態を復元」してしまった場合の対処
すでに別サーバーに復元してしまい、OS は起動するが管理ツールが壊れている――という状況では、次のような順番で被害を最小化するのが現実的です。
まずやるべきこと
- そのサーバーを即座にネットワークから切り離す
- 壊れた DC がドメインに対してレプリケーションや認証を行うと、健全な DC 側も巻き込まれて壊れるリスクが高い
- 可能であれば、復元前のスナップショット／バックアップにロールバック
- 別サーバーをクリーンインストールし、前述の「正しい移行パターン」で新 DC を構築
メタデータクリーンアップが必要なケース
壊れた DC を一度でもドメインに参加させてしまった場合、AD にはその DC 情報の「残骸」が残ります。このままだと、サイトとサービスや DNS に幽霊のようなオブジェクトが残り続けるため、メタデータクリーンアップが必要です。
代表的には次の手順になります（健全な DC 上で実行）。
ntdsutil
metadata cleanup
connections
connect to server HEALTHYDC01
quit
select operation target
list domains
select domain <番号>
list sites
select site <番号>
list servers in site
select server <壊れたDCの番号>
quit
remove selected server
quit
quitさらに、AD サイトとサービスから当該サーバーオブジェクトが消えていること、DNS ゾーンから関連レコードが削除されていることを確認します。
やってはいけないこと
| やってはいけない操作 | なぜ危険か |
|---|---|
| 壊れた DC をそのままドメインネットワークに戻す | 不整合な AD データや DFSR 状態を他 DC にレプリケートし、被害が拡大する |
| DC を一般的なクローン／コピーで複製する | USN ロールバックなど致命的なレプリケーション障害の原因になる |
| SID 変更ツールやレジストリ直接編集で無理やり整合性を取ろうとする | 表面的に直ったように見えても、内部的に破綻しており将来のトラブル要因となる |
「最後の DC しか残っていない」場合の災害復旧パターン
フォレスト全体で DC が 1 台だけ、あるいは他の DC が完全に失われており、残っているのはバックアップだけというケースでは、「AD フォレスト リカバリー」手順に沿った復旧が必要です。ここでもポイントは「同一マシンへの復元」が基本であることです。
復旧の大まかな流れ
- 対象サーバーをディレクトリ サービス復元モード（DSRM）で起動
- システム状態バックアップを使用して、同一マシンとして非権威／権威復元を実施
- SYSVOL（DFSR）の権威復元を実施
- 起動後に次の点をチェック
- 時刻同期（w32tm）
- FSMO 役割（netdom query fsmo）
- dcdiag／repadmin による健全性
- 必要であれば、新しい DC を追加して冗長構成を再構築
代表的なコマンド例
バックアップ復元自体は、Windows Server Backup（GUI）または wbadmin コマンドで実行します。
wbadmin get versions -backupTarget:F:
wbadmin start systemstaterecovery -version:<バージョンID> -authsysvolSYSVOL の DFSR 情報を権威にする場合には、レジストリ変更や WMI を用いた DFSR 状態変更が絡むため、Microsoft の「SYSVOL の DFSR 権威復元手順」を必ず参照してください。
復旧後は次を重点的に確認します。
- 時刻同期の設定
w32tm /query /status w32tm /query /configuration - FSMO 役割の所在
netdom query fsmo - DC の健全性
dcdiag /v repadmin /replsummary
このようなフォレストリカバリーは手順が複雑なため、可能であればテスト環境で一度リハーサルを行い、本番環境に適用することを強く推奨します。
すぐに使えるチェックリスト
今回のようなトラブルに直面した際、またはこれから Windows Server 2022 を運用していく上で、最低限押さえておきたいチェックポイントをまとめます。
- [ ] システム状態バックアップを別サーバーへ直接復元しない
- [ ] DC を新サーバーへ移行する際は
- [ ] 新 DC をドメイン参加 → DC に昇格
- [ ] レプリケーション確認（repadmin、dcdiag）
- [ ] FSMO 役割を新 DC に移譲
- [ ] 旧 DC を正しく降格し、DNS／メタデータをクリーンアップ
- [ ] SYSVOL（DFSR）の状態確認（dfsrdiag）と GPO 動作確認（gpresult）
- [ ] 災害復旧が必要な場合は、Microsoft の「AD フォレストリカバリー」手順に準拠
- [ ] バックアップ方針として、システム状態だけでなくベアメタル回復（BMR）も定期取得
バックアップ戦略の見直しポイント
最後に、今回のようなトラブルを二度と起こさないための「バックアップの考え方」を整理します。
システム状態＋ベアメタル回復（BMR）の組み合わせ
Windows Server 2022 の DC では、次のようなレイヤーでバックアップを考えると整理しやすくなります。
| バックアップ種別 | 主な用途 | 備考 |
|---|---|---|
| システム状態バックアップ | AD／レジストリ／SYSVOL など OS／AD の「心臓部」の保護 | 同一マシンへの復元専用。別サーバーには移さない |
| ベアメタル回復（BMR） | OS 全体の復旧、ハード障害時の復旧 | 可能な限り同等構成のハード／VM に戻す |
| ファイルレベルバックアップ | アプリケーションデータや共有フォルダの復旧 | DC 以外のサーバー（ファイルサーバーなど）に有効 |
| 仮想マシンスナップショット | 短期的なテスト用ポイント | DC では基本的に使用禁止とし、どうしても使う場合は GenerationID 対応など要検証 |
テストリストアと手順書
バックアップは「戻せて初めて価値がある」ため、少なくとも次のような点を定期的に確認しておくと安心です。
- テスト環境でのシステム状態復元リハーサル（フォレストを隔離して検証）
- ベアメタル回復の所要時間と手順
- 復旧後に実施すべきチェック項目（w32tm、netdom、dcdiag、repadmin など）の一覧化
- 手順書を最新版に保ち、担当者がすぐ参照できる場所に保存
まとめ：別サーバーへのシステム状態復元ではなく、正しい DC 移行を
Windows Server 2022 のドメインコントローラーで、システム状態バックアップを別サーバーに復元すると、OS は起動しても Settings や ADUC などの管理コンポーネントが壊れるのは「ほぼ仕様通りの結果」です。
- システム状態バックアップは同一サーバーに戻す前提で設計されている
- 別サーバーに復元すると、マシン SID／コンピューターアカウント／DNS 名／Kerberos 秘密情報など ID 依存項目が矛盾し、Kerberos／グループポリシー／RPC／AD 管理ツールが破綻する
- DC の移行は、新 DC の追加 → レプリケーション確認 → FSMO 移譲 → 旧 DC 降格という標準パターンで行う
- すでに別サーバーに復元してしまった場合は、ネットワークから切り離し、クリーンな新 DC を構築し、壊れた DC のメタデータをクリーンアップする
- 「最後の DC しか残っていない」ような災害復旧では、Microsoft のフォレストリカバリー手順に従うことが必須
目の前のトラブル対応に追われると、つい「復元できたから大丈夫」と思ってしまいがちですが、AD／DC の世界では「誤った復元」が致命的な将来トラブルの種になります。本記事をきっかけに、システム状態バックアップの位置づけと、DC 移行・復旧手順を一度見直していただければ幸いです。
コメント