Entra Connect Sync actualización obligatoria septiembre 2026: por qué 2.5.79.0 es el objetivo equivocado

Qué dice realmente el plazo de la actualización obligatoria de Entra Connect Sync de septiembre de 2026

El plazo de la actualización obligatoria de Entra Connect Sync de septiembre de 2026 es una interrupción total del servicio, no un simple recordatorio de política de soporte. Microsoft lo indica textualmente en la página Microsoft Entra Connect: historial de versiones (fecha de la página: 7 de julio de 2026), y repite la misma redacción en la página de orientación sobre la actualización:

Actualización obligatoria requerida: Todos los servicios de sincronización de Microsoft Entra Connect Sync dejarán de funcionar el 30 de septiembre de 2026 si no estás al menos en la versión 2.5.79.0. En mayo de 2025 publicamos esta versión con un cambio en el servicio de back-end que refuerza nuestros servicios.

La frase siguiente elimina cualquier ambigüedad sobre el modo de fallo: "Si no puedes actualizar antes del plazo, todos los servicios de sincronización fallarán hasta que actualices a la última versión."

Dos detalles operativos en el mismo recuadro son fáciles de pasar por alto. El .msi de Connect Sync ahora está disponible exclusivamente desde el centro de administración de Microsoft Entra, no desde el Centro de descargas. Y el instalador sigue exigiendo los requisitos previos de referencia: .NET Framework 4.7.2 y TLS 1.2.

Vale la pena señalar una inconsistencia, porque hará tropezar a cualquiera que esté verificando su inventario. El aviso dice que 2.5.79.0 se publicó "en mayo de 2025", pero la entrada de estado de lanzamiento de la misma página para 2.5.79.0 dice "01/09/2025: publicado para descarga a través del centro de administración de Microsoft Entra", y la tabla de retirada fecha el fin de soporte de 2.5.76.0 como "01 de septiembre de 2026 (12 meses después del lanzamiento de 2.5.79.0)". El mínimo de versión es el hecho operativo; el mes de lanzamiento indicado en el aviso no coincide con el resto de la página.

Por qué 2.5.79.0 es la versión equivocada a la que actualizar

Si se lee el titular de forma literal, el movimiento obvio es instalar exactamente la 2.5.79.0, marcar la casilla y seguir adelante. La misma página de Learn muestra por qué eso solo compra 23 días, no un año.

La política de retirada de Microsoft para Connect Sync es relativa a la versión, no al calendario: "Las versiones de Microsoft Entra Connect Sync 2.x se retiran 12 meses después de la fecha en que se publica una versión más reciente. Esta política entró en vigor el 15 de marzo de 2023." Desde 2.5.79.0 se han publicado varios builds más recientes, así que su reloj ya se ha puesto en marcha y está a punto de agotarse:

Un administrador que actualiza al mínimo obligatorio supera el corte forzoso del 30 de septiembre y luego queda fuera de soporte el 23 de octubre de 2026, veintitrés días después. La fila adyacente es aún más contundente: 2.5.76.0 deja de tener soporte el 01 de septiembre de 2026, un mes antes del corte forzoso, así que un servidor que se queda un build por debajo del mínimo ya está sin soporte cuando el servicio lo corta.

Hay tres razones más por las que el mínimo es el destino equivocado:

• 2.5.79.0 se publica con un defecto de interfaz conocido. Microsoft repite la misma nota en 2.5.3.0, 2.5.76.0, 2.5.79.0 y 2.5.190.0: "No uses la interfaz de Synchronization Service Manager en esta versión. Hacerlo puede provocar que el asistente de Microsoft Entra Connect y la renovación automática de certificados fallen. Este problema está corregido en la versión 2.6.1.0." El defecto acompaña a todos los builds por debajo de 2.6.1.0, así que actualizar al mínimo no lo evita.
• El build actual incluye correcciones de seguridad. 2.6.84.0, publicada el 07/07/2026, está marcada como "Esta versión incluye correcciones de seguridad. Recomendamos actualizar a esta versión lo antes posible", y su registro de cambios incluye "Corregidas múltiples vulnerabilidades de seguridad en dependencias de terceros incluidas."
• No instales la 2.6.79.0. Microsoft la retiró: "La versión 2.6.79.0 ya no está disponible para descarga. Se identificó un problema tras el lanzamiento y el instalador fue retirado. Los clientes que hayan instalado esta versión deben desinstalarla e instalar la última versión disponible (2.6.84.0) de Microsoft Entra Connect Sync."

