Entra Connect Sync Atualização Obrigatória de Setembro de 2026: Por Que a 2.5.79.0 É o Alvo Errado

O Que o Prazo da Entra Connect Sync Atualização Obrigatória de Setembro de 2026 Realmente Diz

O prazo da atualização obrigatória do Entra Connect Sync em setembro de 2026 é uma parada total do serviço, não um lembrete de política de suporte. A Microsoft afirma isso literalmente na página Microsoft Entra Connect: histórico de versões (data da página: 7 de julho de 2026) e repete o mesmo texto na página de orientação de atualização:

Atualização obrigatória necessária: Todos os serviços de sincronização do Microsoft Entra Connect Sync deixarão de funcionar em 30 de setembro de 2026 se você não estiver, no mínimo, na versão 2.5.79.0. Em maio de 2025, lançamos essa versão com uma mudança de serviço de back-end que reforça a segurança dos nossos serviços.

A frase seguinte elimina qualquer ambiguidade sobre o modo de falha: "Se você não conseguir atualizar antes do prazo, todos os serviços de sincronização falharão até que você atualize para a versão mais recente."

Dois detalhes operacionais no mesmo aviso são fáceis de passar despercebidos. O .msi do Connect Sync agora está disponível exclusivamente na central de administração do Microsoft Entra, não mais no Download Center. E o instalador continua exigindo os pré-requisitos básicos: .NET Framework 4.7.2 e TLS 1.2.

Vale destacar uma inconsistência, pois ela vai confundir quem cruzar seu inventário com a documentação. O aviso diz que a 2.5.79.0 foi lançada "em maio de 2025", mas a entrada de status de lançamento dessa mesma versão, na mesma página, diz "09/01/2025: Lançada para download via central de administração do Microsoft Entra", e a tabela de fim de vida data o fim de suporte da 2.5.76.0 como "01 de setembro de 2026 (12 meses após o lançamento da 2.5.79.0)". O piso de versão é o fato operativo; o mês de lançamento citado no aviso não bate com o restante da página.

Por Que a 2.5.79.0 É a Versão Errada Para Atualizar

Lendo o título ao pé da letra, o movimento óbvio é instalar exatamente a 2.5.79.0, marcar a caixinha e seguir em frente. A mesma página do Learn mostra por que isso compra apenas 23 dias, não um ano.

A política de fim de vida da Microsoft para o Connect Sync é relativa à versão, não ao calendário: "Versões do Microsoft Entra Connect Sync 2.x saem de suporte 12 meses após a data de lançamento de uma versão mais nova. Essa política entrou em vigor em 15 de março de 2023." Vários builds mais novos já foram lançados desde a 2.5.79.0, então o relógio dela já começou a contar e está quase no fim:

Um administrador que atualiza para o piso obrigatório passa pela parada total de 30 de setembro e depois sai de suporte em 23 de outubro de 2026, vinte e três dias depois. A linha vizinha é ainda mais dura: a 2.5.76.0 sai de suporte em 01 de setembro de 2026, um mês antes da parada total - ou seja, um servidor um build abaixo do piso já está sem suporte quando o serviço o desliga.

Mais três razões pelas quais o mínimo é o destino errado:

• A 2.5.79.0 tem um defeito de interface conhecido. A Microsoft repete a mesma observação nas versões 2.5.3.0, 2.5.76.0, 2.5.79.0 e 2.5.190.0: "Não use a interface do Synchronization Service Manager nesta versão. Fazer isso pode causar falhas no assistente do Microsoft Entra Connect e na renovação automática de certificados. Esse problema foi corrigido na versão 2.6.1.0." O defeito acompanha todo build abaixo da 2.6.1.0, então atualizar para o piso não escapa dele.
• O build atual traz correções de segurança. A 2.6.84.0, lançada em 07/07/2026, é sinalizada como "Este lançamento inclui correções de segurança. Recomendamos atualizar para esta versão o quanto antes", e seu changelog inclui "Corrigidas múltiplas vulnerabilidades de segurança em dependências de terceiros incluídas."
• Não instale a 2.6.79.0. A Microsoft a recolheu: "A versão 2.6.79.0 não está mais disponível para download. Um problema foi identificado após o lançamento e o instalador foi recolhido. Clientes que instalaram essa versão devem desinstalá-la e instalar a versão mais recente disponível (2.6.84.0) do Microsoft Entra Connect Sync."

