Microsoft Intune Management Extension logs: guida pratica al troubleshooting
Introduzione
Quando una Win32 app non si installa, uno script PowerShell non viene eseguito o una remediation restituisce un risultato poco chiaro, uno dei primi posti in cui conviene guardare è la cartella dei log della Microsoft Intune Management Extension. Il portale fornisce una vista utile sullo stato del deployment e sui dettagli di troubleshooting, ma quando serve capire con precisione che cosa è successo sul client, il passaggio dai log locali è quasi sempre inevitabile. Su questo argomento si trovano ancora guide utili, ma non tutte sono aggiornate. In alcuni casi l’elenco dei log è incompleto; in altri viene fatta confusione tra sync MDM, check-in dell’IME e flusso delle Win32 app, che sono aspetti distinti e vanno letti nel modo corretto quando si fa troubleshooting.
In questo articolo vediamo quindi dove si trovano i log dell’IME, quali conviene conoscere davvero e come usarli in modo pratico per capire più in fretta che cosa sta succedendo sul device.
Che cos’è l’Intune Management Extension
L’Intune Management Extension, o più semplicemente IME, è l’agente che estende la gestione MDM standard di Windows e permette a Intune di gestire sul client una serie di funzionalità che non vengono coperte dal solo stack MDM nativo. Rientrano qui, ad esempio, gli script PowerShell, le app Win32, le app Microsoft Store, la custom compliance e le Remediations. A questi si aggiungono anche altri scenari che usano l’IME come componente operativa lato client, come Endpoint Analytics, Remote Help, Managed Installer e l’aggiornamento del BIOS tramite policy MDM.
L’installazione dell’IME avviene automaticamente quando vengono soddisfatti i prerequisiti e al dispositivo o all’utente viene assegnato uno di questi workload. Per questo, se stai lavorando con Win32 app, script o Remediations, l’IME entra molto spesso in gioco. Ed è anche il motivo per cui i suoi log diventano centrali non appena il comportamento del client non coincide con quello che vedi nel portale.
C’è poi una distinzione che conviene tenere molto chiara. L’IME ha un proprio ciclo di controllo per installazioni nuove o aggiornate ogni 8 ore, separato dal normale check-in MDM. Inoltre, da Company Portal > Settings > Sync puoi avviare sia il check-in MDM sia quello dell’IME. Se invece lanci la sincronizzazione dalle Impostazioni di Windows o dall’admin center, avvii il check-in MDM ma non forzi quello dell’IME. Quando fai troubleshooting, questa differenza conta.
Dove si trovano i log dell’Intune Management Extension
Sul client Windows, il percorso da cui partire è C:\ProgramData\Microsoft\IntuneManagementExtension\Logs ed è qui che troviamo i log della Intune Management Extension. Quando stiamo analizzando un problema lato client, questa è una delle prime cartelle da aprire, perché dentro ci sono i file che ci aiutano a capire che cosa ha fatto l’agente sul dispositivo. Per leggerli è possibile usare un editor di testo qualsiasi, ma suggerisco il tool CMTrace, che a mio avviso resta la scelta più comoda. I timestamp si leggono meglio, warning ed errori saltano fuori subito e, soprattutto, si riesce a seguire con più facilità la sequenza degli eventi quando devi ricostruire un’installazione, una detection o l’esecuzione di uno script.
Quando non si ha accesso diretto al pc, dal portale Intune è possibile usare la remote device action Collect diagnostics per raccogliere i log del dispositivo da remoto. L’azione si avvia dalla pagina del device e consente di acquisire i diagnostici senza interrompere l’utente. I pacchetti raccolti restano disponibili per 28 giorni, ogni dispositivo può conservarne fino a 10 e, in modalità bulk, l’azione supporta fino a 25 dispositivi Windows per esecuzione. La raccolta diagnostica entra in gioco anche con Windows Autopilot. In caso di errore durante il deployment, i log possono essere raccolti automaticamente sul dispositivo che ha avuto il failure e caricati poi in Intune. È una possibilità utile soprattutto nelle fasi iniziali, quando il client non è ancora facilmente raggiungibile o il problema si presenta prima di avere accesso operativo completo alla macchina. In questo scenario, il dispositivo può caricare automaticamente un set di log al giorno.
Quali log aprire in base al problema
Chiaramente non serve ricordarsi a memoria tutti i file della cartella IME, quello che serve è sapere da quale log partire in base a quello che stai analizzando. Alcuni sono trasversali e conviene aprirli quasi sempre, altri hanno senso solo in scenari più specifici, ad esempio Win32 app, script PowerShell, remediations, certificati o raccolta dati lato client. Oggi i log principali della Intune Management Extension sono i seguenti riportati in tabella:
| Log file | Quando aprirlo | Che cosa ci trovi |
|---|---|---|
IntuneManagementExtension.log | È il primo file da controllare quasi sempre. | È il log principale dell’agente: check-in, richieste di policy, elaborazione delle policy e reporting. È quello che ti aiuta a capire se il client ha parlato con Intune, se ha ricevuto qualcosa e dove il flusso si è fermato. |
AppWorkload.log | Quando il problema riguarda una Win32 app. | È il log più utile per leggere il lato applicativo: check-in delle app, installazioni, applicabilità e detection. Se dal portale vedi solo un errore generico, qui di solito trovi molto più contesto. |
AppActionProcessor.log | Quando vuoi capire perché un’app risulta non applicabile o non rilevata correttamente. | Tiene traccia delle azioni di detection e dei controlli di applicabilità delle app assegnate. È il log giusto quando il problema sembra stare nella logica di detection o nei requirement rules. |
AgentExecutor.log | Quando stai analizzando script PowerShell distribuiti da Intune. | Qui trovi i dettagli di esecuzione degli script. Ti aiuta a capire se lo script è partito davvero, in quale contesto è girato e se il problema è nello script stesso o prima ancora nella sua esecuzione. |
HealthScripts.log | Quando il problema riguarda remediations o workload che usano remediation scripts. | È il log di riferimento per le remediations. Qui finiscono anche altri workload che usano lo stesso meccanismo, come custom compliance scripts, managed installer, hardware configuration e proactive remediations on-demand. |
ClientHealth.log | Quando sospetti un problema più strutturale sull’IME. | Serve a controllare lo stato di salute dell’estensione di gestione Intune. Non è sempre il primo file da aprire, ma è utile quando il problema non sembra limitato a una singola app o a un singolo script. |
ClientCertCheck.log | Quando il comportamento del client fa pensare a problemi di certificati. | Tiene traccia dei controlli sui certificati client del dispositivo. Ha senso guardarlo quando il problema sembra legato all’identità del device o alla parte di certificazione. |
DeviceHealthMonitoring.log | Quando stai indagando un problema più ampio del semplice deployment di un’app. | Raccoglie informazioni legate a idoneità hardware, inventory del dispositivo e altri data collector. È utile quando il comportamento anomalo è più trasversale e non limitato a un singolo workload. |
NotificationInfra.log | Quando vuoi verificare il comportamento del canale di notifica in tempo reale. | Tiene traccia delle notifiche inviate attraverso il canale di comunicazione Microsoft in tempo reale. È uno di quei file che non sempre vengono citati, ma oggi fa parte del set base dei log IME. |
Sensor.log | Quando stai guardando la parte di Endpoint Analytics. | È il log collegato al data collector usato per Endpoint Analytics, con informazioni su prestazioni di avvio, affidabilità delle app e altri indicatori dell’esperienza del dispositivo. |
Win32AppInventory.log | Quando serve verificare la parte di inventory applicativa. | Tiene traccia dell’integrità del collector usato per l’inventario delle app. Conviene aprirlo quando vuoi capire se il client sta rilevando correttamente il software presente. |
Come avviare manualmente un check-in IME
Quando si sta facendo troubleshooting o si vuole verificare subito l’effetto di una modifica, aspettare il ciclo normale dell’agente non è sempre la scelta migliore. Se l’IME è già installato sul dispositivo, il modo più semplice per avviare un check-in manuale è aprire il Company Portal, andare in Settings > Sync e lanciare la sincronizzazione. In questo modo si avviano sia il check-in MDM sia quello della Intune Management Extension.
Un’alternativa, soprattutto se si è già collegati al client, è riavviare il servizio IntuneManagementExtension da Gestione attività. Il servizio viene riavviato immediatamente e avvia un nuovo check-in con Intune. È il metodo più utile quando si vuole vedere rapidamente come si aggiornano i log dopo una modifica, una nuova assegnazione o un test.
Qui conviene però tenere chiara una distinzione: non tutte le sincronizzazioni hanno lo stesso effetto. Il tasto Sync nelle Impostazioni di Windows e l’azione di sincronizzazione lanciata dall’admin center avviano il check-in MDM, ma non forzano quello dell’IME. Se si sta lavorando su script PowerShell, Win32 app o altri workload che dipendono dall’estensione, questa differenza va tenuta presente.
Conclusioni
Quando serve capire con precisione che cosa ha fatto il client, prima o poi si finisce nei log della Intune Management Extension. Il portale aiuta, ma il dettaglio operativo passa da lì. Per ricapitolare brevemente: per una Win32 app, AppWorkload.log è uno dei file più utili da aprire. Per uno script PowerShell, il riferimento diretto è AgentExecutor.log. Per una Remediation, il log da cui partire è HealthScripts.log. Sopra tutti resta IntuneManagementExtension.log, perché è quello che offre la vista più completa del comportamento dell’agente.
