MENU

Intune Autopilot のログ収集・状態確認ガイド｜ESP/IMEログとスクリプト保存場所、最終再起動の把握

Microsoft 365

Intune と Windows Autopilot を使った Windows 端末展開は便利な一方で、「どのポリシーが当たっているのか分からない」「ESP（Enrollment Status Page）で止まった」「配布した PowerShell が端末のどこに落ちているのか知りたい」といった運用の悩みが出やすい領域です。ここでは Intune 管理センター（ポータル）と端末ローカルの両面から、ログ収集・状態確認・スクリプト保存場所・最終再起動の把握方法をまとめます。

目次

Intune Autopilot 端末の状態確認：ポータルと端末で何が分かる？

Autopilot のトラブルシュートは、ポータルで「割り当て／結果」を確認し、端末で「処理の実ログ」を追うのが最短です。まずは「どこを見れば、何が分かるのか」を早見表で整理します。

知りたいことIntune ポータル側（例）端末ローカル側（例）補足
割り当てられている構成プロファイル／ポリシー／更新リング「トラブルシューティング + サポート」またはデバイス詳細の各タブMDM/IME ログ、イベントログ、診断レポートポータルは“割り当て”、端末は“適用の中身”を見る
アプリ（Win32/Store）インストール状況アプリ配布のモニター、デバイスのアプリ関連タブ、検出済みアプリIME ログ、イベントログ、インストール済みアプリ一覧ESP で止まる場合は「どのアプリがブロック要因か」を特定
Autopilot/ESP のプロビジョニング状態Autopilot 関連レポート、デプロイ状態のビューC:\ProgramData\Microsoft\Windows\ESP\Logs端末の ESP ログは「何を待っているか」が見える
最終再起動（最終起動）日時標準の一覧ビューでは直接見えないことが多いPowerShell / systeminfo など複数台はスクリプトで収集し、レポート化するのが現実的
Intune 配布 PowerShell / 検出・修復の保存場所デバイス詳細の「スクリプト」やレポートIME の一時領域（実行後に消えることがある）フォルダが空でも異常とは限らない。ログで実行履歴を追う

Intune ポータル側で確認できる情報（割り当て・適用結果・アプリ・Autopilot）

ユーザー起点で「割り当て済みポリシー」を俯瞰する

「このユーザーの端末に、何が割り当てられているのか」を素早く把握したいときは、ユーザー起点のトラブルシューティングが便利です。代表的な導線は次の通りです。

  • ヘルプとサポート → トラブルシューティング + サポート → トラブルシューティング → 対象ユーザーを選択

対象ユーザーに紐づくデバイスを選ぶと、構成プロファイル、コンプライアンスポリシー、Windows Update の更新リングなど、割り当ての全体像を一覧で確認できます。Autopilot は「ユーザー割り当て／デバイス割り当て」の設計で結果が変わるため、“誰に割り当てているか”を先に揃えると切り分けが一気に楽になります。

デバイス起点で「適用結果」を深掘りする

個別端末の状態を追う場合は、次の導線でデバイス詳細を開きます。

  • デバイス → Windows → 対象デバイスを選択
よく見るタブ/項目分かること確認のコツ
概要（Overview）最終チェックイン、準拠状態、OS バージョン、所有者など最終チェックインが古いなら、まず登録/通信/プロキシを疑う
構成プロファイル割り当てプロファイルと適用結果（成功/失敗/保留）失敗は「競合」や「対象外」も混ざる。エラー詳細を開いて原因を分離する
コンプライアンスポリシー準拠/非準拠の判定と根拠非準拠が複数あるときは、最初に直すべき1件を決める（連鎖で改善することが多い）
更新ポリシー（更新リング等）Windows Update for Business 系設定の適用状況反映にはタイムラグがある。チェックイン時刻と合わせて判断する
スクリプト配布スクリプトの実行状況（成功/失敗）「成功」でも期待結果とズレることがある。端末側のログ/出力も見る

インストール済みアプリをポータルで確認する：検出済みアプリ（Discovered apps）

「端末に何が入っているか」をポータルから手早く確認したい場合は、デバイス詳細の 検出済みアプリ（Discovered apps） が役立ちます。

  • デバイス → 対象デバイス → 検出済みアプリ

配布したアプリが「配布は成功しているはずなのに入っていない」ケースでは、まずこの一覧に載っているかを見て、“未検出（＝入っていない）”なのか、“検出されているが別問題”なのかを切り分けると早いです。

Autopilot/ESP に関する確認ポイント

