Blog do Chesley

Blog Chesley · chesley.com.br | Microsoft 365 · Entra ID · Identidade Híbrida

Introdução — O Fim de uma Era no Sync Híbrido

Por mais de uma década, o Microsoft Entra Connect (anteriormente conhecido como Azure AD Connect e, antes ainda, como DirSync e Azure AD Sync) foi a espinha dorsal da sincronização de identidades híbridas em praticamente toda organização que adota o Microsoft 365. Ele sincroniza usuários, grupos e contatos do Active Directory (AD) on-premises para o Microsoft Entra ID (antigo Azure AD), habilitando cenários como Single Sign-On, autenticação híbrida e SSPR (Self-Service Password Reset).

Essa era está chegando ao fim.

Em maio de 2026, a Microsoft anunciou oficialmente o início do processo de transição do Microsoft Entra Connect Sync para o Microsoft Entra Cloud Sync — a solução nativa de nuvem para sincronização de identidades híbridas. Essa mudança não é opcional no longo prazo: a Microsoft começará a notificar as organizações sobre suas janelas de transição a partir de julho de 2026, e o Connect Sync será progressivamente descontinuado como mecanismo primário de sincronização.

⚠️ Atenção imediata: Todos os serviços de sincronização do Microsoft Entra Connect Sync serão interrompidos em 30 de setembro de 2026 para organizações que não estiverem na versão 2.5.79.0 ou superior. Atualize imediatamente se ainda estiver em versões antigas.

Este artigo cobre a arquitetura completa do Cloud Sync, as diferenças em relação ao Connect Sync, como avaliar a prontidão da sua organização para migrar, o passo a passo técnico da migração e o que não muda após a transição.

O Que é o Microsoft Entra Cloud Sync?

O Microsoft Entra Cloud Sync é a solução de sincronização de identidades híbridas nativa de nuvem da Microsoft. Ao contrário do Connect Sync, que é instalado e gerenciado em um servidor on-premises, o Cloud Sync opera com um agente de provisionamento leve (lightweight provisioning agent) instalado no ambiente local, enquanto toda a lógica de configuração, monitoramento e gerenciamento reside na nuvem — especificamente no Microsoft Entra ID.

Componentes principais

Por que a Microsoft está migrando

A Microsoft posiciona o Cloud Sync como o futuro estratégico da sincronização híbrida por razões técnicas sólidas:

• O Connect Sync foi projetado em uma era em que servidores on-premises eram o padrão; sua arquitetura carrega a complexidade desse modelo
• Novas funcionalidades de sincronização e provisionamento estão sendo desenvolvidas exclusivamente no Cloud Sync
• O modelo de agente leve se alinha com a estratégia de Zero Trust e redução da superfície de ataque on-premises
• Atualizações automáticas eliminam a necessidade de janelas de manutenção manuais

Diferenças Arquiteturais

Entender as diferenças arquiteturais entre as duas soluções é essencial para planejar a migração e antever os impactos operacionais.

Microsoft Entra Connect Sync — Arquitetura legada

Active Directory (on-premises)
        ↓
[Servidor Connect Sync on-premises]
  - Metaverse (banco de dados local de identidades)
  - Motor de regras de sincronização (Sync Rules Engine)
  - Scheduler local
  - Configuração armazenada localmente
        ↓
Microsoft Entra ID (nuvem)

Características:

• Servidor dedicado com instalação completa (500 MB+)
• Banco de dados SQL local (LocalDB ou SQL Server)
• Configuração armazenada no servidor — requer acesso direto ao servidor para mudanças
• Ponto único de falha (Single Point of Failure — SPOF)
• Atualizações manuais necessárias
• Acesso VPN obrigatório para gerenciamento remoto

Microsoft Entra Cloud Sync — Arquitetura moderna

Active Directory (on-premises)
        ↓
[Agente leve de provisionamento on-premises]
  - Apenas conectividade de saída (HTTPS/443)
  - Sem banco de dados local
  - Configuração recebida da nuvem
        ↓
[Microsoft Entra Cloud Provisioning Service]
  - Lógica de sincronização na nuvem
  - Configuração centralizada no Entra ID
  - Múltiplos agentes com failover automático
        ↓
Microsoft Entra ID

Características:

• Agente leve (download ~150 MB)
• Sem banco de dados local
• Configuração armazenada no Microsoft Entra ID — gerenciável de qualquer lugar
• Suporte a múltiplos agentes ativos com failover automático
• Atualizações automáticas gerenciadas pela Microsoft
• Suporte nativo a florestas AD desconectadas (disconnected forests)

