Entra Connect Sync aggiornamento obbligatorio settembre 2026: perché 2.5.79.0 è l'obiettivo sbagliato

Cosa dice davvero la scadenza dell'aggiornamento obbligatorio Entra Connect Sync settembre 2026

L'aggiornamento obbligatorio Entra Connect Sync settembre 2026 è un blocco totale del servizio, non un semplice richiamo della policy di supporto. Microsoft lo dichiara testualmente nella pagina Microsoft Entra Connect: cronologia delle versioni (pagina datata 7 luglio 2026), e ripete la stessa formulazione nella pagina delle linee guida per l'aggiornamento:

Aggiornamento obbligatorio richiesto: tutti i servizi di sincronizzazione di Microsoft Entra Connect Sync smetteranno di funzionare il 30 settembre 2026 se non si utilizza almeno la versione 2.5.79.0. A maggio 2025 abbiamo rilasciato questa versione con una modifica del servizio back-end che rafforza i nostri servizi.

La frase successiva elimina ogni ambiguità sulla modalità di guasto: "Se non è possibile eseguire l'aggiornamento prima della scadenza, tutti i servizi di sincronizzazione andranno in errore finché non si effettua l'aggiornamento all'ultima versione."

Nello stesso riquadro ci sono due dettagli operativi facili da trascurare. Il file .msi di Connect Sync è ora disponibile esclusivamente tramite l'interfaccia di amministrazione di Microsoft Entra, non più dal Download Center. E il programma di installazione continua a imporre i prerequisiti di base: .NET Framework 4.7.2 e TLS 1.2.

Vale la pena segnalare un'incoerenza, perché trarrà in inganno chiunque incroci i dati con il proprio inventario. Il banner afferma che la 2.5.79.0 è stata rilasciata "a maggio 2025", ma la voce sullo stato di rilascio della stessa pagina per la 2.5.79.0 riporta "09/01/2025: rilasciata per il download tramite l'interfaccia di amministrazione di Microsoft Entra", e la tabella di dismissione data la fine del supporto della 2.5.76.0 come "01 settembre 2026 (12 mesi dopo il rilascio della 2.5.79.0)". La soglia di versione è il dato operativo; il mese di rilascio indicato nel banner non corrisponde al resto della pagina.

Perché la 2.5.79.0 è la versione sbagliata a cui aggiornare

Leggendo il titolo alla lettera, la mossa ovvia sarebbe installare esattamente la 2.5.79.0, spuntare la casella e andare avanti. La stessa pagina Learn mostra perché questo garantisce solo 23 giorni e non un anno.

La policy di dismissione di Microsoft per Connect Sync è relativa alla versione, non al calendario: "Le versioni di Microsoft Entra Connect Sync 2.x vengono dismesse 12 mesi dopo la data di rilascio di una versione più recente. Questa policy è in vigore dal 15 marzo 2023." Da allora sono state rilasciate diverse build più recenti della 2.5.79.0, quindi il suo conto alla rovescia è già partito ed è quasi terminato:

Un amministratore che esegue l'aggiornamento alla soglia minima obbligatoria supera il blocco totale del 30 settembre e poi esce dal supporto il 23 ottobre 2026, ventitré giorni dopo. La riga adiacente è ancora più netta: la 2.5.76.0 viene dismessa il 01 settembre 2026, un mese prima del blocco totale, quindi un server che si trova una build sotto la soglia minima è già fuori supporto nel momento in cui il servizio lo interrompe.

Altri tre motivi per cui il minimo è l'obiettivo sbagliato:

• La 2.5.79.0 presenta un difetto noto dell'interfaccia utente. Microsoft ripete la stessa nota per le versioni 2.5.3.0, 2.5.76.0, 2.5.79.0 e 2.5.190.0: "Non utilizzare l'interfaccia di Synchronization Service Manager in questa versione. Farlo potrebbe causare il fallimento della procedura guidata di Microsoft Entra Connect e del rinnovo automatico dei certificati. Questo problema è stato risolto nella versione 2.6.1.0." Il difetto è presente in tutte le build precedenti alla 2.6.1.0, quindi aggiornare alla soglia minima non permette di evitarlo.
• La build attuale include correzioni di sicurezza. La 2.6.84.0, rilasciata il 07/07/2026, è contrassegnata come "Questa versione include correzioni di sicurezza. Consigliamo di aggiornare a questa versione il prima possibile", e il relativo changelog include "Risolte molteplici vulnerabilità di sicurezza nelle dipendenze di terze parti incluse."
• Non installare la 2.6.79.0. Microsoft l'ha ritirata: "La versione 2.6.79.0 non è più disponibile per il download. Dopo il rilascio è stato individuato un problema e il programma di installazione è stato ritirato. I clienti che avevano installato questa versione devono disinstallarla e installare l'ultima versione disponibile (2.6.84.0) di Microsoft Entra Connect Sync."

