複数のオンプレ AD フォレストを1つの Entra ID テナントに統合しつつ、Windows Autopilot（ハイブリッド参加）を運用したい――そんな現場で悩むのが Intune Connector for Active Directory の配置設計です。本記事ではマルチフォレスト構成の勘所と、ODJ blob が別コネクタに送られて失敗する事象の切り分けを解説します。
複数フォレスト×単一 Entra ID テナントで Autopilot を回す全体像
まず押さえるべきポイントは、「ID は1テナントに集約できても、オンプレ AD へのドメイン参加（ODJ）は“参加先ドメイン”ごとにオンプレ側の受け口が必要」ということです。Windows Autopilot で Microsoft Entra ハイブリッド参加を行う場合、クラウド側（Intune/Autopilot）が発行した要求を、オンプレ側の Intune Connector for Active Directory（ODJ コネクタ） が受け取り、対象の Active Directory にコンピューターオブジェクトを作成して、オフラインドメイン参加情報（ODJ blob）を返します。
この仕組みは「フォレストが複数でも、Entra ID テナントは1つ」という設計と相性が良い一方で、フォレスト/ドメインの切り分けが曖昧だと、後述のように ODJ blob の誤ルーティングや権限・通信要件の抜けで詰まりやすくなります。
| 要素 | 役割 | マルチフォレストでの設計ポイント |
|---|---|---|
| Microsoft Entra ID テナント（旧 Azure AD） | ユーザー/デバイスのクラウド側 ID、条件付きアクセス、Intune の管理基盤 | フォレストが複数でもテナントは1つに集約可能。UPN/重複属性の設計が重要。 |
| Microsoft Entra Connect Sync（旧 Azure AD Connect） | 複数フォレストの ID を1テナントへ同期 | 原則は1つの同期サーバーで全フォレストに到達できること。複数のアクティブ同期サーバーは非推奨/非サポートの扱いに注意。 |
| Intune | ポリシー/アプリ配布、Autopilot プロファイル配布、ODJ 要求の管理 | フォレスト（=参加先ドメイン）ごとにプロファイル/割り当ての分離が鍵。 |
| Intune Connector for Active Directory（ODJ コネクタ） | ODJ 要求を受け、指定 OU にコンピューターオブジェクトを作成 | 「参加先ドメインごとにコネクタが必要」。複数台で冗長化は可能。 |
結論：複数フォレストにコネクタを置いて、1つのテナントで運用できる
Microsoft Q&A でも、複数フォレストにそれぞれ Intune コネクタを配置し、単一の Entra ID テナントに紐づけて Windows Autopilot を利用する構成自体は可能、と整理されています。
ただし、ここで“可能”と言っているのは構成として成立するという意味です。Microsoft Learn のドキュメントでは、Autopilot による新規デバイス展開を「Microsoft Entra 参加（クラウドネイティブ）へ寄せる」ことが推奨されており、ハイブリッド参加（Autopilot 経由）は新規展開としては推奨されない、と明記されています。運用上の制約が増えるため、長期的には Entra 参加へ移行するロードマップを持つのが現実的です。
Intune Connector for Active Directory の“重要な制約”を先に把握する
マルチフォレスト設計で事故を減らすには、コネクタの制約を「仕様」として扱うのが近道です。
| 項目 | 要点 | 設計に効く理由 |
|---|---|---|
| サーバー要件 | Windows Server 2016 以降 + .NET Framework 4.7.2 以降が前提。インターネットと AD への到達性が必要。 | 「コネクタはオンプレに置けばOK」ではなく、ネットワーク設計（プロキシ/RPC/名前解決）まで含めて初めて動く。 |
| コネクタの対応ドメイン | 複数ドメインで Autopilot を行う場合、ドメインごとに別インスタンスが必要。コネクタはインストールされたサーバーと同一ドメインの要求しか処理できない。 | 「Forest A の要求が Forest B のコネクタに送られる」と失敗しやすい根本理由。後述の誤ルーティングの理解に直結する。 |
| 台数設計 | 1サーバーにコネクタは1つ。冗長化したい場合は同一ドメイン内でサーバーを増やしてコネクタを追加する。 | 「負荷分散のつもりで1台に複数入れる」は不可。運用/BCP はサーバー台数で担保する。 |
| バージョン/サポート | 古いコネクタは段階的に廃止。特定バージョン未満は要求を処理できない旨が明記されている。 | 「コネクタは Intune で Active になっているのに失敗する」ケースは、バージョン差分が原因になることがある。 |
| 権限モデル（新コネクタ） | 新しいコネクタはローカル SYSTEM ではなく Managed Service Account（MSA） を使用し、最小権限を前提に設計されている。 | 「全部フル権限」はセキュリティ上の問題だけでなく、誤ルーティング時の影響範囲を広げる。 |
マルチフォレスト設計の基本方針
ここからは、実務での設計判断を「迷いにくくする」ための方針をまとめます。ポイントは“参加先ドメインで分ける”ことです。フォレストという単位は運用・組織の事情で増えがちですが、Autopilot のハイブリッド参加の成否は最終的に「どのドメインに、どの OU へ、どの権限で作るか」で決まります。
- 参加先ドメインを先に確定：新規PCは Forest A なのか Forest B なのか。部署/拠点/調達ルートでブレない軸を作る。
- OU をフォレスト/ドメインごとに専用化：Autopilot 専用 OU を用意し、委任・監査・フィルタリングを単純化する。
- Autopilot プロファイルとドメイン参加設定を“セットで分離”：Forest A 用、Forest B 用を混ぜない（割り当てグループも排他的にする）。
- コネクタの権限は最小化：特に双方向トラストがある場合、フルコントロールは“できてしまう”範囲が広く、トラブル時の切り分けが難しい。
| 決めること | 具体例 | 落とし穴 |
|---|---|---|
| 参加先ドメイン | 拠点 A は corp-a.example.com、拠点 B は corp-b.example.com | 「とりあえずトラストがあるからどっちでも」をやると、後で移設/命名/OU が破綻する。 |
| Autopilot の割り当て軸 | Group Tag を FORESTA / FORESTB で分け、動的グループで振り分け | 同じデバイスが複数の Autopilot プロファイル対象になると失敗要因になる。 |
| OU 設計 | OU=Autopilot,OU=Workstations,DC=corp-a,DC=example,DC=com | OU ベースの同期フィルタを使っていると、Autopilot で作った PC が Entra に同期されず後工程で詰まる。 |
| コネクタの冗長化 | 各ドメインに 2 台（同一ドメイン内の別サーバー） | 「1サーバーに2つ」は不可。冗長化＝サーバー追加。 |
構成例：フォレスト A / フォレスト B を1テナントで運用する
典型的な構成例を、具体的な運用イメージに落とし込みます。
構成の骨格
- Entra ID テナント：1つ（Intune/Autopilot もこのテナントで運用）
- オンプレ AD：Forest A と Forest B（必要に応じてトラストあり/なし）
- Entra Connect：1台（到達できない場合はネットワーク設計を見直し、複数アクティブ構成にしない）
- Intune Connector for AD：Forest A の参加先ドメイン用に1台以上、Forest B の参加先ドメイン用に1台以上
- Autopilot：Forest A 用プロファイル + Forest A 用ドメイン参加設定、Forest B も同様
“誰がどこで何をするか”の対応表
| 作業/設定 | Forest A | Forest B | 共通（テナント） |
|---|---|---|---|
| コネクタのインストール | Domain A に参加済みサーバーに導入 | Domain B に参加済みサーバーに導入 | Intune 管理者でサインインしてテナントへ登録 |
| OU と委任 | Autopilot 専用 OU を作成し、MSA に最小権限を委任 | 同様 | OU が同期フィルタ外になっていないか確認 |
| Autopilot プロファイル | FORESTA グループへ割り当て | FORESTB グループへ割り当て | デバイスが二重割り当てにならないよう統制 |
| ドメイン参加設定（ドメイン名/OU） | Domain A の FQDN と OU DN を指定 | Domain B の FQDN と OU DN を指定 | 設定が混在しないようにプロファイルを分割 |
実装で差が出るポイント
Entra Connect（旧 Azure AD Connect）の注意点
質問文では「同じ AD Connect で複数フォレストを同期」との前提がありました。この方向性は一般的です。ただし“複数のアクティブ同期サーバーで同一テナントへ同期する”ような構成は、Microsoft Learn では基本的にサポート対象外（例外は Staging mode）とされています。マルチフォレスト環境であっても、まずは1台で全フォレストに到達できる配置を検討し、BCP はステージングサーバーで担保するのが安全です。
また、ドメイン/OU ベースのフィルタを使っている場合は、Autopilot で作成されるコンピューターオブジェクトの既定 OU（または指定 OU）が同期対象に含まれている必要があります。ここが外れていると、ドメイン参加自体はできても、その後のデバイス状態がクラウド側で整わず、ハイブリッド参加の完成まで到達しないことがあります。
Intune 側の割り当て設計（Autopilot プロファイル/ドメイン参加設定）
誤ルーティングや“片方だけ成功する”系のトラブルの多くは、実はオンプレではなく Intune 側の割り当てが原因です。特に次の2点は、チェックリストとして運用に組み込む価値があります。
- デバイスが複数の Autopilot プロファイル対象になっていないか：Microsoft Learn のトラブルシュートでも、複数グループ割り当てによる競合に触れています。
- Forest A 用と Forest B 用で、ドメイン名/OU 設定が完全に分かれているか：プロファイル自体を分け、割り当てグループも排他的にするのが現実解です。
コネクタの更新と“新旧混在”のリスク
2025 年にかけて Intune Connector for Active Directory はセキュリティ強化の流れで更新され、MSA（低権限）を使う新しいモデルへ移行しました。旧モデル（SYSTEM を使うレガシー）にはサポート期限があり、古いバージョンは要求処理自体ができないとされています。「まずは全ドメインでコネクタの世代とバージョンを揃える」のが、マルチフォレスト運用の安定化に直結します。
ODJ blob が誤ったフォレスト側コネクタに送られて失敗する事象
Microsoft Q&A には、次のような事象が報告されています。
- Forest A 用コネクタと Forest B 用コネクタを、同一 Entra ID テナントに登録
- Forest 間に双方向トラストあり
- 両コネクタに、どのドメインでもコンピューターオブジェクトを作成できるように強い委任を付与
- しかし Forest A のデバイス登録時に ODJ blob が Forest B 側のコネクタへ飛び、エラー 80070002 で失敗（逆も同様）
このスレッド内では明確な解決策が提示されておらず、環境差・実装差（バージョン差を含む）で再現性が変わる可能性があります。そこで本記事では、「再現環境でも外れにくい」観点で、原因候補と対策の優先順位を整理します。
最初に理解しておくべきこと：コネクタは“同一ドメインの要求しか処理できない”
Microsoft Learn の要件では、複数ドメインを扱う場合はドメインごとにコネクタが必要であり、コネクタはインストールされたサーバーと同じドメインの要求しか処理できない、とされています。つまり、もし本当に Forest A（Domain A）向けの ODJ 要求が Forest B（Domain B）のコネクタへ届くと、仕様上うまく完走しないのは自然です。
よくある原因候補と、現実的な対処
| 原因候補 | 起きがちな症状 | 優先度の高い確認/対処 |
|---|---|---|
| ドメイン参加設定（ドメイン名/OU）の割り当てミス | 本来 Forest A に入れたい端末が Forest B 用のドメイン参加設定を掴む | Forest ごとにドメイン参加設定を分け、割り当てグループを排他的に。デバイスが複数プロファイル対象になっていないかも確認。 |
| 同名ドメイン/同名 NetBIOS など識別子の衝突 | FQDN は違うのに短縮名が同じ、ログや UI では同じに見える | 可能なら識別子を揃えない。設定では常に FQDN を使用し、ログ収集時は domainFQDN と DC を明記。 |
| コネクタの権限を“広げすぎ”ている | どちらのコネクタでも作成できる状態になり、挙動が不安定/切り分け困難 | 最小権限へ戻す。特に新コネクタでは OU を設定ファイルで明示し、MSA に許可する OU を限定する。 |
| コネクタの世代/バージョン差 | 片方のドメインだけ断続的に失敗、更新後に急に失敗など | 全ドメインで新コネクタへ統一し、要件のバージョンを満たしているかを確認。 |
| コネクタ～AD 間の到達性不足（RPC/名前解決/プロキシ） | コネクタは Active に見えるが、ODJ 作成時だけ失敗する | コネクタサーバーが DC へ標準的なドメインクライアント通信（RPC 等）を行えるか確認。端末側も DC を ping できる必要がある。 |
“最小権限化”が誤ルーティング対策として効く理由
新しいコネクタでは、MSA は「設定ファイルに列挙した OU（と既定の Computers コンテナー）のみ」へ作成権限を付与するモデルです。逆に言うと、OU を絞ることでコネクタが処理できる範囲を意図的に狭められます。双方向トラスト環境で何でもできる状態にすると、問題発生時に “どちらが処理したのか” が追いにくくなるため、運用面でも最小権限が有利です。
なお、これは「誤ルーティングが必ず直る」という断定ではありません。Intune サービス側のルーティングロジックや、特定バージョンでの既知不具合など、クラウド側要因も考えられます。ただ、少なくとも設計としては、権限と OU を分離しておくほど原因切り分けが容易になり、結果として復旧が早くなるのは間違いありません。
切り分け手順：現場で再現したときに“迷わない”進め方
誤ルーティング/80070002 を短時間で切り分けるための実践手順です。ポイントは「クラウド側（割り当て）」「オンプレ側（コネクタ）」「ネットワーク（到達性）」を同時に疑わず、順番に潰すことです。
| 手順 | 確認内容 | 期待する結論 |
|---|---|---|
| 割り当ての棚卸し | 端末がどの Autopilot プロファイル/ドメイン参加設定を受け取っているか。二重割り当てがないか。 | “Forest A の端末は Forest A 設定のみ”の状態にする。 |
| コネクタの状態確認 | Intune 管理センターで Active/Version を確認。古いビルド/非アクティブが混在していないか。 | 全ドメインで同世代のコネクタに揃える。 |
| コネクタのイベントログ確認 | ODJConnectorService の Admin/Operational ログで、要求の DomainName やエラーを追う。 | 「どの要求が、どのコネクタで処理されようとしているか」を事実として掴む。 |
| 一時的な単独運用テスト | 片方のコネクタを停止/切り離し、もう片方だけで挙動を見る（検証環境推奨）。 | 誤ルーティングの再現条件を絞り込む。 |
| 権限と OU の分離 | コネクタの MSA（またはサービスアカウント）が作成できる OU を “そのドメインの専用 OU のみに” 絞る。 | 「本来の担当範囲だけ処理できる」状態を作り、挙動の安定化を狙う。 |
ログ取得の最低セット
- コネクタサーバー：イベントビューアー「Applications and Services Logs > Microsoft > Intune > ODJConnectorService（Admin/Operational）」
- 端末側：Autopilot 診断（OOBE の診断ページ）と、DeviceManagement-Enterprise-Diagnostics-Provider のログ
- Intune 側：端末が受け取ったプロファイル、割り当てグループ、コネクタ一覧（Active/Inactive/Version）
運用で安定させるためのチェックリスト
| チェック項目 | OK の目安 | 補足 |
|---|---|---|
| 新規デバイスの参加方式の方針 | 原則は Entra 参加、例外としてハイブリッド参加 | Microsoft は新規を Entra 参加へ寄せることを推奨。 |
| コネクタの世代・バージョン統一 | 全ドメインで同世代、要件バージョン以上 | 古いコネクタは要求処理できない旨がある。 |
| OU の同期スコープ | Autopilot 専用 OU が同期対象に入っている | OU フィルタ利用時は特に見落としやすい。 |
| 割り当ての排他性 | 端末が複数の Autopilot プロファイル対象にならない | 競合は失敗要因になり得る。 |
| コネクタの権限 | 専用 OU の作成/削除に必要な最小権限 | 新コネクタは MSA + OU 制限モデル。 |
| ネットワーク到達性 | 端末が DC に到達し ping できる。コネクタも AD とインターネットに到達できる | プロキシ/WPAD や RPC も要件に含まれる。 |
まとめ：マルチフォレストは“できる”が、分離設計がすべて
複数フォレストを単一 Entra ID テナントに集約し、Windows Autopilot（ハイブリッド参加）を回すこと自体は可能です。とはいえ、ハイブリッド参加はクラウドネイティブな Entra 参加より設計要素が多く、フォレスト/ドメイン/OU/権限/割り当てが少しでも混ざると途端に不安定になります。
今回の「ODJ blob が別フォレストのコネクタへ送られる」事象も、根っこは“担当範囲の曖昧さ”で起きやすいタイプです。まずはドメイン参加設定と割り当てを完全に分離し、次にコネクタの最小権限化（OU 限定）で処理範囲を絞り、ログで事実を取りながら切り分けてください。それでも再現が続く場合は、取得したログ一式を添えて Microsoft サポートへエスカレーションするのが最短です。
コメント