Comparativo direto de arquitetura

Comparativo Técnico Completo de Funcionalidades

A tabela abaixo reflete o estado atual das capacidades conforme documentado no Microsoft Learn Decision Guide (atualizado em fevereiro de 2026):

Cronograma de Transição — O Que a Microsoft Comunicou

A Microsoft anunciou oficialmente no M365 Message Center e no Microsoft Learn o seguinte cronograma:

Julho de 2026 — Início das notificações

A Microsoft começará a notificar as organizações sobre suas janelas individuais de transição. As notificações chegarão por três canais:

• M365 Message Center — painel administrativo do Microsoft 365
• Entra Connect Health — portal de saúde do Connect
• E-mails direcionados — para administradores globais e de identidade

Fases de transição

Fase inicial — Configurações simples: Organizações com configurações simples e totalmente suportadas pelo Cloud Sync serão as primeiras a receber notificações. Perfil típico: único AD forest, menos de 150.000 objetos, sem Hybrid Azure AD Join, sem regras de sync avançadas, usando Password Hash Sync.

Fases subsequentes — Configurações complexas: À medida que o Cloud Sync expande suas capacidades, organizações com requisitos mais complexos serão notificadas progressivamente. A Microsoft garante que nenhuma organização será solicitada a migrar antes que o Cloud Sync suporte todos os seus cenários.

O que acontece quando você receber a notificação

1. Você receberá orientações detalhadas e recursos para iniciar a transição
2. Terá acesso à ferramenta de transição e à documentação passo a passo
3. Poderá mover e testar o ambiente no Cloud Sync antes de qualquer mudança permanente
4. O Connect Sync será mantido em staging mode durante a validação
5. Se precisar de mais tempo, pode solicitar uma exceção à Microsoft

Importante: Se sua organização não puder migrar dentro do prazo recomendado, é necessário solicitar formalmente uma exceção. Se aprovada, você poderá continuar com o setup atual enquanto trabalha com o suporte da Microsoft para definir um cronograma adequado.

Avaliação de Prontidão para Migração

O Decision Guide oficial da Microsoft classifica as organizações em três cenários:

✅ Prontas para migração imediata

Sua organização pode migrar imediatamente se atender todos os critérios abaixo:

• Escala de objetos: Menos de 150.000 objetos por domínio Active Directory
• Tamanho de grupos: Grupos com menos de 50.000 membros
• Gestão de dispositivos: Não utiliza Hybrid Azure AD Join, ou está disposta a migrar para Cloud Kerberos Trust
• Autenticação: Utiliza Password Hash Sync (PHS) ou gerencia configurações de ADFS/PTA separadamente
• Filtros: Utiliza filtro por OU em vez de regras complexas baseadas em atributos
• Configuração de floresta: Única floresta ou florestas conectadas (sem requisitos de florestas desconectadas)

⏳ Planejar migração no curto/médio prazo

Considere planejar a migração com base na disponibilidade de funcionalidades se você depende de:

• Sincronização de dispositivos: Utiliza atualmente Hybrid Azure AD Join
• Filtros avançados: Usa filtros complexos baseados em atributos além das capacidades atuais do Cloud Sync
• User Provisioning para AD: Necessita de provisionamento de usuários de nuvem para AD

Monitore os anúncios de novas funcionalidades do Cloud Sync regularmente.

🔍 Avaliar para migração futura

Organizações com as seguintes características devem avaliar o timing de migração com base em ciclos de planejamento de negócios:

• Ambientes de grande escala: Mais de 150.000 objetos por domínio ou grupos com mais de 50.000 membros
• Regras de sincronização complexas: Regras customizadas extensas que exigiriam reconfiguração significativa
• Dependências cross-forest: Relacionamentos complexos de objetos entre florestas não suportados no Cloud Sync
• Dependência de reconciliação: Dependência crítica da correção de sync fora de banda
• Restrições de recursos: Recursos limitados para execução do projeto de migração

Pré-Requisitos Técnicos do Entra Cloud Sync

Antes de iniciar a migração, garanta que o ambiente atende todos os pré-requisitos:

Sistema operacional do servidor do agente

Requisitos de conectividade

