Entra Connect: la data que t'atura la sincronització i la que només t'envia un correu

Hi ha dues coses de Microsoft damunt la taula de qualsevol que tingui un Active Directory sincronitzat amb Entra ID, i s'estan barrejant. Una és una migració: Microsoft vol moure tothom d'Entra Connect Sync a Entra Cloud Sync, va per onades, t'avisa pel Centre de missatges i admet demanar excepció. L'altra és un tall tècnic amb data: el 30 de setembre del 2026, qualsevol servidor d'Entra Connect per sota de la versió 2.5.79.0 deixa de sincronitzar. Només una de les dues trenca alguna cosa, i no és la que surt als correus.

Quan escrivim això queden poc més de set setmanes per a la primera. Ho expliquem perquè la mateixa conversa se'ns ha repetit diverses vegades aquests dies i sempre comença igual: algú ha rebut l'avís de la migració a Cloud Sync, està avaluant si li encaixa, i ningú no ha mirat en quina versió està el servidor que sincronitza. Són dues feines diferents, amb urgències diferents, i l'ordre correcte és el contrari del que gairebé tothom està seguint.

La data que sí que trenca

Microsoft ha desplegat una aplicació de primera part dedicada a la sincronització entre Active Directory i Entra ID: apareix a aplicacions empresarials com a Microsoft Entra AD Synchronization Service, amb identificador d'aplicació 6bf85cfa-ac8a-4be5-b5de-425a0d0dc016. Aquest canvi de servei viatja a la versió 2.5.79.0 d'Entra Connect, que Microsoft situa el maig del 2025. I la documentació de Microsoft és d'una sequedat poc habitual sobre què passa si no la tens: tots els serveis de sincronització d'Entra Connect Sync fallaran.

No hi ha període de gràcia ni degradació progressiva. Hi ha un matís que convé dir per no inflar l'alarma: això no destrueix res i s'arregla actualitzant, fins i tot després. Però la mateixa nota ho deixa clar —la sincronització estarà caiguda des del 30 de setembre fins al moment en què actualitzis—, i aquest moment, si t'enxampa a l'octubre amb el servidor sense .NET actualitzat, pot trigar dies.

El que s'atura no és el correu

Aquí és on això deixa de ser un avís de manteniment i es converteix en un problema de seguretat, i on la paraula «fallarà» enganya. El que s'atura és el sincronisme, no l'autenticació. Si fas servir sincronització de hash de contrasenyes, els hashos que ja hi ha a Entra ID hi continuen: la gent entrarà al Teams i a la seva bústia l'1 d'octubre sense notar absolutament res —Microsoft no ho afirma per a aquest tall, però la seva pròpia guia de recuperació de desastres del servidor de sincronització fa la pregunta a l'inrevés: si fas servir sincronització de contrasenyes, els usuaris accepten haver d'usar la contrasenya antiga a l'Entra ID quan la canviïn en local? És a dir, es dona per fet que entren—. El que deixa de circular és la comptabilitat de qui existeix.

L'alta que no arriba es nota el mateix dia: el comercial nou no té correu i algú truca. El canvi de contrasenya que no baixa es nota a la primera queixa. La baixa no es nota mai. Si desactives un compte a l'AD el 2 d'octubre perquè aquesta persona ha deixat l'empresa, i la sincronització està aturada, aquest compte continua viu al núvol amb el seu token, les seves aplicacions connectades i el seu accés al SharePoint. Ningú no obrirà un tiquet per avisar-ne. És la fallada silenciosa de manual, i la raó per la qual un model de confiança zero no dona per bona una sessió només perquè existeixi.

És el mateix raonament que vam aplicar quan vam escriure sobre la retirada de l'SMS com a segon factor a Entra: la identitat no es defensa en el moment del login, es defensa en el cicle de vida complet del compte. I el cicle de vida, en un entorn híbrid, viatja per aquest servidor.

El paracaigudes només s'obre si no el necessites

Molta gent respon a això amb «tinc l'autoactualitzador posat, ja s'ho farà». És la resposta raonable i en molts casos és correcta: Microsoft actualitza automàticament on pot. Però hi ha una lletra petita que val la pena llegir dues vegades: perquè l'actualització automàtica funcioni, cal estar ja a la versió 2.3.20.0 o superior.

Llegeix-ho en negatiu i apareix el problema sencer: el mecanisme que et salvaria automàticament no funciona justament als servidors més vells, que són els únics que tenen el problema. El que està a la 2.4 no necessitava la teva ajuda. El que no s'ha tocat des del 2019, que és el que s'aturarà el 30 de setembre, és el que no la rebrà. El paracaigudes només s'obre si no anaves a caure.