Chi è realmente a rischio: la trappola dei requisiti per l'aggiornamento automatico

L'interpretazione intuitiva è che siano esposti solo gli amministratori che hanno disattivato deliberatamente l'aggiornamento automatico. Le regole di idoneità documentate dicono il contrario. Secondo Microsoft Entra Connect: aggiornamento automatico, l'aggiornamento automatico è abilitato per impostazione predefinita solo quando tutte le seguenti condizioni sono soddisfatte:

• Installazione con impostazioni Express o aggiornamento da DirSync
• SQL Express LocalDB, che è quanto utilizzano sempre le impostazioni Express
• L'account AD è l'account predefinito MSOL_ creato dalle impostazioni Express o da DirSync
• Meno di 100.000 oggetti nel metaverse

Questo è il profilo tipico di un tenant piccolo. Una distribuzione aziendale tipica - installazione personalizzata, SQL Server completo, un account connettore dedicato, un numero di oggetti a sei cifre - non ha mai avuto l'aggiornamento automatico attivo fin dall'inizio. Sono proprio questi i server che si stanno avvicinando alla deriva verso il 30 settembre, e nessuno ha disattivato nulla per arrivarci.

Microsoft pubblica le condizioni specifiche che rendono un server non idoneo, ciascuna delle quali emerge come una stringa di risultato con un nome specifico:

Esiste una trappola più sottile per i tenant che utilizzano effettivamente l'aggiornamento automatico. L'aggiornamento automatico distribuisce solo le build che Microsoft rilascia su quel canale, e le note di rilascio indicano quali sono: la 2.6.1.0 e la 2.6.3.0 dichiarano entrambe che l'aggiornamento automatico sposterà le installazioni esistenti su quella build, mentre l'attuale 2.6.84.0 riporta soltanto "Rilasciata per il download tramite l'interfaccia di amministrazione di Microsoft Entra." Un server con aggiornamento automatico funzionante si troverà quindi molto probabilmente sulla 2.6.3.0 - ben oltre il blocco totale, ma non sulla build che include le correzioni di sicurezza di luglio 2026. La stessa Microsoft inquadra così il compromesso: "La versione con aggiornamento automatico potrebbe non includere le funzionalità più recenti."

Altri due fattori sospendono silenziosamente l'aggiornamento automatico. Lasciare aperta l'interfaccia di Synchronization Service Manager sul server lo mette in pausa ("l'aggiornamento viene sospeso finché l'interfaccia non viene chiusa"), e bloccare a livello di proxy gli URL di Microsoft Entra Connect Health lo interrompe del tutto, perché l'aggiornamento automatico si appoggia sull'infrastruttura Health.

Rilevamento: verificare la versione e lo stato dell'aggiornamento automatico

Non fidatevi del CMDB. Verificate direttamente ogni server Connect Sync, compresi i server di staging, che sono soggetti alla scadenza esattamente quanto quello attivo.

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

La coppia di versioni conta più di ciascun numero preso singolarmente. Le indicazioni di risoluzione dei problemi di Microsoft per un server che si comporta in modo anomalo dopo un aggiornamento automatico - KB 4038479, il cui elenco di sintomi è limitato alle build legacy 1.x ma la cui descrizione del meccanismo di aggiornamento è generica - sono esplicite: "Durante l'aggiornamento automatico, l'installazione corrente di Microsoft Entra Connect viene aggiornata, e successivamente viene aggiornata la versione nella configurazione del server. Se le due versioni non corrispondono, Microsoft Entra Connect è aggiornato solo parzialmente." Un server che riporta una versione installata conforme insieme a un Microsoft.Synchronize.ServerConfigurationVersion non aggiornato non ha completato l'operazione e non deve essere considerato come risolto. Dalla stessa pagina provengono anche il controllo SchedulerSuspended e il percorso del log SyncEngine-AutoUpgrader.