Quién está realmente en riesgo: la trampa de elegibilidad de la actualización automática

La lectura intuitiva es que solo están expuestos los administradores que desactivaron deliberadamente la actualización automática. Las reglas de elegibilidad documentadas dicen lo contrario. Según Microsoft Entra Connect: actualización automática, la actualización automática está habilitada de forma predeterminada únicamente cuando se cumplen todas las condiciones siguientes:

• Instalación con configuración exprés o una actualización desde DirSync
• SQL Express LocalDB, que es lo que siempre usa la configuración exprés
• La cuenta de AD es la cuenta MSOL_ predeterminada creada por la configuración exprés o DirSync
• Menos de 100.000 objetos en el metaverso

Ese es el perfil de un tenant pequeño. Una implementación empresarial típica -instalación personalizada, SQL Server completo, una cuenta de conector dedicada, cifras de seis dígitos en objetos- nunca tuvo la actualización automática activada en primer lugar. Esos son los servidores que van a la deriva hacia el 30 de septiembre, y nadie desactivó nada para llegar ahí.

Microsoft publica las condiciones específicas que hacen que un servidor no sea elegible, cada una de las cuales aparece como una cadena de resultado con nombre:

Hay una trampa más sutil para los tenants que sí tienen la actualización automática activada. La actualización automática solo entrega los builds que Microsoft publica en ese canal, y las notas de la versión indican cuáles son: 2.6.1.0 y 2.6.3.0 indican cada una que la actualización automática moverá las instalaciones existentes a ese build, mientras que la actual 2.6.84.0 dice únicamente "Publicada para descarga a través del centro de administración de Microsoft Entra." Por tanto, un servidor sano con actualización automática probablemente se encuentra en la versión 2.6.3.0: cómodamente por delante del corte forzoso, pero no en el build que incorpora las correcciones de seguridad de julio de 2026. El propio planteamiento de Microsoft sobre esta disyuntiva: "Es posible que la versión de actualización automática no incluya las funciones más recientes."

Otras dos cosas suspenden silenciosamente la actualización automática. Dejar abierta la interfaz de Synchronization Service Manager en el servidor la pausa ("la actualización se suspende hasta que se cierra la interfaz"), y bloquear en el proxy las URL de Microsoft Entra Connect Health la rompe por completo, porque la actualización automática depende de la infraestructura de Health.

Detección: confirma tu versión y el estado de tu actualización automática

No confíes en la CMDB. Comprueba cada servidor de Connect Sync directamente, incluidos los servidores en staging, que están tan sujetos al plazo como el servidor activo.

Get-ADSyncAutoUpgrade
Get-ADSyncAutoUpgrade -Detail
(Get-ADSyncGlobalSettings).Parameters | Select-Object Name,Value
Get-ADSyncScheduler

El par de versiones importa más que cualquiera de los dos números por separado. La guía de solución de problemas de Microsoft para un servidor que se comporta mal tras una actualización automática -KB 4038479, cuya lista de síntomas está limitada a builds heredados 1.x pero cuya descripción del mecanismo de actualización es genérica- es explícita: "Durante la actualización automática, se actualiza la instalación actual de Microsoft Entra Connect y, a continuación, se actualiza la versión en la configuración del servidor. Si las dos versiones no coinciden, Microsoft Entra Connect solo se actualiza parcialmente." Un servidor que reporta una versión instalada conforme junto con un Microsoft.Synchronize.ServerConfigurationVersion desactualizado no ha terminado el trabajo, y no debe contarse como remediado. La misma página es de donde provienen la comprobación de SchedulerSuspended y la ruta del registro SyncEngine-AutoUpgrader.

El filtro del registro de eventos es la forma más rápida de encontrar servidores que llevan meses intentándolo y fallando: filtra el registro de la aplicación por el origen Microsoft Entra Connect Upgrade y el rango de ID de evento 300-399. Los códigos de resultado con el prefijo UpgradeAborted son transitorios y se reintentan. Los códigos con el prefijo UpgradeNotSupported significan, en palabras de Microsoft, que "se espera que el sistema deba actualizarse manualmente."

