Exchange Hybrid: Pré-Requisitos Técnicos — O Que Sua Infraestrutura Precisa Atender

Exchange Hybrid – chesley.com.br

Exchange Hybrid: Pré-Requisitos Técnicos — O Que Sua Infraestrutura Precisa Atender

Categoria: Treinamentos | Microsoft Exchange
Nível: Intermediário–Avançado
Tempo de leitura: ~20 minutos
Referência principal: Hybrid deployment prerequisites – Microsoft Learn

Introdução

O Hybrid Configuration Wizard (HCW) é a ferramenta que configura o ambiente híbrido, mas ele não trabalha milagres. Se os pré-requisitos não estiverem atendidos, o wizard vai falhar — e o diagnóstico de erros no meio de uma configuração híbrida pode consumir horas de trabalho que poderiam ser evitadas.

Este artigo cobre cada pré-requisito com o nível de detalhe necessário para que você chegue ao HCW com a infraestrutura preparada. Não se trata de uma lista superficial: vamos explorar as implicações de cada requisito, os pontos de atenção e as boas práticas recomendadas pela Microsoft.

1. Versão e Estado do Exchange Server On-Premises

O primeiro requisito é a versão do Exchange Server instalado na infraestrutura local. A Microsoft define quais versões de deployment híbrido são suportadas com base na versão do Exchange on-premises.

Ambiente On-Premises Híbrido Exchange 2019 Híbrido Exchange 2016 Híbrido Exchange 2013 Híbrido Exchange 2010
Exchange 2019 ✅ Suportado ❌ ❌ ❌
Exchange 2016 ✅ Suportado ✅ Suportado ❌ ❌
Exchange 2013 ✅ Suportado ✅ Suportado ✅ Suportado ❌
Exchange 2010 ❌ ✅ Suportado ✅ Suportado ✅ Suportado

Boa prática: Sempre configure o deployment híbrido na versão mais recente suportada pelo seu ambiente. Isso garante acesso a recursos mais recentes e suporte contínuo da Microsoft.

Cumulative Updates (CU)

O Exchange híbrido exige que os servidores estejam no CU mais recente disponível para a versão instalada. A Microsoft também aceita o CU imediatamente anterior caso o mais recente não tenha sido aplicado ainda. CUs são liberados trimestralmente, o que oferece alguma flexibilidade no planejamento de atualizações.

# Verificar a versão atual do Exchange Server
Get-ExchangeServer | Format-List Name, Edition, AdminDisplayVersion

Atenção ao Exchange 2010: Essa versão atingiu o fim do ciclo de suporte. Se você ainda opera caixas no Exchange 2010 e precisa manter caixas postais on-premises, a Microsoft recomenda fortemente migrar para Exchange 2016 ou 2019 como endpoint híbrido antes de prosseguir.

2. Funções de Servidor Necessárias (Server Roles)

As funções de servidor que precisam estar instaladas variam conforme a versão do Exchange:

  • Exchange 2016 e 2019: Pelo menos um servidor com a função Mailbox.
  • Exchange 2013: Pelo menos um servidor com as funções Mailbox e Client Access (podem estar no mesmo servidor).
  • Exchange 2010: Pelo menos um servidor com as funções Mailbox, Hub Transport e Client Access.

Edge Transport Servers: Se você utiliza servidores Edge Transport na rede de perímetro para controle de fluxo de e-mail, eles também precisam estar atualizados para o CU mais recente. A Microsoft recomenda fortemente a implantação de Edge Transport em redes de perímetro. Servidores Mailbox e Client Access não podem ser implantados na rede de perímetro.

3. Assinatura Microsoft 365 / Exchange Online

O lado nuvem do deployment híbrido requer uma assinatura Microsoft 365 compatível. Os seguintes planos suportam deployments híbridos:

  • ✅ Microsoft 365 Business Standard
  • ✅ Microsoft 365 Business Basic
  • ✅ Planos Enterprise (E1, E3, E5)
  • ✅ Planos Government
  • ✅ Planos Academic
  • ✅ Planos Midsize

Os seguintes planos não suportam deployments híbridos: – ❌ Microsoft 365 Apps for Business – ❌ Planos Home

Cada caixa postal migrada para o Exchange Online requer uma licença atribuída.

4. Domínios Personalizados Verificados no Microsoft 365

