Compartir a través de

Prueba de la migración

Pruebe siempre el plan de migración en una configuración de laboratorio controlada antes de implementarlo en toda la organización. En el entorno de prueba, se necesita al menos un equipo para cada tipo de sistema operativo desde el que se migran los datos.

Una vez que todo el proceso de migración se prueba en un único equipo que ejecuta cada uno de los sistemas operativos de origen de la organización, realice una migración piloto con un pequeño grupo de usuarios. Después de migrar algunos estados de usuario típicos al almacén intermedio, tenga en cuenta el espacio necesario y ajuste los cálculos iniciales en consecuencia. Para obtener más información sobre cómo calcular el espacio necesario para la migración, consulte Estimación del tamaño del almacén de migración. Es posible que sea necesario ajustar la información de configuración del Registro y ubicación del archivo en los archivos de regla de migración. Si se realizan cambios, vuelva a probar la migración y compruebe que todos los datos y la configuración se migraron según lo esperado. Una migración piloto también ofrece la oportunidad de probar las estimaciones de espacio para el almacén intermedio.

Si la migración de prueba encuentra errores, examine los registros ScanState y LoadState para obtener el código de retorno exacto de la Herramienta de migración de estado de usuario (USMT) y los mensajes de error asociados o el mensaje de error de la interfaz de programación de aplicaciones (API) de Windows. Para obtener más información sobre los códigos de retorno de USMT y los mensajes de error, vea Códigos de retorno. Para obtener más información sobre los códigos de error del sistema de Windows enumerados, escriba lo siguiente en una ventana del símbolo del sistema:

net.exe helpmsg <error_number>

donde <error_number> es el número de código de error generado por el mensaje de error. Para obtener más información sobre los códigos de error del sistema, vea Códigos de error del sistema (0-499).

En la mayoría de los casos, los registros ScanState y LoadState indican por qué se produce un error en una migración de USMT. Microsoft recomienda usar la /v:5 opción al probar la migración. Este nivel de detalle se puede ajustar en una migración de producción. La reducción del nivel de detalle podría dificultar el diagnóstico de errores que se producen durante las migraciones de producción. Se pueden usar niveles de detalle más altos si los archivos de registro deben generarse para ir a un depurador.

Nota

La ejecución de las herramientas ScanState y LoadState con la /v:5 opción crea un archivo de registro detallado. Aunque esta opción hace que el archivo de registro sea grande, resulta útil para determinar dónde se produjeron los errores de migración.

Una vez comprobada la migración piloto que migró correctamente los archivos y la configuración especificados, USMT está listo para usarse en el entorno para migrar datos. Por ejemplo, usar USMT con Microsoft Configuration Manager. Para obtener más información, vea [Administrar el estado de usuario en Configuration Manager]/(mem/configmgr/osd/get-started/manage-user-state).

Nota

Con fines de prueba, se puede crear un almacén sin comprimir con la /hardlink /nocompress opción . Cuando la compresión está deshabilitada, la herramienta ScanState guarda los archivos y la configuración en una carpeta oculta denominada Archivo en <StorePath>\USMT. El almacén sin comprimir se puede usar para ver lo que USMT ha almacenado o para solucionar un problema. Una utilidad antivirus también se puede ejecutar en los archivos. Además, se pueden usar los siguientes elementos para solucionar problemas con la migración:

  • Opción /listfiles de línea de comandos.
  • Registro de diagnóstico que enumera los archivos recopilados.