Traslado de un entorno a otro para Azure DevOps local

Azure DevOps Server |Azure DevOps Server |Azure DevOps Server 2022 | Azure DevOps Server 2020

En este artículo se explica cómo mover una implementación de Azure DevOps Server de un entorno a otro, como cambiar el nombre de dominio o pasar de un grupo de trabajo a un dominio. Los movimientos basados en entornos son comunes cuando las organizaciones reestructuran su infraestructura de TI, actualizan los nombres de dominio o consolidan los recursos.

Puede encontrar instrucciones paso a paso para preparar la implementación, actualizar permisos y cuentas, detener servicios, realizar copias de seguridad de datos, unir el nuevo dominio, migrar cuentas de usuario y servicio, configurar informes y servicios de análisis, actualizar planes de copia de seguridad y reiniciar servicios.

Cambiar el entorno de Azure DevOps Server requiere una planeación cuidadosa, especialmente en torno a la administración de cuentas e identidades, para evitar conflictos y garantizar una transición sin problemas. En este artículo se proporcionan procedimientos recomendados e instrucciones detalladas para ayudarle a completar correctamente el traslado.

Importante

En algunas situaciones, es posible que desee cambiar el dominio de una implementación de Azure DevOps Server y su hardware. Cambiar el hardware es un movimiento basado en la restauración y nunca debe combinar los dos tipos de movimiento. En primer lugar, complete el movimiento de hardware y, a continuación, cambie el entorno.

El cambio de identidades en Azure DevOps Server como parte de un movimiento del entorno es el aspecto que suele provocar conflictos o problemas. El comando Identities es una herramienta eficaz, pero tiene ciertas limitaciones. Obtenga información sobre él como parte de la planificación de su traslado. Para ayudar a garantizar un traslado correcto, asegúrese de que comprende los siguientes requisitos:

Una vez que una cuenta de usuario está presente en Azure DevOps Server, no se puede quitar ni tener otra cuenta asignada. Por ejemplo, si va a mover DomainA/UserA a DomainB/UserB, el comando Identidades solo funcionaría para migrar el usuario si DomainB/UserB aún no está presente en Azure DevOps Server.
Dado que los miembros del grupo administradores locales se agregan automáticamente a Azure DevOps Server, asegúrese de quitar las cuentas que quiera migrar de ese grupo antes de cambiar el dominio o el entorno.

Para obtener más información general, consulte esta entrada de blog.

1. Comprobación de permisos y cuentas

Para cambiar el entorno de Azure DevOps Server, inicie sesión como administrador en el equipo local, Azure DevOps Server, SQL Server, informes y cualquier otro software dependiente (como Project Server). Evite el uso de cuentas que planea migrar: los miembros del grupo administradores locales se agregan automáticamente a Azure DevOps Server, lo que puede provocar problemas de migración. Use una cuenta administrativa dedicada para el traslado para evitar conflictos.

Comprobación de los permisos de nivel de administrador

Asegúrese de que la cuenta que usa es miembro de los siguientes grupos:
- Servidores: administradores (grupo de administradores locales o equivalente)
- Azure DevOps Server: administradores de Team Foundation y usuarios de la consola de administración
- SQL Server: administrador del sistema

Si no es miembro de uno o varios de estos grupos, obtenga permisos ahora.

Después de confirmar que la cuenta tiene todos los permisos necesarios, compruebe si hay posibles conflictos con los nombres de cuenta o grupo en el entorno de destino. Puesto que no se pueden migrar las cuentas del grupo de administradores locales, quite las cuentas que planee migrar de ese grupo antes de continuar.

Quitar cuentas que se van a migrar del grupo de administradores locales

Abra el grupo Administradores local y quite las cuentas que planee migrar al nuevo entorno. Repita este proceso para cualquier otro grupo que pueda verse afectado.

A continuación, revise la lista de identidades en el entorno actual de Azure DevOps Server. Identifique los posibles conflictos con grupos o cuentas de usuario que ya puedan existir en el nuevo entorno.

Sugerencia

