Demora muito tempo…

Artigo original publicado segunda-feira, 20 de fevereiro de 2012

Depois de nosso recente anúncio da liberação do Rollup 1 de Atualização para o Exchange 2010 Service Pack 2, você verá que liberamos várias correções e eu gostaria de falar sobre uma especificamente e, talvez ao mesmo tempo, fornecer algum background sobre como problemas como esses surgem e como os corrigiremos.

A correção específica é uma mencionada como 2556113, com o título Demora muito tempo para um usuário fazer download de um OAB em uma organização do Exchange Server 2010.

Como um título como esse, você pode pensar que nós simplesmente descobrimos uma maneira de fazer downloads ‘mais rápidos’ do OAB. Talvez você comece a achar que nós fizemos isso simplesmente excluindo aleatoriamente alguns dos usuários no OAB, aqueles que você não conhece, as pessoas que trabalham na contabilidade no quarto andar, por exemplo. Talvez tenhamos tentado reduzir os detalhes que incluímos no OAB, talvez simplesmente removendo informações desnecessárias como nomes de família, localização de escritórios ou números de telefone. Ou talvez nós simplesmente aumentamos a velocidade da Internet. Porque isso é realmente fácil.

Bem, nós não fizemos nada isso; (embora estejamos pesquisando em toda a Internet para ver o que podemos fazer a respeito, já que soa assustador) em vez disso, nós adicionamos uma lógica para assegurar que o Outlook tente fazer download do OAB de um CAS mais próximo de si mesmo.

“Por quê?” você pergunta. Bem, é uma boa pergunta e eu respondo com “Como diz o artigo KB, ‘Considere o seguinte cenário….”

• Você tem dois sites do Active Directory em uma rede lenta em uma organização do Microsoft Exchange Server 2010.
• Você tem um servidor Exchange Server 2010 Client Access e um servidor Exchange Server 2010 Mailbox em um site do Active Directory.
• Você tem um servidor Exchange Server 2010 Client Access e adiciona um usuário do Office Outlook no outro site do Active Directory.
• O usuário cuja caixa postal está localizada no site do Active Directory diferente tenta fazer download do Exchange Offline Address Book (OAB).

Neste cenário, demora muito tempo para fazer download do OAB.

Bem, sim. Sem brincadeira. Realmente pode demorar. Se você tiver um OAB grande, pode realmente demorar muito tempo. Mas vamos expandir um pouco o cenário, já que francamente há algumas informações que eu acho que você deve conhecer e ter um site AD sem nada nele a não ser um CAS não parece algo muito inteligente para a maioria das pessoas.

Sendo assim, considere este cenário mais detalhado;

• Você tem uma implementação centralizada. Todas as caixas postais estão em um local central.
• Você tem milhares de locais pequenos nos quais as pessoas têm contato e trabalham.
• Estes locais estão conectados ao site central com redes deficientes. Satellite, ISDN, PSTN, dispersão troposférica(Tive um cliente com uma dessas uma vez. Brilhante. Até que teve uma tempestade), parte úmida da cadeia, etc.
• Seu OAB é grande. É grande. Não é pequeno. Selecione a definição que você mais gosta. Basta dizer, é de um tamanho significativo para você se importar.
• Seu cliente do Outlook tenta fazer download do OAB e vem do datacenter central. O cliente do Outlook que está sendo usado pela pessoa ao seu lado faz a mesma coisa e o cara divertido do outro lado também. Todos vocês estão fazendo download do mesmo OAB. Sobre a mesma parte úmida da cadeia. Está ficando muito lento.

Com sorte, você pode ver que todos vocês estão competindo pela mesma largura de banda, enquanto também tentam trabalhar e, apesar da tecnologia do cliente BITS usada para os downloads do OAB ser boa, ela não irá ajudá-lo muito.

Então, você adiciona um CAS a cada local remoto. Na verdade, como o diagrama detalhado em https://technet.microsoft.com/en-us/library/bb232155.aspx sugere. A ideia é que o computador cliente fará download do OAB que precisa do CAS local. Bem, isso pode parecer uma grande ideia – mas não é assim que o Exchange tem funcionado. Antes do 2010 SP2 RU1 que é…

Como funcionava? E por que estou dizendo que a TechNet mentiu para você?

