MRM in Exchange Online: la “vecchia” gestione della conservazione che ancora fa il lavoro sporco

Chi amministra Exchange Online da un po’ di tempo avrà notato che Microsoft spinge con insistenza verso le Microsoft Purview retention policies come meccanismo unico per gestire conservazione ed eliminazione dei contenuti su tutto Microsoft 365. È la direzione giusta per la maggior parte degli scenari moderni di compliance, ma c’è un dettaglio che spesso sfugge: il vecchio sistema di Messaging Records Management (MRM), con i suoi tag e policy di retention “classici”, non è stato ritirato. Anzi, Microsoft lo indica ancora esplicitamente come il meccanismo da usare per spostare i messaggi verso le cassette di archiviazione — una funzione che Purview, a oggi, non replica allo stesso modo.

Capire come funziona davvero MRM, al di là dei nomi che si confondono facilmente (tag, policy, azioni), è ancora un prerequisito per diagnosticare problemi di conservazione nelle cassette postali, specialmente in ambienti ibridi o legacy dove le policy sono state configurate anni fa e nessuno le ha mai riviste.

Tre tipi di tag, tre ambiti di applicazione diversi

Il concetto centrale di MRM è il retention tag: un’etichetta che definisce per quanto tempo conservare un elemento e cosa fare quando quel periodo scade. Esistono tre tipi di tag, e la differenza non è solo terminologica: cambia chi può applicarli e a cosa si applicano.

Un dettaglio che genera spesso confusione in fase di supporto: gli utenti non possono modificare DPT o RPT — sono completamente sotto il controllo dell’amministratore. I tag personali, invece, possono essere usati dall’utente per sovrascrivere il comportamento del DPT su singoli elementi: un DPT può eliminare la posta dopo sette anni, mentre un tag personale su una cartella “Newsletter” la elimina dopo tre giorni, e in caso di conflitto vince il tag più specifico (quello applicato direttamente sull’elemento).

Nei client (Outlook e OWA), questi tag non si chiamano “retention tag”: compaiono come Archive Policy se l’azione è “Sposta in archivio”, oppure come Retention Policy se l’azione è di eliminazione. È una delle cause più comuni di ticket di supporto confusi — l’utente vede un nome, l’amministratore in PowerShell ne vede un altro.

Da notare anche che i tag personali sono una funzionalità premium, disponibile solo con una licenza che includa l’Exchange Enterprise CAL (o equivalente nei piani Microsoft 365).

Le azioni di retention: non tutte eliminano davvero

Le quattro azioni possibili meritano una distinzione precisa, perché gli effetti pratici sono molto diversi:

Un punto spesso frainteso: gli elementi nella cartella Recoverable Items (eccetto la sottocartella Deletions) vengono archiviati automaticamente dopo 14 giorni, calcolati sulla data di ultima modifica, a meno che non sia configurato un RPT specifico per quella cartella.

Come funziona davvero il motore di elaborazione: il Managed Folder Assistant

Un errore comune è pensare che le policy di retention si applichino “in tempo reale” quando un messaggio arriva. In realtà il lavoro è svolto da un processo in background sui server Mailbox, il Managed Folder Assistant (MFA), che:

1. Analizza gli elementi di ogni cassetta con una retention policy assegnata, per determinare se sono soggetti a conservazione.
2. Applica il tag corretto agli elementi (stamping).
3. Esegue l’azione di retention su tutti gli elementi che hanno superato l’età limite.

L’MFA è un processo throttle-based: gira continuamente, non segue una pianificazione fissa, ed elabora tutte le cassette di un server in “cicli di lavoro” (work cycle). Ad ogni checkpoint del ciclo, aggiorna l’elenco delle cassette (aggiungendo quelle nuove o spostate) e riprova quelle che avevano fallito l’elaborazione precedente. Per forzare l’elaborazione immediata di una cassetta specifica durante il troubleshooting:

# Forza l'elaborazione immediata di una cassetta
Start-ManagedFolderAssistant -Identity utente@contoso.com