O agente requer apenas conectividade de saída (outbound) na porta 443 (HTTPS). Não requer portas de entrada abertas no firewall, o que representa uma melhoria significativa de segurança em relação ao Connect Sync.

Agente (on-premises) → HTTPS 443 → *.servicebus.windows.net
Agente (on-premises) → HTTPS 443 → *.azure.com
Agente (on-premises) → HTTPS 443 → *.microsoftonline.com
Agente (on-premises) → HTTPS 443 → *.msauth.net

Permissões necessárias

Como Realizar a Migração — Passo a Passo

A Microsoft recomenda uma abordagem faseada usando OU-based scoping — cada Unidade Organizacional é gerenciada por apenas uma ferramenta de sync por vez. Isso permite validar o Cloud Sync em um subconjunto de usuários antes de migrar OUs adicionais.

Importante: Executar o Connect Sync e o Cloud Sync simultaneamente para os mesmos objetos não é suportado. Use o escopo por OU para garantir que cada objeto seja gerenciado por apenas uma ferramenta.

Passo 1 — Backup da configuração atual do Connect Sync

powershell

# Exportar a configuração atual do Connect Sync antes de qualquer mudança
# Requer acesso ao servidor onde o Connect Sync está instalado
# Abrir o assistente do Entra Connect
# Opção: "View current configuration" → "Export settings"
# Via PowerShell (módulo ADSync)
Import-Module ADSync
# Exportar configuração completa
Get-ADSyncGlobalSettings | Export-Clixml -Path "C:\Backup\ADSyncGlobalSettings.xml"
Get-ADSyncConnector | Export-Clixml -Path "C:\Backup\ADSyncConnectors.xml"
Get-ADSyncRule | Export-Clixml -Path "C:\Backup\ADSyncRules.xml"
Get-ADSyncScheduler | Export-Clixml -Path "C:\Backup\ADSyncScheduler.xml"
Write-Host "Backup concluído. Arquivos salvos em C:\Backup\"

Passo 2 — Instalar o agente de provisionamento do Cloud Sync

powershell