Para responder à primeira pergunta, a URL que o cliente usa para fazer download do OAB é fornecida para o cliente pelo serviço AutoDiscover. E o código AutoDiscover sempre selecionou uma URL para o OAB que você deve estar transferindo por download do site AD no qual está sua caixa postal, não o site AD no qual está seu computador cliente.

Para responder à segunda pergunta, primeiro você deve entender que a TechNet nunca está errada (meus amigos na UE, como Scott Schnoll, sentem profundamente se você disser que seus artigos estão incorretos).  É que apenas, algumas vezes, ela não está certa de um determinado ponto de vista.  A TechNet detalha isso, já que fazia parte da especificação de PM original quando o 2007 estava sendo projetado. Provavelmente, eu não deveria ter dito isso a você, mas era. E isso não foi feito. Essas coisas acontecem em um produto de software com mais de 20 milhões de linhas de código quando as coisas mudam o tempo todo. A TechNet geralmente não mente. Bem, não muito.

Voltemos ao funcionamento. Pense sobre isso um momento. Você tem um OAB de 1 GB. E adiciona uma réplica desse OAB a um CAS no site AD remoto e distante, onde estão os usuários. No entanto, eles nunca o utilizam. (Ok, a não ser que suas caixas postais também estejam no mesmo site AD, mas não é este o cenário, é?). Esse tipo de coisa não funciona. Sim, funciona, ouço você dizer. É um pouco parecido com este diagrama.

O Outlook usa o CAS mais próximo do computador cliente para as solicitações AutoDiscover do cliente (bem, ele deve e nós voltaremos nisso em breve), mas a URL do OAB retornada é para o CAS no mesmo site AD que a caixa postal. Então, apesar de estarmos replicando o OAB para o Site AD B, o cliente pega o OAB do Site AD A.

Um cliente grande com muitos sites pequenos e um OAB enorme nos diz que isso não vai funcionar e que os downloads estão acabando com a largura de banda WAN que ele tem. O que podemos fazer em relação a isso? Parece que há algumas maneiras de resolver isso e tenho que dizer que esta é uma das partes divertidas do meu trabalho, tentar descobrir esse tipo de coisa. É coisa de nerd.

1. Eles podem reduzir o tamanho de seu OAB, acelerar sua WAN, mudar os escritórios remotos para mais perto, etc. Nada disso será uma solução para eles. Mesmo assim, perguntamos.
2. Podemos criar muitos OABs que tenham o mesmo conteúdo. E especificar em um nível por usuário ou por banco de dados o OAB do qual o usuário deve fazer download. Em seguida, temos apenas esse OAB disponível em um local remoto. Consequentemente, o AutoDiscover fornecerá a única URL possível para ele, no local remoto. Agora isso parece bom, exceto pelo fato de que os usuários mudam de site para site. E um download significaria um salto duplo da rede lenta. Nossa!
3. A mesma coisa com as caixas postais – mudar as caixas postais para os locais remotos… elas se movem, isso realmente complicaria a administração e a Alta Disponibilidade e, consequentemente, aumentaria o custo.
4. Podemos fazer um tipo de endereço IP reverso para o mapeamento do site AD. Eu acredito que esta era a maneira original que tínhamos planejado para resolver isso e é realmente um pouco difícil. É difícil porque é necessário garantir que todas as subredes das quais um cliente pode vir estejam nos Sites e Serviços AD e, então, tentar e reverter a engenharia do site AD no qual está o usuário e depois dar uma olhada nos custos de link do site e ...você tem uma ideia, espero. É complexo e anulado pelo NAT ou se a administração não listar cada subrede possível nos Sites e Serviços AD.
5. Podemos ‘interferir’ com o DNS ou o XML de AutoDiscover para tentar e fazer o cliente pensar que está falando com o local centralizado, mas, na verdade, estará falando com uma instância IIS local. Novamente, é difícil, complicado implementar e oferecer suporte e novamente não explicar se você estiver perguntando.
6. Outra coisa. Escolhi este, já que os outros pareciam realmente difíceis.

Volte apenas alguns parágrafos para a sentença que dizia “O Outlook usa o CAS mais perto do computador cliente para as solicitações AutoDiscover do cliente”, aquele para o qual eu disse que voltaria. Vale a pena retornar por causa de algo chamado AutoDiscoverServiceSiteScope.