Cree una tabla o un mapa de migración de identidades que se van a mover. Incluya detalles sobre las cuentas que no se pueden migrar automáticamente para ayudar a realizar un seguimiento y resolver problemas durante el traslado.

Comprobación de identidades

En el servidor de nivel de aplicación para Azure DevOps, abra una ventana del símbolo del sistema con permisos administrativos, ir a %ProgramFiles%\Microsoft Visual Studio 12.0 Team Foundation Server\Tools y ejecute el siguiente comando para ver las identidades que están actualmente en el sistema.
```
TFSConfig Identities
```

Se muestra una lista de identidades.

Revise los usuarios y grupos para identificar las identidades duplicadas o conflictivas en el entorno de destino antes de mover Azure DevOps Server. Resuelva los posibles conflictos para garantizar una migración sin problemas.

2. Detener los servicios

Detener los servicios impide que los usuarios realicen cambios en los elementos de trabajo o registren el código fuente en la implementación original durante y/o después del proceso de mover.

Abra una ventana de línea de comandos en el equipo de nivel de aplicación y cambie al directorio Drive:\\%programfiles%\\TFS 12.0\\Tools.
Escriba el siguiente comando TFSServiceControl :
```
TFSServiceControl quiesce
```

3. Copia de seguridad de las bases de datos y la clave de cifrado de SQL Server Reporting Services

Abra la consola de administración de Azure DevOps Server y vaya a la página Copias de seguridad programadas . Realice una copia de seguridad completa para realizar una copia de seguridad inmediata de todo lo especificado en el plan de copia de seguridad. Si la implementación usa informes, incluya la clave de cifrado en este conjunto de copias de seguridad.

Nota:

Si nunca configuró las copias de seguridad, cree un plan de copia de seguridad antes de realizar una copia de seguridad completa.
Una vez completada la copia de seguridad, confirme que la copia de seguridad está disponible en el dispositivo de almacenamiento o el recurso compartido de red y compruebe que puede acceder a ella desde el nuevo hardware.

4. Unir el servidor de capa de aplicación a su nuevo dominio

En cada servidor, abra las propiedades del equipo.
Cambie la configuración del equipo para unirse al dominio o grupo de trabajo deseados.

Si se le solicita, escriba las credenciales de una cuenta con permiso para unir el equipo al dominio.
Reinicie el equipo para aplicar el cambio de dominio.

Nota:

Después de reiniciar, podría aparecer una advertencia indicando que algunos servicios o controladores no pudieron iniciarse. Puede continuar con el siguiente procedimiento de forma segura.

5. Mover cuentas de usuario y cuentas de servicio

La migración de cuentas suele ser la parte más difícil de cambiar los entornos, especialmente si no planeó cuidadosamente la migración de usuarios. El comando TFSConfig Identities no puede migrar una cuenta a una cuenta de destino que ya existe en Azure DevOps Server.

Si los nombres de cuenta son idénticos en ambos dominios (con solo el nombre de dominio diferente), puede usar el modo por lotes de identidades TFSConfig para actualizar todas las identidades a la vez. Si los nombres de cuenta difieren entre entornos, debe actualizar cada identidad individualmente y especificar el nuevo nombre de cuenta de destino, como se describe a continuación.

En el servidor de nivel de aplicación para Azure DevOps, abra una ventana de símbolo del sistema con permisos administrativos. Vaya a %ProgramFiles%\Microsoft Visual Studio 12.0 Team Foundation Server\Tools y ejecute el siguiente comando para actualizar el SID de la cuenta de servicio al nuevo dominio:
```
TFSConfig identities /change /fromdomain:OldComputerorDomainName /todomain:NewDomainName /account:OldTFSServiceAccount /toaccount:NewTFSServiceAccount
```
Advertencia

