¿Quieres mover todo el poder de tu Directorio Activo a la nube sin encontrarte con usuarios duplicados ni cortes de servicio? En esta guía exhaustiva aprenderás a preparar, ejecutar y validar la sincronización entre un bosque on‑premises y Microsoft Entra ID paso a paso, con mejores prácticas y comandos listos para copiar.

Contexto del proyecto

Una compañía que ya utiliza Power BI Cloud necesita que sus identidades corporativas permanezcan alineadas entre su Directorio Activo on‑premises y Entra ID (antes Azure AD). El reto es que los sufijos UPN internos terminan en .local, mientras que las cuentas existentes en la nube usan un dominio público. Probar Azure AD Connect sin planificar provocó la creación de objetos duplicados, originando confusión entre los administradores y desconcierto en los usuarios finales.

Problemas habituales antes de sincronizar

• UPN no enrutable: sufijos .local o .corp impiden iniciar sesión en servicios M365.
• Usuarios duplicados: aparecen porque la nube no reconoce que el objeto on‑premises es el mismo.
• Dependencias de aplicaciones: algunos sistemas legados guardan el UPN como clave primaria.
• Miedo al cambio: modificar identificadores críticos genera resistencia en TI y en el negocio.

Resumen de la estrategia

Para sincronizar sin duplicados debes:

1. Auditar dónde se usa el UPN interno.
2. Agregar un sufijo UPN público al bosque.
3. Actualizar los UPN locales con un plan piloto.
4. Verificar el dominio público en Entra ID.
5. Configurar mS‑DS‑ConsistencyGuid como Source Anchor.
6. Reinstalar o reconfigurar Azure AD Connect con soft‑match.
7. Validar la primera sincronización y depurar errores.
8. Completar la migración de todos los usuarios y grupos.
9. Habilitar supervisión continua y alertas.

Procedimiento detallado

Paso	Acción	Detalles clave
1	Comprobar dependencias del UPN .local	Inventaria aplicaciones que autentiquen con UPN. Revisa bases de datos y scripts que almacenen direcciones @dominio.local. Define acciones de actualización o exclusión por cada sistema detectado.
2	Agregar un sufijo UPN público	Abre Active Directory Domains and Trusts. Haz clic derecho en el nodo principal » Properties. En “Alternate UPN Suffixes” agrega contoso.com.
3	Actualizar gradualmente los UPN locales	Crea un grupo piloto de usuarios voluntarios. Ejecuta un script PowerShell: Get-ADUser -Filter * -SearchBase "OU=Piloto,DC=contoso,DC=local" | Set-ADUser -UserPrincipalName {"$($_.SamAccountName)@contoso.com"} El sAMAccountName no cambia, por lo que los inicios de sesión locales siguen funcionando.
4	Verificar dominio en Entra ID	Entra ID » Custom domain names » Add. Agrega contoso.com, crea registros TXT, espera estado Verified.
5	Planificar ancla y coincidencia	Ejecuta en cada DC: Import-Module ADPreview Set-ADSyncAADObject -EnableConsistencyGuid $true El atributo mS‑DS‑ConsistencyGuid se rellenará automáticamente y actuará como identificador inmutable en la nube.
6	Instalar/Reconfigurar Azure AD Connect	Descarga el instalador más reciente. Selecciona Customize, no Express. Elige Password Hash Sync salvo requerir ADFS. Activa Match using soft‑match. En Attribute Filtering excluye cuentas de servicio y objetos obsoletos.
7	Ejecutar sincronización inicial	Cuando finalice la instalación, usa el siguiente cmdlet en el servidor AD Connect: Start-ADSyncSyncCycle -PolicyType Initial Valida en el portal que los usuarios piloto aparecen con Source of Authority = Windows Server AD.
8	Cambiar el resto de UPNs	Expande el cambio a cada OU en lotes controlados. Envía comunicaciones a los usuarios con la nueva forma de inicio de sesión. Actualiza plantillas de correo automático y sistemas ERP/CRM si almacenaban el UPN.
9	Habilitar sincronización continua	Instala el agente Azure AD Connect Health. Configura alertas por correo y Teams para fallos de sincronización. Revisa el panel de Health semanalmente.

Preguntas frecuentes

