Desmitificando o Objeto de Matriz CAS - Parte 1

Artigo original publicado no sábado, 24 de março de 2012

Desde seu lançamento em 2009, o interesse no Exchange 2010 tem sido fantástico. Enquanto trabalhamos com os clientes para educá-los e prepará-los para mover para o Exchange 2010, descobrimos alguns conceitos errados comuns. Uma tendência tem a ver com as concepções erradas sobre o objeto de matriz do Servidor de Acesso do Cliente ou objeto de matriz CAS. O redator técnico e blogger frequente Scott Schnoll sugeriu que eu escrevesse sobre isso... quer dizer... escrevesse no teclado (?) quando fosse comentar sobre esta tendência em um grupo de distribuição da Microsoft interno, portanto aqui estamos com essa publicação.

Eu não irei passar por todos os aspectos técnicos de um objeto matriz CAS nesta publicação. Isso já foi coberto maravilhosamente por Nagesh Magadev em uma publicação anterior: Explorando o serviço de Acesso do Cliente do Exchange 2010 RPC.

A lista a seguir é um conjunto de verdades que vários clientes não sabem quando se fala sobre um objeto de matriz do CAS que iremos tentar desmitificar. A Parte 1 irá discutir os primeiros três itens e eu irei cobrir os últimos três itens na parte 2.

1. Um objeto de matriz CAS não faz balanceamento de carga do seu tráfego
2. Um objeto de matriz CAS não tem o serviço de Descoberta Automática, OWA, ECP, EWS, IMAP, POP ou SMTP
3. Um fqdn do objeto de matriz CAS não precisa fazer parte do seu certificado SSL
4. Um objeto de matriz CAS não deve ser resolvido através do DNS por clientes externos
5. Um objeto de matriz CAS não deve ser configurado ou alterado após criar bancos de dados de caixa de correio do Exchange 2010 e movendo caixas de correio para bancos de dados
6. Um objeto de matriz CAS não deve ser configurado mesmo se você tiver apenas um CAS ou um servidor multi-função único.

Confusos? Ótimo. Vamos tentar corrigir isso pois o melhor que podemos fazer é falar sobre cada um deles por vez. Você verá alguns nomes de servidores neste artigo, portanto, porque eu não mostro o que estou trabalhando em meu laboratório?

OK, vamos começar!

1. Um objeto de matriz CAS não faz balanceamento de carga do seu tráfego

Um objeto de matriz CAS não realiza balanceamento de carga. É um objeto do Active Directory usado para automatizar algumas funções no Exchange e só. A documentação do Exchange 2010 fala em todos os lugares que é recomendado usar balanceadores de carga (LB) para balancear a carga do tráfego CAS. Portanto, o que eu quero dizer ao falar que o objeto de matriz CAS não realiza balanceamento de carga?

O que você realmente está fazendo com um balanceador de carga é balancear o tráfego entre um pool de CAS ou você pode chamar de matriz de CAS - mas não o objeto de matriz de CAS por si. A diferença é sutil porém distinta; talvez você não distinguiu os nomes para ajudar a evitar a confusão.

A principal razão, e talvez a única, para qual um objeto de matriz CAS existe é para preencher automaticamente o atributo RpcClientAccessServer de qualquer banco de dados de caixa de correio do Exchange 2010 novo criado no mesmo site do Active Directory (como o objeto de matriz CAS).

O atributo RpcClientAccessServer é usado para dizer aos clientes do Outlook durante o processo de criação de perfil qual será o nome do servidor no perfil. É basicamente isso, não há mágica ocorrendo e quando você tiver criado seu objeto de matriz CAS, ele é simplesmente um objeto no Active Directory e não há balanceamento de carga ocorrendo neste momento.

O resto cabe a você. Cabe a você:

• Criar um registro ‘A’ no DNS que irá permitir a máquina cliente resolver o hostname para um endereço IP. Este endereço IP provavelmente será um IP virtual (VIP) do LB atingível apenas por clientes internos. Este VIP é onde o Outlook ou qualquer outro aplicativo com capacidade MAPI/RPC irá se conectar para obter acesso aos recursos da caixa de correio do Exchange 2010.
• Configure sua solução de balancemento de carga para passar tráfego para o pool de servidores CAS através do VIP.

O próprio CAS não tem ideia se há qualquer balanceamento de carga ocorrendo.

Você também pode se confundir pelo o que pode ser visto após criar um objeto de matriz CAS usando o cmdlet New-ClientAccessArray cmdlet ou exibir um objeto de matriz CAS pré-existente usando o cmdlet Get-ClientAccessArray.

Aqui eu estou criando um novo objeto de matriz CAS com meu laboratório com o nome CASArray-A, o FQDN do outlook.lab.local e o site do Active Directory nomeado adequadamente Site-A.

Figura 1: Criando uma matriz de Acesso do cliente