# 1. Baixar o agente do portal do Entra
# Entra admin center → Identity → Hybrid management → Entra Connect → Cloud sync
# Clique em "Download agent"
# 2. Verificar versão do .NET Framework (requisito: 4.7.2+)
(Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full").Release
# 3. Após instalação, verificar status do serviço
Get-Service -Name "AADConnectProvisioningAgent" | Select-Object Status, Name
# 4. Verificar registro no portal
# Entra admin center → Identity → Hybrid management → Entra Connect → Cloud sync
# O agente deve aparecer com status "Healthy"

Passo 3 — Configurar escopo de OU para o piloto

powershell

# Configurar sincronização de OU piloto via Microsoft Graph
# Instalar módulo se necessário
Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "SynchronizationSchema.ReadWrite.All", "Application.ReadWrite.All"
# Verificar sincronizações existentes
$servicePrincipalId = "<seu-service-principal-id>"
$jobs = Get-MgServicePrincipalSynchronizationJob -ServicePrincipalId $servicePrincipalId
$jobs | Select-Object Id, Status, Schedule | Format-Table -AutoSize

Passo 4 — Ativar staging mode no Connect Sync

powershell

# Colocar o Connect Sync em staging mode enquanto valida o Cloud Sync
# No servidor do Connect Sync:
# Verificar modo atual
Get-ADSyncScheduler | Select-Object StagingModeEnabled
# Ativar staging mode
Set-ADSyncScheduler -StagingModeEnabled $true
Write-Host "Connect Sync agora está em Staging Mode."
Write-Host "O Cloud Sync assumirá a sincronização das OUs configuradas."

Passo 5 — Validar com On-Demand Provisioning

powershell

# Testar sincronização de um usuário individual antes do rollout completo
# Requer Microsoft Graph
$body = @{
    subject = @{
        objectId = "<object-id-do-usuario-teste>"
        objectTypeName = "user"
    }
} | ConvertTo-Json
# Via portal: Entra admin center → Cloud sync → On-demand provisioning
# Inserir UPN do usuário teste e clicar em "Provision"
Write-Host "Valide no portal do Entra que o usuário foi sincronizado corretamente."
Write-Host "Verifique: atributos, membros de grupos, e status de licenciamento."

Passo 6 — Expandir para todas as OUs e finalizar

powershell

# Após validação bem-sucedida do piloto:
# 1. Expandir o escopo do Cloud Sync para todas as OUs
# 2. Aguardar ciclo de sincronização completo
# 3. Validar todos os objetos no portal do Entra
# Verificar estatísticas de sincronização
$syncJobId = "<seu-sync-job-id>"
$syncStatus = Get-MgServicePrincipalSynchronizationJob `
    -ServicePrincipalId $servicePrincipalId `
    -SynchronizationJobId $syncJobId
$syncStatus.Status | Format-List
# 4. Desabilitar o Connect Sync após confirmação de sucesso
# No servidor do Connect Sync:
Set-ADSyncScheduler -StagingModeEnabled $true  # Permanece em staging
# A Microsoft fornecerá instrução específica para descomissionamento completo

Passo 7 — Rollback (se necessário)

powershell

# Se precisar reverter para o Connect Sync durante a validação:
# O Connect Sync permanece em staging mode — pode ser reativado
Set-ADSyncScheduler -StagingModeEnabled $false
Write-Host "Connect Sync reativado. Rollback concluído."
Write-Host "Analise os problemas identificados antes de tentar nova migração."

Configuração via PowerShell e Microsoft Graph

Instalando e configurando o módulo de provisionamento

powershell

# Instalar módulo de provisionamento (se necessário)
Install-Module -Name Microsoft.Graph.Applications -Scope CurrentUser -Force
Connect-MgGraph -Scopes `
    "SynchronizationSchema.ReadWrite.All",
    "SynchronizationSchema.Read.All",
    "Application.ReadWrite.All",
    "Directory.ReadWrite.All"
# Listar todos os agentes de provisionamento instalados
$uri = "https://graph.microsoft.com/beta/onPremisesPublishingProfiles/provisioning/agents"
$agents = Invoke-MgGraphRequest -Uri $uri -Method GET
$agents.value | Select-Object id, displayName, status, @{
    N="HealthStatus"; E={$_.agentGroups[0].publishingType}
} | Format-Table -AutoSize

Verificando saúde dos agentes

powershell

# Verificar status de saúde de todos os agentes de provisionamento
$agentsUri = "https://graph.microsoft.com/beta/onPremisesPublishingProfiles/provisioning/agents"
$response = Invoke-MgGraphRequest -Uri $agentsUri -Method GET
foreach ($agent in $response.value) {
    Write-Host "Agente: $($agent.displayName)"
    Write-Host "  Status: $($agent.status)"
    Write-Host "  Versão: $($agent.version)"
    Write-Host "  Última atividade: $($agent.lastActivityDateTime)"
    Write-Host ""
}

Monitorando erros de sincronização

powershell

# Obter erros de provisionamento do Cloud Sync
$provisioningLogsUri = "https://graph.microsoft.com/v1.0/auditLogs/provisioning?`$filter=result eq 'failure'&`$top=50"
$errors = Invoke-MgGraphRequest -Uri $provisioningLogsUri -Method GET
$errors.value | Select-Object `
    @{N="Usuario";E={$_.servicePrincipal.name}},
    @{N="Acao";E={$_.action}},
    @{N="Resultado";E={$_.result}},
    @{N="Erro";E={$_.provisioningStatusInfo.errorInformation.errorCode}},
    @{N="Data";E={$_.activityDateTime}} |
    Format-Table -AutoSize
# Exportar relatório de erros
$errors.value | Export-Csv "cloud-sync-errors-$(Get-Date -Format 'yyyyMMdd').csv" `
    -NoTypeInformation -Encoding UTF8

Auditando objetos sincronizados

powershell

# Listar usuários sincronizados do AD on-premises com seu status
Get-MgUser -Filter "onPremisesSyncEnabled eq true" -All `
    -Property displayName, userPrincipalName, onPremisesSyncEnabled, 
              onPremisesLastSyncDateTime, onPremisesDistinguishedName |
    Select-Object displayName, userPrincipalName, 
                  onPremisesLastSyncDateTime, onPremisesDistinguishedName |
    Sort-Object onPremisesLastSyncDateTime -Descending |
    Export-Csv "synced-users-$(Get-Date -Format 'yyyyMMdd').csv" `
        -NoTypeInformation -Encoding UTF8
# Identificar usuários com erros de sincronização
Get-MgUser -Filter "onPremisesProvisioningErrors/any()" -All `
    -Property displayName, userPrincipalName, onPremisesProvisioningErrors |
    Select-Object displayName, userPrincipalName,
        @{N="Erro";E={$_.onPremisesProvisioningErrors[0].errorDetail}} |
    Format-Table -AutoSize

Autenticação Híbrida Após a Migração

Um dos pontos que gera mais dúvida é: o que acontece com os métodos de autenticação híbrida após a migração?

A resposta oficial da Microsoft é clara: os recursos de autenticação híbrida continuam disponíveis após a migração, mas com uma distinção arquitetural importante.

O que permanece disponível

Importante sobre PTA e ADFS

O Cloud Sync não inclui o assistente de configuração de PTA e ADFS — esses recursos continuarão sendo configurados através do assistente do Connect Sync mesmo após a migração. Em outras palavras:

• O mecanismo de sincronização de objetos (usuários, grupos, contatos) migra para o Cloud Sync
• O mecanismo de autenticação híbrida (PTA, ADFS, Seamless SSO) permanece gerenciado pelo assistente do Connect Sync

Isso significa que o servidor do Connect Sync pode precisar permanecer instalado para gerenciar configurações de PTA mesmo após a migração do sync para o Cloud Sync.

Migrando dispositivos: Cloud Kerberos Trust

Para organizações que usam Hybrid Azure AD Join, a Microsoft recomenda migrar para Cloud Kerberos Trust como parte do processo de modernização:

powershell

# Verificar dispositivos com Hybrid Azure AD Join no tenant
Get-MgDevice -Filter "trustType eq 'ServerAd'" -All `
    -Property displayName, operatingSystem, operatingSystemVersion, 
              approximateLastSignInDateTime |
    Select-Object displayName, operatingSystem, 
                  operatingSystemVersion, approximateLastSignInDateTime |
    Sort-Object approximateLastSignInDateTime -Descending |
    Export-Csv "hybrid-joined-devices.csv" -NoTypeInformation -Encoding UTF8
Write-Host "Total de dispositivos Hybrid Azure AD Joined: $($(Get-MgDevice -Filter "trustType eq 'ServerAd'" -All).Count)"

Mitos e Correções

❌ Mito 1: “Minha organização será forçada a migrar imediatamente em julho de 2026”

Correção: Julho de 2026 é a data em que a Microsoft começa a notificar as organizações sobre suas janelas de transição — não é uma data limite de migração. A transição será faseada, começando pelas configurações mais simples. Organizações com configurações complexas ou que dependem de funcionalidades ainda não disponíveis no Cloud Sync não serão incluídas nas fases iniciais. Se sua organização não puder migrar dentro do prazo recomendado, pode solicitar uma exceção formalmente.

❌ Mito 2: “Cloud Sync e Connect Sync podem rodar simultaneamente para os mesmos objetos”

Correção: Executar os dois sincronizando os mesmos objetos não é suportado e pode causar conflitos de dados. A abordagem correta é usar OU-based scoping — cada Unidade Organizacional é gerenciada por apenas uma ferramenta de sync por vez. Isso permite um processo de migração faseado e seguro, mas os objetos precisam ser claramente divididos entre as duas ferramentas durante a transição.

❌ Mito 3: “O Cloud Sync é apenas uma versão mais leve do Connect Sync com as mesmas funcionalidades”

Correção: O Cloud Sync tem uma arquitetura completamente diferente e, atualmente, não suporta todas as funcionalidades do Connect Sync. Lacunas importantes incluem: sincronização de dispositivos (Hybrid Azure AD Join), regras de sync avançadas (Sync Rules Engine), filtros de atributos complexos, Device Writeback, suporte a florestas cross-forest com relacionamentos entre objetos, e reconciliação out-of-band. Organizações que dependem dessas funcionalidades devem aguardar as fases posteriores da migração.

❌ Mito 4: “Após migrar para o Cloud Sync, o servidor do Connect Sync pode ser descomissionado imediatamente”

Correção: Não necessariamente. Se sua organização usa PTA (Pass-Through Authentication), ADFS, ou Seamless SSO, o assistente de configuração do Connect Sync ainda é necessário para gerenciar esses recursos. O Connect Sync pode permanecer instalado exclusivamente para gerenciar a configuração de autenticação híbrida, mesmo que o sync de objetos tenha migrado para o Cloud Sync.

❌ Mito 5: “O Cloud Sync exige muitas portas abertas no firewall, assim como o Connect Sync”

Correção: Esta é uma das principais melhorias de segurança do Cloud Sync. O agente requer apenas conectividade de saída na porta 443 (HTTPS). Não há necessidade de portas de entrada abertas, o que reduz significativamente a superfície de ataque on-premises e simplifica a configuração de firewall.

Boas Práticas de Segurança e Governança

1. Atualize o Connect Sync para a versão 2.5.79.0 ou superior agora

Independentemente do cronograma de migração para o Cloud Sync, esta atualização é obrigatória. Todos os serviços de sincronização no Microsoft Entra Connect Sync serão interrompidos em 30 de setembro de 2026 para organizações que não estiverem na versão 2.5.79.0 ou superior.

powershell

# Verificar versão atual do Connect Sync instalada
Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* |
    Where-Object { $_.DisplayName -like "*Azure AD Connect*" -or 
                   $_.DisplayName -like "*Entra Connect*" } |
    Select-Object DisplayName, DisplayVersion, InstallDate

2. Faça o backup completo da configuração antes de qualquer mudança

Use a funcionalidade de exportação de configurações do Connect Sync (Import/Export Settings) para criar um backup completo antes de iniciar a migração. Isso garante um rollback limpo se necessário.

3. Use gMSA (Group Managed Service Account) para o agente

Ao instalar o agente de provisionamento, use uma gMSA em vez de uma conta de serviço tradicional. gMSAs têm senhas gerenciadas automaticamente pelo AD, eliminando o risco de senhas de serviço comprometidas ou expiradas.

4. Implante múltiplos agentes para alta disponibilidade

O Cloud Sync suporta múltiplos agentes ativos com failover automático. Implante pelo menos dois agentes em servidores diferentes, idealmente em locais distintos, para eliminar o ponto único de falha que existia no modelo do Connect Sync.

powershell

# Verificar saúde de todos os agentes implantados
# Recomendação: mínimo 2 agentes, ideal 3 para ambientes críticos
$agentsUri = "https://graph.microsoft.com/beta/onPremisesPublishingProfiles/provisioning/agents"
$agents = Invoke-MgGraphRequest -Uri $agentsUri -Method GET
$agentsCount = ($agents.value | Where-Object { $_.status -eq "active" }).Count
if ($agentsCount -lt 2) {
    Write-Warning "ATENÇÃO: Apenas $agentsCount agente(s) ativo(s). Recomendado mínimo de 2."
}

5. Configure alertas no Microsoft Entra Connect Health

Mesmo migrando para o Cloud Sync, mantenha o monitoramento ativo durante o período de transição via Connect Health. Configure alertas para:

• Falhas de sincronização
• Agentes inativos
• Erros de provisionamento recorrentes
• Objetos com erros de atributo

6. Documente todas as regras de sync personalizadas antes da migração

O Cloud Sync usa um expression builder em vez do Sync Rules Engine completo do Connect. Regras customizadas precisam ser recriadas — documente e mapeie cada regra existente para o equivalente no expression builder antes de iniciar a migração.

7. Valide o escopo com On-Demand Provisioning antes do rollout

Nunca realize o rollout completo sem antes validar com o recurso de On-Demand Provisioning. Aplique a configuração a um usuário individual, verifique todos os atributos sincronizados, e só então expanda para o escopo completo.

8. Planeje a janela de comunicação para usuários finais

A migração pode causar atrasos temporários na sincronização durante a transição entre as ferramentas. Planeje uma janela de manutenção adequada e comunique proativamente os usuários sobre possíveis impactos temporários.

Referências do Microsoft Learn

• What is Microsoft Entra Cloud Sync?
• Migrate from Microsoft Entra Connect to Cloud Sync: Decision Guide
• Migrate from Microsoft Entra Connect Sync to Cloud Sync FAQ
• Migrate Microsoft Entra Connect to Microsoft Entra Cloud Sync
• Tutorial: Migrate to Cloud Sync for a synced AD forest (Pilot)
• Cloud Sync prerequisites
• How On-Demand Provisioning works in Cloud Sync
• Microsoft Entra Connect: Upgrade from a previous version
• Microsoft Entra Connect: Version release history
• Microsoft Entra Connect: Import and export configuration settings
• Pass-Through Authentication in Microsoft Entra ID
• Microsoft Entra seamless single sign-on
• Migrate group writeback v2 to Cloud Sync
• Cloud Sync deep dive — how it works
• Microsoft Entra releases and announcements — What’s New

Artigo publicado no Blog Chesley · chesley.com.br Chesley Fernandes — Especialista em Microsoft 365, Entra ID e Segurança de Identidade