Il filtro sul log eventi è il modo più rapido per individuare i server che tentano l'aggiornamento senza successo da mesi: filtrate il log Applicazione sull'origine Microsoft Entra Connect Upgrade e sull'intervallo di ID evento 300-399. I codici di risultato con prefisso UpgradeAborted sono transitori e vengono ritentati. I codici con prefisso UpgradeNotSupported significano, nelle parole di Microsoft, che "ci si aspetta che il sistema debba essere aggiornato manualmente."

Correzione: scegliere il percorso di aggiornamento, poi evitarne la trappola

Microsoft documenta tre strategie di aggiornamento. Scegliete in base al numero di server e alla deriva della configurazione, non per comodità.

1. Aggiornamento automatico. Praticabile solo per le installazioni Express ancora idonee. Nessun intervento manuale richiesto, ma la build su cui si atterra può essere in ritardo rispetto a quella attuale.

2. Aggiornamento in loco (in-place). Microsoft lo definisce "preferibile quando si dispone di un singolo server e di meno di circa 100.000 oggetti", e ne dichiara chiaramente il compromesso: "Se si verifica un problema durante l'aggiornamento in loco, non è possibile ripristinare la versione o la configurazione precedente ..." Due aspetti da pianificare:

• Se le regole di sincronizzazione predefinite sono cambiate tra le build, in seguito viene eseguita un'importazione completa e una sincronizzazione completa. "Questa esecuzione potrebbe richiedere alcune ore, a seconda del numero di oggetti nell'ambito del motore di sincronizzazione." Durante questa fase la sincronizzazione delta è sospesa; la sincronizzazione delle password continua.
• Se voi avete modificato le regole di sincronizzazione predefinite, "tali regole vengono riportate alla configurazione predefinita durante l'aggiornamento."

Per spostare la sincronizzazione completa fuori dall'orario lavorativo, deselezionate Avvia il processo di sincronizzazione al termine della configurazione durante l'aggiornamento, quindi ispezionate e ripulite gli override registrati:

Get-ADSyncSchedulerConnectorOverride | Format-List

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

Set-ADSyncScheduler -SyncCycleEnabled $true

Eseguite l'importazione completa e la sincronizzazione completa rimandate alla prima occasione utile. Ometterle definitivamente lascia la nuova configurazione non applicata agli oggetti esistenti.

3. Migrazione swing. Si crea il nuovo server in parallelo, lo si verifica, quindi lo si promuove. Microsoft la indica come l'"Approccio più sicuro e transizione più fluida verso una versione più recente", segnala che "la sincronizzazione non viene interrotta e non comporta rischi per la produzione", e fornisce un criterio chiaro per sceglierla: i clienti che non hanno eseguito l'aggiornamento da 12-18 mesi "dovrebbero invece considerare un aggiornamento swing, poiché è l'opzione più prudente e meno rischiosa." È inoltre il percorso supportato quando il sistema operativo Windows Server deve essere sostituito, poiché gli aggiornamenti in loco del sistema operativo sono supportati solo da Server 2016, 2019 o 2022 verso Server 2025.

Se effettuate una migrazione swing, dismettete completamente il vecchio server. La modalità di guasto è silenziosa e lenta: un server di sincronizzazione rimasto attivo "potrebbe non essere più in grado di accedere ad Active Directory locale ... ma può comunque connettersi a Microsoft Entra ID e causare il ripristino continuo dei valori degli attributi a ogni ciclo di sincronizzazione."

Due difetti da verificare al momento dell'aggiornamento

File miiserver.exe.config modificato. Nelle versioni 2.5.190.0 e 2.6.1.0, se questo file era stato precedentemente modificato - solitamente seguendo indicazioni precedenti per supportare la sincronizzazione degli hash delle password in ambienti con FIPS abilitato - l'aggiornamento lo lascia invariato e la sincronizzazione va quindi in errore con System.IO.FileLoadException: Could not load file or assembly 'System.Diagnostics.DiagnosticSource, Version=6.0.0.1'. La soluzione documentata consiste nell'eseguire il backup del file in %programfiles%\Microsoft Azure AD Sync\Bin, aggiungere il reindirizzamento del binding all'interno della sezione assemblyBinding e riavviare il servizio 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 versione 2.6.84.0 risolve la causa principale: il relativo changelog riporta che l'aggiornamento automatico ora "unisce le modifiche del cliente con la nuova configurazione e convalida il risultato prima di applicarlo" invece di sovrascrivere il file.

Connettori non standard. Se utilizzate il connettore Generic LDAP o Generic SQL, aggiornate la configurazione del connettore in Synchronization Service Manager dopo un aggiornamento in loco. Se saltate questo passaggio, i passaggi di esecuzione di importazione ed esportazione si interrompono con un errore "Assembly version in AAD Connector configuration ... is earlier than the actual version" nel log eventi dell'applicazione.