Antes de mais nada, meus campos FQDN e Nome não correspondem porque o Nome é um nome de exibição, é puramente cosmético. É o que você deseja para que você saiba para que um objeto de matriz CAS está sendo usado. O FQDN é o registro que você deve criar no DNS ou os clientes nunca poderão resolver para um endereço IP ser conectado. Neste ponto, eu lembrarei você que pode haver apenas um objeto de matriz CAS por site do Active Directory.

Portanto, porque a propriedade Membros é preenchida com dois CAS logo após a criação? Eu não disse que não há balanceamento de carga ocorrendo neste ponto? Parece que eu menti para você, não é?

Para ser honesto, a propriedade Membros é um pouco incorreta. Se você não leu as etapas para criar um objeto de matriz CAS, você pode achar que acabou. Você criou seu objeto de matriz CAS e pode ver que dois CAS se juntaram automaticamente à matriz. Neste momento, você pode estar fora em uma celebração ou ter ido para uma boate para roubar alguns biscoitos deste cara. Ainda não meu amigo!

Como associamos o objeto de matriz CAS ao site do Active Directory Site-A, o cmdlet simplesmente encontra todos os servidores de Acesso do Cliente registrados como residentes no Site-A e os lista na coluna Membros. Eu gostaria de dizer aos clientes para pensar neste coluna como a coluna de Membros em Potencial ou como meu colega Kamal Abburi, outro PFE aqui na Microsoft, sugere é a coluna de Membros CAS do Site. É possível adicionar estes servidores de Acesso do Cliente como nós em sua solução de balanceamento de carga pois eles todos residem no mesmo site do Active Directory. Mas até que o balanceador de carga seja configurado, não temos balanceamento de carga.

Como os cmdlets sabem qual site o CAS está? Bem, estou feliz que você tenha perguntado, porque iremos detalhar o melhor amigo de todos, o AdsiEdit.msc e a partição de Configuração do Active Directory para encontrar feijões mágicos.

Figura 2: O atributo msExchServerSite de um servidor do Exchange 2010 contém o site do Active Directory que o servidor reside

Cada Exchange server possui um atributo msExchServerSite que contém o site do Active Directory onde reside. Caso você esteja se perguntando, sim, é atualizado dinamicamente se você mover um Exchange server para um novo site e o serviço de Topologia do Microsoft Exchange Active Directory tem a chance de executar e atualizar algumas coisas. Mas o atributo AutoDiscoverSiteScope (Parte do Get/Set-ClientAccessServer) não irá ser atualizado dinamicamente e pode ter resultados da Descoberta Automática diferentes até que seja corrigido – dependendo do seu site, servidor e disposição do cliente.

2. Um objeto de matriz CAS não oferece serviço do OWA, ECP, EWS, Descoberta Automática, IMAP, SMTP ou POP

Vamos voltar um pouco para o que um objeto de matriz do CAS realmente faz. Ele preenche o atributo RpcClientAccessServer de um banco de dados da caixa de correio do Exchange 2010, que é usada para dizer ao Outlook onde precisa se conectar ao usar o RPC (por TCP). Para clientes do Outlook Anywhere (HTTPS), indica onde o tráfego que deixa o proxy RPC-por-HTTP precisa se conectar em nome do cliente para poder atingir sua caixa de correio.

Portanto, quais serviços o cliente Outlook tenta conectar ao usar o RPC (por TCP)?

Primeiro, o Outlook se conecta ao objeto de matriz CAS no TCP/135 para se comunicar com o Mapeador de Ponto de Extremidade RPC para descobrir as portas TCP que os seguintes dois serviços estão ouvindo.

1. Acesso do Cliente RPC do Microsoft Exchange (chamado MSExchangeRPC)
2. Catálogo de Endereços do Microsoft Exchange (chamado MSExchangeAB)

Isto é para o modo RPC (por TCP)!

Clientes do Outlook Anywhere (chamado RPC por HTTP) conectam-se ao componente do proxy RPC-por-HTTP no TCP/443 em um CAS resolvendo o hostname externo do Outlook Anywhere ou o que o perfil do Outlook chama no servidor do proxy.

Uma observação interessante para qualquer pessoa, o Outlook adiciona de forma automática e silenciosa o /rpc/rpcproxy.dll no nome do servidor especificado, pois isto é o que ele realmente precisa para se conectar, mas solicitamos que as pessoas digitassem estes nomes, como nós usávamos nos dias do Outlook 2003. Você pode imaginar quantas pessoas esqueceram isso ou entenderam errado?

Figura 3: Especificando a URL do Proxy RPC no Outlook 2003

O tráfego é roteado do proxy RPC-por-HTTP para o ponto de extremidade MAPI/RPC adequado usando uma lista de codificação, ao invés de portas TCP atribuídas dinamicamente, sendo elas TCP 6001, TCP 6002 e TCP 6004. O hostname externo do Outlook Anywhere não é o mesmo no FQDN e no objeto de matriz CAS e eu explicarei por que posteriormente.

