Entra Connect: la fecha que te para la sincronización y la que solo te manda un correo

Hay dos cosas de Microsoft encima de la mesa de cualquiera que tenga un Active Directory sincronizado con Entra ID, y se están mezclando. Una es una migración: Microsoft quiere mover a todo el mundo de Entra Connect Sync a Entra Cloud Sync, va por olas, te avisa por el Centro de mensajes y admite pedir excepción. La otra es un corte técnico con fecha: el 30 de septiembre de 2026, cualquier servidor de Entra Connect por debajo de la versión 2.5.79.0 deja de sincronizar. Solo una de las dos rompe algo, y no es la que está saliendo en los correos.

Cuando escribimos esto quedan poco más de siete semanas para la primera. Lo contamos porque la misma conversación se nos ha repetido varias veces estos días y siempre empieza igual: alguien ha recibido el aviso de la migración a Cloud Sync, está evaluando si le encaja, y nadie ha mirado en qué versión está el servidor que sincroniza. Son dos trabajos distintos, con urgencias distintas, y el orden correcto es el contrario del que casi todo el mundo está siguiendo.

La fecha que sí rompe

Microsoft ha desplegado una aplicación de primera parte dedicada a la sincronización entre Active Directory y Entra ID: aparece en aplicaciones empresariales como Microsoft Entra AD Synchronization Service, con identificador de aplicación 6bf85cfa-ac8a-4be5-b5de-425a0d0dc016. Ese cambio de servicio viaja en la versión 2.5.79.0 de Entra Connect, que Microsoft sitúa en mayo de 2025. Y la documentación de Microsoft es de una sequedad poco habitual sobre lo que pasa si no la tienes: todos los servicios de sincronización de Entra Connect Sync fallarán.

No hay periodo de gracia ni degradación progresiva. Hay un matiz que conviene decir para no inflar la alarma: esto no destruye nada y se arregla actualizando, incluso después. Pero la propia nota lo deja claro —la sincronización estará caída desde el 30 de septiembre hasta el momento en que actualices—, y ese momento, si te pilla en octubre con el servidor sin .NET actualizado, puede tardar días.

Lo que se para no es el correo

Aquí es donde esto deja de ser un aviso de mantenimiento y se convierte en un problema de seguridad, y donde la palabra «fallará» engaña. Lo que se detiene es el sincronismo, no la autenticación. Si usas sincronización de hash de contraseñas, los hashes que ya están en Entra ID siguen ahí: la gente entrará en Teams y en su buzón el 1 de octubre sin notar absolutamente nada —Microsoft no lo afirma para este corte, pero su propia guía de recuperación ante desastres del servidor de sincronización hace la pregunta al revés: si usas sincronización de contraseñas, ¿aceptan los usuarios tener que usar la contraseña antigua en Entra ID cuando la cambien en local? Es decir, se da por hecho que entran—. Lo que deja de circular es la contabilidad de quién existe.

El alta que no llega se nota el mismo día: el comercial nuevo no tiene correo y alguien llama. El cambio de contraseña que no baja se nota a la primera queja. La baja no se nota nunca. Si desactivas una cuenta en el AD el 2 de octubre porque esa persona ha dejado la empresa, y la sincronización está parada, esa cuenta sigue viva en la nube con su token, sus aplicaciones conectadas y su acceso a SharePoint. Nadie va a abrir un ticket para avisar de eso. Es el fallo silencioso de manual, y la razón por la que un modelo de confianza cero no da por buena una sesión solo porque exista.

Es el mismo razonamiento que aplicamos cuando escribimos sobre la retirada del SMS como segundo factor en Entra: la identidad no se defiende en el momento del login, se defiende en el ciclo de vida completo de la cuenta. Y el ciclo de vida, en un entorno híbrido, viaja por ese servidor.

El paracaídas solo se abre si no lo necesitas

Mucha gente contesta a esto con «tengo el autoactualizador puesto, ya se apañará». Es la respuesta razonable y en muchos casos es correcta: Microsoft actualiza automáticamente donde puede. Pero hay una letra pequeña que vale la pena leer dos veces: para que la actualización automática funcione, hay que estar ya en la versión 2.3.20.0 o superior.

Léelo en negativo y aparece el problema entero: el mecanismo que te salvaría automáticamente no funciona precisamente en los servidores más viejos, que son los únicos que tienen el problema. El que está en 2.4 no necesitaba tu ayuda. El que lleva desde 2019 sin tocarse, que es el que se va a parar el 30 de septiembre, es el que no la va a recibir. El paracaídas solo se abre si no ibas a caerte.

