Hybrid Entra Join 環境で Intune 登録が行われないとき ― エラー コード別のトラブルシューティング

Last Update: feedback 共有

みなさま、こんにちは。Intune サポート チームです。

前回は、Hybrid Entra Join (Microsoft Entra ハイブリッド参加) 環境でグループ ポリシーによる自動登録がうまくいかないときに、「どこを、どの順番で確認するか」 を 3 つのステップに整理してご紹介しました。

おさらいすると、この構成で登録が動くには ① Hybrid Entra Join の完了 と ② グループ ポリシーの適用 の 2 つがそろう必要があり、その結果は ③ 自動登録タスク の実行を経て、最終的に次のイベント ログに現れます。

1
2
[アプリケーションとサービス ログ] - [Microsoft] - [Windows]
  - [DeviceManagement-Enterprise-Diagnostics-Provider] - [Enrollment]
イベント ID 意味
75 自動登録に成功
76 自動登録に失敗。末尾のカッコ内のエラー コードが原因特定の最大の手がかり

今回はその続きとして、イベント ID 76 で得られたエラー コードから原因を絞り込み、対処するまで をご紹介します。「エラー コードは取れたものの、そこから先をどう調べればよいか分からない」というときに、お手元でご活用いただければ幸いです。

なお、イベント ID 75 も 76 もまったく記録されない というケースもあります。こちらも本記事で扱いますので、あわせてご確認ください。

エラー コードから原因を絞り込む

ここからは、イベント ID 76 で得られた結果に応じて確認していく内容です。順番に実施するものではなく、症状に応じて該当する項目をご覧ください。

主だったエラーについて下記にまとめました。まずは次の早見表から、お手元で確認できた症状に該当する行をお探しください。

症状 / エラー コード 内部名 原因と次に確認すること
0x80180014 MENROLL_E_DEVICENOTSUPPORTED 登録の制限でブロックされている。Intune 管理センター - [デバイス] - [登録] - [Windows] - [デバイス プラットフォームの制限] で登録が制限されるような設定が行われていないかを確認
0x80180018 MENROLL_E_USERLICENSE Intune ライセンスが未割り当て。Microsoft 365 管理センター で対象ユーザーへの割り当てを確認
0x8018002A MENROLL_E_USER_CANCELED サイレントなトークン取得が完了できなかった → 症状 ①
イベント ID 75 も 76 も記録されていない (タスクが作成されない場合も含む) ― 過去の登録情報の残骸 → 症状 ②
0x8018000A MENROLL_E_DEVICE_ALREADY_ENROLLED デバイスが既に登録済みと判定されている → 症状 ②
0x80180026 MENROLL_E_DEVICE_MANAGEMENT_BLOCKED 外部管理フラグなどで登録がブロックされている → 症状 ③
0x83750005 (イベント ID 56 も記録される) WEB_E_UNEXPECTED_CONTENT 構成の検証に使う ValidNodePaths が欠損・破損している → 症状 ④
0x80190190 (メッセージは Bad request (400).) HTTP_E_STATUS_BAD_REQUEST 過去の登録処理のフラグが残っている → 症状 ⑤

0x80180014 / 0x80180018 は、テナント側の設定不備がそのまま現れたもの です。「デバイス側は正しく動いているが、テナント側で弾かれている」状態ですので、表に記載の管理センターをご確認ください。

その他にも一般的なエラーについて、下記の公開情報で紹介をしておりますので、上記に該当するものがない場合、こちらも参考にしてみてください。

症状 ①：エラー コード 0x8018002A ― 多要素認証 (MFA) の要求

イベント ID 76 のエラー コードが 0x8018002A だった場合、まず疑っていただきたいのが 多要素認証 (MFA) の要求 です。条件付きアクセス (Conditional Access) によるものと、ユーザー単位で設定する従来型のものと、どちらでも発生します。

Hybrid Entra Join 環境の自動登録がうまくいかない原因として、実際によく遭遇するパターンです。

なぜ MFA が問題になるのか

