Fila do Exchange & R: Lidando com ambientes híbridos

Configurar implantações do Exchange híbrido com recursos relacionados ao Office 365 pode ser confuso no melhor, mas vale a pena o esforço.

Henrik Walther

Coexistência de híbrido

**P.**Nós atualmente estamos Configurando uma coexistência baseada no Exchange 2010. Nós estamos preparando para migrar caixas de correio de nossa organização local do Exchange 2007 para o Exchange Online no Office 365. Estamos usando servidores baseados no Exchange 2010 para a implantação de híbrido, porque nós ainda não tiver atualizado nosso inquilino do Office 365.

Nós somos uma empresa de grande porte com usuários do Exchange usando mais de 30 diferentes domínios de SMTP. Temos usuários com muitos domínios de endereço de email principal diferente. Alguns usam alias@contoso.com, outros usam alias@fabrikam.com e assim por diante. Nós queremos a convivência quando estiver trabalhando com o Exchange Online e a organização local do Exchange 2007 para todos os usuários.

Isso exigiria-na criar um registro DNS de descoberta automática para todos os domínios de SMTP, como adicionar o autodiscover totalmente qualificado FQDN nome de domínio () para o certificado de rede (SAN) de área de armazenamento estamos planejando usar nos servidores Exchange 2010 híbrido?

**.**Com servidores mais antigos de híbrido — ou seja, híbrido servidores executando o Exchange 2010, você precisará criar um registro de descoberta automática de DNS para todos os domínios de SMTP. Também, o certificado de SAN tem de incluir todos os registros DNS de descoberta automática usada na lista de SAN. Por exemplo, se você usou três domínios SMTP (contoso.com, fabrikam.com e brinquedos.com) em sua organização do Exchange e você queria configurar a coexistência de todos os três com o Exchange Online no Office 365, você precisa criar os seguintes registros de descoberta automática de DNS:

• Autodiscover.contoso.com
• Autodiscover.fabrikam.com
• Autodiscover.wingtiptoys.com

Você também precisa incluir esses registros no certificado SAN. Você poderia usar registros CNAME para descoberta automática redirecionamento, mas isso não muda o fato que você tem que adicionar todos os registros de descoberta automática para o certificado de SAN. Também, implantações do Exchange híbrido não oferecem suporte a redirecionamento de descoberta automática SRV-baseado.

Com o recurso de descoberta automática de domínio, você tem a opção de configurar um dos seus domínios SMTP como o domínio de descoberta automática. Ao fazer isso, você pode remover os seguintes requisitos:

• A necessidade de criar um registro de descoberta automática para todos os domínios de SMTP no DNS, exceto para o domínio que você definir como o domínio de descoberta automática
• A necessidade de incluir o FQDN do Autodiscover para todos os domínios SMTP usados no certificado SAN

Isso é realmente uma grande novidade do Exchange Server 2013. O grupo de produtos Exchange sempre introduz novas funcionalidades da versão mais recente, mas agora e então eles também escolher a porta de volta um recurso para uma versão anterior do Exchange. Quando se trata de recurso de domínio de descoberta automática, isso aconteceu com o lançamento do Exchange 2010 SP3 RU1 (você pode baixá-lo aqui). Sim, ao aplicar RU1, você pode usar o recurso de descoberta automática de domínio em uma configuração híbrida baseada em Exchange 2010. Para definir o domínio de descoberta automática, use o seguinte comando:

Set-HybridConfiguration –Domains "contoso.com, fabrikam.com", "autod:wingtiptoys.com"

Então você pode ver o domínio de descoberta automática tiver sido definido, executando o cmdlet Get-HybridConfiguration (ver Figura 1).

Figura 1 executar o cmdlet Get-HybridConfiguration para confirmar o domínio de descoberta automática é definido.

Mensagens faltantes

**P.**Apenas configurado uma coexistência baseada no Exchange 2010, a fim de levantar a coexistência do Exchange e a corrida entre o Exchange 2003 e Exchange Online no Office 365. Porque necessitamos de fluxo de mensagens dentro e fora do Exchange Online para passar por nossos servidores locais do Exchange 2010 híbrido, escolhemos a seguinte opção no Assistente de configuração híbrida para configurar transporte centralizado: "Encaminhar todas as mensagens de Internet através de servidores de Exchange no local. Isto é normalmente feito por motivos de conformidade."

