Perché ho deciso di monitorare lo storage di SharePoint Online

Lo storage è uno di quegli aspetti della governance di Microsoft 365 che tendono a restare invisibili finché non diventano un problema. Nessuno controlla lo spazio occupato su SharePoint Online finché non arriva una notifica di quota in esaurimento, o finché non si deve giustificare un costo di storage aggiuntivo che nessuno si aspettava. A quel punto, però, capire cosa sta succedendo e da quando diventa molto più difficile che se lo si fosse osservato per tempo.

Questo articolo racconta il ragionamento dietro a un piccolo strumento che ho costruito per tenere sotto controllo lo storage di SharePoint su base settimanale, e soprattutto due cose che mi interessa condividere: perché ho scelto di trattare separatamente lo storage “normale” da quello del file-level archive, e perché ho deciso di costruirmi uno storico persistente pensando già a un uso futuro con Power BI.

Perché monitorare lo storage è importante, non solo “utile”

Su un tenant enterprise, lo storage di SharePoint non cresce mai in modo lineare o prevedibile: dipende da centinaia (o migliaia) di team che caricano file in autonomia, ognuno con le proprie abitudini. Senza un monitoraggio continuo, l’unico segnale che si riceve è reattivo: una quota che si avvicina al limite, un ticket, un’email di allerta di Microsoft. A quel punto la domanda “perché siamo arrivati qui?” non ha quasi mai una risposta immediata, perché nessuno ha tenuto traccia della crescita nel tempo.

Avere invece un trend settimanale di quanto stiamo usando, quanto stiamo crescendo, con che ritmo, permette di passare da un approccio reattivo a uno predittivo (forecast): si può stimare quando si raggiungerà una certa soglia, decidere per tempo se serve acquistare storage aggiuntivo, individuare picchi di crescita anomali legati magari a un singolo sito o progetto, e portare in un colloquio di budget dei numeri concreti invece di una sensazione.

Il file-level archive: un problema di controllo, non solo di spazio

C’è un aspetto del monitoraggio storage che secondo me merita un’attenzione particolare, ed è il motivo per cui ho tenuto separato il file-level archive (introdotto con Syntex) dal resto: a differenza dell’archiviazione a livello di sito, qui non è l’amministratore a decidere cosa archiviare.

L’archiviazione di un intero sito è un’azione amministrativa: qualcuno, deliberatamente, decide che quel sito non è più attivo e lo sposta in archivio. Il file-level archive funziona in modo diverso: oggi è l’utente stesso, con permessi di modifica sulla libreria, a poter selezionare uno o più file e archiviarli (o riattivarli) in autonomia, senza che sia l’amministratore a deciderlo o a doverlo autorizzare caso per caso — e questo può succedere anche a singoli file dentro un sito perfettamente attivo, per decisioni prese a valle da chi usa quella libreria, non da chi amministra il tenant. Microsoft ha già annunciato che entro fine 2026 arriverà anche l’automazione basata su policy (ad esempio archiviare i file non acceduti da un certo numero di giorni), ma al momento il meccanismo che sposta davvero lo storage è nelle mani di chi lavora quotidianamente su quei file, non in una regola centralizzata che l’admin può leggere o prevedere.

Il risultato è che lo storage “si muove” senza che l’amministratore abbia una visione diretta di cosa sta venendo archiviato e dove. Non è un problema di spazio (anzi, l’archiviazione dovrebbe liberarne), è un problema di perdita di controllo e di visibilità: se non lo si monitora esplicitamente, si perde la percezione di quanto contenuto sta effettivamente “vivendo” in stato archiviato all’interno dei siti attivi, con implicazioni anche su tempi di accesso, esperienza utente e, in alcuni casi, conformità. Per questo lo tratto come una metrica a sé: non voglio che finisca mescolata e nascosta dentro il numero aggregato dello storage attivo, voglio poterla guardare separatamente e capire se sta crescendo in modo silenzioso.

Il legame con le policy di inattività di SharePoint Advanced Management

C’è anche un secondo motivo, più operativo, per cui tengo questo monitoraggio attivo: lo sto affiancando alle policy di inattività dei siti disponibili in SharePoint Advanced Management, quelle che identificano ed eventualmente archiviano automaticamente i siti che non vengono più utilizzati. Anche in quel caso la logica è la stessa del file-level archive: è una policy, non un amministratore, a decidere quando un sito diventa “inattivo” e viene spostato in archivio.