# Verifica lo stato di Recoverable Items
Get-MailboxFolderStatistics -Identity utente@contoso.com `
  -IncludeOldestAndNewestItems -FolderScope RecoverableItems |
  Format-Table Name, OldestItemLastModifiedDate, ItemsInFolder, FolderSize

Un vincolo importante da ricordare in diagnosi: l’MFA non sposta elementi più grandi dei limiti MaxSendSize/MaxReceiveSize configurati sulla cassetta — un messaggio con allegati pesanti può restare “intrappolato” in una cartella anche con una policy di eliminazione attiva, senza che compaia alcun errore evidente.

Precedenza tra i tag: la regola che causa più ticket

Quando un elemento viene spostato in una cartella, eredita il tag di quella cartella; se la cartella di destinazione non ha un tag, si applica il DPT. Ma un tag esplicito applicato direttamente su un elemento ha sempre la precedenza sul tag della cartella e sul DPT, anche se l’elemento viene spostato altrove.

C’è anche una regola meno nota ma rilevante per chi usa cassette di archiviazione: se una cartella nell’archivio ha lo stesso percorso di una cartella nella cassetta primaria, vince il tag della cassetta primaria, e l’MFA resetta periodicamente il tag della cartella archiviata per farlo corrispondere. Esempio concreto: se la cartella primaria “Progetto Contoso” ha un tag “Elimina dopo 3 anni”, e l’utente imposta manualmente la cartella omonima nell’archivio su “Elimina dopo 1 anno”, l’MFA riporterà quest’ultima a 3 anni al ciclo successivo — un comportamento che genera spesso segnalazioni di “il tag non si salva” quando in realtà si sta applicando correttamente la precedenza.

Rimuovere un tag da una policy vs. eliminare un tag: non è la stessa cosa

Questa distinzione è probabilmente la fonte di errori più grave in produzione:

• Rimuovere un tag da una policy lo rende non più disponibile agli utenti, ma gli elementi già taggati continuano a scadere secondo le impostazioni originali del tag.
• Eliminare un tag ne cancella la definizione da Active Directory e da tutte le policy che lo usavano. L’MFA deve quindi ri-elaborare tutti gli elementi nelle cassette coinvolte per ri-assegnare un nuovo tag — un’operazione che può consumare risorse significative sui server Mailbox se applicata su larga scala.

Se l’obiettivo è davvero far cessare l’effetto di un tag su elementi già esistenti, la rimozione dalla policy non basta: serve l’eliminazione del tag stesso, sapendo che questo scatena una ri-elaborazione massiva.

Un’alternativa più leggera per sospendere temporaneamente un comportamento è disabilitare il tag: gli elementi con quel tag non vengono più spostati né eliminati (l’utente vede il periodo come “Mai”), ma il tag resta comunque “applicato” — quindi il DPT non prende il suo posto. È un pattern utile per creare override tipo “non eliminare mai” su cartelle specifiche, ma attenzione: riattivare un tag disabilitato dopo molto tempo può causare eliminazioni o archiviazioni inattese e improvvise su tutto l’arretrato.

Retention Hold: sospendere senza disattivare nulla

Per congelare temporaneamente l’elaborazione MRM su una cassetta — tipicamente durante un’assenza prolungata o un periodo di formazione prima di un roll-out — si usa il Retention Hold, che può includere un commento localizzabile visibile in Outlook per spiegare il motivo della sospensione. Da tenere a mente: il Retention Hold non modifica le quote di spazio della cassetta, quindi per assenze lunghe conviene alzare temporaneamente anche la quota.

Un caveat specifico per gli ambienti hybrid: gli hold configurati in Microsoft 365 scrivono un GUID nell’attributo msExchUserHoldPolicies, che si sincronizza verso Active Directory on-premises. L’MFA on-premises non riesce a leggere i dettagli dell’hold da quel GUID, quindi salta la pulizia delle cartelle DiscoveryHolds — con il rischio, nel tempo, di saturare la quota di Recoverable Items su cassette ibride che sembrano “pulite” ma non lo sono.

Limiti da tenere a mente in fase di progettazione

• Una cassetta può avere solo una retention policy assegnata.
• Una policy può contenere un solo DPT con azione “Sposta in archivio” e un solo DPT con azione di eliminazione (più, opzionalmente, un terzo DPT dedicato alla voicemail con azione di eliminazione).
• Non è possibile collegare più di un RPT per la stessa cartella predefinita all’interno della stessa policy.
• Microsoft raccomanda non più di 10 tag personali per policy, anche se non esiste un limite tecnico rigido.
• Se un DPT di archiviazione e uno di eliminazione coesistono, l’età di archiviazione deve essere inferiore a quella di eliminazione (esempio: archivia dopo 2 anni, elimina dopo 7).
• Una policy priva di tag di retention non è consigliata, perché gli elementi potrebbero non scadere mai.

Perché conviene ancora saperlo, nell’era di Purview

Microsoft Purview è la strada corretta per la governance moderna della conservazione — centralizzata, multi-workload, pensata per compliance trasversale. Ma per chi fa supporto Exchange Online ogni giorno, MRM resta il livello su cui vive l’archiviazione automatica delle cassette, ed è spesso l’unico spiegabile quando un utente chiede “perché questa email è finita in archivio” o “perché non riesco più a recuperare un messaggio eliminato tre settimane fa”. Capire la catena DPT → RPT → tag personale, il ruolo throttle-based del Managed Folder Assistant e la differenza netta tra rimuovere ed eliminare un tag resta un prerequisito pratico, non solo accademico, per il troubleshooting quotidiano.

Fonte: Microsoft Learn, Retention tags and retention policies in Exchange Online; Petri IT Knowledgebase.