Exchange Server – Arquitetura da função de Acesso para Cliente (Client Access Server)

Hoje a ideia é falarmos um pouco sobre a arquitetura do Exchange Server, focando na estrutura de conectividade de clientes conhecida como Client Access Server, ou CAS.  Essa estrutura vem sofrendo alterações desde a sua concepção, quando se chamava Front-End, e tinha a função de estabelecer as conexões externas do ambiente de mensageria.

https://blogdolopez.files.wordpress.com/2016/11/exchange_frontend.jpg?w=604&h=435

Já nas suas próximas versões, ele não teria essa “função” apenas, mas seria o responsável pela conectividade de clientes aos recursos do Exchange Server, funcionando como uma espécie de Proxy das conexões, tratando cada uma delas e enviando/redirecionando para seu respectivo recurso solicitado, seja ele um Outlook Web Access (OWA), ActiveSync ou Outlook cliente.

Aproveitando os exemplos citados, este último (Outlook cliente) usa um protocolo chamado MAPI/RPC (Exchange RPC) que se conecta ao servidor CAS para estabelecer a comunicação com os clientes. Esse protocolo nasce no Exchange Server 2007 e perdura até os dias de hoje, porém já com seus dias contados. Atualmente, no Exchange Server 2016, ele não mais é o protocolo padrão de comunicação dos clientes. Percebeu-se que o protocolo, que não foi originalmente desenhado para este tipo de serviço mas readequado para tal, era sensível a oscilações de rede. E a necessidade fez surgir o MAPI/HTTP.

A junção de um protocolo de comunicação com um protocolo da Web já podia ser vista no Outlook Anywhere (RPC/HTTP), feature que disponibiliza o acesso aos recursos de conectividade de cliente mesmo fora da rede local. Falaremos mais detalhes sobre o Anywhere em outro post aqui do blog.

A conectividade é estabelecida com o CAS, simplesmente para que ele finalize o salto de comunicação com o Mailbox Server, entregando o recurso que o usuário realmente precisa, que é a sua mailbox. É nessa hora que o RPC entra em ação e começa o processo de conectividade conjunta dos usuários, unindo Client Access e Mailbox Servers.

Esse processo pode ser aprimorado também por um balanceador de carga, sendo este entregue através de um software de NLB, como por exemplo o Windows Load Balance (WLB), ou um próprio hardware ou appliance para tal, como temos vários third-party no mercado, como exemplo BigIP, NetScaler, Kemp e outros.

https://blogdolopez.files.wordpress.com/2016/12/hlb1.jpg?w=604

 

No Exchange Server 2010, essa conexão era estabelecida e eram entregues para os clientes os nomes dos servidores membros do CAS Array, um agrupamento de todos os servidores CAS que fossem do mesmo site, ou tivessem semelhanças de ambiente. No Exchange 2007, não existia ainda o CAS Array, mas a forma de conexão era bem similar, entregando o nome de conexão do servidor CAS ou do balanceador de carga existente (NLB/HLB). Já no Exchange 2013 e posterior, esse processo foi melhorado através da entrega do GUID da mailbox do usuário, fazendo com que o nome do servidor ou agrupamento em questão não importasse mais. Isso trouxe uma melhoria na conectividade, principalmente na questão de alta disponibilidade do ambiente, pois os usuários poderiam ser movidos em tempo real, sem impacto.

https://blogdolopez.files.wordpress.com/2016/12/new_cas.png?w=604&h=365

Como os usuários passaram a se conectar diretamente à estrutura de CAS, usando novos tipos de protocolos, alguns recursos que existiam no passado precisaram ser revistos, como por exemplo o Session Afinity. Esse cara fazia uma função simples e bem interessante: toda vez que um usuário se conectasse a um servidor CAS, ele guardaria esse registro, para que nas próximas vezes ele pudesse se conectar da mesma forma, numa espécia de “preferência de atendimento”.

Outro ponto muito importante a ser realçado sobre os servidores CAS é a configuração dos namespaces (URLs) em caso de coexistência. Esse fator é de extrema importância, tendo em vista que ambientes legados (Exchange 2007 ou anterior) precisam receber a configuração das URLs legadas, para que a configuração de Proxy dos CAS mais atualizados possa ocorrer com sucesso. A falta dessa configuração gera transtornos e falhas no processo de obtenção e conexão final da mailbox, principalmente dos usuários que estão no ambiente legado. Esta configuração não se faz necessária no Exchange Server 2010 ou superior, tendo em vista que a função de Proxy destas faz a detecção automática da versão da mailbox do usuário e já a redireciona para o ambiente correto.

Mas não é só de conectividade de clientes finais que o CAS vive …ele também fornece recursos para as conexões de outras necessidades, como por exemplo as APIs para desenvolvimento, através do antigo e famoso MAPI/CDO, e do atual REST API, que permitem que funcionalidades e aplicativos de desenvolvedores se conectem ao CAS e forneçam recursos e acessibilidade ao ambiente. Não podemos deixar de citar também o EWS, Exchange Web Services, que também é hospedado no CAS e fornece de forma semelhantes um Web Services de consulta e ativação de serviços para integração com o Exchange Server, como é o caso do Skype for Business e sua função de salvamento do Conversation History.

Por fim, citamos uma das novidades que surgiu no Exchange Server 2013 e que continua no Exchange Server 2016, que é a inclusão de um serviço de Transporte SMTP no CAS, o chamado FrontEnd Transport Service. A função do mesmo é ser mais uma camada de comunicação do protocolo SMTP com o Transport Pipeline antes da saída da organização, garantindo em alguns casos até uma maior proteção do ambiente, visto que como a função de Hub Transport foi integrada aos Mailbox Servers, seria necessário deixar os mesmos com conectividade a internet para finalizar a opção de transporte, num cenário sem a utilização do Edge Server. Para maior confiabilidade, a função de Transporte no CAS eliminaria a necessidade de conectividade à internet pelo Mailbox Server.

Nosso intuito nesse artigo foi sintetizar como um todo a função de Client Access Server do ambiente de Exchange Server. Os maiores detalhes podem ser encontrados nas documentações de referência citadas ao final.

Espero que tenham gostado!

Abços,

Referências:

Entendendo as Funções Back-End e Front-end do Exchange Server

Exploring Exchange 2010 RPC Client Access service

Exchange 2013 Client Access Server Role

Understanding RPC Client Access

Demystifying the CAS Array Object – Part 1

**
**

Bruno Lopes – MVP Office Servers and Services | Facebook Page | YouTube Channel | Twitter | LinkedIn