Y hay dos requisitos más que en un servidor antiguo son el bloqueo real, no la versión: .NET Framework 4.7.2 y TLS 1.2. En una máquina que nadie ha tocado en años, ninguna de las dos cosas se resuelve en la ventana de mantenimiento del martes. Ese es el trabajo que hay que empezar esta semana y no en la última: comprobar versión, comprobar .NET, comprobar TLS. Diez minutos por servidor.

La otra fecha: la que te manda un correo

En abril de 2026, Microsoft publicó como «plan for change» el arranque de la transición de Entra Connect Sync a Entra Cloud Sync. Merece la pena citar el detalle que más tranquiliza y que casi nadie ha leído: en las primeras olas se centran en los tenants para los que Cloud Sync ya cubre todas las necesidades y, textualmente, si tu organización depende de funciones avanzadas o tiene un directorio grande, no estarás en los primeros grupos. Las siguientes olas llegarán a medida que Cloud Sync gane capacidades.

Las preguntas frecuentes oficiales van todavía más lejos y dicen dos cosas que conviene tener a mano cuando alguien de dirección llegue con el correo en la mano y cara de urgencia. Una: si no puedes migrar dentro de la ventana recomendada, se solicita una excepción y, si se aprueba, sigues con tu configuración actual mientras planificas. Dos, y es la frase clave: no estás obligado a migrar hasta que las funciones de las que dependes estén soportadas en Cloud Sync. No hay fecha de retirada anunciada para Connect Sync. Esto no es un plazo, es una cola.

La tabla que decide de verdad

Microsoft publica una comparativa de más de treinta capacidades entre las dos herramientas. La mayoría están en paridad —usuarios, grupos y contactos, sincronización de hash de contraseñas, escritura de contraseñas, atributos híbridos de Exchange, extensiones de directorio, filtrado por unidad organizativa, SSO integrado— y ahí no hay nada que discutir. Lo que decide son dos números y ocho casillas.

Los dos números son los límites de escala de Cloud Sync: 150.000 objetos por dominio y 50.000 miembros por grupo. Connect Sync no tiene el primero y admite grupos de hasta 250.000 miembros. Para calibrar: 150.000 objetos por dominio deja fuera a muy pocas empresas de las que atendemos en Cataluña, y a la vez es un techo real para universidades, cadenas de retail y grupos industriales con años de objetos acumulados. Si estás por debajo, esta fila no es tu conversación.

Las ocho casillas son las filas donde Connect Sync pone un sí y Cloud Sync pone un no. Ordenadas por la probabilidad de que sean tu problema, no por el orden de la tabla:

• Sincronización de dispositivos. La que decide en la mayoría de casos. Volvemos abajo sobre ella.
• Reglas de sincronización avanzadas. Cloud Sync usa un constructor de expresiones; el motor de reglas complejas de Connect no está.
• Configuración de la autenticación de paso a través. Ojo con el matiz, porque asusta más de lo que debe: lo que no está es la configuración desde la herramienta de sincronización. La autenticación de paso a través y el SSO integrado se configuran aparte y, según Microsoft, siguen funcionando después de migrar.
• Configuración de la integración con AD FS. Fila distinta de la anterior en la tabla, no la misma: la federación se configura con otras herramientas, nunca desde el cliente de sincronización.
• Referencias entre bosques. Relaciones entre objetos de bosques distintos. Cloud Sync sí soporta bosques desconectados, que es otra cosa distinta y ahí gana.
• Fusionar atributos de varios dominios. El clásico de las empresas que crecieron comprando otras y nunca consolidaron.
• Reconciliación. Corrección de sincronización fuera de banda. Cloud Sync tiene aprovisionamiento bajo demanda, que sirve para validar, no para lo mismo.
• Escritura de dispositivos. Descontinuada a favor de Cloud Kerberos Trust. Aquí no hay debate: es la dirección del producto.

Fuera de esas ocho hay una novena fila que conviene mirar y que no es un no: el filtrado por atributo, donde la tabla pone «limitado». Si filtras por unidad organizativa, no te afecta. Conviene decir también lo que Cloud Sync hace y Connect no, porque una comparativa que solo mira los huecos de uno miente por omisión: bosques desconectados sin consolidarlos, varios agentes activos a la vez con conmutación automática —Connect Sync es un único punto de fallo y esto se acaba—, aprovisionamiento de grupos desde la nube hacia el AD, aprovisionamiento bajo demanda para probar un usuario suelto, y toda la configuración en el portal sin necesidad de VPN ni de entrar al servidor.

La fila que decide: los portátiles

