MS-700 · Report e alert

Cosa misurano i report di utilizzo e dove stanno

Il Teams admin center raccoglie sotto la sezione Analytics & reports una famiglia di report di utilizzo pensati per rispondere a domande di adozione e di capacità, non di sicurezza. I principali che un Teams administrator deve saper collocare sono: Teams usage report (team attivi, utenti attivi per team, messaggi in canale, messaggi in chat, riunioni organizzate), Teams user activity report (attività per singolo utente: messaggi, riunioni a cui ha partecipato o che ha organizzato, chiamate 1:1), Teams device usage report (da quali piattaforme si connettono gli utenti: Windows, macOS, mobile, web), Teams app usage report (quali app — Microsoft, di terze parti o line-of-business — vengono effettivamente usate e da quanti utenti) e i report per singola riunione (per-meeting e meeting attendance), utili quando serve capire la qualità percepita o la partecipazione di un evento specifico.

Un dettaglio che l’esame ama: nel Microsoft 365 admin center esistono report di utilizzo paralleli, tra cui quelli relativi allo storage di SharePoint e OneDrive, che è dove risiedono davvero i file di canale e i file condivisi in chat. Quindi la domanda “quanto spazio consumano i contenuti dei team” si risponde con i report di SharePoint, non con il Teams usage report. Attenzione anche alla privacy: se nel Microsoft 365 admin center è attiva l’opzione che nasconde le informazioni identificabili dell’utente, nomi utente e nomi di team compaiono anonimizzati in tutti i report — è la spiegazione tipica dello scenario “vedo GUID al posto dei nomi”.

Dove finiscono le domande sui guest e sui team creati o eliminati

I report di utilizzo dicono quanto si usa Teams, non chi ha fatto cosa. Il monitoraggio del guest access — chi ha invitato un guest, in quale team, quando è stato rimosso — è un’informazione di audit, non di utilizzo, e si recupera dalla ricerca nei log di audit del portale Microsoft Purview. Lo stesso vale per la creazione e l’eliminazione di team in un intervallo di tempo, per i cambi di ruolo owner/member, per l’aggiunta di app e per le operazioni sui canali. Ricorda che un team è supportato da un gruppo Microsoft 365: alcuni eventi sono registrati come attività di gruppo e non con l’etichetta “team”, ed è normale doverli cercare per attività di gruppo.

Va tenuta separata anche la governance dall’osservazione: se l’obiettivo è impedire o revisionare periodicamente la presenza dei guest, lo strumento non è un report ma le access review di Microsoft Entra ID con le relative licenze, o la scadenza dei gruppi. Il report serve a fotografare, non a correggere.

Le alert rule delle notifiche

Sotto le notifiche e gli alert del Teams admin center si configurano regole che avvisano in modo proattivo quando si verifica una condizione, senza dover controllare a mano un cruscotto. I due casi che compaiono con maggiore frequenza negli scenari d’esame sono il Teams device health — un telefono Teams, un Teams Room o un pannello risulta offline o non raggiungibile — e lo stato dei resource account collegati alle app vocali: se il resource account che alimenta un auto attendant o una call queue perde la licenza necessaria oppure il service number assegnato, l’alert segnala il problema prima che i chiamanti trovino la linea muta.

Ogni regola ha uno stato attivo/disattivo, una severità e la scelta del canale su cui recapitare la notifica, tipicamente un post in un canale di Teams via connettore. Il criterio di scelta è semplice: se il requisito parla di essere avvisati quando accade qualcosa, si tratta di un’alert rule; se parla di capire quanto o quanti, è un report di utilizzo; se parla di chi ha fatto una certa azione, è audit in Purview; se parla di perché la chiamata era disturbata, è call analytics per il singolo caso o Call Quality Dashboard per la tendenza aggregata.

Trappole tipiche d’esame

Sapere quanti team sono stati creati o eliminati nell’ultimo trimestre → audit log in Microsoft Purview: i report di utilizzo mostrano i team attivi nel periodo, non gli eventi di creazione o cancellazione. Chi cerca la risposta nel Teams usage report sbaglia console.
Identificare chi ha invitato uno specifico guest in un team → ricerca di audit in Microsoft Purview: il Teams admin center elenca i guest come membri, ma non conserva la traccia dell’autore dell’invito né la data. Il report di utilizzo non ha questa dimensione.
Essere avvisati quando un Teams phone resta offline → alert rule nelle notifiche del Teams admin center: non è un report da schedulare né un avviso di Entra; è una regola nativa sullo stato dei dispositivi, da abbinare a un canale di destinazione per la notifica.
Un auto attendant smette di rispondere dopo un cambio di licenze → alert rule sui resource account: la causa tipica è il resource account rimasto senza licenza o senza service number. L’alert la intercetta prima delle segnalazioni degli utenti; call analytics non serve, perché non è un problema di qualità audio.
Capire quali app di terze parti vale la pena bloccare o promuovere → Teams app usage report: l’app setup policy dice cosa è permesso, non cosa viene usato. La decisione si prende sul dato di utilizzo, poi si applica con le policy.
Un utente lamenta audio disturbato in una riunione di ieri → call analytics per quell’utente, non i report di utilizzo: i report di utilizzo contano riunioni e partecipanti; per il dettaglio per singola chiamata serve call analytics, mentre le tendenze di rete su larga scala stanno nella Call Quality Dashboard.
I nomi di utenti e team appaiono mascherati nei report → impostazione di privacy nel Microsoft 365 admin center: non è un bug né un problema di permessi del ruolo Teams administrator; è l’opzione che anonimizza le informazioni identificabili nei report di utilizzo.