I hi ha dos requisits més que en un servidor antic són el bloqueig real, no la versió: .NET Framework 4.7.2 i TLS 1.2. En una màquina que ningú no ha tocat en anys, cap de les dues coses no es resol a la finestra de manteniment de dimarts. Aquesta és la feina que cal començar aquesta setmana i no a l'última: comprovar versió, comprovar .NET, comprovar TLS. Deu minuts per servidor.

L'altra data: la que t'envia un correu

A l'abril del 2026, Microsoft va publicar com a «plan for change» l'arrencada de la transició d'Entra Connect Sync a Entra Cloud Sync. Val la pena citar el detall que més tranquil·litza i que gairebé ningú no ha llegit: a les primeres onades se centren en els tenants per als quals Cloud Sync ja cobreix totes les necessitats i, textualment, si la teva organització depèn de funcions avançades o té un directori gran, no seràs als primers grups. Les onades següents arribaran a mesura que Cloud Sync guanyi capacitats.

Les preguntes freqüents oficials van encara més enllà i diuen dues coses que convé tenir a mà quan algú de direcció arribi amb el correu a la mà i cara d'urgència. Una: si no pots migrar dins la finestra recomanada, se sol·licita una excepció i, si s'aprova, continues amb la teva configuració actual mentre planifiques. I la segona, que és la frase clau: no estàs obligat a migrar fins que les funcions de les quals depens estiguin disponibles a Cloud Sync. No hi ha data de retirada anunciada per a Connect Sync. Això no és un termini, és una cua.

La taula que decideix de debò

Microsoft publica una comparativa de més de trenta capacitats entre les dues eines. La majoria són en paritat —usuaris, grups i contactes, sincronització de hash de contrasenyes, escriptura de contrasenyes, atributs híbrids d'Exchange, extensions de directori, filtratge per unitat organitzativa, SSO integrat— i aquí no hi ha res a discutir. El que decideix són dos números i vuit caselles.

Els dos números són els límits d'escala de Cloud Sync: 150.000 objectes per domini i 50.000 membres per grup. Connect Sync no té el primer i admet grups de fins a 250.000 membres. Per calibrar: 150.000 objectes per domini deixa fora molt poques empreses de les que atenem a Catalunya, i alhora és un sostre real per a universitats, cadenes de retail i grups industrials amb anys d'objectes acumulats. Si estàs per sota, aquesta fila no és la teva conversa.

Les vuit caselles són les files on Connect Sync posa un sí i Cloud Sync posa un no. Ordenades per la probabilitat que siguin el teu problema, no per l'ordre de la taula:

• Sincronització de dispositius. La que decideix en la majoria de casos. Hi tornem més avall.
• Regles de sincronització avançades. Cloud Sync fa servir un constructor d'expressions; el motor de regles complexes de Connect no hi és.
• Configuració de l'autenticació de pas a través. Compte amb el matís, perquè espanta més del que ha d'espantar: el que falta és la configuració des de l'eina de sincronització. L'autenticació de pas a través i l'SSO integrat es configuren a part i, segons Microsoft, continuen funcionant després de migrar.
• Configuració de la integració amb AD FS. Fila diferent de l'anterior a la taula, no la mateixa: la federació es configura amb altres eines, mai des del client de sincronització.
• Referències entre boscos. Relacions entre objectes de boscos diferents. Cloud Sync sí que admet boscos desconnectats, que és una altra cosa i aquí guanya.
• Fusionar atributs de diversos dominis. El clàssic de les empreses que van créixer comprant-ne d'altres i mai no van consolidar.
• Reconciliació. Correcció de sincronització fora de banda. Cloud Sync té aprovisionament sota demanda, que serveix per validar, no per al mateix.
• Escriptura de dispositius. Descontinuada a favor de Cloud Kerberos Trust. Aquí no hi ha debat: és la direcció del producte.

Fora d'aquestes vuit hi ha una novena fila que convé mirar i que no és un no: el filtratge per atribut, on la taula posa «limitat». Si filtres per unitat organitzativa, no t'afecta. Convé dir també què fa Cloud Sync i Connect no, perquè una comparativa que només mira els forats d'un menteix per omissió: boscos desconnectats sense consolidar-los, diversos agents actius alhora amb commutació automàtica —Connect Sync és un únic punt de fallada i això s'acaba—, aprovisionament de grups des del núvol cap a l'AD, aprovisionament sota demanda per provar un usuari solt, i tota la configuració al portal sense necessitat de VPN ni d'entrar al servidor.

La fila que decideix: els portàtils

