Historias de una migración de Microsoft 365: recursos compartidos de archivos

¡Han pasado 10 meses desde la última entrega de mis cuentos de una serie de migración de Microsoft 365! En ese tiempo tuve un nuevo hijo, me mudé de casa, una y otra vez, además migré una gran cantidad de datos (juego de palabras). En esta publicación, detallaré cómo migramos más de 20 TB de datos a SharePoint Online desde recursos compartidos de archivos locales.

Si desea echar un vistazo a mis otras publicaciones que documentan el viaje de migración de mi organización, puede encontrarlas a continuación:

Contenido

Fondo
Descubrimiento
Análisis
Migración
Problemas y resoluciones + cosas importantes

Fondo

He usado esto antes, pero el siguiente gráfico destaca las fases de nuestros esfuerzos de migración, lo que hemos completado hasta ahora (verde) y dónde nos encontramos actualmente (amarillo):

Nuestro objetivo era migrar todos los datos compartidos de archivos servidor por servidor a SharePoint Online, haciendo que los servidores de archivos locales fueran de solo lectura y finalmente desmantelando los servidores. Estos nuevos sitios de SharePoint iban a actuar como una ubicación de puente temporal, lo que permitiría que la organización continuara trabajando con normalidad, pero durante un período de tiempo más largo revisaría el contenido de los sitios y trasladaría los datos a los equipos organizacionales existentes.

Se había trabajado previamente para reducir el volumen de contenido y también para identificar ubicaciones que requerirían cambios de permisos más granulares.

Descubrimiento

Al igual que con el proyecto de migración de unidades domésticas, necesitábamos asegurarnos de lo siguiente:

  • ¿Cuántos servidores de archivos + recursos compartidos individuales hay?
  • ¿Cuál es el tamaño total del volumen de cada servidor combinado?
  • ¿Cómo obtienen acceso los usuarios a los datos una vez que se migran a SharePoint Online?

Al principio nos dimos cuenta de que Microsoft Migration Manager no sería adecuado para este proyecto, principalmente porque vimos un nivel significativamente mayor de errores al ejecutar exploraciones previas en el Administrador de migración que se redujeron hasta en un 90 % al ejecutar exactamente la misma exploración previa en ShareGate. Esto nos llevó a comprar licencias adicionales de ShareGate para acelerar nuestros esfuerzos de migración, ¡lo cual, sinceramente, fue lo mejor que hicimos!

Las migraciones previas al escaneo con ShareGate nos brindaron una excelente línea de base para comprender nuestros datos, pero también compramos Treesize pro, que usamos para generar informes en cada servidor de archivos, lo que hizo mucho más fácil comprender lo que estábamos migrando e interactivo (puede profundizar hacia abajo a través de las carpetas usando este método, que es útil; más sobre esto más adelante).

Análisis

Con todas las herramientas anteriores a nuestra disposición, nos pusimos a trabajar usando Treesize para generar informes para cada servidor de archivos y compartirlos con los propietarios de datos antes de la migración. También mantuvimos un escaneo activo de cada ubicación abierta dentro de la aplicación Treesize para consultar, además de una exportación de cada tarea de migración desde Sharegate para el primer paso y la migración incremental final.

Utilizando los informes anteriores, pudimos dividir cada servidor en tareas que estarían dentro de las limitaciones del software ShareGates:

  • Descubrimos que migrar más de 1 TB o 1 millón de elementos en una tarea generalmente causaba problemas. Las tareas no se completarían o, una vez completadas, no podríamos abrir ni exportar los informes de tareas.
  • Decidimos ceñirnos a la creación de tareas que no contenían más de 500 GB de datos, distribuidos en varias máquinas virtuales para evitar también la limitación: resaltamos cada tarea en un bloque de color en cada hoja de cálculo de Treesize para ayudar a identificar

Migración

Según el volumen de datos y la cantidad de archivos/carpetas que tuvimos que migrar, ejecutamos una migración en dos etapas para todos nuestros datos compartidos de archivos:

  • Primer paso: esta fue la gran migración, la ejecutamos de forma silenciosa en segundo plano para permitir que se ejecutaran tareas de migración más largas y cambiar todos los datos durante esta primera migración.
  • Incremental: esta fue la migración que hicimos pública para nuestros usuarios. Publicamos cronogramas de migración para que los vea toda la organización y programamos tareas en ShareGate para que se ejecuten durante los fines de semana para garantizar que no haya pérdidas en el servicio después de la migración.