Si la cuenta de servicio era una cuenta del sistema (como el servicio de red), no se puede migrar directamente porque existe una cuenta del sistema con el mismo nombre en el nuevo entorno. Debe seguir un proceso compuesto por dos etapas. Consulte el ejemplo de Comando de identidades.
Para migrar todas las cuentas con el mismo nombre en el nuevo entorno, ejecute:
```
TFSConfig Identities /change /fromdomain:OldDomainName /todomain:NewDomainName
```
Este lote de comandos procesa las cuentas.
Si el nuevo dominio contiene identidades con nombres diferentes entre entornos, actualice manualmente los SID para cada uno. Por ejemplo, si la cuenta de Christie Church era Fabrikam\CChurch en el entorno antiguo y es NewFabrikam\ChristieC en el nuevo, actualice su SID de la siguiente manera:
```
TFSConfig Identities /change /fromdomain:OldDomainName /todomain:NewDomainName /account:OldAccountName /toaccount:NewAccountName
```

Actualice la cuenta de servicio mediante la ejecución de:

TFSConfig Accounts /change /AccountType:ApplicationTier /account:AccountName /password:Password

Si la implementación usa informes, actualice la cuenta de origen de datos:

TFSConfig Accounts /change /AccountType:ReportingDataSource /account:AccountName /password:Password

Si la implementación usa el servidor proxy de Azure DevOps, actualice la cuenta de servicio de proxy:
```
TFSConfig Accounts /change /AccountType:Proxy /account:AccountName /password:Password
```
Nota:

Si va a pasar a un dominio que no es de confianza, es posible que también tenga que agregar manualmente usuarios y grupos a equipos, proyectos, colecciones y azure DevOps Server. Para más información, consulte Incorporación de usuarios a proyectos, Establecimiento de permisos de administrador para colecciones de proyectos y Establecimiento de permisos de administrador para Azure DevOps Server.
Si la implementación se integra con Project Server, es posible que tenga que realizar otros pasos para configurar cuentas de servicio con los permisos necesarios. Para obtener más información, consulte Asignación de permisos para admitir la integración de TFS-Project Server y Configuración de la integración de TFS-Project Server.

6. Configurar informes y servicios de análisis

Omita este procedimiento si su implementación no utiliza informes.

Si cambió el nombre del servidor de informes durante el traslado, actualice Azure DevOps Server para que apunte a la nueva ubicación del servidor de informes. También debe reiniciar el almacenamiento y volver a generar manualmente la base de datos de Analysis Services.

Abra la consola de administración de Azure DevOps, vaya al nodo Informes y edite la configuración.
Actualice los valores de las tres pestañas para reflejar el nuevo nombre del servidor. Asegúrese de ingresar los datos correctos de la cuenta del origen de datos para el nuevo entorno.
Seleccione Iniciar trabajos para reiniciar los informes.
Seleccione Iniciar recompilación para recompilar el almacenamiento.

7. Configurar copias de seguridad

Si cambió el nombre del recurso compartido de red o el dispositivo de almacenamiento durante el cambio de nombre de dominio, actualice el plan de copia de seguridad programado para hacer referencia a los nuevos recursos.

En la consola de administración, vaya al nodo Copias de seguridad programadas y vuelva a configurar las copias de seguridad programadas para realizar copias de seguridad de las bases de datos de Azure DevOps Server en el nuevo servidor. Para obtener más información, consulte Creación de una programación y un plan de copia de seguridad.

8. Reiniciar servicios

Ahora que actualizó Azure DevOps Server con toda la información del nuevo entorno, para reiniciar los servicios, siga estos pasos:

En el equipo de nivel de aplicación de Azure DevOps Server, abra una ventana del símbolo del sistema con permisos administrativos y cambie los directorios a Drive:\%programfiles%\TFS 12.0\Tools.
Escriba el siguiente comando TFSServiceControl :
```
TFSServiceControl unquiesce
```

Preguntas más frecuentes (preguntas más frecuentes)

P: Quiero cambiar el servidor físico o los servidores para mi implementación, no los dominios. ¿Puedo hacerlo?

A: Sí, esta acción se denomina movimiento basado en hardware y los pasos se proporcionan en Mover o clonar de un hardware a otro. No debe intentar combinar un movimiento basado en entornos con un movimiento basado en hardware. En primer lugar, complete el movimiento de hardware y, a continuación, cambie el entorno.

Last updated on 2025-12-20

Compartir a través de