Perché il monitoraggio degli endpoint è un processo, non un cruscotto

Gestire una flotta di endpoint significa passare da un modello reattivo (l’utente apre un ticket) a uno proattivo e data-driven: individuare i dispositivi problematici prima che generino chiamate all’help desk. In Microsoft Intune questo si costruisce su tre livelli complementari: i report operativi, Endpoint analytics e le proactive remediations.

I report di Intune

Dall’interfaccia admin (Reports e le viste per-oggetto) trovi i report che fotografano lo stato corrente della flotta. I tre da padroneggiare per l’esame sono:

  • Device status — inventario e stato di gestione: dispositivi enrolled, piattaforma, ultimo check-in, stato di sync con il servizio.
  • Configuration status — esito dell’applicazione dei configuration profiles: quanti dispositivi risultano Succeeded, Error, Conflict o Pending. Lo stato Conflict è diagnostico: due profili impostano la stessa CSP con valori diversi.
  • Compliance status — allineamento alle compliance policies. Il risultato alimenta le Conditional Access policy in Microsoft Entra ID: un device Not compliant può essere bloccato dall’accesso alle risorse.

Questi report rispondono alla domanda “cosa è configurato e conforme adesso”, ma non dicono nulla sull’esperienza percepita dall’utente. Per quello serve Endpoint analytics.

Endpoint analytics

Endpoint analytics produce uno score aggregato (0-100) che misura la qualità dell’esperienza sui Windows client gestiti, confrontandola con un baseline (mediana degli altri tenant o baseline personalizzato). I sottopunteggi principali:

  • Startup performance — tempo di boot e di sign-in, con breakdown su core boot, GPO/policy processing e app all’avvio. Serve a stanare i dispositivi lenti all’accensione.
  • Application reliability — frequenza di crash e hang delle applicazioni, per identificare quali app degradano la produttività su quali modelli hardware.
  • Work-from-anywhere score — prontezza al lavoro moderno: percentuale di device idonei a Windows 11, gestiti in cloud (Intune vs on-prem), con Microsoft Entra join e Windows Autopilot deployment ready.

L’uso corretto per l’esame è prioritizzare gli interventi: confronti lo score reale col baseline, individui il sottopunteggio più basso e agisci lì. Se lo startup performance è sotto baseline, il drill-down ti dice se la colpa è del boot core, dei GPO o di un’app; se il work-from-anywhere è basso, sai su quale asse (hardware, cloud management, OS) investire. Non si “aggiusta lo score” in astratto: si segue la catena score → sottopunteggio → device/insight.

Proactive remediations

Le proactive remediations (oggi anche solo Remediations, sotto Endpoint analytics) sono coppie di script PowerShell: un detection script e un remediation script. Il ciclo è: Intune esegue il detection sui device del gruppo assegnato; se lo script termina con exit code 1 (problema rilevato), scatta il remediation script; exit code 0 significa “sano” e non fa partire la correzione. La schedulazione è configurabile (una tantum, oraria, giornaliera) e i risultati sono visibili con esito per-device.

Sono lo strumento per automatizzare la manutenzione ricorrente: pulizia di cache corrotte, restart di servizi bloccati, riparazione di chiavi di registro, rinnovo di certificati. La logica detect-then-fix evita di applicare modifiche dove non servono.

Il punto architetturale delicato — e la trappola d’esame — è il contesto di esecuzione. Nella configurazione del pacchetto scegli Run this script using the logged-on credentials:

  • No → lo script gira in contesto SYSTEM, con privilegi elevati sulla macchina ma nessun accesso al profilo o alle risorse dell’utente (HKCU, mapped drive, contesto interattivo).
  • Yes → gira nel contesto dello user loggato, con i permessi limitati di quell’utente ma con visibilità sul suo profilo.

Sbagliare contesto è la causa tipica di uno script “corretto” che fallisce: una remediation su HKEY_CURRENT_USER in contesto SYSTEM non trova nulla, e una che scrive in Program Files in contesto user va in access denied.

Trappole tipiche d’esame

  • Uno script di remediation deve modificare una chiave in HKCU o un file nel profilo utente → configura “Run using logged-on credentials = Yes” (contesto user). In SYSTEM non vede il profilo utente.
  • Lo script deve installare software o scrivere in aree protette del sistema → lascia “logged-on credentials = No” (contesto SYSTEM, elevato). Il contesto user non ha i permessi.
  • Le proactive remediations non compaiono / non partono → verifica la licenza idonea (Windows Enterprise E3/E5, Education A3/A5, VDA o Microsoft 365 che include Intune) e che il device sia Intune-managed o co-managed. Senza licenza eleggibile la feature non è disponibile.
  • Un configuration profile risulta in stato Conflict → due profili impostano la stessa CSP con valori diversi. Non è un bug del device: rimuovi la sovrapposizione, non ri-applicare.
  • Serve capire perché gli utenti lamentano avvii lenti → usa lo Startup performance di Endpoint analytics, non il Device status report. I report operativi mostrano config e compliance, non l’esperienza percepita.
  • Obiettivo “modernizzare la flotta / prontezza a Windows 11 e cloud management” → guarda il Work-from-anywhere score e agisci sull’asse col sottopunteggio più basso.