La questione Cloud Sync

Microsoft ora apre la propria pagina di aggiornamento con un suggerimento: "Invece di aggiornare all'ultima versione di Microsoft Entra Connect, verificate se cloud sync fa al caso vostro." Si tratta di un'opzione legittima, e le due soluzioni possono coesistere nella stessa foresta. Prima di impegnarvi, però, consultate la tabella degli scenari supportati: cloud sync non supporta il join ibrido di Microsoft Entra, Windows Hello for Business, domini con più di 250.000 oggetti, il filtraggio degli oggetti di directory in base ai valori degli attributi, né la topologia con account utente in una foresta e caselle di posta in una foresta di risorse.

Cosa si blocca realmente il 1° ottobre

"Tutti i servizi di sincronizzazione andranno in errore" ha un raggio d'impatto più ampio di un semplice ciclo di sincronizzazione in pausa, perché Connect Sync è il canale di trasporto per diverse funzioni che non sono ovviamente legate alla "sincronizzazione".

• La sincronizzazione degli hash delle password smette di aggiornarsi. PHS è, nelle parole di Microsoft, "un'estensione della funzionalità di sincronizzazione della directory implementata da Microsoft Entra Connect Sync." Le modifiche alle password on-premises smettono di raggiungere il tenant, per cui gli utenti continuano ad autenticarsi con hash sempre più obsoleti.
• Il rilevamento delle credenziali trapelate diventa obsoleto per gli account ibridi. La stessa pagina afferma che "Password Hash Sync abilita anche il rilevamento delle credenziali trapelate per i vostri account ibridi." Senza un flusso di hash aggiornati, le corrispondenze vengono valutate rispetto a password che potrebbero già essere state cambiate on-premises - e gli utenti a rischio che nessuno risolve sono già l'anello debole di questa catena.
• Il processo joiner-mover-leaver si arresta al confine del tenant. Questo è l'aspetto rilevante per la sicurezza. La disattivazione o l'eliminazione di un account in AD on-premises non si propaga più, quindi l'identità cloud continua a funzionare per tutta la durata dell'interruzione, e ogni uscita avvenuta durante quella finestra temporale diventa un account orfano ma ancora abilitato. Questo è esattamente il punto cieco della sincronizzazione dell'identità ibrida che emerge come rilievo di audit mesi dopo.
• L'appartenenza ai gruppi si blocca. Le modifiche ai gruppi on-premises smettono di determinare l'accesso al cloud, compresa l'appartenenza ai gruppi usati per l'assegnazione dei ruoli o per l'ambito dell'accesso condizionale.

Trattate il 30 settembre come un evento di governance dell'identità, non solo come un evento di disponibilità del servizio. Non è nemmeno l'unico cambiamento Entra con una data precisa in corso - la modifica sui soli metodi registrati per SSPR del 9 novembre 2026 arriva circa sei settimane dopo.

Come EtcSec rileva questo problema

Un Connect Sync bloccato o aggiornato solo parzialmente non si manifesta da sé nel tenant. Si presenta come deriva dell'identità, ed è proprio questo che un audit può individuare. I controlli Azure di EtcSec rilevano esattamente questa classe di deriva: HYBRID_ORPHANED_CLOUD_USER segnala gli utenti ibridi ancora contrassegnati come sincronizzati on-premises ma lasciati disabilitati in Entra ID, HYBRID_CLOUD_ONLY_PRIVILEGED individua gli utenti solo cloud che detengono ruoli privilegiati al di fuori della governance Tier 0 on-premises, UNRESOLVED_PRIVILEGED_MEMBERS segnala le assegnazioni di ruoli privilegiati che puntano a principali non più risolvibili, e PA_ADMIN_STALE_ACCOUNT rileva le assegnazioni di ruoli di amministratore detenute da utenti che non hanno effettuato l'accesso per un periodo prolungato.

Sul versante on-premises, lo stesso audit copre gli account privilegiati e di servizio che una sincronizzazione interrotta lascia silenziosamente isolati, e si inserisce nel tipo di workflow di audit ripetibile che individua la deriva tra una scadenza e l'altra invece che dopo. Sul versante del tenant, si integra nella stessa revisione di sicurezza di Entra ID che dovreste già eseguire su accesso condizionale, MFA e assegnazioni dei ruoli.