グループ ポリシーによる自動登録は、PRT (Primary Refresh Token) を使ってサイレントに (ユーザーに何も聞かずに) トークンを取得 して処理を進めます。このとき、対象ユーザーに対して MFA が要求されていると、追加の認証操作が必要になるため、サイレントなトークン取得を完了できません。

その結果、デバイス上には「管理者による変更が必要です」といった趣旨のトースト通知が表示され、ユーザーがそれに気づかず放置されるとタイムアウトし、最終的に 0x8018002A (MENROLL_E_USER_CANCELED) というエラーで失敗します。

エラー名に “USER_CANCELED” と入っているため「ユーザーが操作をキャンセルした」と読めてしまうのですが、実際にはユーザーが意図的にキャンセルしたとは限らない、という点が切り分けを難しくしています。

見分け方のヒント

この事象には、次のような分かりやすい特徴があります。

  • 失敗するデバイスで、イベント ID 76 のエラー コードが 0x8018002A になっている
  • デバイス上にサインインを促すトースト通知が表示された形跡がある

決め手になるのが、Microsoft Entra ID 側のログとの突き合わせ です。次のログをあわせてご確認ください。

1
2
[アプリケーションとサービス ログ] - [Microsoft] - [Windows]
  - [AAD] - [Operational]

Intune 登録が失敗したタイミングで、次のようなエラーが記録されていれば、MFA の要求が原因であることがほぼ確定します。

1
2
3
4
エラー: 0xCAA2000C 要求にはユーザーの操作が必要です。
コード: interaction_required
説明: AADSTS50076: 管理者によって行われた構成の変更、または新しい場所に移動したために、
      多要素認証を使用してアクセスする必要があります。

interaction_required (ユーザーの操作が必要) というコードが、「サイレントに処理を完了できなかった」 という状況をそのまま表しています。デバイス側の 0x8018002A と、この AADSTS50076 が同じタイミングで記録されていれば、まず間違いありません。

「特定のユーザーだけ登録できない」という状況であれば、ユーザーに適用されている条件付きアクセス ポリシーの差 を確認してみてください。確認の際は、Microsoft Entra 管理センターのサインイン ログで、対象ユーザーの認証が MFA 要求によって中断されていないかをご確認いただくのが確実です。

この症状については、下記の公開情報でも紹介をしています。

💡 共同管理向けの公開情報ですが、原因は同じです
上記は Configuration Manager との共同管理環境を対象とした情報ですが、「PRT を使ったサイレントな登録が MFA 要求で中断される」という原因そのものは、グループ ポリシーによる自動登録でも共通 です。記載されている現象・エラー コード・回避策は、本記事の構成でもそのまま参考にしていただけます。

症状 ②：イベント ID 75 / 76 が記録されない ― 登録をブロックする「レジストリの残骸」

「グループ ポリシーは適用されている」「なのにイベント ID 75 も 76 も記録されず、何も起こらない」。この、いちばんもどかしいパターンの正体が 過去の MDM 登録情報の残骸 であることが少なくありません。

一見すると「エラーすら出ていない」ように見えますが、実際には内部でエラーが発生しています。 ただしそれがイベント ID 75 / 76 には現れないため、「何も起きていない」と判断してしまいがちです。

なぜ 75 / 76 が記録されないのか

Windows は自動登録を実行する前に「このデバイスは既に MDM に登録済みか？」を確認します。ここで 既に登録済みと判定されると、その時点で処理を打ち切ります。

このとき重要なのが、打ち切りが「エラー コードを返して即座に抜ける」形で行われる という点です。その結果、イベント ID 75 / 76 を書き出す処理まで到達しません。「エラーが起きていないから何も出ない」のではなく、エラー自体は発生しているが、75 / 76 には現れない というのが実態です。

具体的には、次のエラー コードが返されています。

1
2149056522 (0x8018000A)  =  デバイスが既に MDM に登録済み