Quem Está Realmente em Risco: a Armadilha da Elegibilidade para Atualização Automática

A leitura intuitiva é que só administradores que desativaram deliberadamente a atualização automática estão expostos. As regras documentadas de elegibilidade dizem outra coisa. Segundo Microsoft Entra Connect: atualização automática, a atualização automática vem habilitada por padrão apenas quando todas as condições a seguir são atendidas:

• Instalação com configurações expressas ou uma atualização do DirSync
• SQL Express LocalDB, que é o que as configurações expressas sempre usam
• A conta do AD é a conta padrão MSOL_ criada pelas configurações expressas ou pelo DirSync
• Menos de 100.000 objetos no metaverse

Esse é o perfil de um tenant pequeno. Uma implantação corporativa típica - instalação personalizada, SQL Server completo, uma conta de conector dedicada, contagens de objetos na casa das centenas de milhares - nunca fez atualização automática, desde o início. São esses servidores que estão indo à deriva rumo a 30 de setembro, e ninguém desativou nada para chegar lá.

A Microsoft publica as condições específicas que tornam um servidor inelegível, cada uma aparecendo como uma string de resultado nomeada:

Há uma armadilha mais sutil para tenants que estão de fato com a atualização automática ativa. A atualização automática só entrega builds que a Microsoft libera para esse canal, e as notas de versão dizem quais são: a 2.6.1.0 e a 2.6.3.0 afirmam, cada uma, que a atualização automática moverá as instalações existentes para aquele build, enquanto a atual 2.6.84.0 diz apenas "Lançada para download via central de administração do Microsoft Entra." Um servidor saudável com atualização automática, portanto, provavelmente está na 2.6.3.0 - confortavelmente além da parada total, mas não no build que carrega as correções de segurança de julho de 2026. A própria Microsoft resume essa contrapartida: "A versão da atualização automática pode não incluir os recursos mais recentes."

Mais duas coisas suspendem a atualização automática silenciosamente. Deixar a interface do Synchronization Service Manager aberta no servidor pausa o processo ("a atualização fica suspensa até que a interface seja fechada"), e bloquear as URLs do Microsoft Entra Connect Health no proxy o interrompe por completo, já que a atualização automática depende da infraestrutura do Health.

Detecção: Confirme a Versão e o Estado da Atualização Automática

Não confie no CMDB. Verifique cada servidor Connect Sync diretamente, incluindo os servidores de staging, que estão tão sujeitos ao prazo quanto o ativo.

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

O par de versões importa mais do que qualquer um dos números isoladamente. A orientação de solução de problemas da Microsoft para um servidor que se comporta mal após uma atualização automática - KB 4038479, cuja lista de sintomas é restrita a builds legados 1.x, mas cuja descrição do mecanismo de atualização é genérica - é explícita: "Durante a atualização automática, a instalação atual do Microsoft Entra Connect é atualizada, e então a versão na configuração do servidor é atualizada. Se as duas versões não coincidirem, o Microsoft Entra Connect foi atualizado apenas parcialmente." Um servidor que reporta uma versão instalada compatível junto com uma Microsoft.Synchronize.ServerConfigurationVersion desatualizada não terminou o processo e não deve ser contado como corrigido. É da mesma página que vêm a verificação de SchedulerSuspended e o caminho do log SyncEngine-AutoUpgrader.

O filtro do log de eventos é a forma mais rápida de encontrar servidores que vêm tentando e falhando há meses: filtre o log de Aplicativo pela origem Microsoft Entra Connect Upgrade e pelo intervalo de IDs de evento 300-399. Códigos de resultado com prefixo UpgradeAborted são transitórios e são reprocessados. Códigos com prefixo UpgradeNotSupported significam, nas palavras da Microsoft, que "a expectativa é de que o sistema precise ser atualizado manualmente."

