Segur que més d'una vegada has tingut la sensació que els teus documents de Word, Excel o PowerPoint (ia Word l'ús del control de canvis i comentaris) viuen en un caos permanent: versions amb noms impossibles, arxius sobrescrits sense voler, companys que editen sense avisar… Amb Office, OneDrive i SharePoint aquest control es pot controlar, però com i les polítiques associades.
En entorns empresarials, no es tracta només de poder tornar enrere quan algú fica la pota: parlem de compliment normatiu, registres, auditoria, costos d'emmagatzematge i polítiques de llicenciament . A continuació veuràs, de forma ordenada i en castellà clar, com funcionen les versions a Office i OneDrive, quin paper juguen les etiquetes de retenció, què fan exactament les biblioteques de suspensió per a conservació, quines polítiques d'OneDrive pots fer servir com a admin i com tot això encaixa amb canvis de llicències com Microsoft 365 Archive.
Conceptes bàsics: versions, retenció i registres a Microsoft 365
A Microsoft 365, tot gira al voltant de tres peces clau: l' historial de versions de documents , la retenció i eliminació controlada i la capacitat de declarar certs continguts com a registres . Aquestes capacitats s'apliquen tant a fitxers de OneDrive com a llocs de SharePoint, incloent llocs arxivats i contenidors de SharePoint Embedded usats per Loop o Copilot.
El control de versions de documents permet conservar diferents iteracions d'un fitxer amb marques de temps, autor, mida i comentaris , i és important gestionar metadades correctament. Sobre aquest historial se superposen les directives i etiquetes de retenció, que dicten durant quant de temps se'n conserva el contingut i què ha de passar quan s'arriba al final del període: només conservar, conservar i eliminar, o només eliminar . A més, algunes etiquetes de retenció poden marcar els elements com ara registres o registres normatius , afegint restriccions addicionals per bloquejar canvis i eliminacions.
Control de versions a SharePoint i OneDrive
A totes les biblioteques de documents del SharePoint i OneDrive, el control de versions està habilitat per defecte i desa almenys 500 versions principals . Les versions principals es numeren amb enters (per exemple 5.0) i les versions secundàries amb decimals (5.1, 5.2, etc.), cosa que diferencia les fites “oficials” dels esborranys en curs.
Moltes organitzacions usen les versions secundàries per al treball en curs i reserven les principals per a revisions formals o publicacions. En determinats escenaris, la seguretat d'esborranys es configura perquè només el propietari del fitxer i els que el poden aprovar vegin aquestes versions secundàries, de manera que la resta del personal només accedeixi a la versió principal publicada.
En llistes de SharePoint la cosa és diferent: només s'admeten versions principals numerades amb enters . Si cal aprovació d'elements, aquests passen per un estat Pendent (esborrany) i, fins que no s'aproven, continuen tenint numeració decimal i un control més estricte de visibilitat.
Hi ha un límit de 511 versions secundàries per versió principal que es pot ajustar per adaptar-se a cada entorn. Si s'arriba a aquest màxim i s'intenta desar una altra versió secundària amb un client modern, se sobreescriurà la versió secundària més recent; amb clients antics, el desament pot fallar. Per evitar problemes, sol ser bona idea publicar versions principals periòdicament i combinar-ho amb una política de retenció de versions adequada.
Control de versions de registres: bloquejar i desbloquejar
En escenaris de compliment, moltes empreses necessiten no només conservar versions, sinó tractar-ne algunes com a registres immutables . Per això, SharePoint Online i OneDrive ofereixen l'anomenat control de versions de registres, que permet marcar un fitxer com a registre però seguir generant noves versions que també poden esdevenir registres.
La clau és aplicar una etiqueta de retenció que marqui l'element com a registre . Quan un fitxer rep aquesta etiqueta, apareix una propietat de document anomenada “Estat de registre”, que pot estar en estat Bloquejat o Desbloquejat . El comportament és el següent:
- Quan el registre està bloquejat, el document original no es pot editar. Només es permet llegir i les accions d'eliminació solen quedar bloquejades del tot.
- Al desbloquejar un registre, s'activa una seqüència interna: si no hi ha la biblioteca de suspensió per a conservació, es crea; si no teniu carpeta “Registres”, s'afegeix; i es realitza una acció “Copiar a” que envia la última versió del fitxer a aquesta carpeta de registres amb un nom que inclou títol, GUID i número de versió.
Aquesta “còpia” passa a formar part de l'historial de versions, amb un comentari visible identificant-ho com a Registre . El document original, un cop desbloquejat, passa a ser editable de nou, encara que la columna “L'element és un registre” segueix marcant “Sí”, i mentre l'”Estat de registre” romangui Bloquejat, no es podran modificar ni esborrar els continguts.
Cada vegada que es torna a desbloquejar el document, es crea una nova versió de registre a la biblioteca de suspensió per a conservació . Això us permet mantenir una línia temporal de versions de registre sense inundar el sistema amb còpies innecessàries, ja que només s'emmagatzema com a registre quan l'estat s'estableix explícitament en bloquejat.
Biblioteca de suspensió per a conservació i paperera de reciclatge
Per garantir que el contingut retingut no es perd encara que un usuari modifiqui o elimini fitxers, SharePoint i OneDrive usen una biblioteca oculta anomenada biblioteca de suspensió per a conservació . És una ubicació de sistema, no pensada per a ús interactiu, on s'envien les còpies que ha de preservar el sistema per complir les directives de retenció.
El comportament varia segons el tipus de configuració de retenció que apliqui als fitxers o elements:
- Directiva de retenció: quan un element subjecte a la directiva s'edita o elimina, es copia la versió original a la biblioteca de suspensió per a conservació. En el cas d'edicions, la primera vegada que es modifica un nou document no es copia, però sí a partir de canvis posteriors si el control de versions està actiu.
- Etiqueta de retenció estàndard (no marca com a registre): en editar l'element no es copia res automàticament a la biblioteca de conservació, però si s'elimina, sí que se'n genera còpia en aquesta ubicació.
- Etiqueta de retenció que marca com a registre: en editar un registre desbloquejat es copia el contingut a la biblioteca de suspensió per a conservació; si el registre està bloquejat o és un registre normatiu, les accions d'edició o d'eliminació queden bloquejades directament.
Un treball de temporitzador s'executa regularment (en uns set dies) sobre el contingut de la biblioteca de conservació. Quan un fitxer porta més de 30 dies allà, el treball compara el contingut amb totes les directives i etiquetes de retenció aplicables; si heu superat el període de retenció i no esteu en revisió d'eliminació, es mou cap a la Paperera de reciclatge de segona fase , on roman durant 93 dies abans d'eliminar-se de forma permanent. Per entendre alternatives de conservació i còpia, consulta tipus de còpies de seguretat i diferències.
Si un contingut subjecte a retenció no s'ha modificat ni esborrat durant el període de retenció, en funció de la configuració es pot moure directament a la Paperera de reciclatge de primera fase quan expira el termini, per després passar a la segona. Aquestes papereres de reciclatge no estan indexades, per la qual cosa no es poden cercar mitjançant eDiscovery , cosa que reforça el caràcter d'àrea d'eliminació progressiva.
Hi ha casos en què, malgrat haver-hi retenció, no es crea còpia a la biblioteca de conservació perquè l'acció de l'usuari es bloqueja directament. Passa, per exemple, quan una etiqueta marca el contingut com a registre normatiu sense permetre eliminació, o quan la configuració global d'administració de registres indica que els usuaris no poden eliminar elements etiquetats.
Retenció: conservar, eliminar o ambdues coses
Una directiva o etiqueta de retenció es pot configurar per retenir i després esborrar, només retenir o només esborrar . Cada modalitat provoca un flux diferent del contingut entre la biblioteca de suspensió per a conservació, la ubicació original i les papereres:
Retenir i esborrar
Si la configuració indica “conservar durant X temps i després eliminar” , el comportament és:
- Si el contingut es modifica o esborra durant el període, es copia a la biblioteca de suspensió, on es manté fins que el treball de temporitzador detecta que ha expirat el període. A partir d'aquí s'envia a la Paperera de reciclatge de segona fase i s'esborra definitivament al cap de 93 dies.
- Si el contingut no es toca durant aquest període, en finalitzar el termini es mou a la Paperera de reciclatge de primera fase. D'aquí podeu passar a la segona fase si un usuari la buida o elimina manualment l'ítem. En total, aquests 93 dies cobreixen les dues fases.
Només retenir
Quan lobjectiu és simplement garantir que es conserva el contingut per un temps mínim sense forçar la seva eliminació final, la ruta és més senzilla. Si el contingut es modifica o esborra durant el període, es crea còpia a la biblioteca de conservació, que romandrà allà fins que caduqui el període configurat. En acabar, aquesta còpia es mou a la Paperera de reciclatge de segona fase i, després de 93 dies, s'elimina permanentment. Si el contingut no es modifica ni s'esborra , no passa res addicional: el document segueix a la vostra ubicació original.
Només esborrar
En polítiques orientades a l'eliminació programada (per exemple, per netejar contingut transcorregut cert termini), si un usuari esborra el contingut abans que arribi la data configurada, el document entra a la Paperera de reciclatge de primera fase i, si es purga, passa a la segona; després de 93 dies, desapareix del tot. Si ningú no ho esborra, en arribar el final del període configurat, el sistema l'envia a la primera fase de la Paperera de reciclatge ia partir d'aquí segueix el mateix circuit fins a la seva eliminació definitiva.
Versions, retenció i canvis de comportament
El control de versions i la retenció interactuen de forma força específica. Quan un document amb versions està subjecte a configuració de retenció, el comportament va canviar el juliol de 2022 per millorar el rendiment: ara totes les versions que s'han de conservar s'emmagatzemen com un únic fitxer a la biblioteca de conservació , en lloc de múltiples fitxers independents com passava abans.
Si l'etiqueta no marca l'element com a registre i l' acció al final del període és eliminar :
- Si l'inici de la retenció es basa en la data de creació, la data d'etiquetatge o un esdeveniment, totes les versions comparteixen la mateixa data d'expiració. S'eliminen alhora juntament amb el document original.
- Si la retenció es basa en la darrera modificació i estem ja amb el nou model on les versions es guarden com un únic fitxer, totes les versions expiren segons la data de la darrera versió. Abans del canvi, cada versió podia tenir la seva pròpia data d'expiració independent, perquè cadascuna es copiava com a fitxer separat.
Mentre un fitxer està subjecte a una directiva de retenció oa una suspensió d'eDiscovery , el límit de versions configurat a la biblioteca s'ignora: les versions no es purguen automàticament per fer buit i els usuaris no poden eliminar-les manualment. Això garanteix la preservació completa de l'historial mentre duri la retenció o la suspensió.
En canvi, quan es tracta d'una etiqueta de retenció aplicada a un fitxer que també pertany a una directiva , sí que es respecten els límits de versions de la biblioteca; es poden anar eliminant versions antigues segons la configuració de control de versions, encara que lusuari segueixi sense poder esborrar versions manualment.
Dades adjuntes al núvol i Copilot
Les anomenades dades adjuntes al núvol són enllaços a fitxers emmagatzemats a SharePoint uOneDrive que s'insereixen en correus d'Outlook, missatges de Teams o Viva Engage, així com els documents que es referencien en interaccions amb Microsoft 365 Copilot i Copilot Chat. Per a aquests casos, les regles de retenció també s'apliquen, però amb un matís important.
Quan s'utilitza una directiva d'etiquetatge automàtic per a dades adjuntes al núvol, l'etiqueta de retenció no s'aplica al fitxer original, sinó a una còpia que es crea a la biblioteca de suspensió per a la conservació . El que és recomanable és que el període de retenció comenci "quan l'element s'etiqueta", perquè si es basa en "creació" o "última modificació" s'usarien les dates del fitxer original en el moment de l'ús compartit, i això pot no ajustar-se al cicle de vida real de l'adjunt.
Si el fitxer original s'edita i es torna a compartir, es crea una nova versió de la còpia a la biblioteca de conservació i s'etiqueta de nou. Si només es torna a compartir sense canvis, s'actualitza la data d'etiquetatge de la còpia, cosa que estén el període de retenció si aquest es basa en aquest moment d'etiquetatge. A més, s'aplica una retenció temporal addicional d'un dia a la biblioteca de conservació per a fitxers que s'eliminen o mouen abans de poder crear la còpia etiquetada, de manera que la referència usada per l'adjunt al núvol segueixi tenint un suport disponible.
Contingut d'OneNote i estructures especials
Quan apliqueu retenció al contingut del OneNote, cada quadern es descompon internament en seccions que es tracten com a fitxers individuals . Les pàgines viuen dins de cada secció i hereten la configuració. Per tant, les directives o etiquetes de retenció actuen sobre seccions completes amb totes les pàgines, conservant-les o eliminant-les segons correspongui, mentre que la data “Modificat” del quadern complet no es fa servir per a aquestes decisions.
La retenció s'aplica a fitxers, elements de llista (via etiquetes), contenidors de Loop i pàgines de Copilot , però no a estructures organitzatives com biblioteques, llistes, carpetes o àrees de treball en si mateixes. Aquestes estructures s'han de gestionar amb altres eines d'administració.
Retenció, usuaris que abandonen l'organització i Microsoft 365 Arxiu
A SharePoint, els llocs es consideren espais col·laboratius i el contingut no s'esborra només perquè un usuari abandoni la companyia. Els documents continuaran existint i estant subjectes a directives de retenció o etiquetes fins que es compleixin els seus períodes respectius.
A OneDrive el comportament és diferent, perquè es tracta d'un espai personal. Si l'usuari marxa, els fitxers amb directives o etiquetes de retenció segueixen retinguts i són accessibles per a cerques de compliment, eDiscovery i accessos compartits durant el temps estipulat. Quan expira el termini i si la configuració inclou eliminació, el contingut es mou a la Paperera de reciclatge de la col·lecció de llocs, on només l'administrador pot recuperar-lo durant el període de 93 dies.
Amb la introducció de Microsoft 365 Archive , molts llocs del SharePoint poden passar a estat arxivat per optimitzar emmagatzematge i costos. Per als administradors, les directives i etiquetes de retenció es gestionen pràcticament igual per a llocs actius i arxivats : els llocs arxivats segueixen inclosos a les directives per defecte, es poden crear noves polítiques específiques per a ells i es poden aplicar etiquetes automàticament.
La principal limitació és que els usuaris finals no poden interactuar amb el contingut de llocs arxivats (per exemple, aplicar o treure etiquetes, bloquejar/desbloquejar registres o editar propietats), i en el cas de dades adjuntes al núvol, una directiva d'etiquetatge automàtic ja no conserva nous adjunts que apuntin a contingut actualment en un lloc web.
Canvis de llicenciament a OneDrive i Microsoft 365 Archive
Microsoft ha anunciat que a partir d'una data concreta, qualsevol compte d' OneDrive sense llicència durant més de 93 dies s'arxivarà automàticament a Microsoft 365 Archive. Això implica dues conseqüències rellevants per a l'estratègia de versions, retenció i costos:
- L'accés a aquest compte arxivat queda restringit tant per a usuaris com per a admins; el compte apareix en eines d'administració, però el contingut no és accessible directament.
- L'emmagatzematge a Microsoft 365 Archive comporta costos addicionals tant per conservar les dades com per restaurar-les, que depenen del volum dinformació.
Per mitigar aquest impacte, és clau portar un control rigorós de qui fa servir OneDrive, qui té llicència assignada i qui no , i creuar-lo amb informació d'ús real. Eines d'ITAM com Proactivanet permeten veure quins plans de servei i llicències estan actius, quins comptes usen OneDrive en els darrers 28 dies i on hi ha llicències duplicades o sense assignar que podrien aprofitar-se per evitar que comptes actius acabin arxivats sense voler.
Govern d'OneDrive mitjançant GPO i claus de registre
En entorns Windows corporatius, OneDrive s'administra en gran mesura mitjançant objectes de directiva de grup (GPO) que estableixen claus del Registre als equips del domini. Aquestes plantilles administratives (.admx i .adml) s'obtenen en instal·lar el client de sincronització de OneDrive i es copien al magatzem central de directiva de grup del domini. Cada vegada que habiliteu o desactiveu una configuració, s'ajusten les claus corresponents a HKLM o HKCU; si més endavant es deixa una configuració a “No configurada”, aquestes claus no es toquen, per la qual cosa convé mantenir-les a Habilitat o Deshabilitat després de decidir el seu estat.
Hi ha una extensa llista de GPO que permeten controlar des del comportament de la sincronització fins a l'ús d'amplada de banda, passant per qui pot fer servir OneDrive personal, com es gestionen les carpetes conegudes de Windows, com es tracten els conflictes d'Office o quan advertir l'usuari sobre eliminacions en massa. Algunes de les més rellevants relacionades amb el control de versions, la retenció i l'experiència d'usuari són:
Directives de configuració de l'equip per a OneDrive
Entre les polítiques de “Configuració de l'equip\Plantilles administratives\OneDrive” en destaquen diverses que incideixen en com es gestionen fitxers, sincronització i esborrats:
- Eliminar de forma rígida el contingut en desmuntar carpetes agregades o en perdre permisos: aquestes GPO controlen si, en desmuntar una carpeta agregada o quan es perden permisos sobre ella, el contingut local s'envia a la Paperera de reciclatge o elimina de forma permanent. S'activen mitjançant les claus AddedFolderHardDeleteOnUnmount i AddedFolderUnmountOnPermissionsLoss.
- Permet deshabilitar l'herència de permisos a carpetes sincronitzades de només lectura: pensada per millorar el rendiment en carpetes de només lectura molt complexes, mitjançant la clau PermitDisablePermissionInheritance. No afecta els permisos al SharePoint, només els ACL locals.
- Control de llogaters permesos o bloquejats: les GPO AllowTenantList i BlockTenantList determinen amb quines organitzacions es pot sincronitzar OneDrive, evitant que els usuaris carreguin contingut corporatiu a tenants no autoritzats.
- Mínim d'espai en disc i advertiments de poc espai: mitjançant MinDiskSpaceLimitInMB i WarningMinDiskSpaceLimitInMB es pot impedir que OneDrive descarregui fitxers per sota de cert llindar o mostrar avisos quan un fitxer deixi el disc per sota del mínim.
- Fitxers sota demanda i deshidratació de llocs d'equip: les polítiques FilesOnDemandEnabled i DehydrateSyncedTeamSites forcen l'ús de Fitxers a petició i converteixen contingut sincronitzat de llocs d'equip a només en línia, reduint consum de disc i trànsit de xarxa.
- Gestió d'amplada de banda de càrrega: amb EnableAutomaticUploadBandwidthManagement i AutomaticUploadBandwidthPercentage es pot fer que OneDrive usi LEDBAT o limitar les càrregues a un percentatge de la capacitat de pujada.
- Moviment i bloqueig de carpetes conegudes (KFM): directives com KFMBlockOptIn, KFMBlockOptOut, KFMOptInWithWizard i KFMSilentOptIn permeten forçar o impedir que Documents, Imatges i Escriptori es redirigeixin a OneDrive, ja sigui de forma silenciosa o demanant confirmació a l'usuari.
- Advertiments i confirmacions d'esborrament massiu: les claus LocalMassDeleteFileDeleteThreshold i ForcedLocalMassDeleteDetection controlen a partir de quants fitxers esborrats s'ha d'avisar a l'usuari i si aquest avís és obligatori o es pot recordar “no tornar a mostrar”.
- Control de manera sense connexió a OneDrive web: DisableOfflineMode i DisableOfflineModeForExternalLibraries determinen si els usuaris poden habilitar el mode desconnectat a la web per a les seves pròpies biblioteques i per a les compartides des d'altres tenants.
- Inici automàtic, trànsit previ al login i configuració silenciosa: polítiques com EnableAutoStart, PreventNetworkTrafficPreUserSignIn i SilentAccountConfig controlen si OneDrive s'arrenca amb Windows, si pot generar trànsit abans d'iniciar sessió i si pot configurar-se automàticament amb les credencials de Microsoft Entra.
Directives de configuració d'usuari per a OneDrive
A “Configuració d'usuari\Plantilles administratives\OneDrive” hi ha GPO més centrades en l'experiència de l'usuari i el comportament habitual de l'aplicació:
- Conflictes de fitxers d'Office i coautoria: les polítiques EnableHoldTheFile i EnableAllOcsiClients determinen com es manegen els conflictes de sincronització amb Office i si es permet coautoria en temps real i ús compartit des de les apps descriptori. Microsoft planeja habilitar per defecte el comportament de coautoria i combinació de conflictes per a tots els tenants, eliminant aquests GPO.
- Sincronització en xarxes d'ús mesurat i mode d'estalvi de bateria: DisablePauseOnMeteredNetwork i DisablePauseOnBatterySaver fan que OneDrive seguiu sincronitzant fins i tot en xarxes amb tarifa mesurada o quan està activat l'estalvi de bateria, en lloc de pausar per defecte.
- Límits de velocitat de descàrrega i càrrega: DownloadBandwidthLimit i UploadBandwidthLimit fixen un màxim de KB/s per a la sincronització, útil per a desplegaments inicials o entorns amb restriccions de xarxa estrictes.
- Ubicació i personalització de la carpeta de OneDrive: DefaultRootDir i DisableCustomRoot permeten establir una ruta predeterminada per a la carpeta “OneDrive – {organització}” i controlar si l'usuari pot canviar-la a l'assistent.
- Bloqueig de OneDrive personal: DisablePersonalSync impedeix que els usuaris sincronitzin comptes personals d'OneDrive en equips corporatius, mantenint així més clar el perímetre de dades.
Bones pràctiques per a versions, retenció i polítiques a OneDrive/Office
Amb totes aquestes peces sobre la taula, la clau és combinar-les de forma coherent per no tornar-te boig ni fondre l'emmagatzematge. Un enfocament raonable sol incloure:
- Definir polítiques de retenció per tipus dinformació: per exemple, contractes amb conservació de diversos anys i eliminació forçada al final, documentació interna amb només retenció de curt/mitjà termini i contingut transaccional amb polítiques de només eliminació.
- Ajustar els límits de versions segons rellevància del contingut. No té sentit guardar centenars de versions de documents trivials, però sí de registres financers, legals o tècnics.
- Usar registre i control de versions de registres per a contractes, actes i documents que realment necessitin traçabilitat completa, evitant marcar-los tots com a registres sense necessitat.
- Combinar GPO d'OneDrive amb retenció: forçar Arxius sota demanda en equips amb poc disc, moure carpetes conegudes de forma silenciosa i limitar ample de banda en desplegaments massius redueix problemes de rendiment sense sacrificar control de versions.
- Vigilar els canvis de llicenciament i Archive: revisar periòdicament els comptes d'OneDrive sense llicència ni ús recent, reassignar llicències infrautilitzades i decidir quins continguts val la pena pagar per emmagatzemar a Microsoft 365 Archive.
Si alinees el control de versions d'Office, les etiquetes i directives de retenció de SharePoint/OneDrive i les GPO d'OneDrive amb la teva política de compliment i els teus límits de cost, tindràs una combinació molt potent: historial complet dels documents crítics, control real sobre què s'esborra i quan, i una experiència bastant neta per als usuaris . disparen sense que ningú sàpiga per què. Comparteix aquesta informació perquè els usuaris hagin assabentats del tema.