Remediación: elige la ruta de actualización y luego evita su trampa

Microsoft documenta tres estrategias de actualización. Elige según el número de servidores y la desviación de configuración, no según la comodidad.

1. Actualización automática. Solo es viable para instalaciones con configuración exprés que siguen siendo elegibles. No requiere intervención manual, pero el build en el que aterrizas puede ir por detrás del actual.

2. Actualización in situ (in-place). Microsoft la denomina "preferida cuando tienes un único servidor y menos de unos 100.000 objetos", y expone la contrapartida sin rodeos: "Si surge un problema durante la actualización in situ, no puedes revertir la nueva versión ni la configuración ..." Hay dos cosas que planificar:

• Si las reglas de sincronización predeterminadas cambiaron entre builds, después se ejecuta una importación completa y una sincronización completa. "Esta ejecución puede tardar varias horas, según el número de objetos dentro del alcance del motor de sincronización." La sincronización delta se suspende durante ese proceso; la sincronización de contraseñas continúa.
• Si tú modificaste las reglas de sincronización predeterminadas, "estas reglas se restablecen a la configuración predeterminada durante la actualización."

Para posponer la sincronización completa a horas fuera de servicio, desmarca Iniciar el proceso de sincronización cuando se complete la configuración durante la actualización, y luego inspecciona y borra las anulaciones registradas:

Get-ADSyncSchedulerConnectorOverride | Format-List

foreach ($connectorOverride in Get-ADSyncSchedulerConnectorOverride)
{
    Set-ADSyncSchedulerConnectorOverride -ConnectorIdentifier $connectorOverride.ConnectorIdentifier.Guid -FullSyncRequired $false -FullImportRequired $false
}

Set-ADSyncScheduler -SyncCycleEnabled $true

Ejecuta la importación completa y la sincronización completa aplazadas en cuanto tengas ocasión. Omitirlas de forma permanente deja la nueva configuración sin aplicar a los objetos existentes.

3. Migración swing. Construye el nuevo servidor en paralelo, verifícalo y luego promuévelo. Microsoft lo presenta como el "enfoque más seguro y una transición más fluida a una versión más reciente", señala que "la sincronización no se interrumpe y no supone un riesgo para producción", y da un desencadenante claro para elegirlo: los clientes que no han actualizado en 12-18 meses "deberían considerar una actualización swing en su lugar, ya que es la opción más conservadora y de menor riesgo." También es la ruta compatible cuando hay que sustituir el sistema operativo Windows Server, ya que las actualizaciones in situ del SO solo son compatibles desde Server 2016, 2019 o 2022 hacia Server 2025.

Si haces swing, desmantela por completo el servidor antiguo. El modo de fallo es silencioso y lento: un servidor de sincronización que queda atrás "puede que ya no pueda acceder a Active Directory local ... pero aun así puede conectarse a Microsoft Entra ID y provocar que los valores de atributo reviertan continuamente en cada ciclo de sincronización."

Dos defectos en el momento de la actualización que hay que comprobar

miiserver.exe.config modificado. En 2.5.190.0 y 2.6.1.0, si ese archivo se había editado previamente -habitualmente siguiendo indicaciones anteriores para admitir la sincronización de hash de contraseñas en entornos con FIPS habilitado-, la actualización lo deja intacto y la sincronización falla entonces con System.IO.FileLoadException: Could not load file or assembly 'System.Diagnostics.DiagnosticSource, Version=6.0.0.1'. La solución documentada consiste en respaldar el archivo en %programfiles%\Microsoft Azure AD Sync\Bin, añadir la redirección de enlace (binding redirect) dentro de la sección assemblyBinding, y reiniciar el servicio ADSync:

<dependentAssembly>
  <assemblyIdentity name="System.Diagnostics.DiagnosticSource" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-8.0.0.0" newVersion="8.0.0.0" />
</dependentAssembly>

La versión 2.6.84.0 aborda la causa raíz: su registro de cambios indica que la actualización automática ahora "combina las modificaciones del cliente con la nueva configuración y valida el resultado antes de aplicarlo" en lugar de sobrescribir el archivo.