En SharePoint Online, a nivel de sitio abrimos el acceso a todos excepto a los usuarios externos. Luego, creamos bibliotecas de documentos dentro de cada sitio de SharePoint y asignamos cada grupo de dominio local existente a la biblioteca compartida de archivos correspondiente. Debido al gran tamaño de las estructuras de carpetas dentro de nuestro entorno de servidor de archivos, decidimos publicar solo el segundo y tercer nivel de cada estructura de recursos compartidos de archivos como parte de los análisis previos a la migración del tamaño del árbol. Los propietarios de datos de cada área de la empresa revisaron los informes que producimos con Treesize e identificaron las carpetas que requerirían más cambios en los permisos.

En algunos casos, se nos pidió que dividiéramos las tareas de migración de ShareGate en varias partes. Tendríamos que hacer esto cuando el recurso compartido de archivos contenga más de 1 TB de datos o más de 1 millón de archivos/carpetas, como se mencionó anteriormente. Para hacer esto, necesitaríamos profundizar más en la estructura de archivos compartidos usando Treesize hasta llegar a la posición de estar por debajo de 1 TB o 1 millón de archivos/carpetas.

Problemas y soluciones alternativas + cosas importantes

Administrador de migración n.º 1 frente a ShareGate

Como se mencionó anteriormente, cuando ejecutamos escaneos previos de nuestras ubicaciones de archivos compartidos usando el Administrador de migración, la herramienta reportó miles de errores que en gran parte estaban relacionados con caracteres no válidos, tipos de archivos bloqueados o nombres de archivos o rutas demasiado largas, lo que significa que no pudimos usar la herramienta. por nuestros esfuerzos de migración.

Solución alternativa: ShareGate funciona mejor para sus migraciones de recursos compartidos de archivos

Después de ejecutar un escaneo previo idéntico con ShareGate, nuestros informes de errores se redujeron hasta en un 90 % en algunos casos, principalmente debido a la capacidad integrada de ShareGate de reemplazar caracteres no válidos. También vale la pena señalar que la interfaz de usuario de ShareGate tiene muchas más funciones y le permite realizar muchas más configuraciones de migración.

ShareGate tiene una función incorporada de reemplazo de caracteres ilegales que reducirá la cantidad de posibles errores en sus migraciones.

#2 Límite de permisos de 50,000 elementos únicos

Al migrar datos de archivos compartidos mediante ShareGate, notamos este mensaje de error al migrar archivos/carpetas con más de 50 000 permisos:

El permiso personalizado asociado con el elemento no se pudo copiar porque excedería el límite de la lista. Se ha alcanzado el número máximo de ámbitos de permiso para esta lista.

https://support-desktop.sharegate.com/hc/en-us/articles/360001453523-El-permiso-personalizado-asociado-con-el-elemento-no-podría-ser-copiado-ya que- exceder el límite de la lista

SharePoint tiene un límite de 50 000 ámbitos de permiso dentro de una lista o biblioteca. Un ámbito es un elemento, documento o carpeta con herencia rota. La documentación proporcionada por Microsoft hace referencia a SharePoint Server, pero esta limitación también se aplica a SharePoint Online.

Si se alcanza el límite de permiso de elemento único de 50 000, todos los elementos programados para la migración después de que se alcance el permiso único de 50 000 fallarán.

Solución alternativa: no migre los permisos como parte de la migración

Seamos realistas, si tiene recursos compartidos de archivos con más de 50 000 permisos de elementos únicos, es probable que tenga problemas mayores que simplemente tratar de migrar los datos. En mi caso, tomamos la decisión de no incluir permisos como parte de cada tarea de migración. Esta fue una gran decisión que requirió el respaldo de la alta gerencia, pero finalmente fue la correcta ya que nos permitió migrar los datos.

Como ya creamos informes para la estructura de recursos compartidos de archivos de nivel superior, asignamos los permisos para el nivel superior de los recursos compartidos de archivos para cada biblioteca en cada sitio de SharePoint. Habiendo publicado la misma hoja de cálculo, les dimos a nuestros propietarios de datos la oportunidad de resaltar cualquier otra ubicación que requiriera agregar permisos únicos adicionales y los incluimos como parte del esfuerzo de migración.

#3 Rompiendo la herencia de permisos en bibliotecas de documentos

Ya escribí un artículo separado sobre cómo romper la herencia de permisos en bibliotecas/listas grandes en SharePoint. Sin embargo, resumiré las áreas clave a tener en cuenta y cómo solucionarlas:

  • Umbral de vista de lista de 5000 para bibliotecas en SharePoint Online
  • Límite de 100 000 elementos para romper la herencia de permisos para bibliotecas de documentos en SharePoint Online

