Microsoft Defender for Endpointのオンボーディングで「スクリプトは実行したのにデバイスが表示されない」「Intuneでは失敗していないように見える」「SENSEサービスが起動しない」といった問題が起きた場合、まず見るべきなのは展開方法・イベントログ・SENSEサービス・WinHTTP/プロキシ・Intune/MDMポリシーです。公式情報では、オンボーディング完了後1時間経ってもデバイス一覧に表示されない場合、オンボーディングまたは接続の問題が疑われるとされています。(Microsoft Learn)
この記事では、Microsoft Defender for Endpoint onboarding issuesのトラブルシューティング要点を、管理者がすぐ確認できる形で整理します。結論から言うと、いきなり再オンボーディングを繰り返すのではなく、最小要件、展開ツールごとのログ、SENSEの状態、ネットワーク到達性、Intune/Configuration Managerの管理経路を順番に切り分けることが重要です。
Microsoft Defender for Endpointオンボーディング問題の要点
Microsoft Defender for Endpointのオンボーディング問題は、単に「Defender側の登録に失敗した」という話だけではありません。実際には、次のような複数の層で失敗します。
| 確認領域 | よくある問題 | まず見る場所 |
|---|---|---|
| 展開方式 | GPOやスクリプトの実行結果が不明 | イベントビューアー、スクリプト出力 |
| サービス | SENSEサービスが起動しない | sc query sense、SENSE Operationalログ |
| 権限 | レジストリへ書き込めない、管理者権限不足 | WDATPOnboardingイベント、実行権限 |
| Intune/MDM | OMA-URI、MDMイベント、非準拠判定 | Intune管理センター、MDMイベントログ |
| ネットワーク | WinHTTPやプロキシ経由でクラウドに到達できない | Client Analyzer、プロキシ設定 |
| サーバー | Windows Server 2016以前でMMAやプロキシ設定に問題 | Microsoft Monitoring Agent、Operation Managerログ |
管理者が最初に避けたいのは、「デバイス一覧に出ないから、とりあえずスクリプトを何度も実行する」対応です。原因がプロキシ、権限、古いOS、Intuneポリシー競合にある場合、再実行だけでは解決しません。
影響範囲：誰が確認すべきか
今回のトラブルシューティング情報は、セキュリティ管理者だけでなく、Intune管理者、Configuration Manager管理者、ネットワーク担当者、端末イメージを扱う開発・運用担当にも関係します。
| 担当者 | 影響する作業 | 確認すべきポイント |
|---|---|---|
| セキュリティ管理者 | Microsoft Defenderポータルでのデバイス可視化 | デバイス一覧、オンボーディング状態、SENSEイベント |
| Intune管理者 | MDMポリシー配布、準拠状態管理 | OMA-URI、MDM自動登録、非準拠理由 |
| Configuration Manager管理者 | 既存管理基盤からの展開 | アプリケーション展開、検出ルール、net start sense |
| ネットワーク管理者 | Defender for Endpointサービスへの通信許可 | WinHTTP、プロキシ、必要URLへの接続 |
| サーバー管理者 | Windows Serverのオンボーディング | MMA、Azure Log Analyticsワークスペース、サーバープロキシ |
| 開発・VDI・イメージ管理担当 | ゴールデンイメージや初回起動時の展開 | OOBE、初回ログオン、起動スクリプトのタイミング |
とくに大規模展開では、Microsoft Defender側の問題に見えても、実際には「プロキシ設定がユーザーのブラウザーには効いているがWinHTTPには効いていない」「オンボードとオフボードのポリシーが同じ端末に当たっている」「古いサーバーでMMAの状態を見ていない」といった運用設計の問題が原因になりがちです。
まず確認すべき初動チェック
オンボーディング後に端末がMicrosoft Defenderポータルへ表示されない場合は、次の順番で確認すると切り分けが早くなります。公式情報では、展開ツール側で明確なエラーが出ていなくても、1時間以内にデバイス一覧へ表示されない場合は、デバイス側のMicrosoft Defender for Endpointエージェントで追加確認する流れが示されています。(Microsoft Learn)
| 順番 | 確認内容 | 具体的な確認方法 |
|---|---|---|
| 1 | 対象OS・ライセンス・前提条件 | Microsoft Defender for Endpointの最小要件を確認 |
| 2 | デバイスが1時間後も表示されないか | Microsoft Defenderポータルのデバイス一覧を確認 |
| 3 | 展開方式のログ | GPO、スクリプト、Intune、Configuration Managerの結果を確認 |
| 4 | SENSEサービス | sc query sense、イベントビューアーのSENSEログを確認 |
| 5 | 通信経路 | WinHTTP、プロキシ、Client Analyzerで接続確認 |
| 6 | ポリシー競合 | Intune、GPO、Configuration Manager、オフボードポリシーを確認 |
| 7 | サーバー固有要件 | Windows Server 2016以前ではMMAとOMS設定を確認 |
最小要件の確認も重要です。Microsoftの最小要件ページでは、サーバーをDefender for Endpointにオンボードするにはサーバー向けライセンスが必要であること、サポートされるWindowsやWindows Server、Mac、Linux、iOS、Androidなどの対象環境が整理されています。(Microsoft Learn)
展開方法ごとの確認ポイント
グループポリシーで展開している場合
グループポリシーでのオンボーディングは、端末上でオンボーディングスクリプトを実行する方式です。ただし、グループポリシー管理コンソールだけでは、展開が成功したかどうかを十分に判断できません。公式情報でも、GPOコンソールは展開成功の有無を示さないため、端末側でスクリプトの出力を確認する必要があるとされています。(Microsoft Learn)
確認すべき場所は次の通りです。
イベントビューアー
└ Windows ログ
└ Application
└ WDATPOnboarding イベントソースGPO展開でありがちな失敗は、スクリプトの配布はできているが、端末側で管理者権限やレジストリ権限が不足しているケースです。GPOのリンク、OU、セキュリティフィルター、WMIフィルターだけでなく、端末側イベントまで確認してください。
ローカルスクリプトで展開している場合
ローカルスクリプト展開では、WDATPOnboardingイベントのIDが重要です。代表的なイベントIDと初動対応は次の通りです。
| イベントID | 主な意味 | 初動対応 |
|---|---|---|
| 5 | オフボードデータを削除できない | HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protectionの権限確認 |
| 10 | オンボードデータをレジストリへ書き込めない | レジストリ権限と管理者実行を確認 |
| 15 | SENSEサービス開始失敗 | sc query sense、ELAM、SENSE FoDを確認 |
| 30 | サービス起動待機に失敗 | SENSE関連イベントを確認 |
| 35 | オンボード状態のレジストリ値が見つからない | HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Statusを確認 |
| 40 | SENSEのオンボーディング状態が1でない | SENSEログで追加エラーを確認 |
| 65 | 権限不足 | 管理者権限で再実行 |
| 70 | 別組織向けのオフボードスクリプト | 正しい組織のオフボードスクリプトを取得 |
イベントID 15では、単に「SENSEが起動しない」と見るのではなく、エラー577または1058、ELAMドライバー、SENSE Feature on Demandの有無まで確認する必要があります。SENSE FoDの状態確認には、管理者権限のCMDまたはPowerShellで次のコマンドを使います。(Microsoft Learn)
DISM.EXE /Online /Get-CapabilityInfo /CapabilityName:Microsoft.Windows.Sense.Client~~~~状態がInstalledでない場合やエラーが返る場合は、SENSE FoDのインストールが必要になる可能性があります。
Microsoft Intuneで展開している場合
Intuneでは、ポリシーが作成されていても端末に反映されない場合があります。公式情報では、Intuneでポリシーを構成しているのにデバイスへ反映されない場合、MDMの自動登録を構成する必要がある可能性があるとされています。(Microsoft Learn)
Intuneで見るべき主な観点は次の3つです。
| 観点 | 確認内容 |
|---|---|
| エラーコード | 0x87D1FDE8、0x87D101A9など |
| OMA-URI | Onboarding、Offboarding、SampleSharing、SenseIsRunning、OnboardingState、OrgId |
| MDMイベント | Microsoft\Windows\DeviceManagement-EnterpriseDiagnostics-ProviderのAdminログ |
たとえば0x87D1FDE8は、オンボードまたはオフボードのBLOBが誤っている、署名が正しくない、必要なフィールドがない、レジストリキーが存在しない、OMA DMクライアントに書き込み権限がない、といった原因が考えられます。公式情報では、HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protectionの存在確認も案内されています。(Microsoft Learn)
Intune運用で特に注意したいのは、オンボードポリシーとオフボードポリシーを同じデバイスへ同時に展開しないことです。非準拠の原因として、両方のポリシーが同一端末へ同時展開されているケースが示されています。(Microsoft Learn)
Microsoft Configuration Managerで展開している場合
Microsoft Configuration Managerを使う場合、Configuration Managerコンソールで展開状況を追跡できます。公式情報では、Configuration Managerバージョン1606以降では、ローカルスクリプトを使わなくても、アプリケーションまたはエンドポイント保護ポリシーでオンボーディング構成ファイルを展開できるとされています。(Microsoft Learn)
Configuration Managerで確認するポイントは次の通りです。
| 確認ポイント | 内容 |
|---|---|
| 展開状態 | Configuration Managerコンソールで成功・失敗を確認 |
| インストールプログラム | net start senseが指定されているか |
| 検出方法 | 展開後の状態を検出できるルールになっているか |
| ユーザーエクスペリエンス | メンテナンス期間や再起動要件が運用に合っているか |
| 端末側ログ | コンソールで成功でもSENSEログを確認 |
GitHub上のMicrosoftDocs履歴では、該当ドキュメントに対して2026年3月5日に「ConfigMgr updates」というコミットが記録されています。これはConfiguration Manager関連の表記やリンク更新が中心であり、管理者は旧称や古いリンクを前提にした手順書を見直しておくと安全です。(GitHub)
デバイス側で確認するSENSEログ
展開ツール側でエラーが出ていないのにMicrosoft Defenderポータルへ表示されない場合は、端末側のSENSEログを確認します。SENSEは、Microsoft Defender for Endpointを支える動作センサーの内部名です。公式情報では、次の場所で重大、警告、エラーをフィルターする手順が示されています。(Microsoft Learn)
イベントビューアー
└ アプリケーションとサービスログ
└ Microsoft
└ Windows
└ SENSE
└ Operational代表的なイベントIDと見方は次の通りです。
| イベントID | 典型的な意味 | 対応の方向性 |
|---|---|---|
| 5 | Defender for Endpointサービスがサーバーに接続できない | インターネット接続、プロキシ、サービスURLを確認 |
| 6 | オンボードされておらず、パラメーターが見つからない | オンボーディングスクリプトを再実行 |
| 7 | オンボードパラメーターを読み取れない | 接続確認後、オンボーディング全体を再実行 |
| 9 | サービス開始タイプを変更できない | 再起動後、オンボーディングを再試行 |
| 10 | オンボーディング情報を保持できない | スクリプト再実行、解消しなければサポート |
| 15 | コマンドチャネルを開始できない | ネットワーク接続を確認 |
| 55 | Secure ETW autologger作成失敗 | デバイス再起動 |
| 63・68 | 外部サービスの開始タイプが想定外 | 変更元のポリシーや管理ツールを特定 |
| 69 | サービス停止 | 該当サービスを開始し、再発時は追加調査 |
ここで重要なのは、SENSEイベントを「結果」ではなく「分岐点」として使うことです。たとえばイベントID 5や15ならネットワーク、6や7ならオンボーディングパラメーター、63や68なら他の管理ツールやGPOによるサービス設定変更を疑います。
ネットワークとプロキシ設定の確認ポイント
オンボーディング問題で見落とされやすいのが、ブラウザーのプロキシ設定とWinHTTPの違いです。Microsoft Defender for Endpointセンサーは、センサーデータの送信やサービスとの通信にWindows HTTP、つまりWinHTTPを使用します。WinHTTPはブラウザーのプロキシ設定やユーザーコンテキストのアプリとは独立しているため、「Edgeではインターネットに出られる」だけでは確認として不十分です。(Microsoft Learn)
接続確認には、Microsoft Defender for Endpoint Client Analyzerを使うのが実務的です。公式情報では、オンボーディング前後のデバイスでClient Analyzerを実行でき、オンボード済み端末ではオンボーディングパラメーターを使い、未オンボード端末では既定の地域情報やオンボーディングパッケージを指定して接続テストできると説明されています。(Microsoft Learn)
基本的な実行例は次の通りです。
C:\Work\tools\MDEClientAnalyzer\MDEClientAnalyzer.cmd合理化された接続方式のオンボーディングパッケージを使う未オンボード端末では、次のようにオンボーディングCMDファイルを指定してテストします。
mdeclientanalyzer.cmd -o <path to onboarding cmd file>Client Analyzerの結果で、いずれかの接続方式がHTTP 200を返していれば、その方式ではDefender for EndpointサービスURLへ通信できていると判断できます。(Microsoft Learn)
診断データサービスとMicrosoft Defender Antivirusの確認
Microsoft Defender for EndpointのEDRサービスは、Windows 10 ビルド1809以降ではDiagTrackサービスへ直接依存しなくなっています。ただし、デバイスが正しく報告されない場合は、Windows診断データサービスが自動起動に設定され、実行中であるか確認する必要があります。(Microsoft Learn)
確認コマンドは次の通りです。
sc qc diagtrackSTART_TYPEがAUTO_STARTでない場合は、自動起動へ変更し、サービスを開始します。
sc config diagtrack start=auto
sc qc diagtrack
sc start diagtrackまた、サードパーティ製ウイルス対策ソフトを使っている環境では、Microsoft Defender AntivirusのELAMドライバーが無効化されていないかを確認します。公式情報では、オンボーディング完了後にサービス開始時エラー577または1058が表示される場合、ELAMドライバーを有効にする必要があるとされています。(Microsoft Learn)
古いポリシーが残っている環境では、次の設定を確認してください。
| 確認項目 | 見る場所 |
|---|---|
| DisableAntiSpyware | HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender |
| DisableAntiVirus | HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender |
| Defender関連サービス | wdboot、wdfilter、wdnisdrv、wdnissvc、windefend |
注意点として、Defender関連サービスの起動設定を独自に変更することはサポートされておらず、環境によっては再イメージ化が必要になる可能性があります。運用で「不要そうだから停止する」といった扱いは避けるべきです。(Microsoft Learn)
Windows Server 2016以前のサーバーで注意すべきこと
Windows Server 2016以前のWindows Serverでは、クライアントOSと同じ感覚でトラブルシューティングすると原因を見落としやすくなります。公式情報では、サーバーのオンボーディング問題ではMicrosoft Monitoring Agent、いわゆるMMAがインストールされ、センサーデータをサービスへ報告するよう構成されているかを確認する必要があるとされています。(Microsoft Learn)
確認すべき項目は次の通りです。
| 確認項目 | 確認場所 |
|---|---|
| Microsoft Defender for Endpoint Serviceのプロセス | タスクマネージャー |
| Operation Managerのエラー | イベントビューアー |
| Microsoft Monitoring Agentの実行状態 | サービス管理画面 |
| Azure Log Analyticsワークスペース | Microsoft Monitoring Agent > Azure Log Analytics |
| ポータル反映 | Microsoft Defenderポータルのデバイス一覧 |
サーバーでは、ライセンス、OS、MMA、プロキシ、Log Analyticsワークスペースが絡みます。特にプロキシ経由の環境では、MMAが必要なURLへ接続できているかを別途確認してください。
新規構築デバイスやゴールデンイメージでの注意点
新しく構築したデバイスでは、オンボーディングパッケージが展開されていても、OOBEや初回ユーザーログオンのタイミングによってSENSEサービスが自動開始しない場合があります。公式情報では、オンボーディングパッケージが新規デバイスに展開されたものの、OOBEまたは最初のユーザーログオンが完了する前にデバイスが停止・再起動された場合、SENSEサービスが自動的に開始されないシナリオが示されています。(Microsoft Learn)
ただし、次のバージョン以降では、SENSEサービス開始にOOBE後のユーザーログオンは不要とされています。
| OS | 条件 |
|---|---|
| Windows 10 | バージョン1809以降 |
| Windows Server | Windows Server 2019以降 |
| Azure Stack HCI OS | バージョン23H2以降 |
VDI、Azure Virtual Desktop、キッティング済みPC、ゴールデンイメージを使う環境では、オンボーディングスクリプトを「イメージに入れた」だけで終わらせず、初回起動後にSENSEが起動し、Microsoft Defenderポータルに単一の意図したデバイスとして表示されるかまで検証する必要があります。
管理者が使える実務向け切り分け手順
現場では、次の流れで対応すると手戻りを減らせます。
| 手順 | 作業 | 判断基準 |
|---|---|---|
| 1 | 対象デバイスを数台に絞る | OS、管理方式、ネットワークセグメントが異なる端末を選ぶ |
| 2 | Microsoft Defenderポータルで反映を確認 | 1時間後も表示されない場合は端末側確認へ進む |
| 3 | 展開方式のログを見る | GPO、Intune、Configuration Manager、スクリプトのどこで止まったか確認 |
| 4 | SENSEログを確認 | イベントIDごとにネットワーク、権限、サービス、パラメーターへ分岐 |
| 5 | WinHTTPとプロキシを確認 | ブラウザーではなくClient Analyzerで到達性を確認 |
| 6 | ポリシー競合を確認 | GPO、Intune、ConfigMgr、オフボードポリシーの重複を排除 |
| 7 | 修正後に再オンボーディング | 原因を潰してから再実行 |
| 8 | 展開対象を広げる | パイロット成功後に段階展開 |
特に大規模展開では、「失敗した端末だけを個別修復する」のではなく、失敗した端末をグループ化することが重要です。たとえば、同じOU、同じプロキシ、同じOSビルド、同じConfiguration Managerコレクションに失敗が集中していれば、端末個別の問題ではなく展開設計の問題である可能性が高くなります。
失敗しやすいポイントと回避策
| 失敗しやすいポイント | なぜ問題になるか | 回避策 |
|---|---|---|
| ブラウザーの通信だけで正常判断する | DefenderセンサーはWinHTTPを使う | Client Analyzerで確認する |
| スクリプトを一般ユーザー権限で実行する | レジストリ書き込みやサービス変更に失敗する | 管理者権限で実行する |
| オンボードとオフボードを同時に配布する | Intuneで非準拠や登録失敗につながる | 対象グループを分離する |
| ConfigMgrとIntuneの管理範囲を曖昧にする | ポリシー競合が起きやすい | 管理プレーンを明確にする |
| 古いサーバーでMMAを見ない | Windows Server 2016以前ではMMAが関係する | MMA、OMS、Operation Managerログを確認 |
| サードパーティAV環境でELAMを確認しない | SENSE開始失敗につながる | ELAMとDefenderポリシーを確認 |
| ゴールデンイメージに入れただけで検証しない | 初回起動やOOBEでSENSEが開始しない場合がある | 初回起動後のポータル反映まで検証する |
| サービス起動設定を独自に変更する | サポート外構成や不安定化の原因になる | Defender関連サービスは既定状態を維持する |
セキュリティ製品の展開では、「強く制御する」ことと「製品が必要とするサービスを止めない」ことのバランスが重要です。ハードニング目的でサービスや通信を絞り込みすぎると、EDRの可視性そのものを失うことがあります。
開発者・運用担当が確認すべき展開上の注意点
開発者やDevOps担当が直接Defenderポリシーを管理しない場合でも、端末イメージ、VDI、検証環境、自動構築スクリプトを扱うならオンボーディング問題に関係します。
確認すべきことは次の通りです。
| 項目 | 確認内容 |
|---|---|
| イメージ作成 | オンボーディングスクリプトの実行タイミングが初回起動後に適切か |
| 自動化スクリプト | 管理者権限、再起動、エラー処理、ログ保存を組み込んでいるか |
| ネットワーク制限 | ビルド環境や検証環境からDefenderサービスへ到達できるか |
| VDI | 再展開時にデバイスが重複登録されない設計か |
| 変更管理 | GPO、Intune、ConfigMgrのどれが設定の正とするか決めているか |
| ロールバック | オフボーディング手順と対象グループを明確化しているか |
運用上は、オンボーディング成功を「スクリプト終了コード」だけで判定しない方が安全です。Microsoft Defenderポータルへの反映、SENSEログ、Client Analyzer、必要に応じた検出テストまで含めて完了条件を定義しましょう。
次に取るべき対応
Microsoft Defender for Endpointのオンボーディング問題は、原因が一つとは限りません。最初に確認すべき答えは明確で、1時間経ってもデバイス一覧に表示されない場合は、展開方式の結果、SENSEイベント、WinHTTP/プロキシ、Intune/MDM、サーバー固有要件を順番に切り分けることです。
まずは、次の3点を管理者向けの標準チェックにしてください。
- パイロット端末で、オンボーディング後1時間以内にMicrosoft Defenderポータルへ表示されるか確認する
- 表示されない端末では、WDATPOnboardingログとSENSE Operationalログを必ず確認する
- ネットワーク問題の判断には、ブラウザーではなくClient AnalyzerとWinHTTP観点を使う
そのうえで、Intune、Configuration Manager、GPO、サーバー、VDIのどこに原因が集中しているかを分類します。個別端末の再実行で終わらせず、展開設計・プロキシ設計・ポリシー競合まで見直すことが、Microsoft Defender for Endpointを安定して展開するための近道です。
コメント