Avere uno storico storage mi permette di leggere l’effetto reale di queste policy nel tempo: quanti siti stanno effettivamente venendo archiviati settimana dopo settimana, quanto spazio si sta “recuperando” di conseguenza dallo storage attivo, e se il ritmo di archiviazione è coerente con quello che mi aspetto dalla configurazione della policy. Senza un trend storico, anche l’efficacia di queste automazioni resterebbe un numero che si può solo controllare in un istante, non un lavoro di cui si può verificare l’andamento.

Uno storico pensato per durare, non solo per l’email di oggi

Il report settimanale via email è comodo per una lettura veloce, ma un’email non è un buon posto dove far vivere uno storico: non è interrogabile, non si presta ad analisi, e se in futuro voglio incrociare questi dati con altri (crescita per reparto, correlazione con progetti, confronto tra tenant diversi) partire da una casella di posta è la scelta peggiore possibile.

Per questo, oltre a inviare il report, ogni esecuzione registra automaticamente una riga di storico — data, storage attivo, storage archiviato, totale, percentuale quota — in una lista SharePoint dedicata, popolata via PnP PowerShell. È una scelta volutamente semplice: nessun database esterno da gestire, nessuna infrastruttura aggiuntiva, solo una lista che si accumula in modo affidabile settimana dopo settimana, dentro l’ambiente che sto già monitorando.

Il motivo per cui questa scelta mi interessa particolarmente è quello che ci si può costruire sopra: una lista SharePoint è una fonte dati nativamente collegabile a Power BI, che è esattamente la direzione in cui voglio andare. L’idea è passare da un report email “statico” a dashboard interattive e aggiornate automaticamente ogni settimana, dove poter tagliare i dati per periodo, confrontare trend su archi temporali più lunghi delle 8 settimane che mostro nell’email, e magari incrociare lo storage con altre metriche di governance che sto già raccogliendo con altri strumenti. È un’area su cui sto lavorando attivamente, e probabilmente sarà oggetto di un prossimo articolo quando avrò qualcosa di più concreto da mostrare.

Un accenno più tecnico: API, autenticazione e flusso

Per chi è curioso di capire come è fatto concretamente lo strumento, senza entrare nel codice: l’autenticazione è interamente app-only tramite certificato, sia verso SharePoint Online Management Shell sia verso Microsoft Graph, così da non dipendere da un account di servizio con password da ruotare o MFA da gestire. Su questo fronte, una nota “da addetto ai lavori”: Microsoft ha introdotto relativamente di recente il supporto all’autenticazione con certificato anche per lo scenario che uso io su SPO Management Shell, e ho colto l’occasione per testarlo direttamente sul campo con questo script, oltre che per il monitoraggio in sé.

Le fonti dati che lo script interroga sono tre, e riflettono esattamente il ragionamento “pre-aggregato dove possibile” di cui parlavo sopra:

• la quota totale del tenant, letta direttamente dal servizio di amministrazione SharePoint;
• lo storage attivo aggregato di tutti i siti, ottenuto tramite l’endpoint di reportistica di Microsoft Graph dedicato all’utilizzo storage di SharePoint — un dato già calcolato da Microsoft, aggiornato quotidianamente, che evito quindi di ricalcolare da zero;
• lo storage archiviato, ottenuto interrogando solo il sottoinsieme di siti effettivamente in stato di archivio (un numero contenuto rispetto al totale, quindi rapido da recuperare anche su tenant grandi).

Il flusso, in breve: lo script si autentica, recupera questi tre valori, calcola i delta rispetto all’esecuzione precedente leggendo lo storico, costruisce il report HTML con i KPI e i grafici del trend, lo invia via email tramite Microsoft Graph, e in parallelo scrive la riga di storico sia su file locale che sulla lista SharePoint di cui parlavo prima. Tutto in un’unica esecuzione pianificata, senza intervento manuale.

In sintesi

Il filo conduttore di questo lavoro è che lo storage di SharePoint non va guardato come un numero statico da controllare quando serve, ma come un dato che racconta una storia se lo si osserva nel tempo - e che ha almeno due dimensioni distinte da tenere d’occhio separatamente: quanto stiamo usando in modo “visibile” e deliberato, e quanto si sta muovendo in automatico per decisioni prese dagli utenti stessi attraverso il file-level archive. Costruire uno storico persistente fin da subito, anche in modo semplice come una lista SharePoint, è quello che permette di trasformare questo monitoraggio da un report da leggere ogni lunedì a una base dati su cui costruire qualcosa di più, quando sarà il momento.

---

Hai un caso d’uso simile o vuoi confrontarti sull’approccio? Trovi i miei contatti nel blog.