Todos os domínios SMTP que serão utilizados no ambiente híbrido precisam estar verificados e registrados no tenant do Microsoft 365. A verificação é feita via DNS (TXT ou MX record) e pode ser realizada pelo portal do Microsoft 365 Admin Center.

# Verificar domínios no PowerShell do Exchange Online
Get-AcceptedDomain

Cada domínio precisa ter um registro Autodiscover público apontando para os servidores Exchange on-premises, conforme detalhado na seção de DNS abaixo.

5. Sincronização de Diretório com Microsoft Entra Connect

A sincronização do Active Directory local com o Microsoft Entra ID (anteriormente Azure AD) é obrigatória para o funcionamento correto do ambiente híbrido. Sem ela, os objetos de usuário não existem no tenant Microsoft 365, o que impede migração de caixas e operação da GAL unificada.

Existem duas opções:

Microsoft Entra Connect (Connect Sync)

Solução tradicional, instalada em um servidor dedicado. Suporta topologias complexas, múltiplas florestas e sincronização de hash de senha, autenticação de passagem (PTA) e federação (AD FS).

# Verificar o status de sincronização via PowerShell (Azure AD PowerShell Module)
Get-MsolCompanyInformation | Select LastDirSyncTime

Cloud Sync

Solução mais recente, baseada em agente leve instalado on-premises. Recomendada para topologias mais simples e organizações que querem reduzir a dependência de servidores de sincronização dedicados.

Recomendação da Microsoft: Para ambientes com requisitos de SSO robusto e topologias complexas de floresta, o Connect Sync ainda é a opção mais completa. Para ambientes simples, o Cloud Sync oferece menor overhead operacional.

Single Sign-On (SSO)

Embora não seja tecnicamente obrigatório para o funcionamento básico do híbrido, o SSO é fortemente recomendado pela Microsoft, pois: – Garante que os usuários acessem ambos os ambientes com as mesmas credenciais. – Melhora significativamente a experiência do usuário durante e após a migração. – Simplifica a administração de políticas de conta.

Opções de SSO disponíveis via Entra Connect: – Password Hash Synchronization (PHS): Sincronia do hash de senha para o Entra ID. Solução mais simples, suportada por qualquer tamanho de organização. – Pass-Through Authentication (PTA): Autenticação ocorre sempre contra o AD local, sem armazenar credenciais na nuvem. – Active Directory Federation Services (AD FS): Federação completa, com suporte a cenários avançados de autenticação multifator e Claims.

6. Certificados Digitais

Este é um dos pré-requisitos mais frequentemente subestimados e que causa mais falhas durante a configuração híbrida.

O Que a Microsoft Exige

  • O certificado deve ser emitido por uma Autoridade Certificadora (CA) pública e confiável — certificados autoassinados não são aceitos para os serviços do Exchange em ambiente híbrido.
  • O certificado deve ter os seguintes nomes no campo Subject Alternative Name (SAN):
    • A URL externa do EWS (Exchange Web Services)
    • O endpoint do Autodiscover publicado no DNS público
  • Em organizações com múltiplas florestas do Active Directory, cada floresta requer um certificado separado, emitido pela mesma CA.
  • Todos os servidores Exchange configurados no deployment híbrido devem usar certificados emitidos pela mesma CA e com o mesmo subject.

Exemplo de SAN em Certificado Híbrido

Subject: mail.contoso.com
Subject Alternative Names:
  - mail.contoso.com
  - autodiscover.contoso.com
  - contoso.com (opcional, se necessário para OWA)

Verificação do Certificado Atual

# Listar certificados atribuídos aos serviços Exchange
Get-ExchangeCertificate | Format-List FriendlyName, Thumbprint, Services, Subject, CertificateDomains

Boa prática: Use o Microsoft Remote Connectivity Analyzer (testconnectivity.microsoft.com) para validar a acessibilidade do Autodiscover e do EWS externamente antes de iniciar o HCW.

7. Registros DNS Públicos

Os seguintes registros DNS precisam estar configurados e resolvíveis publicamente:

Autodiscover

O registro de Autodiscover deve apontar para o servidor Exchange on-premises. Esse registro é usado pelo Exchange Online para descobrir os endpoints de EWS, migração e outras funcionalidades híbridas.

autodiscover.contoso.com  CNAME  mail.contoso.com

