オンプレミスのActive DirectoryとMicrosoft Entra ID（旧 Azure AD）の同期は、企業のID基盤の「最後の一本の橋」です。障害時にこの橋が落ちないようにするには、ドキュメントの要点をなぞるだけでなく、現場の運用に耐えるディザスターリカバリ（DR）設計が不可欠です。本記事は、最短復旧と安全な切替を両立するための実装指針と、フェールオーバー／フェールバックの運用ノウハウを徹底的に整理しました。
目次
Azure AD Connect サーバーのディザスターリカバリ設定
質問概要
オンプレミスADとMicrosoft Entra ID（旧 Azure AD）を同期するAzure AD Connect（以降、Connect Sync）のサーバーについて、障害発生時に備えたDRをどのように構成すべきか。
結論（先に要点）
最も安全でサポートされるアプローチは、同期エンジンを仮想マシン（VM）で稼働させ、ステージングモードの2台目を常設し、構成を暗号化エクスポートで随時バックアップする二段構えです。障害時は本番VMを止め、ステージングのエクスポートを有効化して即時フェールオーバー、復旧後にフェールバックします。
| 手順／要素 | 具体的な内容・補足 | 狙い（RTO/RPO観点） |
|---|---|---|
| 仮想マシン化 | Connect SyncをVMに導入し、VHD/VHDXイメージ（アプリ整合性）を定期取得。ホスト故障時は別ハイパーバイザへ即時リストア。 | RTOを数分～数十分に短縮。ハード故障に強い。 |
| ステージング サーバー常設 | 2台目をステージングモードで構成。通常はインポート／同期のみ、エクスポート停止。障害時にエクスポートを有効化して切替。 | 本番停止でも同期継続。人為ミスを避けつつ即時切替。 |
| 設定の暗号化バックアップ | ウィザードのExport/Import Settings（PowerShellでも可）でカスタムルール・フィルター・スケジューラ設定を暗号化保存。 | RPOをゼロに近づけ、再構築時の設定差異を抑止。 |
| DB/ファイル保護 | 内部SQL Express（LocalDB）をVMスナップショットで保全しつつ、%ProgramData%\Microsoft\Azure AD Sync配下のADSync.mdf/ldfも世代管理。 | 論理破損や古いスナップショット復元のリスク低減。 |
| 月次の運用確認 | Synchronization Service ManagerのOperationsでエラー監視。差分同期・フル同期の健全性とステージング側の遅延を点検。 | いざという時に切替できる確証を維持。 |
| DR手順書の整備 | 「本番停止→ステージング昇格→DNS/Firewall確認→同期確認→通知」までを手順化。演習は年1回以上。 | 切替時間短縮と誤操作の回避。 |
なぜ「ステージング＋VMイメージ」が最善なのか
Connect Syncはアクティブ－アクティブの同時エクスポートを非推奨とする設計思想です。「常時1台のみがエクスポート」という運用原則を守る限り、DRで求められるのは「もう1台への迅速な主役交代」と「設定差異ゼロの再現性」です。VMイメージとステージングモードはこの要件に自然にフィットし、サポート性も高く、構築や引継ぎが容易です。
前提と制約（重要）
- 同時エクスポートは1台のみ：本番とステージングで同時にエクスポートを有効化しない。ループや重複更新の原因になります。
- スナップショット復元の落とし穴：古いDBを戻すと想定外の削除・再作成が発生し得ます。復元後は必ず差分検証を。
- サインイン方式の影響：PHS（パスワードハッシュ同期）／PTA（パススルー認証）／フェデレーションでDRの考慮が異なります（後述）。
- Cloud Syncとの混在：Connect SyncとCloud Syncは別製品。置換するか共存させるかは要件次第。DR方針も変わります。
アーキテクチャの全体像
推奨の最小構成は次の通りです。
- Connect Sync（本番）：VM化、アプリ整合性スナップショット、エージェント・証明書・AV例外の適用。
- Connect Sync（ステージング）：本番と同一バージョン／同一ルール。エクスポート無効、スケジューラは有効でも可。
- オプション（PTA採用時）：PTAエージェントを少なくとも2～3台に分散導入（同期サーバー以外がおすすめ）。
- 監視：Connect Healthエージェント、イベントログ、Ops月次レビュー。
Connect SyncとCloud Syncの比較（DR視点）
| 項目 | Connect Sync（本記事の対象） | Cloud Sync（参考） |
|---|---|---|
| 運用モデル | サーバー常設。強力なカスタムルール。 | クラウド制御＋軽量エージェント。構成はポータル。 |
| DRの肝 | ステージング＋VMスナップショット。 | エージェント多重化。サーバーDRは軽微。 |
| 適合要件 | 複雑な変換・多フォレスト・書き戻し。 | シンプル要件、迅速展開。 |
構築ステップ（ベストプラクティス）
前準備
- Windows Serverのパッチ適用、TLS 1.2有効化、時刻同期。
- 必要ポートの開放（AD/DC・インターネット・プロキシ）。
- ウイルス対策の除外（
C:\Program Files\Microsoft Azure AD Sync\、LocalDBのDBファイル格納パスなど）。 - 同期に使用するAD DSコネクタのサービスアカウント権限を最小化。
本番サーバー（VM）
- Connect Syncをクリーンインストール（既定はLocalDB）。
- サインイン方式（PHS/PTA/フェデレーション）と同期スコープ（OU/属性）を定義。
- 必要に応じてカスタム同期ルールを作成（Sync Rules Editor）。
- 初回フル同期完了後、エクスポート設定を暗号化でバックアップ。
- アプリ整合性スナップショットのポリシーを適用（前後で
ADSyncサービスのクイエスを推奨）。
ステージングサーバー
- 本番と同一バージョンをインストール。
- セットアップ時にEnable staging modeを有効化。スケジューラは有効のままでOK。
- 本番の暗号化設定ファイルをImportして構成を一致させる。
- 差分同期が追随しているかをOperationsタブで確認。
設定のバックアップ（自動化例）
# 実行サーバー：本番 or ステージング（いずれも可）
$stamp = Get-Date -Format yyyyMMdd_HHmmss
$dir = "C:\Backup\AADC_Config\$stamp"
$newpw = Read-Host "暗号化用パスワードを入力" -AsSecureString
New-Item -ItemType Directory -Path $dir -Force | Out-Null
Export-ADSyncServerConfiguration -Path $dir -Password $newpw
# 変更検出（任意）：構成XMLの差分を出して監査保管
※Import時はImport-ADSyncServerConfiguration -Path <dir> -Password (Read-Host -AsSecureString)を利用します。ウィザードからのExport/Importでも構いません。
障害対応：フェールオーバー手順
計画停止（メンテナンスやホスト更改）の場合
- 本番でスケジューラ停止：
Set-ADSyncScheduler -SyncCycleEnabled $false - 最終差分同期を実行しエクスポート完了を確認：
Start-ADSyncSyncCycle -PolicyType Delta - 本番VMを停止。もしくはネットワーク遮断（二重エクスポート防止）。
- ステージングで昇格：
- ウィザードでStaging Modeのチェックを外す。
- 必要に応じて
Set-ADSyncScheduler -SyncCycleEnabled $true。 - 差分同期を起動し、エクスポートが始まることを確認。
- 監視：Operationsタブ、イベントログ、Connect Healthでエラーがないか確認。
- 周知：切替完了を運用・ヘルプデスクへ通知。
突発障害（ホスト故障・OSクラッシュ）の場合
- 本番サーバーが確実に停止している（通信しない）ことを確認。
- ステージングへ即時昇格（上記と同じ手順）。
- 必要であればVMバックアップから本番を別ホストへリストアし、後述のフェールバックを準備。
切替後の健全性チェック（推奨観点）
- 差分同期サイクルが正常完走すること（Import→Sync→Export）。
- AD→Entraの変更（テストユーザーの属性変更）が所要時間で反映されること。
- PTA利用時：サインイン試験（MFAや条件付きアクセスも含む）。
- Exchange/Group/Device等の書き戻し機能がある場合はテストケースを網羅。
復旧後：フェールバック手順
- リストア済みの本番サーバーに最新設定をImportしてステージング化。
- 現行稼働中（旧ステージング）でスケジューラ停止→最終差分同期→停止。
- 本番サーバーのステージング解除（昇格）、同期開始。
- 問題なければ旧サーバーをステージングに戻す（DR待機役に再配置）。
バックアップ戦略（何を、どれくらいの頻度で）
| 対象 | 場所／方法 | 頻度 | 備考 |
|---|---|---|---|
| VMイメージ | ハイパーバイザのアプリ整合性スナップショット | 毎日～週次＋直前 | 取得前にADSyncサービスを停止すると整合性向上 |
| 構成（暗号化設定） | Export Settings（PowerShellまたはウィザード） | 構成変更のたび／日次自動化 | パスワードは保管庫に分離保管 |
| LocalDBのMDF/LDF | %ProgramData%\Microsoft\Azure AD Sync\ | 日次 | スナップショットと世代管理を合わせ技で |
| ログ／監査 | イベントログ、Operations履歴、変更差分 | 日次収集 | 不整合時の鑑識に有用 |
運用監視と月次点検
- Operationsタブのエラーゼロを維持（Export Errors, Permission-issueなどの早期発見）。
- ステージング側の遅延が溜まっていないか（Import/Syncのキュー増大）。
- 月1回のドライラン切替演習：営業時間外に計画停止プロセスで昇格→戻し。
- Connect Health（インストール推奨）でエージェント健全性・スループット・失敗率を可視化。
サインイン方式別のDR考慮
PHS（パスワードハッシュ同期）
- Connect Syncだけで成立。フェールオーバーは前述の手順で十分。
- 復旧直後は念のためフル同期を検討（
-PolicyType Initial）。
PTA（パススルー認証）
- PTAエージェントは最低2～3台を別サーバーに分散導入（同期サーバーと同居させないのが理想）。
- Connect Syncを切替えても、PTAエージェントが生きていればサインインは継続。
- DR演習ではサインイン検証も必ず実施。
フェデレーション（AD FS等）
- 同期サーバーのDRとは別に、フェデレーション基盤のHA/DRを設計（フェデレーションの証明書更新・WAP・SQL）。
- 切替手順書は同期・フェデレーション双方の観点で統合する。
複数フォレスト・複数コネクタの注意点
- OUスコープ・属性変換・アンカー（sourceAnchor）を設計図として明文化し、両サーバーで完全一致させる。
- 外部ID（UPN/SAM/メール）に基づく結合ルールは、二重エクスポート防止のため特に精査。
- Initial（フル）実行の順番や接続先DCの優先度に一貫性を持たせる。
セキュリティ・ハードニングの勘所
- 最小権限：AD DSコネクタのアカウントは必要権限のみ。パスワード保管は保管庫。
- サーバーは管理端末からのみRDP許可、インターネット直接ブラウズ禁止。
- 自動更新・再起動は同期サイクルと衝突しないようにメンテナンス時間帯で。
- 証明書・TLS・暗号スイートの企業標準に整合。
「よくある落とし穴」と回避策
| 事象 | 原因 | 対処／予防 |
|---|---|---|
| フェールオーバー後に大量の削除提案 | 古いDBを復元、設定差異、ルール順序のズレ | 昇格前に最新設定をImportし、プレビューで差分検証 |
| 両方がエクスポートして属性競合 | 本番停止が不十分、運用連携不備 | ネットワーク遮断またはVM停止を手順に明記、二重防護 |
| PTAで認証失敗が散発 | PTAエージェント単系統、プロキシ経路不安定 | エージェント多重化・経路冗長、監視しきい値を設定 |
| ステージングの遅延が大きい | 接続DCの性能・ネットワーク遅延 | 接続先DCの見直し、スケジューラ間隔や並列度の調整 |
変更管理と監査テンプレート（サンプル）
■ 変更名：OUスコープの追加（営業部）
■ 目的 ：クラウドアカウントの自動プロビジョニング対象拡大
■ 影響範囲：ユーザー100名、グループ15
■ 手順：
1) 本番で設定変更 → Export Settings
2) ステージングへImportし差分検証（Exportプレビュー）
3) 本番に適用、差分同期の完走を確認
■ ロールバック：設定の前版をImport
■ 監査資料：構成XML差分、OperationsログDR演習チェックリスト（配布用）
- 変更凍結の周知／チケット起票
- 本番：
Set-ADSyncScheduler -SyncCycleEnabled $false、Start-ADSyncSyncCycle -PolicyType Delta - 本番VM停止（ネットワーク遮断でも可）
- ステージング：Staging Mode解除、
Set-ADSyncScheduler -SyncCycleEnabled $true - 同期プレビュー・テストユーザーで属性変更の伝播確認
- PTA/サインイン試験、MFA・条件付きアクセス確認
- 関係者へ完了通知、記録保管（所要時間／観測値）
FAQ（現場でよく受ける質問）
Q. ステージングサーバーにも同じDBを共有させられますか？
A. 共有は推奨されません。各サーバーが自前のメタバースを持ち、構成を設定Importで一致させるのが正道です。
Q. VMスナップショットだけで十分ですか？
A. スナップショットは強力ですが、古い状態へ戻すリスクも伴います。設定の暗号化バックアップとDBファイルの世代管理を併用してください。
Q. ステージング側の同期スケジューラは無効にすべき？
A. 一般に有効で問題ありません（エクスポートは無効なので）。定期的に差分を追随させておく方が切替時に安全です。
Q. Cloud Syncへ移行すればDRは不要？
A. Cloud Syncはサーバー負担を減らしますが、要件や変換の複雑さによってはConnect Syncが依然有利です。移行は要件表と試験計画をもって判断を。
実装メモ（運用小技）
- 「人」優先の運用設計：誰が何をいつ実行するかをカード化し、交代要員でも迷わない文言に。
- 通知の二重化：切替時はTeams/メールのテンプレート文面を用意。
- 差分の見える化：構成XMLをGitでバージョン管理し、Pull Request型の承認フローに。
- ラボの維持：本番と同版のミニ環境を保持し、ルール変更は必ずラボ→ステージング→本番の順で。
まとめ
Connect SyncのDRは、ステージング常設＋VMイメージというシンプルな枠組みに、暗号化設定バックアップと月次の演習を添えることで、短時間復旧と安全性を両立できます。ポイントは、二重エクスポートを絶対に避けること、設定差異を出さないこと、そして人が迷わない手順書を維持すること。この記事の手順と表をそのまま運用台本に落とし込み、明日からのDR体制強化に役立ててください。
参考：本記事の実装スニペット一覧
# スケジューラ ON/OFF
Set-ADSyncScheduler -SyncCycleEnabled $true
Set-ADSyncScheduler -SyncCycleEnabled $false
# 差分／フル同期の起動
Start-ADSyncSyncCycle -PolicyType Delta
Start-ADSyncSyncCycle -PolicyType Initial
# 設定の暗号化エクスポート／インポート
$pw = Read-Host "暗号化パスワード" -AsSecureString
Export-ADSyncServerConfiguration -Path "C:\Backup\AADC_Config$(Get-Date -Format yyyyMMdd_HHmmss)" -Password $pw
Import-ADSyncServerConfiguration -Path "C:\Backup\AADC_Config\LATEST" -Password $pw 上記を運用標準化し、ステージングサーバーを確実に育てておけば、障害は「可逆的なイベント」に変わります。DRは仕組みだけでなく、演習と記録が品質を決めます。
付録：設計クイックリファレンス
| 設計項目 | 推奨値／判断基準 | メモ |
|---|---|---|
| サーバー台数 | 本番1＋ステージング1（最小） | PTAならエージェントは2～3台別配置 |
| バックアップ | VMイメージ日次＋設定日次 | 構成変更時は即時バックアップ |
| 演習頻度 | 月次健全性点検、年1回切替演習 | 所要時間を毎回記録し短縮を狙う |
| ルール管理 | Git等で差分管理 | レビューと承認のワークフロー化 |
| 監視 | Operations＋Connect Health | しきい値をチームで合意 |
注意点／デメリット（再掲）
- ステージングにもOSやSQL等のライセンスが必要。
- カスタムルールが多い環境では、設定エクスポートの自動化がないとズレが蓄積。
- 不適切なスナップショット復元は意図しない同期の原因。復元後の検証を徹底。
ここまで実践すれば、Azure AD Connect（Microsoft Entra ID同期）のDR体制は短期間で整備でき、ID連携の継続性と変更管理の品質が飛躍的に向上します。
コメント