Cambiar el sufijo DNS de example.com a test.com es una operación crítica que exige preparación, pruebas y una estrategia de coexistencia que elimine cualquier tiempo de inactividad.

Escenario y objetivos

Migrar Active Directory (AD) y las zonas DNS asociadas a un nuevo nombre de dominio implica salvaguardar la continuidad del servicio, conservar los identificadores de seguridad (SIDHistory) y garantizar que cada usuario, equipo y aplicación siga autenticándose sin interrupciones.

Domain Rename vs. Migración cruzada

Con Windows Server 2022 y Azure AD Connect todavía aceptando ADMT v3.2, la opción Domain Rename (renombrado “in place”) suele descartarse en entornos con Exchange Server, ADFS, Lync/Skype for Business, Intune, MDM o aplicaciones sensibles a SPN/UPN. La ruta recomendada en 2025 continúa siendo una migración cruzada entre bosques con confianza bidireccional y ADMT, que permite trabajar en paralelo y revertir en caso de problemas.

Fases de alto nivel

Fase	Objetivo	Acciones principales
Respaldo del entorno actual	Garantizar recuperación ante fallos	Copias de seguridad de System State y volúmenes críticos mediante wbadmin start systemstatebackup. Exportación de zonas DNS: GUI (DNS Manager) o dnscmd /zoneexport example.com example.com.dns. Snapshot de máquinas virtuales y exportación de GPO (Backup-GPO).
Preparar el nuevo dominio	Crear infraestructura paralela	Instalar rol AD Domain Services en un Windows Server limpio. Ejecutar asistente o Install-ADDSForest -DomainName "test.com" para promover el primer DC. Configurar zona DNS primaria integrada en AD para test.com.
Establecer confianza	Capacitar coexistencia y migración gradual	Crear confianza forestal bidireccional: New-ADForestTrust -Name "example.com". Habilitar SID filtering únicamente durante las pruebas; deshabilitarlo (netdom trust /quarantine:no) al iniciar la migración para preservar SIDHistory.
Migrar objetos	Trasladar cuentas y equipos	Instalar AD Migration Tool 3.2 y un SQL Express local. Registrar servidores de origen y destino en ADMT, habilitar opción “Migrate SIDHistory”. Instalar Password Export Server y copiar su clave de cifrado al DC origen. Migrar en lotes: primero grupos, luego usuarios, finalmente equipos y servidores.
Pruebas piloto	Validar antes del “cut‑over”	Seleccionar usuarios representativos (TI, finanzas, producción). Verificar inicio de sesión, itinerancia de perfiles, acceso a archivos, impresoras y aplicaciones corporativas. Medir latencia de autenticación y replicación (repadmin /replsummary).
Ajustes finales de DNS	Redirigir tráfico y retirar el dominio antiguo	Configurar reenvíos condicionales y zonas secundarias temporales. Actualizar registros SRV. Validar con nltest /dsgetdc:test.com. Revisar GPO, scripts de inicio, certificados, SPN y UPN—cambiar sufijos utilizando Set-ADUser y “UPN Suffixes” en Domains and Trusts.

Pasos detallados y mejores prácticas

Respaldo, instantáneas y versiones

Antes de tocar producción, mantén tres copias: una local, otra offline (almacenamiento WORM) y una en la nube. Verifica bare‑metal restore iniciando el asistente de recuperación en un entorno aislado.

Diseño del nuevo bosque

• Nomenclatura: define un NetBIOS coherente (TEST) y decide si mantendrás el mismo sufijo UPN principal o múltiples.
• Sitios y subredes: crea los mismos “Sites & Services” que en el bosque original para evitar autenticaciones intersite inesperadas.
• Controladores de dominio: al menos dos DC por sitio para resistencia a fallos.

Sincronía de tiempo y catálogos globales

Sin un NTP común, Kerberos fallará: configura w32tm /config /manualpeerlist:"ntp1.test.com" y marca un DC por sitio como PDC Emulator de referencia. Habilita Global Catalog en al menos un DC por sitio para acelerar búsquedas.

Migración de usuarios y contraseñas

1. En ADMT, ejecuta “User Account Migration Wizard”.
2. Selecciona opción “Migrate user SIDs to target domain”.
3. Marca “Enable password migration” y detén las cuentas de origen al finalizar para evitar accesos simultáneos.
4. Revisa conflicto de grupos anidados con admt.exe groupmigration /runonce.

Migración de estaciones y servidores

La tarea “Computer Migration” agrega automáticamente la máquina al nuevo dominio, reinicia y actualiza su perfil. Usa directiva Restricted Groups para inyectar administradores locales de TEST\IT‑Support.

Aplicaciones dependientes de SPN

Servicios como SQL Server, IIS, SharePoint y System Center requieren re‑registrar SPN en el nuevo dominio:

setspn -s MSSQLSvc/sql01.test.com:1433 test\sqlsvc

Automatiza con PowerShell y un inventario CMDB para no omitir nada.

Proceso de “cut‑over”

1. Detén la creación automática de cuentas nuevas en example.com.
2. Vuelve a migrar objetos cambiados desde la última ejecución (delta migration).
3. Actualiza DHCP Options 15 & 6 apuntando a test.com y a los nuevos DNS.
4. Modifica GPO de inicio de sesión para usar \\fs01.test.com\NETLOGON.
5. Monitorea el visor de eventos en busca de errores KDCERRSPRINCIPALUNKNOWN.

Post‑migración y retirada del dominio anterior

• Transferir roles FSMO a DCs de test.com con Move-ADDirectoryServerOperationMasterRole.
• Despromover DCs de example.com (Uninstall-ADDSDomainController) y eliminar zonas DNS.
• Deshabilitar confianza y eliminarla cuando todos los objetos estén verificados.
• Mantener los respaldos durante un ciclo de auditoría completo (normalmente 13 meses).

Consideraciones de Azure AD y servicios híbridos

Si empleas Azure AD Connect, cambia primero el sufijo verificado en Azure AD y actualiza las reglas de sincronización. Dependiendo del volumen, podría ser preferible implementar un nuevo inquilino y utilizar cross‑tenant synchronization.

Preguntas frecuentes

¿Cuánto tiempo debería coexistir la confianza?

Lo habitual son 2‑4 semanas, tiempo suficiente para detectar tickets relacionados con autenticación y permisos heredados.

¿Puedo omitir ADMT y hacer un backup/restore de objetos?

No. Restaurar objetos en otro bosque rompe referencias internas y pierde SIDHistory.

¿Qué impacto tiene en certificados?

Plantillas que usan el nombre de dominio deben duplicarse; los certificados existentes permanecen válidos hasta renovar y propagar la nueva CRL.

Conclusión

Una migración de dominio exitosa descansa en el principio de planificar, probar y automatizar. Al seguir la estrategia de confianza cruzada, ADMT y desmantelamiento controlado, obtendrás un bosque limpio, con un nuevo sufijo DNS alineado a la marca corporativa y sin pérdida de seguridad ni productividad.