AutoDiscoverServiceSiteScope é uma configuração do CAS que ajuda o cliente do Outlook a mapear sites AD para o CAS para localizar o CAS mais perto para o cliente parea as solicitações AutoDiscover. Ele faz isso buscando os Service Connection Points (SCPs), que, na verdade, são ponteiros para o serviço AutoDiscover.

Ele funciona da seguinte maneira. Quando um cliente do Outlook inicializa, ele passa para o triângulo, algumas vezes, conhecido como ‘AD’ e procura todos os SCPs colocados lá pela configuração do Exchange. Localiza muitos (esperamos) e em cada um há um atributo, o atributo Keywords, que é configurado/alterado/algumas vezes confundido pelo uso de Set-ClientAccessServer –AutoDiscoverServiceSiteScope: ADSiteNameA, ADSiteNameB, etc. O atributo Keywords é usado para especificar por quais sites AD este CAS é responsável, para solicitações AutoDiscover.

Quando o cliente do Outlook localiza mais de um SCP, ele mesmo faz uma lista dos SCPs utilizáveis comparando o valor armazenado no atributo Keywords com seu próprio site AD (que é dinamicamente atualizado pelo serviço Netlogon local, quando ele inicializa ou muda o endereço IP).

Ele, então, faz uma lista. Tudo aquilo que corresponde ao seu site AD (em que o atributo Keywords = Site AD do cliente) ou, se não houver nada, ele coloca cada SCP na lista. Esses são os servidores que ele pode usar para suas solicitações AutoDiscover.

Depois, ele começa no topo da lista (que está sempre na mesma ordem, por data de instalação) e tenta conectar à URI contida no atributo ServiceBindingInformation – que é o local do serviço AutoDiscover em si. Ele lança o XML, obtém uma resposta, etc. e vive feliz para sempre. Mais detalhes sobre o AutoDiscover podem ser encontrados aqui.

Por que isso é interessante? O AutoDiscoverServiceSiteScope ajuda o Outlook a localizar o CAS mais perto do local do cliente, supondo que o administrador configurou corretamente os escopos do site (e nós realmente falamos aos administradores como fazer isso). Assim, nós não precisamos descobrir qual CAS está mais perto do cliente já que temos a solicitação, como já aconteceu quando a solicitação atingiu o CAS.

Depois que a solicitação atinge o CAS, nós descobrimos as configurações a serem retornadas ao cliente – mas sempre esquecemos de uma coisa – que o OAB que o usuário precisa pode ser local para o CAS no qual estamos executando a solicitação e, em vez disso, nós sempre demos ao usuário uma URL de um CAS. E é isso que precisamos corrigir.

Portanto, a solução para isso é teoricamente muito simples e significa que não temos que inventar uma nova maneira de descobrir o CAS mais perto do cliente, uma vez que já temos um que funciona muito bem.

Se tivermos que supor que o administrador configurou o AutoDiscoverServiceSiteScope corretamente, o CAS ao qual o cliente se conecta para o AutoDiscover será o CAS mais perto do cliente. Se a suposição for verdadeira, o CAS, ao descobrir o que retornar no XML do AutoDiscover, deve simplesmente verificar se ele mesmo tem uma cópia do OAB que o usuário deve estar usando – e, se tiver, ele apenas fornece sua própria URL do OAB. Não aquela para um CAS no site AD no qual está localizada a caixa postal do usuário. Naturalmente, se ele não tiver uma cópia do OAB que o usuário precisa, o comportamento antigo deverá prevalecer, o que significa que o CAS retornará a URL do OAB de um CAS no site AD da Caixa postal.

Basicamente, a figura é semelhante ao seguinte;

Agora é muito mais fácil para a WAN, não é? Uma cópia é replicada na WAN e todos os clientes no local terão o OAB do local do CAS para eles.

O que você tem que fazer para ter este novo comportamento para discutir? Apenas duas coisas. Implementar o SP2 RU1 no CAS e assegurar que seus parâmetros AutoDiscoverServiceSiteScope sejam configurados corretamente.

Espero que ache isso útil e que sua WAN possa ser sempre um long fat pipe.

Greg Taylor
Principal Program Manager
Exchange Customer Experience

Esta é uma postagem em blog localizado. Localize o artigo original em It Takes a Long Time…