Autopilot では、次のような観点をポータル側で押さえておくと、現場対応がスムーズです。

  • Autopilot デバイスとして登録されているか（対象端末の識別子/グループタグなど）
  • Autopilot プロファイルが割り当てられているか（割り当て先グループ、フィルター）
  • ESP を有効化している場合、ブロック対象（必須アプリ/必須設定）が何か
  • どのフェーズ（デバイス準備/アカウント設定/アプリ）で詰まっているか

ポータルで概要を掴み、端末側の ESP ログで「何を待っているか」を確認する、という流れを作ると、再現待ちが減ります。

ポータルからログを回収する：デバイス診断（Collect diagnostics）

端末に触れない状況でも、Intune のリモート操作で診断ログを回収できる機能が用意されています（名称や表示箇所は環境により異なる場合があります）。

  • ユーザーに「Zip を作って送ってください」と依頼せずに済む
  • MDM/IME/イベントログなど、トラブルシュートに必要な情報がまとまる
  • 回収後はポータルからダウンロードして確認する

特に Autopilot のように初期セットアップで問題が起きる領域は、“端末側のログが無いと結論が出ない”ことが多いので、ログ回収の手順を運用に組み込んでおくと安心です。

端末ローカル側で確認するログ・情報（Autopilot/IME/再起動/アプリ）

最終再起動時間の確認（端末単体）

単体端末の「直近の起動（再起動）日時」を確認する代表的な方法です。英語検索文字列に依存しない PowerShell を覚えておくと、言語混在環境でも困りません。

方法コマンド例強み注意点
systeminfo（英語表示を前提）systeminfo | find "System Boot Time"cmd でも動くOS 言語によって検索文字列が変わる
PowerShell（推奨：言語依存が少ない）(Get-CimInstance Win32_OperatingSystem).LastBootUpTimeスクリプト化しやすい実行権限や実行ポリシーに注意
最終起動＋稼働時間を一度に出す$os = Get-CimInstance Win32_OperatingSystem $boot = $os.LastBootUpTime $uptime = (Get-Date) - $boot "{0} / LastBoot={1} / UptimeHours={2:N1}" -f $env:COMPUTERNAME,$boot,$uptime.TotalHours運用で「何日再起動していないか」が即わかる端末のタイムゾーン/時刻設定に依存

Autopilot / ESP（Enrollment Status Page）ログの保存場所

Autopilot のプロビジョニング状況を振り返るなら、ESP ログが最重要です。端末上では次のパスに保存されます。

C:\ProgramData\Microsoft\Windows\ESP\Logs

ESP で止まる場合、ポータルのエラーだけでは「どの待機ポイントで止まっているか」が読み取りづらいことがあります。ESP ログは、アプリのインストール待ちなのか、ポリシー適用待ちなのか、といった切り分けに強いログです。

Intune Management Extension（IME）ログの保存場所

Win32 アプリ配布や PowerShell スクリプト配布（デバイス スクリプト／検出・修復）を使うなら、IME ログは必須級です。代表的なログの置き場所は次の通りです。

  • C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

「ダウンロードしたか」「実行したか」「戻り値は何か」「再試行しているか」などが時系列で追えるため、フォルダの実体を追う前に、まずログで“事実”を押さえるのが安全です。

イベントビューアーで見る：MDM/Autopilot の代表的なイベントログ

GUI で素早く状況を見たい場合はイベントビューアーも有効です。よく参照されるカテゴリの例は次の通りです（環境により名称が多少異なる場合があります）。

  • MDM/デバイス管理：DeviceManagement-Enterprise-Diagnostics-Provider
  • Autopilot：AutoPilot（Operational）
  • 展開/セットアップ：Modern Deployment-Diagnostics-Provider など

ポータルのエラー情報とイベントログのタイムスタンプを突き合わせると、原因の当たりがつけやすくなります。

端末ローカルで「どのポリシーが効いているか」を確認するコツ

Intune の構成プロファイルや設定カタログは、Group Policy のように gpresult で一発一覧化できるわけではありません。そのため端末ローカルで確認するときは、次の考え方が現実的です。

  • 「割り当て」はポータルで確認し、端末では適用の痕跡（ログ/診断レポート）を確認する
  • “何が効いているか”は、ポリシーの名称そのものよりも、結果として端末がどうなっているか（設定値・動作）で判断する

端末側で情報をまとめて採取したい場合は、Windows のMDM 診断レポート（職場/学校アカウントの情報画面から作成できるレポート）を使うと便利です。生成先は画面に表示されるパスに保存されるため、保存先を確認して ZIP/フォルダの中身を参照してください。

  • 設定 → アカウント → 職場または学校にアクセス → 接続中アカウント → 情報 → 診断レポートを作成（文言は OS ビルドで変わることがあります）

