MENU

Entra ID Connect（旧 Azure AD Connect）アップグレード失敗の対処と復旧手順【今夜中に直す】

Azure

本番環境での Azure AD Connect（現：Microsoft Entra ID Connect）アップグレードが途中停止し、旧版と新版のサービスが混在──そんな「今夜中に直したい」緊急事態を想定した復旧ガイドです。0x31（Invalid Credentials）への対処、残存コンポーネントのクリーンアップ、正しい再インストールと確認手順、暫定復旧と翌日以降の恒久対策まで、実務に即した具体策だけをまとめました。

目次

状況とゴールの整理

想定状況：

  • 旧バージョンを削除して新バージョンへ置き換え中にセットアップが中断。
  • サーバー上に旧版・新版のサービス／ファイルが混在（起動と停止が交互に発生）。
  • 本番：ハイブリッド AD、SSO（Seamless SSO）、パスワード ハッシュ同期（PHS）、Autopilot を利用。
  • ログに Invalid Credentials（0x31） でスキーマ取得失敗の記録あり。

本記事のゴール：

  1. 残骸を安全に除去し、サービスの二重起動や競合を解消。
  2. 0x31 の原因である資格情報不整合を是正。
  3. 正しいオプションで Entra ID Connect を再セットアップ。
  4. 今夜中の業務継続を最優先とした暫定復旧ラインも確保。

復旧戦略（時間優先／恒久対策）の使い分け

戦略目的作業範囲向くケース主なリスク
恒久復旧最新版へ健全移行完全クリーンアップ＋再インストール＋検証保守時間を確保できる、構成が複雑でない時間超過で今夜中の同期再開に間に合わない可能性
暫定復旧今夜の同期再開安定していた旧版を再インストールし一旦復旧業務優先、直近の変更が少ない翌日に再アップグレードが必要、二度手間

10分で現状診断（衝突源の特定）

管理者 PowerShell（昇格）で実行し、混在状態と残存物を洗い出します。

