Solución al error de instalación de un segundo Azure AD Connect (Entra Connect) en modo Staging

¿Tu intento de agregar un segundo servidor de Microsoft Entra Connect (Azure AD Connect) en modo staging se detiene con errores de conector y autenticación? A continuación encontrarás una guía paso a paso para identificar la causa—habitualmente la ausencia de TLS 1.2—y corregirla de forma definitiva.

Resumen del problema

Al lanzar el asistente de Azure AD Connect 2.3 para configurar un servidor secundario en modo staging, la tarea Configure AAD Sync muestra mensajes como:

• Creation of connector <tenant>.onmicrosoft.com – AAD failed. This may be due to replication delay
• An error occurred while sending the request
• MSALThrottledUiRequiredException / AADSTS50173 durante la creación de la cuenta de servicio

Aunque el texto hace referencia a una “replicación”, los comandos repadmin y el Visor de eventos no reportan problemas de Active Directory. El síntoma real es la imposibilidad de establecer conexiones seguras hacia Azure AD porque el sistema operativo o .NET no negocian TLS 1.2.

Causa raíz: TLS 1.2 deshabilitado

Desde la versión 2.0, Azure AD Connect requiere exclusivamente TLS 1.2. Si el protocolo no está activo:

1. Las peticiones HTTPS que crean el conector de metadatos y la cuenta de sincronización se rechazan.
2. El asistente interpreta el rechazo como un problema de replicación o un error transitorio y se detiene.
3. En el archivo %ProgramData%\AADConnect\AADConnectConfigErrors.log se registran excepciones System.Net.Http.HttpRequestException y Microsoft.Identity.Client.MsalServiceException.

Activar TLS 1.2 a nivel de sistema y de .NET framework resuelve el 99 % de los casos documentados.

Pasos de solución

Paso	Acción	Detalles
1	Habilitar TLS 1.2 en Windows y .NET	Regedit → agregue o verifique los DWORD (valor 1): HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SystemDefaultTlsVersions HKLM\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319\SystemDefaultTlsVersions HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SchUseStrongCrypto HKLM\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319\SchUseStrongCrypto Confirme además que existen y están habilitados: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server Enabled = 1 Así forzarás que WinHTTP y .NET negocien directamente TLS 1.2 sin retroceder a versiones antiguas.
2	Reiniciar el servidor	Reinicia el sistema o, al menos, los servicios ADSync, Winmgmt y Netlogon para que las claves de registro surjan efecto. Evita probar la instalación antes de reiniciar.
3	Ejecutar de nuevo el instalador en modo Staging	Vuelve a lanzar AzureADConnect.msi, selecciona “Staging mode” y completa el asistente. El conector onmicrosoft.com – AAD y la cuenta de servicio deberían crearse sin excepciones MSAL.

Validaciones posteriores

Si el problema persiste tras habilitar TLS 1.2, revisa los puntos siguientes antes de abrir un caso de soporte:

• Conectividad HTTPS: desde PowerShell ejecuta Test-NetConnection login.microsoftonline.com -Port 443. La columna TcpTestSucceeded debe ser True.
• Sincronía de reloj: una desviación superior a 5 min provocará AADSTS50008 (token expirado). Comprueba NTP.
• Proxy corporativo: define las variables de entorno HTTPSPROXY/NOPROXY si usas un proxy autenticado.
• Puertos internos: asegúrate de que el servidor secundario alcance al primario por SQL (MSSQL 1433) si comparten base.

Buenas prácticas al desplegar servidores Entra Connect en modo Staging

Mantener la configuración en espejo

Tras una instalación exitosa, importa la configuración del servidor activo ejecutando en la consola de Azure AD Connect:

Export-ADSyncServerConfiguration -Path C:\BackupConfig

En el nuevo servidor importa con:

Import-ADSyncServerConfiguration -Path C:\BackupConfig -SynchronizationOption Initial

Plan de failover

Mantén el servidor secundario desconectado (staging) hasta que el primario falle o requiera mantenimiento. Para invertir roles basta con:

1. Desactivar el modo staging en el secundario.
2. Activarlo en el primario.
3. Forzar Start-ADSyncSyncCycle -PolicyType Delta en el nuevo activo.

Actualizaciones coordinadas

Aplica rollups y nuevas versiones primero en el servidor pasivo. Si la prueba es satisfactoria, repite en el activo y vuelve a intercambiar roles. Reducirás al mínimo el downtime.

Monitoreo

Habilita Azure AD Connect Health en ambos nodos; incluso en modo staging recopila métricas de latencia, error rate de CS y estado del motor de sincronización.

Preguntas frecuentes (FAQ)

¿Puedo instalar Azure AD Connect 2.x en Windows Server 2012 R2?

No. La versión 2.x requiere como mínimo Windows Server 2016 con .NET Framework 4.8.

¿Necesito desinstalar la versión antigua antes de probar la nueva?

No. El instalador detecta una versión 1.x y procede a migrar configuraciones y la base SQL LocalDB. Sin embargo, para un entorno de pruebas se recomienda una VM limpia.

¿El modo staging replica contraseñas mientras está pasivo?

Sí. El servidor sincroniza datos en su base local pero no exporta cambios a Azure AD. Cuando pasa a modo activo publica inmediatamente los objetos más recientes.

¿TLS 1.3 es compatible?

Actualmente Azure AD Connect no fuerza TLS 1.3. Si el sistema lo negocia, funcionará; de lo contrario, caerá a TLS 1.2.

Conclusión

La mayoría de los errores que aparecen durante la creación de un segundo servidor de Azure AD Connect en modo staging se deben a la falta de TLS 1.2. Con solo cuatro claves de registro y un reinicio desbloquearás el proceso, obtendrás redundancia para la sincronización híbrida y habilitarás un camino seguro de actualización y failover sin impacto para los usuarios.