診断レポートには、MDM 関連のログや状態がまとまって出力されます。調査時は、対象日時の前後で ポリシー適用・アプリ配布・再起動が起きていないかをタイムラインで追うと、原因に辿り着きやすくなります。なお、レポートには端末情報が含まれるため、取り扱い（共有範囲・保管先）には注意してください。

インストール済みアプリを端末ローカルで確認する（必要時）

「ポータルの検出済みアプリに反映されるのを待てない」「検出対象外のアプリも含めて確認したい」場合は、端末側で一覧を取得すると確実です。

  • 設定 UI：設定 → アプリ → インストール済みアプリ

コマンドで取得する場合の例です。

# 代表例：インストール済み（従来型）アプリの表示名を取得
Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* |
  Select-Object DisplayName, DisplayVersion, Publisher |
  Where-Object { $_.DisplayName } |
  Sort-Object DisplayName

# 32bit アプリ（WOW6432Node）も併せて見る場合

Get-ItemProperty HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall* |
Select-Object DisplayName, DisplayVersion, Publisher |
Where-Object { $_.DisplayName } |
Sort-Object DisplayName

Intune 配布スクリプトの保存場所（PowerShell / 検出・修復）

Intune から配布された PowerShell スクリプトは、クライアント側の Intune Management Extension（IME） によってダウンロードされ、キャッシュ領域に一時保存されたうえで実行されます。ここで重要なのは、実行後に自動削除／クリーンアップされることが多い点です。つまり「フォルダが空＝配布されていない」とは限りません。

デバイス スクリプト（PowerShell）の一時保存先

一般的に、次のような場所に一時保存されます。

C:\Program Files (x86)\Microsoft Intune Management Extension\Policies\Scripts

実行直後に削除されることがあるため、常にファイルが残っているとは限りません。調査目的で「実体をどうしても確認したい」場合は、IME ログのタイムラインと合わせて、実行前後でフォルダ内容を確認してください。

Staging（キャッシュ）領域について

以前からよく参照されるキャッシュ領域として、次が挙げられます。

C:\Program Files (x86)\Microsoft Intune Management Extension\Content\Staging

ここもキャッシュ／一時領域であり、クリーンアップされることが多いです。「配布しているのに空」という状態は珍しくありません。

検出・修復（Detection & Remediation / プロアクティブ リメディエーション）

検出・修復も IME を介して実行されるため、端末側の挙動は似ています。ただし運用としては、端末側のファイルを追うよりも、まずポータルのレポートで次を押さえるのがおすすめです。

  • どのデバイスで、いつ実行されたか
  • 検出（Detection）結果はどうだったか
  • 修復（Remediation）を実行したか／成功したか

その上で詳細が必要なときに、IME ログへ降りて時系列を確認すると無駄がありません。

複数台の最終再起動時間を Intune 経由で把握する方法

「再起動が必要な端末を一覧で見たい」「いつ再起動されたかをまとめて把握したい」というニーズは多いものの、Intune の標準ビューだけで “最終再起動時刻” を複数台分まとめて一覧表示するのは難しい（または目的の形で出せない）ことが多いのが実情です。

代替案：スクリプト配布で収集し、可視化する

現場で取りやすいのは、PowerShell で最終起動日時を取得し、それを「見える形」にして回収する方法です。代表的な 2 パターンを紹介します。

方法A：検出・修復（プロアクティブ リメディエーション）で収集する

検出スクリプトで最終起動日時と稼働時間を出力し、レポートで各端末の最新値を確認するパターンです。必ずしも“修復”が目的ではなく、情報収集として使うのがポイントです。

# 検出スクリプト例：最終起動と稼働時間を出力（情報収集用途）
$os = Get-CimInstance Win32_OperatingSystem
$boot = $os.LastBootUpTime
$uptime = (Get-Date) - $boot

$result = [pscustomobject]@{
ComputerName   = $env:COMPUTERNAME
LastBootUpTime = $boot
UptimeHours    = [math]::Round($uptime.TotalHours, 1)
}

# 文字列として出力（ポータル側で確認しやすくする）

$result | ConvertTo-Json -Compress

# ここでは常に「検出＝OK」で終了（目的に合わせて設計）

exit 0

この方法のメリットは、Intune の枠内で継続的に回せることです。一方で、出力の見せ方やエクスポートのしやすさは、レポート仕様や運用設計に左右されます。

方法B：デバイス スクリプトでファイルへ書き出す

端末が自分自身の最終起動日時をファイルへ書き出し、調査時に回収しやすくする方法です（例：ProgramData 配下に固定で残す）。

# 例：ローカルに書き出す（端末調査の補助）
$os = Get-CimInstance Win32_OperatingSystem
$boot = $os.LastBootUpTime
$uptime = (Get-Date) - $boot