この判定に使われるのが HKLM\SOFTWARE\Microsoft\Enrollments 配下のレジストリです。通常、登録解除時にこれらのエントリは削除されますが、何らかの理由でキーが残ってしまうことがあります。過去に別の MDM 製品をご利用だった場合や、登録解除が正常に完了しなかった場合などが該当します。

確認は「レジストリを直接見る」のが確実です

この事象に該当するかどうかは、判定に使われているレジストリそのものを確認するのが最短 です。後述の「登録情報の『残骸』を確認する」で、具体的な確認方法をご紹介します。

そのうえで、エラー コードが実際に出ていることを裏付けたい場合 は、タスク スケジューラーの 前回の実行結果 列をご確認ください。タスクが作成されている場合、ここに 2149056522 (0x8018000A) と表示されます。追加の設定なしで確認できます。

なお、この判定が起きるとタスク自体が削除される場合もあるため、「一度は動いた形跡があるのにタスクが消えている」 という状態になることがあります。

また、グループ ポリシーが適用された時点で既に残骸があると、そもそも登録タスクが作成されない場合があります。 この場合はタスク スケジューラー側に手がかりが残りませんので、タスクの有無にかかわらず、レジストリをご確認ください。

登録情報の「残骸」を確認する

HKLM\SOFTWARE\Microsoft\Enrollments 配下には GUID 名のキーが複数並んでいることが多く、どれが現在有効な登録で、どれが残骸なのか判断に迷うところです。

見分ける鍵は DiscoveryServiceFullURL という値の有無 です。この値を持つキーは、実際に MDM サービスと通信するための情報を保持している「生きている登録」を示します。

次の PowerShell コマンドで、DiscoveryServiceFullURL を持つ Enrollment ID を抽出できます。

1
2
3
4
Get-ChildItem HKLM:\Software\Microsoft\Enrollments |
    ForEach-Object { Get-ItemProperty $_.PSPath } |
    Where-Object { $_.DiscoveryServiceFullURL } |
    ForEach-Object { $_.PSChildName }

実行結果の例：

1
17ABFAA0-BE06-422E-AB1C-DBDCCBA8D4B6

このコマンドで GUID が出力された場合、Windows はそのデバイスを「MDM に登録済み」と認識している ということです。Intune 管理センターに該当のデバイスが存在しないにもかかわらず GUID が出力される場合、それが自動登録をブロックしている残骸である可能性があります。

特に確認したい「ダミーの登録情報」

残骸のなかでも特徴的なのが、FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF という、すべて F で構成された GUID のキーです。

このキーは自然に発生したものではなく、ドメインに参加していないデバイスに対して一部のポリシーを適用させる目的で、意図的に構成されることがある ものです。Windows からは「MDM に登録済み」と認識されるため、当然ながら Intune への自動登録もスキップされてしまいます。

⚠️ 削除する前に必ずご確認ください
このキーは、過去に何らかの意図をもって構成された可能性があります。削除するとそれまで適用されていた設定が効かなくなる場合がありますので、削除の前に、そのような構成を行っていないか社内の運用担当の方にご確認ください。

残骸を削除する場合 ― 公開されている手順をご利用ください

意図的な構成でないことが確認でき、残骸として削除する場合は、Azure & Identity サポート チームが公開している次の記事の手順をご利用ください。

この記事の 「2. 事前準備: Intune の登録解除」 に、削除対象のレジストリを PowerShell でまとめて処理する手順 が掲載されています。前述の DiscoveryServiceFullURL で Enrollment ID を特定するコマンドから、関連するレジストリ (Enrollments / EnterpriseResourceManager / PolicyManager / Provisioning\OMADM など) の削除、さらに 登録タスクの削除 までが一連の流れとして整理されています。

手作業でレジストリ エディターから 1 つずつ削除するよりも、確実で、削除漏れも起きにくい 手順です。残骸の削除だけが目的であれば、この「2.」の手順のみを実施いただければ十分です。