Correção: Escolha o Caminho de Atualização e Depois Evite Sua Armadilha

A Microsoft documenta três estratégias de correção e atualização. Escolha pela quantidade de servidores e pelo desvio de configuração, não pela conveniência.

1. Atualização automática. Só é viável para instalações com configurações expressas que ainda são elegíveis. Não exige intervenção manual, mas o build alcançado pode ficar atrás do atual.

2. Atualização in-place. A Microsoft chama isso de "preferível quando você tem um único servidor e menos de cerca de 100.000 objetos", e é direta sobre a contrapartida: "Se houver um problema durante a atualização in-place, não é possível reverter para o release ou a configuração anterior ..." Duas coisas a planejar:

• Se as regras de sincronização padrão mudaram entre os builds, uma importação completa e sincronização completa roda em seguida. "Essa execução pode levar algumas horas, dependendo do número de objetos dentro do escopo do mecanismo de sincronização." A sincronização delta fica suspensa durante o processo; a sincronização de senhas continua.
• Se você modificou as regras de sincronização padrão, "essas regras voltam à configuração padrão na atualização."

Para empurrar a sincronização completa para fora do horário comercial, desmarque Start the synchronization process when configuration completes durante a atualização, depois inspecione e limpe as substituições registradas:

Get-ADSyncSchedulerConnectorOverride | Format-List

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

Set-ADSyncScheduler -SyncCycleEnabled $true

Execute a importação completa e a sincronização completa adiadas na primeira oportunidade disponível. Deixá-las de lado permanentemente mantém a nova configuração não aplicada aos objetos existentes.

3. Migração swing. Construa o novo servidor em paralelo, verifique-o e só então promova-o. A Microsoft o lista como "a abordagem mais segura e a transição mais tranquila para uma versão mais nova", observa que "a sincronização não é interrompida e não impõe risco à produção", e dá um gatilho claro para escolhê-la: clientes que não atualizam há 12-18 meses "devem considerar uma atualização swing, pois essa é a opção mais conservadora e de menor risco." Também é a rota suportada quando o sistema operacional Windows Server precisa ser substituído, já que atualizações in-place do SO só são suportadas de Server 2016, 2019 ou 2022 para Server 2025.

Se você fizer a migração swing, desative completamente o servidor antigo. O modo de falha é silencioso e lento: um servidor de sincronização deixado para trás "pode não conseguir mais acessar o Active Directory local ... mas ainda consegue se conectar ao Microsoft Entra ID e fazer com que valores de atributos revertam continuamente a cada ciclo de sincronização."

Dois Defeitos na Hora da Atualização Para Verificar e Corrigir

miiserver.exe.config modificado. Nas versões 2.5.190.0 e 2.6.1.0, se esse arquivo foi editado anteriormente - comumente seguindo orientações antigas para dar suporte à sincronização de hash de senha em ambientes com FIPS habilitado -, a atualização o deixa intocado, e a sincronização então falha com System.IO.FileLoadException: Could not load file or assembly 'System.Diagnostics.DiagnosticSource, Version=6.0.0.1'. A correção documentada é fazer backup do arquivo em %programfiles%\Microsoft Azure AD Sync\Bin, adicionar o redirecionamento de binding dentro da seção assemblyBinding e reiniciar o serviço 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>

A versão 2.6.84.0 resolve a causa raiz: seu changelog registra que a atualização automática agora "mescla as modificações do cliente com a nova configuração e valida o resultado antes de aplicá-lo", em vez de sobrescrever o arquivo.

Conectores não padrão. Se você usa o conector Generic LDAP ou Generic SQL, atualize a configuração do conector no Synchronization Service Manager depois de uma atualização in-place. Pule essa etapa e as execuções de importação e exportação falham com um erro "Assembly version in AAD Connector configuration ... is earlier than the actual version" no log de eventos de Aplicativo.