# インストール済み製品名の確認（64/32bit の両方）
Get-ItemProperty `
  'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
  'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*' |
Where-Object { $_.DisplayName -match 'Azure|Entra|DirSync' } |
Select-Object DisplayName, DisplayVersion, InstallDate | Format-Table -Auto

# 競合しそうなサービス

Get-Service | Where-Object { $_.Name -match 'ADSync|DirSync|FIM' } |
Select-Object Name,DisplayName,Status,StartType | Format-Table -Auto

# スケジューラ（古い世代の残骸確認）

Get-ScheduledTask | Where-Object { $_.TaskName -match 'Azure|AAD|DirectorySync' } |
Select-Object TaskName,State,Actions | Format-Table -Auto

# ローカルDB の存在確認（単一サーバー構成想定）

sqllocaldb i

# イベント ログ（直近の 0x31/認証失敗を拾う）

Get-EventLog -LogName Application -Newest 200 |
Where-Object { $*.Source -match 'ADSync|Directory Sync|Azure' -and $*.Message -match '0x31|Invalid|Credential' } |
Select-Object TimeGenerated, Source, EventID, Message | Format-List

目的は「旧エンジン（DirSync 系/FIM 系）」「現行エンジン（ADSync）」の同居と、タスク・DB の取り残しを把握することです。

残存コンポーネントのクリーンアップ

まずは GUI で除去できるものを確実に除去します。

  • 「設定」→「アプリと機能」から Azure AD Connect / Microsoft Entra ID Connect に該当する項目をすべてアンインストール。
  • アンインストール後に以下のディレクトリを確認し、残っていれば バックアップ取得のうえ削除。
    • C:\Program Files\Microsoft Azure AD Sync\
    • C:\Program Files\Microsoft Azure AD Connect\（環境により Azure AD Connect 表記揺れあり）
    • C:\ProgramData\AADConnect\（ログやトレースが残ることあり）

自動削除されない残骸はスクリプトで整理します。

# 旧サービスの停止と無効化（存在確認しつつ実施）
$old = 'DirSync','FIMSynchronizationService' # 例：DirSync世代
foreach($svc in $old){
  if(Get-Service -Name $svc -ErrorAction SilentlyContinue){
    Stop-Service -Name $svc -Force -ErrorAction SilentlyContinue
    Set-Service -Name $svc -StartupType Disabled
  }
}

# 残存スケジュールタスクの削除（確認後に実行）

Get-ScheduledTask | Where-Object {$_.TaskName -match 'DirectorySync|Azure|AAD'} |
Unregister-ScheduledTask -Confirm:$false

# LocalDB の整理（旧インスタンスが暴走するケース）

# ※ フル SQL を使っていない単一サーバー構成のみで実行

sqllocaldb i

# 例：ADSync という名前があれば停止→削除

sqllocaldb p "ADSync"
sqllocaldb d "ADSync"

注意：フル SQL Server を別サーバーで使用している構成では LocalDB の操作を実行しないでください。誤削除は復旧を難しくします。迷ったら DB は触らず、製品の再セットアップで再生成させる方が安全です。

サービスの整理（二重起動の解消）

混在しやすいサービス名と役割の対応表です。存在するものだけに絞って処置します。

サービス名（Name）表示名（DisplayName）世代処置
ADSyncMicrosoft Azure AD Sync現行（Entra ID Connect）最終的に有効。混在時は一旦停止してからクリーンアップ→再インストールで復活させる。
DirSyncWindows Azure Active Directory Sync Service など旧（DirSync/FIM）停止→無効化→削除
FIMSynchronizationServiceForefront Identity Manager Synchronization Service旧（DirSync/FIM）停止→無効化→削除
# 旧サービスの完全削除（存在する場合のみ）
$target = 'DirSync','FIMSynchronizationService'
foreach($svc in $target){
  if(Get-Service -Name $svc -ErrorAction SilentlyContinue){
    Stop-Service $svc -Force -ErrorAction SilentlyContinue
    Set-Service  $svc -StartupType Disabled
    sc.exe delete $svc | Out-Null
  }
}

0x31（Invalid Credentials）の原因と確実な直し方

0x31 は「オンプレ AD へ接続するアカウントの資格情報不一致」が典型です。多くは以下のどれかです。

  • セットアップ ウィザードで入力した AD DS コネクタ アカウント のパスワードが古い／誤り。
  • アカウントがロックアウト／期限切れ／無効化。
  • パスワード変更後に AAD Connect 側へ更新反映していない。

是正手順：

  1. セットアップ ウィザードを再実行し、「既存の構成を修復（Repair）」または「カスタマイズ」を選択。
  2. AD DS コネクタの資格情報に、最新の正しいパスワードを入力。権限は少なくとも以下を満たすこと：
    • ディレクトリ読み取り
    • パスワード ハッシュ同期を使う場合：Replicate Directory Changes と Replicate Directory Changes All
  3. Seamless SSO を使う場合、ウィザードの 「シングル サインオンを有効化」を必ず入れ直す（AZUREADSSOACC のキー更新を行うため）。

補足：構成上「ドメイン管理者相当」でセットアップしても、実運用は最小権限アカウント推奨です。アップグレード時だけ一時的に高権限を使い、その後限定権限の AD DS コネクタ アカウントへ戻します。

再インストール／アップグレードの確実な流れ

前章までのクリーンアップと資格情報修正が終わったら、最新版へ移行します。

  1. 実行ファイルを起動（Microsoft Entra ID Connect セットアップ）。
  2. ウィザードで以下のチェックを入れる：
    • ハイブリッド Azure AD 参加（Hybrid Azure AD join）：オンプレ参加端末をクラウドへ登録。SCP（サービス接続ポイント）の設定を更新。
    • シームレス SSO（Seamless SSO）：AZUREADSSOACC コンピューター オブジェクトのキーを新規作成／更新。
    • パスワード ハッシュ同期（PHS）：パスワード変更のクラウド反映を維持。
    • Autopilot を利用：Intune/Autopilot のグループ評価やデバイス登録に影響が出ないよう、同期スコープと属性マッピングを確認。
  3. カスタム同期ルールを運用している場合：
    • 事前にエクスポートしておいた構成を再インポートするか、ウィザード後に差分を適用。
# バックアップ（アップグレード前に取得しておくのが理想）
Export-ADSyncServerConfiguration -Path "C:\Backup\ADSyncConfig.json" -NoPasswordExport

# 復元（再インストール後、必要に応じて）

Import-ADSyncServerConfiguration -Path "C:\Backup\ADSyncConfig.json" -Force

動作確認：同期・SSO・Hybrid Join・Autopilot

ウィザード完了後、以下の順序で健全性を検証します。

1) サービス状態とスケジューラ

# サービス起動確認
Get-Service ADSync

# スケジューラの状態・次回サイクル

Get-ADSyncScheduler | Format-List

# 直ちに増分同期（Delta）

Start-ADSyncSyncCycle -PolicyType Delta

# 重要変更を入れた場合（属性マッピング変更など）はフル同期（Initial）

Start-ADSyncSyncCycle -PolicyType Initial

2) Synchronization Service Manager（MIIS クライアント）で視覚確認

以下から起動：C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe。
「Operations」タブでエラーがないことを確認し、必要に応じてコネクタごとに Full Synchronization を実行します。

3) Seamless SSO の健全性

  • AD 上に AZUREADSSOACC が存在し、無効化されていないこと。
  • セットアップ ウィザードで SSO を再有効化した直後は、キーの更新が反映されるまで数分待機してからクライアントのサインインを試験。

4) Hybrid Azure AD Join（HAADJ）

  • オンプレ AD の Service Connection Point（SCP） が正しく書き換わっているか。
  • クライアント端末で dsregcmd /status を実行し、AzureAdJoined と DomainJoined の両方が YES になることを確認。

5) Autopilot 影響確認

  • デバイス オブジェクトが想定のグループに評価されるか（同期属性／OU フィルタを再点検）。
  • 少数端末で登録～プロファイル適用のスモークテストを実施。

「今夜中に」業務を動かすための暫定対応

今すぐ同期を復旧させたい場合、安定していた旧版（例：2.4.131.0 など）を再インストールして一旦同期を戻すランディングも現実解です。翌日に計画停止を取り、再度アップグレードして恒久対応に進みます。

  1. 本章冒頭のクリーンアップを実施（旧版が動く最低限の整地）。
  2. 旧版インストーラーでセットアップ。AD DS 資格情報は最新パスワードを必ず入力。
  3. 同期を Delta → 問題なければ Initial で実行。
  4. 夜間帯は監視を強化（イベント ログと失敗件数のトラッキング）。

翌日以降の恒久対策：安全なアップグレード設計

バックアップと凍結

  • 同期の一時停止（Get-ADSyncScheduler → Set-ADSyncScheduler -SyncCycleEnabled $false）。
  • 構成を Export-ADSyncServerConfiguration でバックアップ（パスワード除外でも可）。

ステージング モード運用

  • 別サーバーへ Entra ID Connect をインストールし、ステージング モードで構成同期だけ行う。
  • テスト完了後、主系をステージングへ切替（ステージング側のチェックを外し、旧系のチェックを付与して停止）。

カスタム同期ルールの差分レビュー

  • 「編集した人」「編集日時」「影響属性」を台帳化し、アップグレード直後に差分をレビュー。
  • ムーブ／除外ルールが Autopilot のターゲティングに影響しないか再点検。

よくあるハマりどころと回避策

症状原因の傾向対応策
0x31（Invalid Credentials）でスキーマ取得失敗AD DS コネクタのパスワード不一致／アカウント無効ウィザードで正しい資格情報を再入力。必要権限（読み取り＋RDC/RDCA）を再付与。
ADSync サービスは起動するが同期が動かない旧スケジュールタスクの残骸／LocalDB 競合タスクと LocalDB を整理。Get-ADSyncScheduler で SyncCycleEnabled が True になっているか確認。
Seamless SSO が有効化できないAZUREADSSOACC キー不整合／権限不足ウィザードから「シングル サインオン」を再有効化。必要なら AD 上の AZUREADSSOACC を再作成。
Hybrid Join が登録されないSCP 未設定／GPO・ネットワーク制約ウィザードの「デバイス オプション」で SCP を更新。クライアントで dsregcmd /status を確認。
インストーラーが途中で失敗する.NET/TLS 前提条件不足／古い残骸クリーンアップを徹底。最新の Windows 更新、TLS 1.2 有効化、再起動後に再実施。

現場で使えるチェックリスト

  • アンインストール後のフォルダー残骸を削除した（Program Files/ProgramData）。
  • 旧サービス（DirSync/FIM 世代）を停止・無効化・削除した。
  • LocalDB 競合がない（単一サーバー構成のみ確認）。
  • セットアップ ウィザードで SSO・PHS・Hybrid Join・Autopilot の各オプションを再設定。
  • AD DS コネクタの資格情報は最新パスワードかつ必要権限を満たす。
  • 初回同期：Delta → 問題なければ Initial を完了。
  • MIIS クライアントでエラーがゼロである。
  • クライアント 1 台で SSO と dsregcmd の両方を確認。

参考スクリプト集（コピーして使える最低限）

同期の一時停止／再開

# 停止
Set-ADSyncScheduler -SyncCycleEnabled $false
# 再開
Set-ADSyncScheduler -SyncCycleEnabled $true

強制同期（夜間の暫定復旧で実施）

# 増分同期
Start-ADSyncSyncCycle -PolicyType Delta
# フル同期（構成変更や初期化後）
Start-ADSyncSyncCycle -PolicyType Initial

サービスの健全性表示（簡易）

# 最終同期時刻と次回予定のみを素早く把握
$s = Get-ADSyncScheduler
"LastSync: $($s.LastSyncTime) / Next: $($s.NextSyncCycleStartTime) / Enabled: $($s.SyncCycleEnabled)"

セキュリティと運用の注意点

  • コネクタ アカウントは最小権限で運用し、アップグレード時のみ一時的に高権限を利用する。
  • SSO のキー管理（AZUREADSSOACC）は人事異動に左右されない手順書に落とす。
  • 構成バックアップは平時から自動取得（Export-ADSyncServerConfiguration をタスク化）。
  • テスト用のステージング サーバーを常設し、更新は常にステージング経由で本番へ。

まとめ：最短で安定、翌日に確実

アップグレード途中での停止は「旧世代の残骸」と「資格情報の不整合」が 9 割の原因です。まずは GUI と PowerShell で残存物を掃除し、0x31 を解消するために AD DS コネクタのパスワードを確実に更新。続いて Entra ID Connect を正しいオプション（Hybrid Join／Seamless SSO／PHS／Autopilot）で再構成し、Delta → Initial の順に同期。どうしても今夜の業務再開が最優先なら旧版で暫定復旧し、翌日にステージング経由の恒久アップグレードで完了させてください。これが、現場で実際に使える最短復旧ラインです。

付録：アップグレード前後のベストプラクティス（抜粋）

  • アップグレード前に同期を停止し、Export-ADSyncServerConfiguration でバックアップ。
  • 新サーバーで ステージング モードにて並行稼働テスト後に切替。
  • 完了後はカスタム同期ルールの差分レビューを実施し、手動フル同期で最終確認。

付録：作業ログのサンプル（エラー特定に）

[Operations] Delta Import (Stage) - On-Prem AD Connector
Error: invalidCredentials (0x31)
Detail: Bind to LDAP failed. The supplied credential is invalid.
Action: Re-enter AD DS connector account credentials in setup wizard.

付録：安全な削除・再作成の順序（簡易フローチャート）

残骸把握
  └→ 旧サービス停止→無効化→削除
      └→ スケジュールタスク削除
          └→ LocalDB 整理（必要時のみ）
              └→ 再起動
                  └→ ウィザード実行（資格情報更新）
                      └→ 必要オプション有効化
                          └→ Delta → Initial 同期
                              └→ クライアント確認（SSO/HAADJ）
                                  └→ 監視へ

執筆メモ：本記事は、旧版の残骸を整理しつつ資格情報を修正すれば最新版へ問題なく移行できる、という一点に集中して設計しています。迷ったら「削除より停止・無効化」「DB は触らず再セットアップ」「同期は Delta → Initial」「夜は暫定、昼に恒久」を判断基準にしてください。

Azure
PowerShell トラブルシューティング Azure AD Connect Autopilot Entra ID Connect ハイブリッド Azure AD 参加 シームレス SSO パスワード ハッシュ同期

コメント

コメントする

目次