Solución alternativa: elimine elementos para obtener una biblioteca de menos de 100,000 elementos> rompa la herencia de permisos> luego restaure los elementos eliminados

Además, si lee esto antes de comenzar, simplemente deje de heredar permisos para cada biblioteca antes de hacer cualquier otra cosa.

#4 Uso de grupos de dominio de Active Directory locales para administrar bibliotecas de documentos

Decidimos usar los grupos de dominio locales existentes para administrar nuestras bibliotecas de documentos en SharePoint Online, ya que consideramos que sería una tarea más fácil solucionar problemas si puede rastrear dónde los usuarios tenían permisos originalmente con el mismo grupo de dominio. Sin embargo, descubrimos que no puede agregar ni administrar la membresía de un grupo de dominio local sincronizado en Microsoft 365. Como se explica en este artículo de Microsoft:

Si el grupo se sincroniza desde Windows AD local, no se puede administrar en Azure AD. Deben administrarse localmente con herramientas como Usuarios y equipos de Active Directory.

https://docs.microsoft.com/en-us/microsoft-365/community/all-about-groups

Solución alternativa: cree sus propios grupos de seguridad de Azure Active Directory

Como queremos poder administrar todo en Microsoft 365, tener que administrar la membresía de nuestras bibliotecas de SharePoint Online usando el directorio activo local simplemente no iba a funcionar. Así que decidimos crear nuestros propios grupos de seguridad en Azure Active Directory, siguiendo una convención de nomenclatura similar y usar estos grupos para administrar los permisos de la biblioteca de documentos.

#5 Sincronización y borrado accidental

Una vez que comenzamos a implementar nuestros nuevos sitios de reemplazo del servidor de archivos de SharePoint, no pasó mucho tiempo antes de que los usuarios comenzaran a darse cuenta de que tenían la capacidad de sincronizar o crear accesos directos a las bibliotecas/carpetas. El primer problema al que nos enfrentamos fue que cuando los usuarios comenzaban a sincronizar estos grandes archivos compartidos, su OneDrive se interrumpía. Llevaría mucho tiempo completar la sincronización y, en muchos escenarios, la ubicación sincronizada contendría tipos de archivos bloqueados que harían que los usuarios de OneDrive cometieran un error y detuvieran la sincronización.

También observamos que la naturaleza de la sincronización confundió a algunos de nuestros usuarios, lo que significa que pensaron que la sincronización en realidad había creado una copia local en sus máquinas y comenzaron a eliminar archivos sin darse cuenta de que era una conexión activa a la biblioteca de documentos de SharePoint.

Solución alternativa: desactive la sincronización en bibliotecas de documentos grandes

¡Greg Zelfond de SharePoint Maven vino al rescate por mí aquí! Tiene un excelente artículo sobre cómo puede deshabilitar la sincronización en SharePoint y OneDrive que nos permitió evitar que nuestros usuarios sincronicen bibliotecas grandes y eliminen elementos accidentalmente.

6# Mover archivos crea duplicados en la papelera de reciclaje

Algo que no sabía de antemano era que cuando mueve archivos en SharePoint Online, en realidad crea una copia en la ubicación de destino y luego se elimina de la fuente una vez completada. Esto es lo que dice Microsoft al respecto:

Cuando un archivo se mueve, continúa apareciendo en el directorio de origen hasta que se mueve por completo al destino y luego se elimina. El archivo permanece en la Papelera de reciclaje de los sitios de origen después de que se completa el traslado y está sujeto al programa de reciclaje normal a menos que un usuario lo recupere de la Papelera de reciclaje.

https://support.microsoft.com/en-us/office/mover-o-copiar-archivos-en-sharepoint-00e2f483-4df3-46be-a861-1f5f0c1a87bc

Solución alternativa: tenga en cuenta el destino de los archivos/carpetas antes de moverlos

Creo que, en retrospectiva, si nos hubiéramos dado cuenta de esto antes, lo habríamos planificado con anticipación y habríamos comprado más espacio de almacenamiento para prepararnos para tener duplicados en nuestro entorno durante 93 días seguidos, o habríamos trabajado con los propietarios de datos para identificar mejor los archivos/carpetas para migrar a la casa final del equipo de la organización, en lugar de sentarse en un sitio de SharePoint de reemplazo del servidor de archivos.