Una domanda per strumento

Nell’area di monitoraggio e troubleshooting l’esame MS-700 torna quasi sempre sulla stessa biforcazione: davanti hai un caso o un pattern? Se lo scenario nomina una persona e un momento preciso (“un utente segnala audio robotico nella riunione di ieri pomeriggio”), la risposta è call analytics. Se lo scenario nomina un insieme — una sede, una subnet, un modello di headset, un andamento “nelle ultime settimane” — la risposta è Call Quality Dashboard (CQD). Nessuno dei due sostituisce l’altro: le call analytics non hanno la vista d’insieme, il CQD non ti dice cosa è successo a quel singolo utente. Riconoscere la parola-spia nel testo della domanda vale più che ricordare ogni metrica.

Call analytics: il singolo caso, dall’inizio alla fine

Le call analytics vivono nel Microsoft Teams admin center, sotto il singolo utente: si parte da chi ha aperto il ticket e si scende alla sessione. Per ogni chiamata o riunione trovi il dispositivo usato (microfono, altoparlante, driver), il tipo di connessione (Wi-Fi o cablata, presenza di VPN, subnet e gateway), il percorso seguito dal media e le metriche per stream — packet loss, jitter, round-trip time, degradazione della qualità audio. Il sistema evidenzia le sessioni classificate come poor e in quale segmento sta il degrado: sul primo hop Wi-Fi, sulla rete aziendale, oltre il perimetro. Le call analytics espongono anche la telemetria di una riunione ancora in corso, utile quando il problema è vivo mentre il ticket è aperto.

Rilevante per l’esame è il modello di delega. Un help desk non ha bisogno del ruolo Teams Administrator per fare questo lavoro: esistono Teams Communications Support Specialist, che vede un livello di dettaglio ridotto e con informazioni utente limitate, e Teams Communications Support Engineer, che accede al dettaglio completo. Assegnare il ruolo amministrativo pieno “così vede le chiamate” è la scelta sbagliata in qualunque scenario che citi il least privilege.

Call Quality Dashboard: il pattern che il ticket non mostra

Il CQD aggrega le chiamate dell’intero tenant e serve a rispondere a domande di popolazione: quale percentuale di stream è di qualità scarsa, dove si concentra, se il numero peggiora o migliora dopo un intervento. I report si filtrano per periodo, subnet, edificio, tipo di client, versione, dispositivo, e si distingue fra scenari cablati e wireless, interni ed esterni alla rete aziendale. È lo strumento con cui si costruisce un caso: “il 30% degli stream scarsi arriva da una sola sede”, oppure “un modello di dispositivo genera anomalie ovunque”.

Il rovescio della medaglia è che il dato è aggregato e non istantaneo. Il CQD non è il posto dove verificare cosa è appena successo a una persona: serve volume per mostrare una tendenza, e l’identità del singolo non è il suo oggetto.

Building file e network readiness

Un CQD senza building data (il caricamento del file che mappa le subnet dell’organizzazione) mostra indirizzi di rete, non luoghi. È leggibile solo da chi conosce a memoria il piano di indirizzamento, e i report che ragionano per sede restano vuoti. Il file associa ogni range a un edificio, a una città e a un paese, e marca se la subnet è interna alla rete aziendale o raggiunta via VPN: da lì nascono i report per location e la distinzione fra traffico interno ed esterno.

La network readiness è la fase che precede tutto: prima del rollout non esiste traffico da analizzare, quindi né CQD né call analytics servono. Lì si dimensiona la banda con gli strumenti di pianificazione, si testano i percorsi verso Microsoft, si verifica che il media UDP esca localmente invece di attraversare proxy o VPN full tunnel. Il CQD arriva dopo, come misura del risultato.

Trappole tipiche d’esame

  • Un utente segnala pessima qualità in una riunione specifica → call analytics: il CQD non risponde a un ticket individuale; cerca l’utente e apri la sessione.
  • Sospetto che una sede intera degradi → CQD con building data caricato: aprire una a una le call analytics di dieci utenti non dimostra un pattern e non è la risposta attesa.
  • Riunione critica in corso con problemi ora → telemetria in tempo reale nelle call analytics: il CQD non è progettato per l’evento appena avvenuto.
  • Report CQD illeggibili, solo subnet e nessun nome di sede → caricare il building file: non è un problema di licenza né di permessi, è dato di tenant mancante.
  • Help desk deve vedere le chiamate degli utenti → Teams Communications Support Specialist o Engineer: scegli il ruolo in base al dettaglio necessario, non Teams Administrator.
  • Valutare la rete prima del deployment di Teams → strumenti di network planning e assessment: CQD e call analytics richiedono traffico già esistente e non dicono nulla su una sede non ancora attiva.