Configurado a coexistência pelo livro. Vemos o Assistente de configuração híbrida criou o necessário receber e enviar conector no local e os conectores de entrada e de saída no Forefront Online Protection for Exchange (FOPE). O nome de domínio que é usado para forçar o TLS do FOPE para servidores locais do híbrido é o certificado de terceiros nos servidores do híbrido. Está definido corretamente no "receber conector que aceita sessões SMTP das faixas de IP do FOPE."

Apesar disso, os e-mails enviados do Exchange Online no Office 365 para destinatários nas organizações Exchange no local (como destinatários externos) nunca são entregues. Ao usar a mensagem de rastreamento no centro de administração do FOPE, vemos o seguinte erro:

"Endereço IP do alvo primário de 451 4.4.0 respondido com: 'Falha de validação de certificado da 454 4.7.5.' Tentativa de failover para host alternativo, mas que não teve sucesso."

Realmente estamos presos aqui. Está-se perguntando se você tem alguma idéia de como solucionar isso ainda?

**.**Na verdade, eu vi esta mensagem de erro em um cenário de implantação do Exchange 2010 híbrido. Quando configurar uma configuração híbrida, usando o Assistente de configuração híbrida, uma das coisas que ele cria é receber um novo conector chamado "entrada do Office 365" em cada servidor de transporte de híbrido (ver Figura 2).

Figura 2 a configuração híbrida assistente cria a nova entrada do conector de recebimento do Office 365.

Este conector é definido para aceitar apenas sessões de SMTP de entrada de um conjunto específico de intervalos de IP, que são associados com o serviço FOPE usado no Office 365 (ver Figura 3).

Figura 3 a entrada do conector de recebimento do Office 365 só recebe mensagens de um conjunto específico de endereços IP.

Isso receber conector também será definido como o FQDN que corresponda ao FQDN do certificado usado para a coexistência (ver Figura 4).

Figura 4 a entrada das configurações do conector de recebimento do Office 365 corresponder ao FQDN do certificado híbrido.

Isso também é definido no certificado para coincidir com o FQDN no conector de saída no FOPE, assim você pode usar forçado TLS. Tudo isso foi criado pelo livro, como você explica que você fez, mas ainda gera a mesma mensagem de erro que você recebeu para mensagens de saída do Exchange Online.

Enquanto olha para o log de protocolo para o conector de recebimento nos servidores híbrido, eu vi algo estranho. Sessões de SMTP de entrada do FOPE estavam indo para o padrão de conector de recebimento. Porque o IP correto varia e outras configurações estavam corretas sobre o Office 365 conector de recebimento, isso não fazia sentido. Então, notei que, embora as sessões de SMTP de entrada se apresentaram como FOPE, o endereço IP de origem era um endereço IP privado. Verifica-se que era um endereço IP virtual (VIP) em um balanceador de carga que distribuídas sessões de SMTP de entrada entre os servidores de híbrido Exchange 2010.

Eu adicionei o conector de recebimento privado VIP para a lista de intervalos IP do servidor remoto sobre o Office 365. Em seguida, as mensagens foram entregues com sucesso. Se você estiver usando um balanceador de carga para SMTP, verifique se você está lidando com o mesmo problema.

A tecla direita

**P.**Nós acabou de configurar dois servidores de híbrido de Exchange Server 2013. Está-se perguntando se podemos usar uma Exchange Server 2013 híbrido edition chave para esses servidores como podemos com servidores do Exchange 2010 híbrido?

**.**As coisas ainda estão sendo resolvidas agora mesmo quando se trata da chave de produto utilizada para licenciamento devidamente Exchange Server 2013 como servidor híbrido. Então, por agora, basta use Exchange Server 2013 no modo de teste. Quando o julgamento expira, ele não deve ter qualquer impacto sobre sua coexistência. Resultará apenas em telas do nag extra.

Henrik Walther é um Microsoft Certified Master: Exchange 2007 e MVP em Exchange com mais de 18 anos de experiência na atividade de ti. Ele trabalha como consultor sênior da equipe de nuvem do Office 365 com a Dinamarca de serviços Microsoft e como redator técnico da Biblioso Corp. (uma empresa norte-americana especializada em gestão de serviços de documentação e localização). Ele tem mais de 14 anos de experiência, escrever livros, artigos, colunas, white papers e boletins informativos.

Conteúdo relacionado

• Fila do Exchange & R: Equivaleria a praticável

• Fila do Exchange & R: Gestão da migração

• Fila do Exchange & R: Exchange está sempre mudando