Exchange 2016 não faz proxy ao Exchange 2010 em modo coexistente com o Load Balancer F5 BigIP

Logo após a instalação do Exchange 2016 em coexistência com o Exchange 2010, solicitei que fosse criada duas regra no balanceador F5 BigIP para balanceamento de ambos os servidores, uma para acesso interno e outra externo. Me foi fornecido então os VIPs do balanceador, eu adicionei em meu HOSTS file e comecei a fazer os testes. Internamente a coisa funcionava normalmente, as mailboxes de teste no novo Exchange 2016 se conectavam diretamente nele via MAPI over HTTP, e respectivamente as mailboxes no Exchange 2010 se conectavam internamente através do endereço de CAS Array – que é um comportamento esperado, até ai nada de anormal.

Entretanto a coisa começou a ficar estranha ao ser realizado os testes de acesso externo. As mailboxes de testes no Exchange 2016 se conectavam normalmente via MAPI over HTTP, todavia eu não conseguia acessá-las no Exchange 2010 através do Exchange 2016 – via OWA ou ActiveSync funcionava. Eu fiz questão de revisar todas as configurações de todos os CAS, como por exemplo os métodos de autenticações do Outlook Anywhare e IIS. Tudo estava perfeitamente correto, método de autenticação NTLM, e o IISAuthMethod configurado como NTLM – o que é um requisito da Microsoft.

2

Analisando logs de HTTPProxy, não achei nada de requisição que viesse do balanceador, o que me fez ter a ideia de solicitar um by-pass do balanceador ao time responsável, e BINGO! Sem o balanceador no meio, o proxy fluía perfeitamente, com o balanceador não.

LOG:

Realizei uma rápida modificação no meu DNS externo para tentar obter alguma log através do Remote Connectivity Analyzer, pois por mais que soubéssemos que o problema não era no Exchange, o time responsável pelo balanceador não estava conseguindo encontrar uma solução para o problema. Logo após o test de Outlook Conectivity, obtive a seguinte log:

Testing HTTP Authentication Methods for URL https://mail.domain.com/rpc/rpcproxy.dll?cas1.domain.local:6002.
  The HTTP authentication test failed.
Additional Details
Exception details:
Message: The underlying connection was closed: An unexpected error occurred on a receive.
Type: System.Net.WebException
Stack trace:
at System.Net.HttpWebRequest.GetResponse()
at Microsoft.Exchange.Tools.ExRca.Extensions.RcaHttpRequest.GetResponse()
Exception details:
Message: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
Type: System.IO.IOException
Stack trace:
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
at System.Net.FixedSizeReader.ReadPacket(Byte[] buffer, Int32 offset, Int32 count)
at System.Net.Security._SslStream.StartFrameHeader(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security._SslStream.StartReading(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security._SslStream.ProcessRead(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.TlsStream.Read(Byte[] buffer, Int32 offset, Int32 size)
at System.Net.PooledStream.Read(Byte[] buffer, Int32 offset, Int32 size)
at System.Net.Connection.SyncRead(HttpWebRequest request, Boolean userRetrievedStream, Boolean probeRead)
Exception details:
Message: An existing connection was forcibly closed by the remote host
Type: System.Net.Sockets.SocketException
Stack trace:
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
Elapsed Time: 737 ms.
 

Resolução:

Após quase uma semana de troubleshooting, entendemos o que estava ocorrendo com o F5 BigIP. A pessoa em que criou as regras de balanceamento para o Exchange 2016, utilizou o template disponível default para tal, o problema é que esse tal template ele é literalmente configurado APENAS para o Exchange 2016, porque eu digo isso ?

No template automaticamente é configurado a opção de aceitação apenas do protocolo MAPI over HTTP. O problema é que esse é um protocolo default apenas do Exchange 2016 – salvo exceção do Exchange 2013 com SP1 que se pode configurar manualmente, mas não é o protocolo default – e o Exchange 2010 jamais saberia utilizar esse protocolo.

Portanto no autodiscover da mailbox no Exchange 2010, será retornado informações para conexão em RPC over HTTP (Outlook Anywhare) e RPC (CAS Array Endpoint), o que significa que o Outlook jamais se conectara utilizando MAPI over HTTP. E no resumo da opera, no momento em que o Outlook se conectava via RPC over HTTPS, o BigIP realizava o drop por não aceitar o tipo de protocolo.

Mudamos a regra para a seguinte opção: Outlook cliente will use both MAPI-over-HTTP and RPC-over-HTTP

F5 iRule Exchange Server 2016

A partir daí, o problema foi sanado.

Nota:

É importante que fique claro, em um ambiente coexistente entre Exchange 2010 e 2016, os protocolos funcionaram sempre assim:

MAPI over HTTP: Utilizado somente por mailbox no Exchange 2016 internamente e externamente.

RPC over HTTP: Utilizado somente externamente para mailboxes no Exchange 2010, seja com proxy através do Exchange 2016 ou não.

RPC over TCP: Utilizado somente internamente para conexão direta no CAS array do Exchange 2010.

Portanto minha dica é: antes de iniciar os testes de proxy entre as versões, teste sempre primeiramente com um by-pass no balanceador, com a conexão direta no Exchange. Isso evitará que se perca horas de troubleshooting achando que o problema é no Exchange.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *