Esborrar per damunt de la retenció: tres signatures a Exchange, una a SharePoint

Hi ha una frase a la documentació de Priority Cleanup que no es llegeix gairebé enlloc més de l'ecosistema Microsoft 365: «items are permanently deleted and cannot be restored by users, by admins, or by Microsoft». Ni l'usuari, ni l'administrador, ni Microsoft. La funció és en vista prèvia per a SharePoint i OneDrive des de mitjan agost i el desplegament general arrenca a finals d'aquest mes.

El que fa especial aquesta frase és el contrast amb tota la resta. A Microsoft 365 gairebé qualsevol esborrat té una finestra de retorn: papereres de dues fases, elements recuperables, biblioteques de conservació. Nosaltres mateixos hem escrit aquí sobre la carpeta d'elements recuperables d'Exchange i la seva finestra per defecte, que és exactament el lloc d'on surten la majoria dels correus que algú creia perduts. Priority Cleanup és la primera peça del producte dissenyada perquè aquesta finestra no existeixi.

Administrem tenants de Microsoft 365 de clients i ens toca respondre de què es pot recuperar i de què no. Així que hem llegit les dues pàgines de Microsoft Learn amb calma, la de bústies i la de fitxers, i el que ens ha cridat l'atenció no és la funció. És que no està governada igual als dos llocs.

Per a què la va fer Microsoft (i no és el que sembla)

A bústies, els exemples que dona Microsoft són els que un esperaria: una petició de privacitat sobre algú que ja no és a l'empresa, o un vessament de dades —el correu amb la informació d'una adquisició futura enviat a qui no tocava— que cal esborrar encara que hi hagi holds d'eDiscovery oberts.

A fitxers, no. El títol literal de la pàgina de SharePoint i OneDrive és «Override holds to clean up files for Copilot and reclaim storage». Saltar-se els holds per netejar el que veu Copilot i recuperar emmagatzematge. I els dos casos d'ús que enumera són igual de prosaics: enregistraments i transcripcions de reunions de Teams caducades —«typically large and have little business value after 1-3 months», diu Microsoft— i l'OneDrive d'algú que ha marxat i que no es pot esborrar perquè queden fitxers a la Preservation Hold library amb la retenció sense vèncer.

El problema que resol és real, i convé dir-ho abans de criticar res. La retenció de Microsoft 365 no tenia un «això sí, i ja»: o esperaves que vencés el període més llarg, o aixecaves el hold amb tot el que això arrossega. Priority Cleanup és aquest botó. La nostra objecció no és que existeixi. És a qui se li lliura i amb quantes signatures.

Tres signatures a Exchange, una a SharePoint

És el mateix botó i el mateix motor —per dins són etiquetes de retenció amb auto-aplicació—, però el règim d'aprovació canvia segons on visqui la dada. Aquesta és la comparació, muntada amb la taula que publiquen les dues pàgines i amb el text dels seus apartats d'aprovadors:

La línia que ens sembla la més important de la taula és la tercera, i ve textual de la documentació de fitxers: «Separate approval from a retention admin isn't required to override retention settings». A la meitat del tenant on viu la major part dels documents d'una empresa, saltar-se una política de retenció no necessita la signatura de qui la va posar.

És defensable, per cert, i no ho volem vendre com un descuit. El cas d'ús de fitxers és llençar enregistraments de Teams del mes passat, i muntar tres aprovacions per a això, en una política que Microsoft descriu com a contínua, seria inviable. El nostre criteri és un altre: el control ha deixat de ser tècnic i ara és una llista de noms, i aquesta llista cal mirar-la avui, no el dia que algú la faci servir.

Qui té el rol sense haver-lo demanat

El rol que cal es diu Priority Cleanup Admin, i la documentació diu com es reparteix: «This role is automatically added to the Organization Management role group but must be manually added to any other role group». Traduït: si no has tocat res, ja el té qui sigui a Organization Management. En un tenant d'una pime això sol ser l'equip de sistemes sencer, més algun consultor que va entrar un dimarts de fa dos anys.

I hi ha un detall de la regla de dues persones que mereix llegir-se a poc a poc. A la pàgina de bústies, sobre el primer aprovador: «This should be a different person to the user who created the priority cleanup policy, but isn't enforced». Hauria de ser una altra persona, però el producte no ho imposa. A fitxers sí que s'imposa, i d'una manera més elegant: «The last person to edit the policy can't also turn it on». Dos criteris diferents per al mateix principi, dins del mateix producte i de la mateixa pantalla de configuració.

Dit això, i per no deixar la impressió equivocada: a Exchange calen tres rols diferents —priority cleanup admin, retention manager i eDiscovery admin—, així que si al darrere hi ha tres persones de debò, el control és força més fort que a fitxers encara que la regla de dues persones no estigui forçada. El risc no és simètric i per això no serveix una sola resposta per als dos costats.

El que sí que ho atura

L'interruptor es decideix abans, no després

La funció es pot apagar a nivell d'inquilí, a Purview > Data Lifecycle Management > Priority cleanup settings, i l'interruptor és únic: apaga bústies i fitxers alhora. La mateixa Microsoft ho suggereix per a un perfil concret d'organització, i la frase val la pena sencera: «highly regulated organizations that use Preservation Lock might want the additional safeguard of turning off priority cleanup at the tenant level».

Ara la part que cal llegir dues vegades. Si apagues el control amb polítiques ja creades, la documentació és explícita: «Existing priority cleanup policies continue to function». Es poden esborrar, sí, però no es poden modificar i continuen funcionant. I encara hi ha una volta més: «Although you can delete a priority cleanup policy, if the approval process for it is complete, items might still be permanently deleted». Esborrar la política després que les signatures estiguin posades no atura necessàriament l'esborrat.

És un interruptor d'abans. Igual que l'auditoria, que segons Microsoft ha d'estar activa almenys un dia abans de crear i executar la primera política, i que a més cal per veure els resultats de la simulació. La documentació no diu què passa si no ho està: nosaltres no encendríem res sense comprovar-ho abans.

I quan vagis a buscar aquell rastre, els esdeveniments no surten al desplegable del portal —«these events don't have friendly names to select from the Microsoft Purview portal»—, així que cal escriure'ls a mà:

PriorityCleanupTagApplied     # l'element entra al circuit
PriorityCleanupDelete         # esborrat d'un element de bústia
PriorityCleanupFileRecycled   # esborrat d'un fitxer de SharePoint o OneDrive

On no ens quadren les fonts

Preferim dir-ho a tapar-ho. La pàgina de Microsoft Learn afirma que «the feature itself is enabled by default at the tenant level». L'avís del centre de missatges MC1261587 —publicat el 25 de març de 2026 i actualitzat el 19 d'agost— diu el contrari: que la capacitat «is not enabled by default and requires explicit admin configuration».

La nostra lectura, i és lectura i no dada: les dues frases se sostenen alhora si «enabled» es refereix a l'interruptor i «not enabled by default» a l'efecte. El control ve posat, però no s'esborra res fins que algú crea una política, l'encén i un altre signa. El mateix avís ho diu: «There is no change to user workflows unless an admin configures and applies a priority cleanup policy». Si la teva lectura és una altra, la comprovació són trenta segons al portal del teu inquilí, i aquesta val més que la nostra.

Hi ha un segon buit, i també el deixem obert. L'avís del centre de missatges anuncia per a fitxers una opció de «Delete data permanently» el resultat de la qual és que el contingut deixa de ser localitzable a la cerca de SharePoint, a Copilot i a eDiscovery. La pàgina de Learn que hem llegit descriu el camí amb paperera de segona fase. No hem trobat a Learn la descripció d'aquesta opció nova, així que no afirmem com es comporta. Ho mirarem quan la documentació es posi al dia.

I la teva còpia, et salva d'això?

És la quarta vegada aquest estiu que aquest blog acaba al mateix lloc, i ho diem en veu alta abans de repetir-ho: una política de retenció no és una còpia de seguretat, la còpia que ofereix Microsoft no surt mai de Microsoft i arxivar tampoc no és copiar. Priority Cleanup afegeix un cas que cap d'aquelles dues peces cobria: un esborrat legítim, aprovat i auditat, fet des de dins per gent amb permís. No és ransomware ni és un error de plataforma. És un procediment correcte executat amb la consulta KeyQL mal escrita, o amb l'abast més ample del compte.

Una còpia fora de l'inquilí et retorna el fitxer només si es compleixen dues condicions. Que estigués copiat abans de l'esborrat, que és òbvia. I que la retenció de la teva còpia no purgui el que desapareix de l'origen, que no ho és gens. Hi ha productes de còpia per a Microsoft 365 que sincronitzen esborrats: si l'element marxa de l'origen, marxa de la còpia en vèncer un termini curt. Aquesta clàusula és la que decideix si tens una còpia o un mirall, i és la pregunta que fem sempre quan muntem còpia de Microsoft 365 per a algú.

Cinc coses que faríem aquesta setmana

Una entrada nova a l'inventari

Aquí no hi ha cap fallada. Priority Cleanup fa exactament el que la seva documentació diu que fa, resol un problema que existia i porta més salvaguardes de les que sol portar un esborrat a Microsoft 365. El que canvia és una altra cosa: la llista de qui pot fer desaparèixer una dada de la teva empresa té des d'aquest mes una entrada més a SharePoint i OneDrive, i aquesta entrada només necessita una signatura.

La fallada és inevitable; l'avaria és una decisió de disseny. Aquesta vegada ni tan sols hi ha fallada: hi ha una capacitat nova i una decisió pendent sobre qui la té. Nosaltres això ho revisem com a part de la feina de Microsoft 365 i de compliment i continuïtat, juntament amb la pregunta que va al darrere i que gairebé mai no es fa a temps: si demà desapareix, d'on torna?

Fonts (verificades el 3 de setembre de 2026): frase sobre l'esborrat irreversible, tres aprovacions sempre exigides, rols d'aprovador, regla de dues persones no forçada, excepció de registres i dels review sets, avís sobre Preservation Lock, comportament en apagar l'interruptor, requisit d'auditoria i esdeveniments de log — Microsoft Learn, «Use priority cleanup to expedite the permanent deletion of sensitive information from mailboxes». Títol de la pàgina de fitxers, casos d'ús de Teams i de la Preservation Hold library, aprovació única, simulació obligatòria, paperera de segona fase i regla de l'últim editor — Microsoft Learn, «Override holds to clean up files for Copilot and reclaim storage». Dates de vista prèvia i disponibilitat general, opció «Delete data permanently» i frase sobre l'activació — avís del centre de missatges de Microsoft 365 MC1261587, publicat el 25-març-2026 i actualitzat el 19-ag.-2026 (visible des de l'inquilí). La pàgina de bústies de Learn està marcada com a funció en vista prèvia i subjecta a canvis; la de SharePoint i OneDrive no porta aquest avís.