ou via registro A:

autodiscover.contoso.com  A  203.0.113.10

OWA / EWS External URL

A URL externa do OWA e do EWS precisa ser resolvível externamente e apontar para o Exchange Server on-premises.

# Verificar URLs externas configuradas no Exchange
Get-OwaVirtualDirectory | Format-List Name, ExternalURL
Get-WebServicesVirtualDirectory | Format-List Name, ExternalURL, InternalURL

Verificação via Remote Connectivity Analyzer: 1. Acesse testconnectivity.microsoft.com 2. Selecione “Outlook Connectivity” para validar Autodiscover 3. Selecione “Exchange Web Services” para validar o EWS externo

8. Portas e Protocolos de Rede (Firewall)

O deployment híbrido requer que determinadas portas estejam abertas no firewall que protege a infraestrutura on-premises. A tabela a seguir consolida os requisitos documentados pela Microsoft:

Origem Protocolo/Porta Destino Finalidade
Exchange Online TCP 25 (SMTP/TLS) Exchange Server on-premises Fluxo de e-mail híbrido seguro (inbound)
Exchange Server on-premises TCP 25 (SMTP/TLS) Exchange Online Fluxo de e-mail híbrido seguro (outbound)
Exchange Online TCP 443 (HTTPS) Exchange Server on-premises EWS, Autodiscover, migrações
Exchange Server on-premises TCP 443 (HTTPS) Exchange Online EWS, Autodiscover, migrações
Exchange Server on-premises TCP 80 (HTTP) ctldl.windowsupdate.com Atualização da Certificate Trust List (CTL)

Importante: A lista completa de endpoints IP do Exchange Online e Microsoft 365 está disponível em Microsoft 365 URLs and IP address ranges. Esses endpoints são dinâmicos e atualizados regularmente pela Microsoft — configure o firewall para permitir os ranges documentados, não IPs individuais.

Autenticação e Protocolos por Endpoint

Endpoint Porta Autenticação Protocolo
SMTP (fluxo de e-mail) TCP 25 Baseada em certificado SMTP/TLS mútuo
Autodiscover TCP 443 Microsoft Entra Auth System WS-Security
EWS (Free/Busy, MailTips) TCP 443 Microsoft Entra Auth System WS-Security
Migração de caixas postais (MRS Proxy) TCP 443 NTLM/Basic HTTPS

9. Configuração do EdgeSync (se aplicável)

Se a organização utiliza Edge Transport Servers, o EdgeSync precisa estar configurado e funcional antes de executar o HCW. O EdgeSync sincroniza as informações de configuração necessárias entre o servidor Mailbox e o Edge Transport, e precisa ser reexecutado sempre que um novo CU for aplicado ao Edge Transport.

# Verificar status do EdgeSync
Test-EdgeSynchronization -FullCompareMode

10. Microsoft .NET Framework

A versão do .NET Framework necessária para executar o HCW e para o funcionamento do Exchange varia por versão. Consulte a Exchange Server Supportability Matrix para verificar a versão compatível com o seu Exchange.

# Verificar versão do .NET instalada no servidor
(Get-ItemProperty "HKLM:SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full").Release

Ferramentas de Verificação Recomendadas

Antes de iniciar o HCW, execute as verificações abaixo:

1. Microsoft Remote Connectivity Analyzer

testconnectivity.microsoft.com

Testa: – Conectividade Autodiscover – EWS externo – Sincronização, notificações e disponibilidade

2. Mail Migration Advisor

Disponível no Microsoft 365 Admin Center

Gera um guia passo a passo personalizado para o seu ambiente, cobrindo pré-requisitos e etapas de configuração.

3. Exchange Server Health Checker

Script do time do Exchange disponível no GitHub oficial da Microsoft, que verifica a saúde geral do ambiente Exchange antes de operações críticas.

Checklist de Pré-Requisitos

Use esta lista antes de iniciar o Hybrid Configuration Wizard:

Próximo Artigo

Com os pré-requisitos atendidos, o próximo passo é entender os diferentes tipos de deployment híbrido disponíveis — Classic Full Hybrid vs. Modern Hybrid com Hybrid Agent — e escolher a topologia adequada para o seu ambiente.

Referências Técnicas Microsoft

Artigo publicado em chesley.com.br | Série: Exchange Hybrid — Da Teoria à Produção