Cambiar el UPN romperá mis aplicaciones internas o SaaS?

Depende de cómo cada aplicación almacene las identidades:

• Las que usan exclusivamente sAMAccountName (la mayoría de servicios Windows) no se ven afectadas.
• Aplicaciones que guardan el UPN como texto deben actualizarse o mapear el nuevo valor.
• Servicios SaaS modernos (SharePoint Online, Teams, Exchange Online) requieren un UPN con dominio enrutado, por lo que la actualización es inevitable para una experiencia homogénea.

Puedo mantener el UPN .local y aún así iniciar sesión en la nube?

Es posible habilitar Alternate Sign‑In ID o un “User Sign‑In Configuration” especial, pero añade complejidad operativa, genera excepciones de soporte y no es la vía recomendada por Microsoft. Migrar a un UPN público simplifica la administración y reduce incidencias.

Qué hacer si ya tengo usuarios duplicados?

1. Anota el UserPrincipalName correcto para cada duplicado en la nube.
2. Ejecuta:
   Set-MsolUser -UserPrincipalName usuario@contoso.onmicrosoft.com ` -ImmutableId $null
3. Fuerza un ciclo completo de sincronización. La cuenta local y la nube se fusionarán.

Buenas prácticas adicionales

• Versiona tu configuración: guarda un export settings de Azure AD Connect antes de cada cambio.
• Prueba en laboratorio: clona el bosque y levanta un tenant de pruebas para ensayar la migración.
• Avisa con antelación: alinear TI, Help Desk y usuarios es clave para una transición fluida.
• Automatiza reportes: usa Graph API o cmdlets MSOnline para generar listas de objetos con errores.
• Plan de reversión: documenta cómo deshacer la última sincronización o pausar el scheduler si surge un fallo crítico.

Ventajas y riesgos de la metodología

Ventajas	Riesgos mitigables
Un único conjunto de credenciales para todos los servicios. Inicio de sesión con dominio público: experiencia coherente en M365, Intune y Power BI. Objetos fusionados sin interrupción gracias al soft‑match. Cumplimiento de prácticas recomendadas de Microsoft.	Impacto en aplicaciones que usan el UPN; se mitiga con auditoría previa y pruebas piloto. Ventana de mantenimiento necesaria; se minimiza con lotes fuera de horario laboral. Necesidad de capacitación a usuarios sobre el nuevo formato de inicio de sesión.

Scripts útiles

Obtener tamaño real del batch antes de cada oleada

$OU = "OU=Usuarios,DC=contoso,DC=local"
Get-ADUser -Filter * -SearchBase $OU |
Where-Object {$_.UserPrincipalName -like "*.local"} |
Select-Object Name,SamAccountName,UserPrincipalName |
Export-Csv C:\Reportes\UsuariosPendientes.csv -NoTypeInformation

Forzar ciclo Delta tras cada oleada

Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Delta

Resolución de problemas comunes

• Error “Duplicate Attribute”: indica conflicto en ImmutableId. Libera el atributo en la nube y resincroniza.
• El servicio Connector se detiene: revisa espacio en disco, actualiza TLS 1.2 y reinicia el servicio ADSync.
• Usuario ve su antiguo UPN en Teams: Teams almacena caché; cerrar sesión y borrar %AppData%\Microsoft\Teams.
• Eventos ID 611: fallos al aplicar reglas; exporta configuración, reinstala AD Connect y vuelve a importar.

Checklist de validación final

1. Todas las cuentas tienen UPN público y estado “Sincronizado”.
2. No existen objetos _onmicrosoft.com#EXT# innecesarios.
3. Power BI Service muestra la misma lista de grupos AAD que on‑premises.
4. Los informes agendados continúan enviándose sin error.
5. Azure AD Connect Health no muestra alertas críticas.

Conclusión

Migrar de UPN .local a un dominio verificado y aprovechar mS‑DS‑ConsistencyGuid como ancla inmutable es la fórmula que Microsoft respalda para consolidar identidades y sacar el máximo partido a la nube sin sobresaltos. Con una fase piloto bien planificada, validaciones automáticas y supervisión proactiva, el riesgo operacional disminuye y la empresa gana trazabilidad, seguridad y agilidad para proyectos tan estratégicos como la adopción completa de Power BI.