Intune自動登録トラブルシューティング：GPO適用後も登録されない原因

1. はじめに

1.1 記事の背景

Intuneの導入や既存環境からの移行案件では、「設定はあっているはずなのに、なぜか端末が自動登録されない」という場面に遭遇することがあります。
本記事は、オンプレミスAD環境においてGPOを用いたIntune自動登録構成を行った際、実際に発生したトラブルの記録です。
今回のケースでは、

• GPOの設定内容を見ても問題なさそう
• gpresultでも想定通りポリシーは適用されている
• Intune/Entra ID側の設定やライセンスにも不備は見当たらない

という状況にもかかわらず、端末が一向にIntuneに登録されないという事象に直面しました。最終的に原因は判明しましたが、同じ環境を扱う方が同様のポイントで悩まないよう、本記事ではその内容を備忘録としてまとめています。

1.2 この記事で伝えたいこと

この記事で特に伝えたいのは、以下のポイントです。

• Intune自動登録が失敗する原因は、必ずしも「今設定している内容」だけとは限らない
• GPOを切り替えた際、過去に適用されていた設定が端末側に残り続けることがある
• GPOの現在状態だけでなく「端末の状態」に目を向けることが重要
  本記事が、同様の構成変更やトラブルに遭遇した際の着眼点として、少しでも参考になれば幸いです。

2. 起きた事象

2.1 環境の前提

まず、今回の事象が発生した環境の前提を整理します。
主な前提条件は以下のとおりです。

• オンプレミスAD環境を利用
• 端末はオンプレミスADにドメイン参加済み
• Entra Connectを利用して端末を同期（Entra Hybrid Joined構成）
• GPOを利用してIntune自動登録を構成

GPOによる自動登録は、既存のAD環境を生かした構成として一般的であり、今回も特別な構成や特殊な設定は行っていませんでした。

2.2 実際に起きたこと

GPOを適用後、端末の再起動やgpupdateを実行しても、Intuneへの自動登録は行われませんでした。Intune管理センター上でも該当端末は表示されず、管理者視点では「何も起きていない」ように見える状況でした。
一方で、端末側のイベントログを確認すると、DeviceManagement-Enterprise-Diagnostics-Providerの管理チャネルにエラーが記録されていることがわかりました。
該当するログは以下のとおりです。

※ログ内のホスト名や識別子は、環境固有情報のため一部マスキングしています。

System
  - Provider
    [ Name]  Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider
    [ Guid]  {********-****-****-****-************}

    EventID  76
    Level    2

  - TimeCreated
    [ SystemTime]  2025-09-19T07:11:01.9308776Z

  - Channel
    Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin

  - Computer
    ********.********.***

EventData
  HexInt1  0x1
  HRESULT  0x80180031

イベントIDは76で、HRESULTとして0x80180031が出力されています。

3. 原因

3.1 真因

今回の事象の真因は、過去に適用されていた「デバイス資格情報を使用したIntune自動登録GPO」によるレジストリ設定が、端末上に残り続けていたことでした。
この状態では、管理者が新しいGPOを適用しても、端末から見ると「すでにIntuneに登録済みのデバイス」として誤認識されている状態になっていました。そのため、新しい自動登録処理が開始されず、結果としてIntuneへの自動登録が行われない挙動となっていました。

以下の図は、旧GPOの残存設定がどのように影響し、自動登録の失敗に至ったかを時系列で示したものです。

この挙動は、Microsoft Learnの以下のドキュメントにも言及されています。
端末に残存するMDM関連情報が原因で、MDMポリシーの適用や再登録が失敗するケースについて説明されています。

今回のケースでも、端末側には過去の自動登録情報が残っていたため、新しいGPOによる自動登録が正常に開始されませんでした。

3.2 なぜこの問題が起きたのか

この問題が発生した背景には、GPOの動作仕様があります。
GPOは設定の追加や変更は行いますが、設定を削除・変更したからといって、必ずしも端末上のレジストリが完全に戻るとは限りません。今回のケースでは、GPO自体は正しく設定できていましたが、端末側に残っていた情報が影響し続けており、結果として自動登録が失敗していました。

4. 解決方法

4.1 実施した対応

原因が端末側に残っているMDM関連のレジストリ情報であることが分かったため、端末ごとにレジストリのクリーンアップを実施しました。
方針としては、Intune自動登録に直接関係する残存情報のみに限定することとし、MDMやAutopilotなどほかの機能へ影響が出ないように注意します。
実際に行った手順は以下のとおりです。

1. 事前にレジストリのバックアップを取得
2. Intune自動登録に関連するレジストリキーのうち、過去のMDM登録に紐づく残存情報のみを削除
   ・Enrollments配下の、MDM登録に使用されていたGUIDキー
   ・それに対応するMDM/Provisioning配下の残存情報
3. 端末を再起動
4. 対象ユーザーでサインイン
5. ユーザー資格情報を使用したIntune自動登録GPOが再実行されていることを確認

なお、MDMやProvisioning配下を一括で削除することは推奨されておらず、削除対象はあくまで「MDM登録の残骸と明確に判断できるもの」に限定しています。
具体的には、Enrollments配下のGUIDのうち、DeviceEnroller/MDClient/Poll/Pushを内包するレジストリキーが削除対象です。

※上記画像は以下のMicrosoft Learnに記載されている内容の抜粋です。

5. まとめ

本記事では、GPOを用いたIntune自動登録において、設定自体に問題がないにもかかわらず、端末が自動登録されない事象について紹介しました。今回のケースでは、過去に適用されていた自動登録設定によるレジストリ情報が端末側に残っており、端末自身が「すでにIntuneに登録済み」と誤認識していたことが原因でした。その結果、新しいGPOを適用しても自動登録処理が開始されない状態となっていました。
GPOやIntune、Entra ID側の設定を確認しても原因が見つからない場合、管理者が把握している「現在の設定」と、端末内部の状態が一致していない可能性があります。特に、自動登録方式の変更や過去に異なる構成を適用していた環境では、このような状態が発生しやすいと感じました。
同様の事象に遭遇した際、本記事の内容が切り分けや対応を検討するうえでの参考になれば幸いです。

We Are Hiring

BIPROGYでは一緒に働く仲間を募集しています。ご興味ある方は下記をご参照ください。