$out = "{0},{1},{2:N1}" -f $env:COMPUTERNAME,$boot,$uptime.TotalHours
$path = "C:\ProgramData\Company\Inventory\LastBoot.csv"
New-Item -ItemType Directory -Path (Split-Path $path) -Force | Out-Null
$out | Out-File -FilePath $path -Encoding UTF8 -Force

メール送信や共有フォルダへのアップロードなども考えられますが、ネットワーク要件・認証・情報漏えい対策が絡むため、まずテスト環境で検証し、社内ポリシーに沿って設計することを推奨します。

テナント側に登録したスクリプトを棚卸し・バックアップする（Graph API）

Intune 管理センター上では、登録済みのスクリプトを「元ファイルとしてダウンロード」できないケースがあり、引き継ぎや監査で困りがちです。バックアップや棚卸しが必要な場合は、Graph API + PowerShellで一覧取得・エクスポートする方法が検討できます。

Graph API は公式に提供されている手段ですが、取得スクリプト自体は利用者側で作ることが多いので、次を徹底してください。

  • 最小権限（Read 系）で実行する
  • 検証環境で動作確認してから本番へ持ち込む
  • 取得したスクリプト（機密情報の有無）を安全に保管する

以下は概念例です（実環境では権限・エンドポイント・モジュールのバージョンに合わせて調整してください）。

# 概念例：Graph から Intune デバイス スクリプトを列挙し、内容をデコードして保存するイメージ
# ※実行には Graph への接続（Connect-MgGraph 等）と適切な権限が必要です

$listUri = "[https://graph.microsoft.com/beta/deviceManagement/deviceManagementScripts](https://graph.microsoft.com/beta/deviceManagement/deviceManagementScripts)"
$list = Invoke-MgGraphRequest -Method GET -Uri $listUri

foreach ($s in $list.value) {
$detailUri = "[https://graph.microsoft.com/beta/deviceManagement/deviceManagementScripts/$($s.id)](https://graph.microsoft.com/beta/deviceManagement/deviceManagementScripts/$%28$s.id%29)"
$detail = Invoke-MgGraphRequest -Method GET -Uri $detailUri

$bytes = [Convert]::FromBase64String($detail.scriptContent)
$safeName = ($detail.displayName -replace '[\/:*?"<>|]', '_')
[IO.File]::WriteAllBytes("C:\Temp\IntuneScripts$safeName.ps1", $bytes)
}

非公式のコミュニティスクリプトを使う場合は、特にソースコードの精査と検証が欠かせません。実務では「自社のバックアップ手順として最小機能で作る」ほうが、安全に運用しやすいことが多いです。

切り分けを短縮する：現場で使える手順（おすすめ順）

  1. ポータルで最終チェックインと割り当て状況を確認する（古ければ端末側の登録/通信を疑う）
  2. ポータルで失敗しているプロファイル/アプリ/スクリプトを特定する（「何がブロック要因か」を絞る）
  3. 端末側でESP ログ（C:\ProgramData\Microsoft\Windows\ESP\Logs）を確認する
  4. 端末側でIME ログ（C:\ProgramData\Microsoft\IntuneManagementExtension\Logs）を確認する
  5. 必要に応じてイベントビューアーでタイムラインを突き合わせる
  6. 端末に触れない場合は、ポータルのデバイス診断（Collect diagnostics）でログを回収する

この流れに固定すると、「どこから手を付けるか」で迷う時間を削れます。

まとめ

  • ポータル側：トラブルシューティング + サポート（ユーザー起点）とデバイス詳細（デバイス起点）を使い分け、割り当てと適用結果を押さえる。
  • 端末ローカル側：ESP ログ（C:\ProgramData\Microsoft\Windows\ESP\Logs）と IME ログ（C:\ProgramData\Microsoft\IntuneManagementExtension\Logs）をセットで確認すると、Autopilot/アプリ/スクリプトの失敗箇所を特定しやすい。
  • スクリプトの保存場所：IME が一時領域（例：C:\Program Files (x86)\Microsoft Intune Management Extension\Policies\Scripts）に保存して実行し、実行後に消えることがあるため、フォルダが空でも異常とは限らない。
  • 複数台の最終再起動：標準ビューでの一覧化が難しい場合は、スクリプト配布（デバイス スクリプト／検出・修復）で収集し、運用に合う形でレポート化する。
  • スクリプトの棚卸し：テナント側のバックアップが必要なら Graph API を検討し、最小権限・検証・安全な保管を徹底する。
Microsoft 365
IME Intune Microsoft Graph ESP Windows Autopilot プロアクティブリメディエーション

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次