Windows 10 / 11 デバイスを Azure AD（現 Microsoft Entra ID）に参加（Azure AD Join）させようとした際、あるいは Intune にデバイス登録（Enrollment）しようとした際に、「Error Code: 80192ee7」 が発生して登録に失敗することがあります。
このエラーは発生原因が多岐にわたるため、単一の対処法では解決しない場合があります。本記事では、Microsoft 公式コミュニティやトラブルシューティング事例から判明している主な原因と解決策を体系的にまとめて紹介します。
この記事を一番最初に書いたのは2021年ごろなのですが、そのきっかけについても少しだけ説明します。2021年ごろ、個人で Windows Virtual Desktop（現 Azure Virtual Desktop）を検証していました（このブログでも100記事ほど投稿）。
WVDを使うために Microsoft 365 E5 ライセンスを購入し、仮想デスクトップと対になる物理PCを Windows 10 Enterprise 化したり、その物理PCを Intune 登録して色々テストを行っていました。この時、80192ee7 エラーが発生し、調べまくったり試行錯誤したので「その情報を誰かの役に立てば」と書いたのが始まりです。その後、2024年以降に判明した最新の知見も加えて更新しています。
目次
Error Code: 80192ee7 の主な原因と解決策一覧
エラー 80192ee7 は、主に クラウド側の管理設定（Intune/Entra ID）、認証情報、または ネットワーク/DNS のいずれかに問題がある場合に発生します。まずは以下の対応フローを順にお試しください。
| 分類 | 主な原因 | 解決策 |
|---|---|---|
| 管理者設定 | WIP（Windows Information Protection）の干渉 | WIP ユーザースコープを 「なし (None)」 に設定 |
| 管理者設定 | MDM ユーザースコープの設定不備 | MDM ユーザースコープを 「すべて」 または 「なし」 に変更 |
| 管理者設定 | デバイス登録制限・台数上限オーバー | Intune のデバイス登録制限・プラットフォーム制限を見直し |
| 管理者設定 | Windows Hello の初期構成エラー | Intune で Windows Hello for Business を一時的に無効化 |
| 認証・アカウント | MFA（多要素認証）情報の不整合 | Entra ID ポータル側でユーザーの認証方法をリセット・再設定 |
| ネットワーク | DNS CNAME レコードの欠落 | EnterpriseEnrollment 等の CNAME レコードを設定 |
| クライアントPC | 古い接続キャッシュ・資格情報の競合 | PCの「職場・学校アカウント」および資格情報マネージャーをクリア |
具体的な対処手順
Microsoft サポートからも案内されている、最も一般的で有効な解決策です。
- Azure Portal（または Microsoft Entra 管理センター）に管理者権限でサインインします。
- [Microsoft Entra ID] > [モビリティ (MDM および WIP)] > [Microsoft Intune] に移動します。
- 「Windows Information Protection (WIP) ユーザースコープ」 を [なし (None)] に変更して保存します。
Note: WIP ポリシーをアクティブに運用していない環境であれば、この設定による影響はありません。
Intune の自動登録が有効になっている場合、MDM ユーザースコープの設定不備によって処理がブロックされることがあります。
- 上記と同じ [Microsoft Intune] 設定画面を開きます。
- 「MDM ユーザースコープ」 の設定を確認します。
- Intune ライセンスを保有するユーザーで自動登録させる場合：[すべて (All)] に設定
- デバイス管理を行わず、単に Entra Join のみにしたい場合：[なし (None)] に設定
- 必要に応じて 「既定の MDM URL を復元する」 をクリックし、エンドポイント URL を再セットアップします。
Intune 側でデバイス登録自体がブロックされているケースです。
- Microsoft Intune 管理センター（
intune.microsoft.com）を開きます。 - [デバイス] > [デバイスの登録] > [デバイスプラットフォーム制限] を開き、Windows（特に BYOD/個人所有デバイスや特定のバージョン）が制限されていないか確認します。
- [デバイス上限の制限] を確認し、対象ユーザーが登録上限数（デフォルト5台など）に達していないか確認します。
ユーザーの携帯電話番号変更やデバイス交換時などに MFA 情報が古くなっていると、登録処理中に 80192ee7 が返されることがあります。
- Microsoft Entra 管理センター にサインインします。
- [ユーザー] > [すべてのユーザー] から該当ユーザーを選択し、[認証方法] を開きます。
- 最新の電話番号や認証アプリ等の情報を管理者側で直接追加・更新し、再度デバイス接続を試みます
カスタムドメイン環境で、デバイスが自動検出エンドポイントを特定できずにエラーとなるパターンです。
- ドメイン管理パネル（DNS サーバー）にて、以下の CNAME レコードが正しく設定されているか確認してください。
- EnterpriseEnrollment:
enterpriseenrollment.manage.microsoft.com - EnterpriseRegistration:
enterpriseregistration.windows.net
- EnterpriseEnrollment:
- クライアント PC からコマンドプロンプトで
nslookup enterpriseenrollment.yourdomain.comを実行し、正しく名前解決できるかテストします。
Entra ID Join 処理と同時に Windows Hello の初期セットアップが走る設定になっていると、途中で通信が切れてエラーになるケースがあります。
- Microsoft Intune 管理センター > [デバイス] > [Windows の登録] に移動します。
- [Windows Hello for Business] を選択します。
- 「Windows Hello for Business の構成」を一時的に [無効] または [未構成] に変更して保存し、デバイス登録完了後に再有効化します。
過去に登録解除を行った、または過去の登録処理が途中で失敗して残骸が残っている場合の設定クリア手順です。
- [設定] > [アカウント] > [職場または学校にアクセスする] を開き、過去の古い接続情報が残っている場合は「切断」します。
- Windows の [資格情報マネージャー] を開き、「Windows 資格情報」および「汎用資格情報」から、対象ドメインや Azure/Office 関連の古い資格情報を削除します。
- PC を再起動し、再度接続を試みます。
トラブルシューティング時の重要な注意点
Intune や Entra ID のクラウド側設定を変更しても、クライアント側に即座に反映されない場合があります。設定変更後は 少なくとも 15〜30 分程度時間をおいてから 再試行してください。
Intune 側の管理画面にエラーログが残っていない場合でも、Microsoft Entra ID の「デバイス監査ログ」 を確認すると、「Add（追加）」と「Delete（自動キャンセル・復旧）」のログから失敗タイミングを絞り込むことができます
（参考情報）私の環境で起きた問題とどうやって解決したか
ここからは、実際に私の環境で発生した問題とその状況、どうやって解決したのかについて紹介します。
Error Code : 80192ee7が発生した手順について、物理PC側で行った Azure AD Join の操作内容を紹介します。
※ エラーが発生したときはスクリーンショットを残せておらず、最終的に問題が解決したときの操作内容となります。
アカウントの設定から “接続” をクリックし、
このデバイスを Azure Active Directory に参加させる をクリックしAzure Active Directory の参加を進めます。
Microsoft 365 のアカウントでサインインします。 Azure AD のデバイス設定についてユーザによる Join を許可しています。
2要素認証を進めます。
組織ネットワークであることを確認し、”参加する” をクリックします。
ここで Error Code : 80192ee7 が発生しました。最初に記載の通り、すでに問題が解消されており Error Code : 80192ee7 のスクリーンショットを残すことが出来ませんでした。
以下は Azure AD Join に成功した際の画面です。
通常、この手のトラブルシューティングはサーバ側とクライアント側のログを確認していきます。 しかし、Intune 側には全くログが無い状況でした。
そこで Azure AD のデバイス監査ログ を確認したところ、ヒントが見つかりました。
ログ上には 「Add」と「Delete」がセットで記録されている履歴 がありました。これは、私が 80192ee7 エラーを解消しようと試行錯誤していたタイミングと一致します。
この挙動から推測されるのは、「Azure AD 側でのデバイス登録自体は成功しているが、その後の Intune デバイス登録フェーズで失敗し、Azure AD の自動復旧プロセス（ロールバック）によって Delete され元の状態に戻されている」 ということでした。
試行錯誤の中で、もともと有効だった MDM ユーザースコープを “なし” に変更しました。
断定はできないのですが、最終的にはこの設定変更によってエラーが解消されたと考えています。
設定変更の直後は相変わらずエラーが発生し、しばらく時間を置いた後にいつの間にか問題が解決していたのですが、これはクラウド側の設定反映にタイムラグがあったためだと推測しています。ログ上は設定直後も失敗していましたが、それは反映待ち時間によるものでした。
ただ、この MDM のコンプライアンスポリシー等で失敗しているのであれば、Microsoft Endpoint Manager Admin Center の画面で何らかのエラーが確認できても良いはずですが、有用な情報は見つけられませんでした（当時は私の Intune の習熟度が低かったため、有識者であればより適切な切り分けができた可能性もあります）。
なお、後日「MDM ユーザースコープを ”なし” にすることが本当に有効だったのか」を切り分けるため、設定を ”なし” から ”すべて” に戻して再検証してみました。設定を ”すべて” に戻した直後は想定通り 80192ee7 エラーが発生したのですが、その後に再度 ”なし” に戻してもすぐにはエラーが解消せず、当時は反映時間の問題も含めてそれ以上の追求を断念しました。
以上