Um cliente pode também realizar conexões HTTPS em serviços como a Descoberta Automática, downloads OAB, EWS, POP ou IMAP, mas estes serviços são definidos por métodos totalmente diferentes como as URLs de diretórios virtuais ou o valor AutoDiscoverServiceInternalUri. Nenhum destes serviços adicionais são servidos pelo objeto de matriz CAS, pois nenhum deles está usando o RPC, embora seja provável que estejam conectando ao mesmo servidor. O FQDN do objeto de matriz CAS pode compartilhar o mesmo VIP que outra URL de serviço, mas recomendamos que o FQDN do objeto de matriz CAS não seja o mesmo que outras URLs de serviço, se o DNS dividido estiver em uso. Falaremos dessa última recomendação posteriormente.

3. Um FQDN do objeto de matriz CAS não precisa fazer parte da sua lista de nome de certificado SSL

Este é um erro muito comum, geralmente difundido devido ao item acima. Os certificados SSL no realm deste artigo são utilizados apenas quando desejamos fazer algo como estabelecer uma sessão HTTP protegida por SSL. como o RPC (por TCP) não é uma sessão HTTP, não será protegido com SSL e, portanto, não precisa que o FQDN do objeto de matriz CAS seja incluído na lista de nome de assunto do certificado SSL. Vamos dar uma olhada nisso.

Abaixo está o Outlook 2010 no modo MAPI/RPC conectado a um objeto de matriz CAS do Exchange 2010.

Figura 4: Conexões RPC do Outlook 2010 (por TCP) para o CAS do Exchange 2010

Nós podemos ver que realizou um diretório e duas conexões de email. Na saída netstat (sobreposta acima da captura de tela) podemos ver que a máquina realizou uma conexão do mapeador de ponto de extremidade (TCP 135) para o objeto de matriz CAS, assim como conexões para o TCP 59531 e TCP 59532, que representam portas TCP atribuídas estaticamente para os serviços MSExchangRPC e MSExchangeAB respectivamente neste laboratório.

No lado do servidor podemos ver os serviços ouvindo usando o comando netstat –n –b.

Figura 5: Os Serviços do Outlook que precisam ser conectados quando usar o RPC (por TCP)

Como esperado, mostra que nenhum dos serviços está sendo contatado por HTTP (para TCP 443). Isto é o porque você não precisa do FQDN do objeto de matriz CAS no certificado SSL.

Pensar na sua necessidade do FQDN da matriz CAs no certificado SSL pode algumas vezes ser confundido com a forma que o Outlook exibe as conexões enquanto está no modo HTTPS, como visto abaixo.

Figura 6: Conexões do Outlook Anywhere

Desta vez vemos que o Outlook 2010 realizou duas conexões de email e uma conexão de Pasta Pública quando a captura de tela foi realizada e também podemos ver que estamos usando HTTPS. De dentro do Outlook parece como se estivéssemos conectados o outlook.lab.local e E2K10-MLT-01.lab.local, que estamos por um lado, mas utilizando o netstat novamente, veremos que estamos realmente conectados ao proxy RPC-por-HTTP localizado em webmail.lab.local no TCP/443 (HTTPS). O Outlook irá sempre exibir qual servidor está eventualmente conectado para dados por si só ou através do proxy RPC-por-HTTP. Se você está pensando em porque vemos 6 conexões pelo netstat ao invés de três, é porque o HTTP é um protocolo half-duplex e, portanto, estabelece um RPC_DATA_IN em um canal RPC_DATA_OUT para cada conexão vista dentro do Outlook.

Você também pode estar pensando, “Espere O Outlook 2007 e 2010 criptografam sessões RPC por padrão! Precisamos ter o nome no certo!” Errado meus amigos, porque a configuração de criptografia que você vê abaixo utiliza a criptografia RPC e não tem nada a ver com o SSL. A comunicação ainda está ocorrendo por RPC e não por HTTPS.

Figura 7: Ao conectar usando o RPC (por TCP), o Outlook usa a criptografia RPC

Simplesmente não! Se um objeto de matriz CAS encontra uma Autoridade de Certificação e o CA diz: “Ei amigo, você realmente precisa de mim! Vamos lá, eu irei vender um curinga bem barato!” o objeto de matriz CAS iria simplesmente responder “Querido, o crachá não importa!” e provavelmente usará o CA para abrir um pistache. Agora, isso claro se você seguir nossa recomendação de usar um FQDN diferente para o objeto de matriz CAS do que você está usando para o outro serviço FQDN(s). Sim, estou começando a entender porque...

Eu espero que a Parte 1 deste artigo tenha sido útil para você até o momento ao entender os problemas geralmente não compreendidos com os objetos de matriz CAS e espero que você fique ligado na Parte 2 posteriormente, onde iremos cobrir os três erros comuns sobre os objetos de matriz CAS.

Brian Day
Engenheiro de Campo Premier, Mensagem

Esta é uma publicação localizada. Encontre o artigo original em Demystifying the CAS Array Object - Part 1