⚠️ 作業前に必ずレジストリのバックアップを取得してください。
レジストリの編集は、誤るとシステムが正常に動作しなくなるおそれがあります。まずは 1 台のデバイスで動作を確認したうえで、展開されることをおすすめします。

削除後にデバイスを再起動し、あらためて gpupdate /force を実行すると、自動登録タスクが起動するようになります。

💡 Hybrid Entra Join 自体の再構成が必要な場合も
上記の記事は本来、Hybrid Entra Join (MEHJ) をデバイス上で再構成するための手順 です。前編のステップ ① で AzureAdJoined や AzureAdPrt に問題が見つかっていた場合など、登録の土台からやり直したいケースでは、記事の手順を最後まで通して実施 いただくことで解決できることがあります。

なお、残骸が広範に残っている場合や、削除後も改善しない場合は、デバイスを初期化して再展開するほうが結果的に確実で早い ケースもあります。対象デバイスの台数や重要度に応じて、ご判断ください。

症状 ③：エラー コード 0x80180026 ― 「外部管理」フラグが残っている

症状 ② と同じく レジストリが登録をブロックしている パターンですが、こちらは イベント ID 76 にエラー コードが記録される 点が異なります。

イベント ID 76 のエラー コードが 0x80180026 (MENROLL_E_DEVICE_MANAGEMENT_BLOCKED) だった場合、Windows が 「このデバイスは別の仕組みで管理されている」と判断している 可能性があります。

確認するレジストリ

Windows は登録処理の前に「そもそも MDM 登録が許可されているか」を確認しており、次の 2 つの値のどちらかが 0 以外 だと、その時点で登録を拒否します。

キー 値 意味
HKLM\SOFTWARE\Microsoft\Enrollments ExternallyManaged デバイスが外部の仕組みで管理されているとマークされている
HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\MDM DisableRegistration ポリシーで MDM 登録そのものが無効化されている

いずれも 値が存在しない、または 0 であることが正常な状態です。

なぜ ExternallyManaged が残るのか

この値は、サード パーティ製の MDM やデバイス管理エージェントが「このデバイスは自分が管理している」と宣言するために設定する ものです。Windows 側にはこの値を設定するための API が用意されており、外部の管理製品から呼び出せるようになっています。

そのため、過去に別の管理製品を導入していたデバイス で、アンインストール時にこの値が戻されないまま残ってしまう、というケースが起こり得ます。症状 ② の「登録情報の残骸」と発生要因はよく似ています。

対処

意図的に設定されたものでないことを確認したうえで、値を 0 に変更する (または値自体を削除する) ことで登録が可能になります。

⚠️ 削除前に「本当に不要か」をご確認ください
現在も稼働中のサード パーティ製 MDM がこの値を設定している場合、削除するとその製品の動作に影響する可能性があります。その管理製品を既に利用していないこと を確認したうえで実施してください。判断がつかない場合は、当該製品の提供元へご確認いただくことをおすすめします。

変更後に gpupdate /force を実行すると、確実に登録タスクの実行を試行することが出来ます。

症状 ④：エラー コード 0x83750005 ― ValidNodePaths の欠損・破損

こちらもレジストリに起因する問題で、HKLM\SOFTWARE\Microsoft\Enrollments\ValidNodePaths 配下のレジストリが欠損していたり、破損している場合に発生します。

このキーの配下には NodePath1、NodePath2… という値が並んでおり、それぞれに certificatestore、application、registry といった 構成項目の名前 が格納されています。

ここの構成項目の情報が欠損していたり、破損していると Windows は「想定外の内容が含まれている」と判断し、0x83750005 (WEB_E_UNEXPECTED_CONTENT) エラーで登録処理を中止してしまいます。

該当するイベント ログ

このケースでは、イベント ID 76 に加えて イベント ID 56 が記録されます。

1
2
3
4
5
[イベント ID 56]
MDM Enroll: Failed to parse server provisioning XML. Result: (CertificateStore:0x83750005).

[イベント ID 76]
Auto MDM Enroll: Device Credential (0x0), Failed (Unexpected content.) (0x83750005)

