A finales de septiembre, las pizarras que alguien crea desde la pestaña de un canal de Teams dejarán de guardarse en el OneDrive de quien las creó y pasarán al SharePoint del canal. Lo anunció Microsoft el 16 de marzo en el aviso MC1253753, va activado por defecto y no requiere que el administrador haga nada. Es un cambio de tres líneas en el centro de mensajes y una admisión bastante grande: el trabajo del equipo estaba en la cuenta personal de una persona, y por eso se rompía. Lo que casi nadie ha mirado es cuántas cosas más siguen exactamente donde estaban.
El motivo que da Microsoft en el aviso es operativo y suena razonable: guardarlas en el sitio del canal evita los problemas de acceso que provocaban la configuración de compartición, las barreras de información o las políticas de acceso condicional, y hace que las pizarras hereden los controles de Purview del sitio —DLP, etiquetas de confidencialidad, retención, eDiscovery y registro de auditoría—. Todos los miembros del canal tendrán el mismo acceso, según los permisos del canal. Hay una cosa que el aviso no dice y que nosotros no vamos a suponer: qué ocurre con las pizarras que ya existen dentro de OneDrive. Trátalas como lo que son hasta que Microsoft diga otra cosa: ficheros que viven en la cuenta de una persona concreta.
El mapa que casi ninguna empresa tiene
La documentación de Teams sobre almacenamiento de grabaciones se actualizó el 7 de agosto, hace tres días. Merece la pena leerla entera una vez en la vida, porque el reparto no es intuitivo y cada fila tiene consecuencias distintas el día que alguien se marcha:
- Reunión o evento programado: la grabación va a la carpeta
Recordingsdel OneDrive del organizador, incluso si el organizador no asistió a la reunión. También si la convocó una persona delegada en su nombre. - Llamada individual o de grupo: va al OneDrive de quien pulsó Grabar. En una llamada con alguien de fuera, la otra parte no tiene ningún acceso salvo que se lo compartas a mano.
- Reunión de canal: esta es la buena. La grabación se guarda en la biblioteca de documentos del sitio de SharePoint del equipo, en
Documents/Recordings, y los permisos los heredan los miembros del canal. Nadie es dueño de nada a título personal. - Reunión convocada desde un buzón compartido: el buzón cuenta como organizador, pero como los buzones compartidos no suelen tener OneDrive, la grabación acaba en el del coorganizador o, si no lo hay, en el de quien inició la grabación. Es decir: creíste que estaba en una cuenta de servicio y está en la de una persona.
- Sala de reuniones de Teams: cuando alguien pulsa Reunirse ahora desde una sala, la sala es la organizadora. Si su cuenta de recurso tiene licencia de OneDrive, la grabación se guarda ahí y ninguno de los participantes tiene permisos completos sobre el fichero. La recomendación literal de Microsoft para evitarlo es no asignar licencia de OneDrive a la cuenta de recurso de la sala. Que la solución oficial sea quitarle el almacenamiento a un dispositivo resume bastante bien el problema de fondo.
- Y si nadie tiene OneDrive: la grabación va a un almacenamiento temporal asíncrono, no se reintenta la subida y se borra a los 21 días si nadie la descarga. Como referencia de tamaño, la propia documentación calcula 400 MB por cada hora grabada.
Fíjate en el patrón: de seis casos, solo en el de canal el fichero pertenece al equipo. En cuatro acaba colgando de una persona o de una cuenta de recurso, y en el último no cuelga de nadie y se borra solo en tres semanas. Ninguna de esas personas decidió ser la propietaria del fichero: le tocó porque convocó la reunión o porque pulsó un botón.
El reloj no empieza cuando la persona se va
Aquí es donde la mayoría de procedimientos de baja que nos encontramos tienen un agujero, y el motivo es que el detalle vive en un párrafo de la documentación de OneDrive que no lee nadie. El periodo de retención de OneDrive empieza a contar cuando la cuenta se elimina de Entra ID. Ninguna otra acción lo dispara: ni bloquear el inicio de sesión, ni quitar la licencia. El valor por defecto son 30 días, y se cambia desde el centro de administración de SharePoint o con Set-SPOTenant -OrphanedPersonalSitesRetentionPeriod.
Durante esos 30 días, por defecto el responsable directo de la persona recibe acceso automático al OneDrive y un correo avisándole. Si no hay responsable definido en Entra, el aviso va al propietario secundario que se configura en el centro de administración de SharePoint, dentro de Setup My Sites. Y si no hay ninguno de los dos —que es lo que nos encontramos a menudo, porque el campo del responsable se queda sin rellenar en cuanto un alta la hace alguien con prisa— nadie recibe acceso y nadie recibe el aviso. Siete días antes del final se manda un segundo correo, al mismo destinatario inexistente. Después, el OneDrive pasa a la papelera de la colección de sitios durante 93 días: ahí nadie puede acceder ya al contenido que estuviera compartido, restaurarlo exige PowerShell y, como la papelera no está indexada, una retención por eDiscovery tampoco puede localizar nada dentro. El matiz que juega a favor y conviene saber: si ese OneDrive ya estaba bajo una retención de eDiscovery antes, no se borra hasta que se levante, y las políticas de retención de Microsoft 365 tienen prioridad sobre todo este proceso, así que pueden borrar antes de los 30 días o conservar mucho más allá.
Y ahora la costumbre del sector, esa que todos hemos aplicado: «la cuenta no la borramos, la dejamos bloqueada y sin licencia por si acaso». Es verdad que así no arranca el reloj de los 30 días. Lo que casi nadie sabe es lo que dice el aviso destacado al principio de ese mismo documento: toda cuenta de OneDrive sin licencia válida se archiva automáticamente en su día 93 sin licencia. Mientras ese archivo esté pagado, Microsoft dice que se siguen respetando la configuración y las políticas de retención, eDiscovery y todas las retenciones legales. Pero tras 12 meses de almacenamiento archivado sin pagar, los datos pueden borrarse con independencia de todo eso. Dicho de otro modo: la cuenta que dejaste bloqueada acaba en un archivo de pago, y ese archivo tiene factura y tiene fecha.
«Pero nosotros tenemos copia de seguridad de Microsoft 365»
Es la respuesta que recibimos siempre que sacamos este tema, y normalmente es cierta: hay una herramienta, corre cada noche y los informes salen en verde. El problema es que una copia responde a la pregunta «¿puedo recuperar este fichero?», y la que aquí hace daño es otra: «¿de quién era este fichero, y quién sabrá dentro de un año que hay que pedir su recuperación?». Cuando restauras el OneDrive de una cuenta que ya no existe, lo que recuperas es una carpeta huérfana: sin la estructura de permisos del equipo que la usaba, sin los enlaces que la gente tenía guardados, y con alguien de sistemas decidiendo a las tres de la tarde de un martes en qué sitio la deja. Se puede hacer y lo hemos hecho. Es lento, es manual y nadie lo cuenta cuando vende la copia.
Conste que hay que hacer copias de Microsoft 365, y ya explicamos en su día por qué la retención de Purview no es una copia de seguridad. Lo que discutimos aquí es el orden: la copia es la red de abajo, y este problema está arriba, en quién es el propietario del dato mientras todo va bien. Si el fichero nació en el sitio del equipo, la baja de una persona se resuelve con un formulario de recursos humanos y quince minutos de un administrador.
Lo que hacemos antes de tocar la cuenta
- Rellenar el campo del responsable en Entra ID para toda la plantilla, y configurar además un propietario secundario en Setup My Sites por si alguien no lo tiene. Y antes que nada, comprobar que Enable access delegation está marcado en My Site Cleanup: si está desactivado, ni el responsable ni el propietario secundario reciben nada.
- Subir el periodo de retención de OneDrive de los 30 días por defecto a algo que aguante un cierre contable o un traspaso real de funciones. El matiz: ese almacenamiento sigue contando en tu cuota y sigue costando, así que la cifra sale de una conversación con el negocio.
- Convocar las reuniones recurrentes desde el canal, en lugar de desde el calendario de una persona. Cambia una sola cosa —dónde cae la grabación— y con eso el histórico del comité deja de tener propietario individual.
- Revisar las cuentas de recurso de las salas: sin licencia de OneDrive, tal y como recomienda la propia documentación.
- Mover el material del equipo al sitio del equipo mientras la persona está. El momento de mover un fichero es cuando todavía hay alguien a quien preguntarle qué es y para qué servía. Después es arqueología.
- Probar una restauración de verdad, de una cuenta ya borrada, cronometrándola. Un plan de recuperación que no se ha ejecutado nunca es una intención. Lo mismo vale para el correo, donde el borrado también puede venir de fuera: lo contamos al hablar de la retirada de mensajes entre organizaciones en Exchange Online.
Cuatro de esas seis se hacen en una tarde. Mover el material del equipo lleva su tiempo, y la prueba de restauración hay que meterla en el calendario igual que un simulacro de incendios. Lo que queda es la conversación con recursos humanos sobre qué pasos incluye la baja de una persona, que es donde de verdad se decide esto: el procedimiento de empresa que la tecnología deja al descubierto cada vez que alguien se marcha.
Cuando revisamos un tenant, hay una pregunta que hacemos pronto porque ordena el resto de la conversación: enséñame la grabación del comité de dirección de hace dos años. Casi nunca aparece a la primera, y el guion se repite: la grabación estaba en el OneDrive de alguien que se marchó, la cuenta se eliminó meses después en un saneamiento de licencias y el aviso salió hacia una dirección que ya no lee nadie. No la borró nadie a propósito ni falló ninguna copia: todo funcionó exactamente como está documentado. Ese es exactamente el problema.
Nosotros desplegamos y mantenemos Microsoft 365 para empresas y no vendemos ninguna herramienta milagrosa para esto: lo que hay es procedimiento, gobierno del dato y una copia que alguien ha probado a restaurar de verdad. Es lo que montamos en los proyectos de copia de seguridad de Microsoft 365 y de puesto de trabajo moderno. Si quieres salir de dudas sin comprar nada, coge la última baja de tu empresa y busca sus ficheros; si no aparecen, escríbenos y lo revisamos contigo.
Nota sobre fuentes.
El traslado de las pizarras de los canales de Teams al sitio de SharePoint del canal, la fecha de despliegue (finales de septiembre de 2026), que va activado por defecto y sin acción del administrador, y los motivos declarados (barreras de información, acceso condicional, herencia de controles de Purview), del aviso MC1253753 del centro de mensajes de Microsoft 365, publicado el 16 de marzo de 2026. Que el aviso no dice nada sobre las pizarras ya existentes lo comprobamos en ese mismo texto y por eso no afirmamos nada al respecto. El reparto de las grabaciones (OneDrive del organizador, de quien pulsa grabar en llamadas, SharePoint del canal en reuniones de canal, buzones compartidos, salas de Teams sin licencia de OneDrive, almacenamiento asíncrono con borrado a los 21 días y los 400 MB por hora), de la documentación de Microsoft Teams, actualizada el 7 de agosto de 2026. El inicio del periodo de retención al eliminar la cuenta de Entra ID, los 30 días por defecto, Set-SPOTenant -OrphanedPersonalSitesRetentionPeriod, la delegación automática de acceso al responsable y el propietario secundario, los avisos por correo, los 93 días en la papelera de la colección de sitios, que la papelera no está indexada para eDiscovery y el archivado automático el día 93 sin licencia con posible borrado tras 12 meses pese a retenciones y holds, de la documentación de OneDrive sobre retención y eliminación, revisada el 2 de junio de 2026. La lectura sobre la propiedad del dato, el orden entre copia y gobierno, y la pregunta del comité de dirección son nuestras. Imagen de portada: «Kansallisarkisto Helsinki Rauhankatu 17 luettelohuone kortistokaappi 2026 02 23», de Fuje23, vía Wikimedia Commons, bajo licencia CC BY-SA 4.0 (recortada; la imagen resultante se publica bajo la misma licencia).