Conectores no estándar. Si utilizas el conector genérico LDAP o el conector genérico SQL, actualiza la configuración del conector en Synchronization Service Manager después de una actualización in situ. Si te lo saltas, los pasos de ejecución de importación y exportación fallarán con un error "Assembly version in AAD Connector configuration ... is earlier than the actual version" en el registro de eventos de la aplicación.

La pregunta sobre Cloud Sync

Microsoft ahora abre su propia página de actualización con una sugerencia: "En lugar de actualizar a la última versión de Microsoft Entra Connect, comprueba si cloud sync es adecuado para ti." Es una opción legítima, y ambas pueden ejecutarse en el mismo bosque en paralelo. Aun así, comprueba la tabla de escenarios compatibles antes de comprometerte: cloud sync no admite la unión híbrida de Microsoft Entra, Windows Hello for Business, dominios con más de 250.000 objetos, el filtrado de objetos de directorio por valores de atributo, ni la topología de cuentas de usuario en un bosque con buzones en un bosque de recursos.

Qué se rompe realmente el 1 de octubre

"Todos los servicios de sincronización fallarán" tiene un radio de impacto más amplio que un ciclo de sincronización en pausa, porque Connect Sync es el transporte de varias cosas que no son obviamente "sincronización".

• La sincronización de hash de contraseñas deja de actualizarse. PHS es, en palabras de Microsoft, "una extensión de la función de sincronización de directorios implementada por Microsoft Entra Connect Sync." Los cambios de contraseña en local dejan de llegar al tenant, así que los usuarios siguen autenticándose contra hashes cada vez más desactualizados.
• La detección de credenciales filtradas queda obsoleta para las cuentas híbridas. La misma página indica que "Password Hash Sync también habilita la detección de credenciales filtradas para tus cuentas híbridas." Sin un flujo de hashes actualizado, las coincidencias se evalúan contra contraseñas que quizá ya se hayan rotado en local -y los usuarios de riesgo que nadie remedia ya son el eslabón débil de esa cadena.
• El proceso de alta-cambio-baja se detiene en el límite del tenant. Este es el relevante desde el punto de vista de seguridad. Deshabilitar o eliminar una cuenta en el AD local ya no se propaga, así que la identidad en la nube sigue funcionando mientras dure la interrupción, y cada baja durante esa ventana se convierte en una cuenta huérfana pero todavía habilitada. Ese es precisamente el punto ciego de la sincronización de identidad híbrida que sale a la luz meses después como hallazgo de auditoría.
• La pertenencia a grupos se congela. Los cambios de grupos en local dejan de impulsar el acceso en la nube, incluida la pertenencia a grupos usados para la asignación de roles o el alcance del acceso condicional.

Trata el 30 de septiembre como un evento de gobernanza de identidad, no solo de disponibilidad. Tampoco es el único cambio de Entra con fecha límite en curso: el cambio a solo métodos registrados de SSPR del 9 de noviembre de 2026 llega aproximadamente seis semanas después.

Cómo lo detecta EtcSec

Un Connect Sync bloqueado o parcialmente actualizado no se anuncia a sí mismo en el tenant. Se manifiesta como desviación de identidad, y eso es lo que una auditoría puede detectar. Las comprobaciones de Azure de EtcSec identifican exactamente este tipo de desviación: HYBRID_ORPHANED_CLOUD_USER señala usuarios híbridos que siguen marcados como sincronizados desde on-premises pero que están deshabilitados en Entra ID, HYBRID_CLOUD_ONLY_PRIVILEGED detecta usuarios exclusivamente en la nube que tienen roles privilegiados fuera de la gobernanza de Tier 0 en local, UNRESOLVED_PRIVILEGED_MEMBERS reporta asignaciones de roles privilegiados que apuntan a principales que ya no se pueden resolver, y PA_ADMIN_STALE_ACCOUNT detecta asignaciones de roles de administrador en manos de usuarios que no han iniciado sesión durante un periodo prolongado.

En el lado local, la misma auditoría cubre las cuentas privilegiadas y de servicio que una sincronización rota deja varadas en silencio, y encaja en el tipo de flujo de auditoría repetible que detecta la desviación entre plazos en lugar de después de ellos. En el lado del tenant, se integra en la misma revisión de seguridad de Entra ID que ya deberías estar ejecutando sobre acceso condicional, MFA y asignaciones de roles.