確認方法

OS ビルド番号や更新プログラムの適用状況が同じ正常なデバイス と、症状が発生しているデバイスの HKLM\SOFTWARE\Microsoft\Enrollments\ValidNodePaths 配下を比較して、不足している値がないかを確認してください。

キー自体が存在しない、または 値の数が明らかに少ない 場合は、この事象に該当する可能性があります。

対処 ― 正常なデバイスから移植する

このレジストリは、比較元としたデバイスからエクスポートして取り込むことで復旧できます。

  1. 正常に Intune 登録できているデバイスで、上記のキーをエクスポートする
  2. 出力した .reg ファイルを対象デバイスにコピーして取り込む
  3. gpupdate /force を実行し、登録が進むことを確認する

⚠️ エクスポート元のデバイスは慎重にお選びください
この値の内容は OS のビルドによって異なる可能性があります。新しい機能が追加されると項目も増えていくため、異なるビルドから持ち込むと、今度は別の構成項目が弾かれる という事態になりかねません。エクスポート元は、必ず対象デバイスと OS ビルド番号や更新プログラムの適用状況をそろえて ください。

なお、このレジストリが失われている場合、他のレジストリもあわせて破損している可能性 があります。移植しても改善しない場合や、複数の箇所に異常が見られる場合は、OS の再インストール (リセットまたはクリーン インストール) をご検討ください。

どのようなときに起こるのか

このレジストリは、通常の運用で失われるものではありません。実際にご相談いただくのは、カスタム イメージを使って展開されたデバイス や、デバイスのリセット・再イメージングの過程で処理が中断したデバイス といったケースが中心です。

同じイメージから展開したデバイスで同様の事象が複数台発生している場合は、イメージそのものに起因していないか をあわせてご確認いただくとよいでしょう。

症状 ⑤：エラー コード 0x80190190 ― 過去の登録のフラグが残っている

イベント ID 76 に Bad request (400). というメッセージが記録されている場合 (エラー コードは 0x80190190) に疑っていただきたいのが、過去の登録処理で使われたフラグの消し忘れ です。

これも症状 ②・③ と同じ「レジストリの残骸」の一種ですが、残っているのが登録情報そのものではなく、登録処理の途中経過を示すフラグ である点が異なります。

該当するイベント ログ

1
Auto MDM Enroll: Device Credential (0x0), Failed (Bad request (400).)

確認するレジストリ

次の値が 2 になっていないかをご確認ください。

1
2
キー : HKLM\SOFTWARE\Microsoft\Enrollments
値   : MmpcEnrollmentFlag

値が存在しない、または 0 であれば正常です。

この値は、Intune への登録処理の途中経過を示すために使われるもので、本来は処理の完了時に 0 に戻される 想定になっています。

ところが、サーバー側のエラーなどで処理が途中で終わってしまうと、2 のまま残ってしまう ことがあります。その結果、通常の Intune 登録として処理されるはずのリクエストが不正な状態となってしまい、サーバーから「不正なリクエスト (400)」として拒否される という流れになります。

過去に Intune 登録していたデバイスを登録解除し、あらためて Hybrid Entra Join や自動登録を試みた、といったケースで発生することがあります。

対処

値を 0 に変更する (または値自体を削除する) ことで登録が可能になります。変更後に gpupdate /force を実行すると、次回のタスク実行時に登録が試行されます。

ログの採取 ― いざというときのために

ご自身での切り分けが難しい場合や、サポートへお問い合わせいただく場合に備えて、次の情報をあわせてご採取いただけると、調査をスムーズに進められます。

  • dsregcmd /status の出力 (事象が発生しているユーザーのコンテキストで実行。Device State / SSO State に加え、Tenant Details の MdmUrl も含まれます)
  • TSS で採取した診断ログ (次の手順をご参照ください)

TSS で診断ログをまとめて採取する

TSS (TroubleShootingScript) は、マイクロソフトが提供している診断情報の採取ツールです。本記事でご紹介したイベント ログやレジストリのほか、前編でご紹介した情報も含めて、調査に必要な情報をまとめて取得できます。