De las ocho, la que en nuestra experiencia manda es la primera. Si tus equipos están unidos al dominio local y además registrados en Entra ID —lo que se llama unión híbrida—, esa unión depende hoy de que el objeto del equipo se sincronice desde el AD. Cloud Sync no sincroniza dispositivos. Esa sola casilla decide la respuesta de una parte enorme de empresas españolas de cien a mil empleados, que es justo el perfil que, por tamaño de directorio, entraría en las primeras olas de la migración.

Hay una salida en camino y hay que contarla con su etiqueta puesta. En marzo de 2026 Microsoft publicó en vista previa la unión híbrida mediante Entra Kerberos: el equipo queda unido en el momento del aprovisionamiento, sin esperar a la sincronización de Entra Connect y sin AD FS. Si eso llega a disponibilidad general, esta fila deja de bloquear a nadie. Pero es vista previa, y una vista previa no se pone en el camino crítico de doscientos portátiles que tienen que arrancar el lunes. Nuestra recomendación aquí es aburrida a propósito: anótalo, síguelo, y no planifiques con ello.

Cuándo Cloud Sync ya es la decisión correcta

Para una parte grande de las empresas que atendemos, Cloud Sync no es un mal menor que hay que tragarse: es mejor herramienta hoy. El perfil es concreto y se comprueba en una tarde: un bosque, sincronización de hash de contraseñas, filtrado por unidad organizativa, sin reglas personalizadas heredadas, muy por debajo de 150.000 objetos, y equipos gestionados desde Intune sin unión híbrida al dominio. Si te reconoces ahí, el argumento decisivo no es que Microsoft lo pida: es que dejas de tener un único servidor del que cuelga que las altas y las bajas lleguen a la nube.

Y hay una pieza que casi nadie usa y que ordena el camino: desde enero de 2026 está en disponibilidad general el cambio de fuente de autoridad por objeto. Permite pasar usuarios concretos de estar sincronizados desde el AD a ser cuentas gestionadas en la nube, uno a uno, sin dejar de operar la sincronización para el resto. Lo soportan las dos herramientas. Sirve para lo de siempre en una migración: hacerla por trozos, con la gente que menos duele si algo sale raro, en vez de un fin de semana con todo dentro.

Tres maneras de complicarse la vida

• Usar la migración a Cloud Sync como atajo para llegar al 30 de septiembre. Es la tentación evidente —«si me voy a Cloud Sync, me olvido de la versión»— y es un error de secuencia: cambias un trabajo de una tarde por un proyecto, y durante ese proyecto el servidor de Connect sigue ahí, porque la propia guía lo deja en modo preparación para poder validar y volver atrás. Actualiza primero. Migra después, con calendario y sin fecha ajena encima.
• Dejar las dos herramientas trabajando sobre los mismos objetos «un tiempo, por si acaso». Ejecutar Connect Sync y Cloud Sync a la vez sobre los mismos objetos no está soportado. La convivencia se hace por unidades organizativas: cada una la gestiona una sola herramienta. No es una recomendación de estilo, es la condición para que la prueba piloto signifique algo.
• Tratar el servidor de sincronización como un servidor más. Es la pieza que decide quién existe en tu nube y quién deja de existir. Cuando escribimos sobre la auditoría de tu AD CS, el hilo era el mismo: los sistemas que gobiernan la identidad no van al inventario junto a los servidores de ficheros. Este entra en esa lista, con su ficha, su dueño y su versión anotada.

Qué hacer esta semana

Abre el asistente de Entra Connect, mira la versión y compárala con 2.5.79.0. Si estás por debajo, comprueba .NET Framework y TLS 1.2 antes de tocar nada, porque ahí está el trabajo real. Después, y solo después, siéntate con la tabla de comparación y marca tus ocho casillas: casi seguro que la respuesta te la da la primera. Es el mismo método que propusimos con el cierre de EWS en Exchange Online —inventario primero, plazo después— porque las fechas de Microsoft no vienen de una en una. Y un matiz que ahorra hacer el trabajo dos veces: 2.5.79.0 es el mínimo, no el destino. Esa versión deja de estar soportada el 23 de octubre de 2026, tres semanas después del corte, y arrastra una nota del propio fabricante que pide no usar el Synchronization Service Manager mientras la tengas. Ve a la última, no al mínimo.

Todo esto —identidad, dispositivos y el pegamento entre la oficina y la nube— es lo que montamos y operamos en puesto de trabajo moderno. Si tienes un servidor de Entra Connect y no sabes en qué versión está, escríbenos y lo miramos contigo.