A Questão do Cloud Sync

A Microsoft agora abre sua própria página de atualização com uma sugestão: "Em vez de atualizar para a versão mais recente do Microsoft Entra Connect, veja se o cloud sync é adequado para você." Essa é uma opção legítima, e os dois podem rodar lado a lado na mesma floresta. Mas verifique a tabela de cenários suportados antes de se comprometer: o cloud sync não oferece suporte a Microsoft Entra hybrid join, Windows Hello for Business, domínios com mais de 250 mil objetos, filtragem de objetos de diretório por valores de atributo, ou a topologia de contas de usuário em uma floresta com caixas de correio em uma floresta de recursos.

O Que Realmente Quebra em 1º de Outubro

"Todos os serviços de sincronização vão falhar" tem um raio de impacto maior do que um ciclo de sincronização pausado, porque o Connect Sync é o transporte para várias coisas que não são obviamente "sincronização".

• A sincronização de hash de senha para de ser atualizada. O PHS é, nas palavras da Microsoft, "uma extensão do recurso de sincronização de diretório implementado pelo Microsoft Entra Connect Sync." Mudanças de senha locais deixam de chegar ao tenant, então os usuários continuam se autenticando contra hashes cada vez mais desatualizados.
• A detecção de credenciais vazadas fica obsoleta para contas híbridas. A mesma página afirma que "o Password Hash Sync também habilita a detecção de credenciais vazadas para suas contas híbridas." Sem hashes recentes fluindo, as correspondências são avaliadas contra senhas que já podem ter sido trocadas localmente - e usuários de risco que ninguém corrige já são o elo mais fraco dessa cadeia.
• O processo de admissão-movimentação-desligamento para na fronteira do tenant. Este é o ponto relevante para a segurança. Desativar ou excluir uma conta no AD local deixa de se propagar, então a identidade na nuvem continua funcionando enquanto durar a interrupção, e cada desligamento nesse período vira uma conta órfã, porém ainda ativa - o mesmo padrão que aparece nas contas obsoletas e superprivilegiadas no AD quando ninguém revisa saídas de funcionários. É exatamente o ponto cego da sincronização de identidade híbrida que aparece meses depois como achado de auditoria.
• A associação de grupos congela. Mudanças de grupo locais deixam de direcionar o acesso na nuvem, incluindo a associação a grupos usados para atribuição de funções ou escopo do Conditional Access.

Trate 30 de setembro como um evento de governança de identidade, não apenas de disponibilidade. Também não é a única mudança do Entra com data marcada em andamento - a mudança do SSPR para apenas métodos registrados em 9 de novembro de 2026 chega cerca de seis semanas depois.

Como a EtcSec Detecta Isso

Um Connect Sync travado ou parcialmente atualizado não se anuncia no tenant. Ele aparece como desvio de identidade, e é isso que uma auditoria consegue capturar. As verificações do Azure da EtcSec identificam exatamente esse tipo de desvio: HYBRID_ORPHANED_CLOUD_USER sinaliza usuários híbridos ainda marcados como sincronizados localmente, mas desativados no Entra ID, HYBRID_CLOUD_ONLY_PRIVILEGED identifica usuários exclusivamente na nuvem com funções privilegiadas fora da governança de Tier 0 local, UNRESOLVED_PRIVILEGED_MEMBERS reporta atribuições de função privilegiada que apontam para principais que não podem mais ser resolvidos, e PA_ADMIN_STALE_ACCOUNT identifica atribuições de função de administrador de usuários que não fazem login há muito tempo.

No lado local, a mesma auditoria cobre as contas privilegiadas e de serviço que uma sincronização quebrada isola silenciosamente, e se encaixa no tipo de fluxo de auditoria repetível que captura o desvio entre os prazos, não depois deles. No lado do tenant, ela se integra à mesma revisão de segurança do Entra ID que você já deveria estar fazendo em Conditional Access, MFA e atribuições de função.