対象デバイスに管理者権限を持つアカウントでサインインし、次の手順で実行してください。

1. TSS を入手して配置する

下記から TSS.zip をダウンロードし、任意の場所に展開します。以降の手順は、C ドライブ直下 (C:\TSS) に展開した場合の例です。

2. PowerShell を管理者として実行し、ファイルのブロックを解除する

インターネットから入手したファイルはブロックされた状態のため、次のコマンドで解除します。

1
Get-ChildItem -Recurse -Path C:\TSS\*.ps* | Unblock-File -Confirm:$false

3. スクリプトの実行ポリシーを設定する

1
Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned -Force

-Scope Process を指定しているため、変更の影響は現在の PowerShell セッションのみ です。ウィンドウを閉じれば元の設定に戻ります。

4. 情報の採取を開始する

1
2
cd C:\TSS
.\TSS.ps1 -CollectLog ITN_Report

使用許諾 (Microsoft Diagnostic Tools End User License Agreement) が表示された場合は、内容をご確認のうえ [Accept] をクリックしてください。

5. 出力されたファイルを確認する

採取が完了すると、C:\MS_DATA 配下に TSS_<コンピューター名>_YYMMDD-hhmmss から始まる名前の zip ファイルが出力されます。

「正常に登録できているデバイス」と「登録できないデバイス」の両方から同じ情報をご採取いただけると、差分から原因を絞り込みやすくなります。可能であれば、ぜひ両方の情報をご用意ください。

おわりに

今回は、Hybrid Entra Join 環境で Intune 登録が失敗したときに、エラー コードから原因を特定して対処する方法をご紹介しました。あらためて要点を整理します。

  • 特定のユーザーだけ失敗する場合は、MFA の要求 (0x8018002A) を疑う。条件付きアクセスだけでなく、従来型のユーザーごとの MFA が 強制 (Enforced) になっているケースもある。AAD の Operational ログに AADSTS50076 が出ていれば確定。よく遭遇するパターン
  • イベント ID 75 / 76 が出ない ときは、HKLM\SOFTWARE\Microsoft\Enrollments 配下の 登録情報の残骸 を疑う。「エラーが出ていない」のではなく 2149056522 (0x8018000A = 既に登録済み) が返っており、75 / 76 に到達していないだけ。レジストリを直接確認するのが最短で、タスクの 前回の実行結果 列でも裏付けが取れる
  • イベント ID 76 が 0x80180026 のときは、Enrollments の ExternallyManaged と MDM ポリシーの DisableRegistration を確認する。過去に導入したサード パーティ製 MDM のフラグが残っていることがある
  • イベント ID 76 が 0x83750005 (またはイベント ID 56) のときは、Enrollments\ValidNodePaths の欠損・破損を疑う。OS ビルドがそろった正常なデバイスからレジストリを移植して復旧する
  • イベント ID 76 が Bad request (400). (0x80190190) のときは、Enrollments の MmpcEnrollmentFlag が 2 のまま残っていないかを確認する。
  • 残骸の削除は、意図的な構成でないことを確認し、バックアップを取得したうえで慎重に実施する。手順は Azure & Identity サポート チームの公開ブログ (Microsoft Entra ハイブリッド参加デバイスを再構成する) をご利用いただくのが確実

前編とあわせてご覧いただくと、「① と ②、欠けているのはどちらか」を切り分け、③ で得られたエラー コードから原因までたどり着く という一連の流れになります。

この構成のトラブルシューティングは、一見すると手がかりが少なく難しく感じられるかもしれません。しかし「そろうべき条件のうち、欠けているのはどれか」という視点で見ていけば、確認すべき場所は自ずと絞り込まれていきます。ぜひ、本記事をお手元のチェックリストとしてご活用ください。

次回以降も、皆さまの運用に役立つ情報をお届けしていきます。最後までお読みいただき、ありがとうございました。