De les vuit, la que segons la nostra experiència mana és la primera. Si els teus equips estan units al domini local i a més registrats a l'Entra ID —el que se'n diu unió híbrida—, aquesta unió depèn avui que l'objecte de l'equip se sincronitzi des de l'AD. Cloud Sync no sincronitza dispositius. Aquesta sola casella decideix la resposta d'una part enorme d'empreses espanyoles de cent a mil empleats, que és just el perfil que, per mida de directori, entraria a les primeres onades de la migració.

Hi ha una sortida en camí i cal explicar-la amb l'etiqueta posada. Al març del 2026 Microsoft va publicar en vista prèvia la unió híbrida mitjançant Entra Kerberos: l'equip queda unit en el moment de l'aprovisionament, sense esperar la sincronització d'Entra Connect i sense AD FS. Si això arriba a disponibilitat general, aquesta fila deixa de bloquejar ningú. Però és vista prèvia, i una vista prèvia no es posa al camí crític de dos-cents portàtils que han d'arrencar dilluns. La nostra recomanació aquí és avorrida a propòsit: apunta-ho, segueix-ho, i no hi planifiquis.

Quan Cloud Sync ja és la decisió correcta

Per a una part gran de les empreses que atenem, Cloud Sync no és un mal menor que cal empassar-se: és millor eina avui. El perfil és concret i es comprova en una tarda: un bosc, sincronització de hash de contrasenyes, filtratge per unitat organitzativa, sense regles personalitzades heretades, molt per sota de 150.000 objectes, i equips gestionats des de l'Intune sense unió híbrida al domini. Si t'hi reconeixes, l'argument decisiu no és que Microsoft ho demani: és que deixes de tenir un únic servidor del qual penja que les altes i les baixes arribin al núvol.

I hi ha una peça que gairebé ningú no fa servir i que ordena el camí: des del gener del 2026 està en disponibilitat general el canvi de font d'autoritat per objecte. Permet passar usuaris concrets d'estar sincronitzats des de l'AD a ser comptes gestionats al núvol, un a un, sense deixar d'operar la sincronització per a la resta. Ho suporten les dues eines. Serveix per al mateix de sempre en una migració: fer-la a trossos, amb la gent que menys fa mal si alguna cosa surt estranya, en comptes d'un cap de setmana amb tot a dins.

Tres maneres de complicar-se la vida

• Fer servir la migració a Cloud Sync com a drecera per arribar al 30 de setembre. És la temptació evident —«si me'n vaig a Cloud Sync, m'oblido de la versió»— i és un error de seqüència: canvies una feina d'una tarda per un projecte, i durant aquest projecte el servidor de Connect continua allà, perquè la mateixa guia el deixa en mode preparació per poder validar i tornar enrere. Actualitza primer. Migra després, amb calendari i sense data aliena a sobre.
• Deixar les dues eines treballant sobre els mateixos objectes «un temps, per si de cas». Executar Connect Sync i Cloud Sync alhora sobre els mateixos objectes no és compatible. La convivència es fa per unitats organitzatives: cadascuna la gestiona una sola eina. No és una recomanació d'estil, és la condició perquè la prova pilot signifiqui alguna cosa.
• Tractar el servidor de sincronització com un servidor més. És la peça que decideix qui existeix al teu núvol i qui deixa d'existir. Quan vam escriure sobre l'auditoria del teu AD CS, el fil era el mateix: els sistemes que governen la identitat no van a l'inventari al costat dels servidors de fitxers. Aquest entra en aquesta llista, amb la seva fitxa, el seu propietari i la seva versió anotada.

Què fer aquesta setmana

Obre l'assistent d'Entra Connect, mira la versió i compara-la amb 2.5.79.0. Si estàs per sota, comprova el .NET Framework i el TLS 1.2 abans de tocar res, perquè aquí hi ha la feina real. Després, i només després, seu amb la taula de comparació i marca les teves vuit caselles: gairebé segur que la resposta te la dona la primera. És el mateix mètode que vam proposar amb el tancament d'EWS a l'Exchange Online —inventari primer, termini després— perquè les dates de Microsoft no venen d'una en una. I un matís que estalvia fer la feina dues vegades: 2.5.79.0 és el mínim, no la destinació. Aquesta versió deixa d'estar suportada el 23 d'octubre del 2026, tres setmanes després del tall, i arrossega una nota del mateix fabricant que demana no fer servir el Synchronization Service Manager mentre la tinguis. Ves a l'última, no al mínim.

Tot això —identitat, dispositius i el pegament entre l'oficina i el núvol— és el que muntem i operem a lloc de treball modern. Si tens un servidor d'Entra Connect i no saps en quina versió està, escriu-nos i ho mirem amb tu.