Artigo original publicado sábado, 18 de fevereiro de 2012
Queríamos dar a você algumas informações relativas a uma alteração no comportamento do proxy CAS a CAS entre servidores que estão executando o Exchange 2010 SP2 RU1 e servidores que estão executando versões mais antigas do Exchange.
O pacote SP2 RU1 introduziu uma alteração no cookie de contexto do usuário que é usado no proxy CAS-a-CAS. Um efeito colateral indesejado é uma incompatibilidade temporária entre servidores SP2 RU1 e servidores que estão executando versões anteriores do Exchange. A alteração é tanta que versões anteriores do Exchange não entendem o cookie mais novo usado pelo servidor SP2 RU1. Como resultado, o proxy de SP2 RU1 para uma versão anterior do Exchange falhará com o seguinte erro:
Cookie de contexto de usuário inválido localizado na resposta do proxy
O servidor pode mostrar exceções no log de eventos, como o seguinte:
Event ID: 4999Log Name: ApplicationSource: MSExchange CommonTask Category: GeneralLevel: ErrorDescription: Watson report about to be sent for process id: 744, with parameters: E12, c-RTL-AMD64, 14.02.0283.003, OWA, M.E.Clients.Owa, M.E.C.O.C.ProxyUtilities.UpdateProxyUserContextIdFromResponse, M.E.C.O.Core.OwaAsyncOperationException, 413, 14.02.0283.003.
Nem todos os clientes são afetados por isso. Mas como recebemos algumas questões sobre isso, gostaríamos de informá-lo sobre a alteração. Muitos clientes do Exchange não usam o proxy entre o Exchange 2010 e o Exchange 2007, mas, em vez disso, usam o redirecionamento, que não é afetado pela alteração. No entanto, se você estiver usando o proxy CAS-a-CAS, onde um servidor Exchange 2010 SP2 RU1 Client Access está realizando proxy para uma versão anterior do servidor Exchange 2010 ou Exchange 2007 Client Access, você será afetado pela alteração.
Se for afetado, é importante observar que esse problema é temporário e existirá apenas até que todo o CAS envolvido no processo de proxy CAS-a-CAS seja atualizado para o Exchange 2010 SP2 RU1. Assim, se você for afetado por esse problema, apenas implemente o SP2 RU1 nos servidores Exchange 2010 relevantes e o problema deixará de existir.
Se você usar o proxy CAS-a-CAS entre o Exchange 2010 e o Exchange 2007, teremos uma atualização temporária (IU) para o Exchange 2007. A disponibilidade da UI será anunciada neste blog.
A equipe do Exchange
Esta é uma postagem em blog localizado. Localize o artigo original em Exchange 2010 SP2 RU1 and CAS-to-CAS Proxy Incompatibility
Artigo original publicado terça-feira, 14 de fevereiro de 2012
Hoje, a equipe do Exchange CXP liberou o Rollup 1 de Atualização para o Exchange Server 2010 SP2 para o Centro de Download.
Esta atualização contém vários problemas relatados pelos clientes e localizados internamente desde a liberação do SP2. Consulte o KB 2645995: Descrição do Rollup 1 de Atualização para o Exchange Server 2010 Service Pack 2' para obter mais detalhes.
Observação: Se alguns dos seguintes artigos do KB ainda não funcionarem, tente novamente mais tarde.
Nós gostaríamos de chamar especificamente as seguintes correções que estão incluídas nesta liberação:
Para alterações do DST: http://www.microsoft.com/time.
Observação para usuários do Forefront Protection for Exchange Para aqueles que estão executando o Forefront Protection for Exchange, certifique-se de executar estas etapas importantes da linha de comandos no diretório do Forefront antes e depois desse processo de instalação de rollup. Sem essas etapas, os serviços do Exchange para Armazenamento de informações e transporte não serão iniciados depois da aplicação dessa atualização. Antes de instalar a atualização, desative o ForeFront usando este comando: fscutility /disable. Depois de instalar a atualização, reative o ForeFront executando fscutility /enable.
Equipe do Exchange
Esta é uma postagem em blog localizado. Localize o artigo original em Released: Update Rollup 1 for Exchange 2010 Service Pack 2
Artigo original publicado sábado, 11 de fevereiro de 2012
Tenho o imenso prazer de anunciar que a nova Calculadora de Largura de Banda do Cliente do Exchange Beta está disponível para download!!
Nos últimos 12 meses, estivemos trabalhando em uma nova calculadora para ajudar com a aproximação da largura de banda da rede do cliente do Exchange. Essa nova calculadora baseia-se em novos dados de prognóstico e foi projetada para funcionar com o Exchange local e com implementações do Office 365! (Sim, sabemos que está muito atrasada!)
O resumo era conciso e simples para esta calculadora; queríamos conseguir prever os requisitos da largura de banda da rede do cliente para um conjunto específico de usuários. A calculadora precisava lidar com o Outlook, OWA e Dispositivos móveis, tanto no local quanto para cenários do Office 365.
Os clientes a seguir estão incluídos neste Beta; clientes adicionais serão adicionados com o passar do tempo.
A calculadora é baseada em novos algoritmos de prognóstico derivados depois de analisar o comportamento de cada cliente individualmente. Essa abordagem permite que um modelo de largura de banda seja criado para cada cenário do cliente, que é muito escalável e flexível.
Os dados de entrada são baseados nas métricas de perfil de usuário existentes, como mensagens enviadas e recebidas por usuário por dia e tamanho médio da mensagem. Depois que esses parâmetros são fornecidos, a calculadora consegue prever quanta largura de banda cada cliente exigirá para que seja executado adequadamente.
Os prognósticos fornecidos representam os requisitos durante as duas horas de maior ocupação do dia de trabalho.
Os novos algoritmos de prognóstico foram criados do zero e validados para precisão internamente; no entanto, gostaríamos de reunir mais alguns dados de telemtria de cenários reais para ajustar a fórmula de prognóstico da calculadora. Durante o processo Beta, gostaríamos de receber seu feedback e suas sugestões para a calculadora. Se puder fornecer prognóstico real vs. dados de observações para sua infraestrutura, isso também seria muito bem-vindo!
Sugestões e solicitações de feedback devem ser enviadas para netcalc@microsoft.com
A meta é concluir o processo Beta em meados de 2012.
A calculadora é dividida em duas planilhas principais no Excel.
Há um manual que acompanha que explica tudo mais detalhadamente, vou dar uma olhada rápida aqui.
A planilha de entrada é dividida em cinco seções;
A seção Dados de organização representa as configurações globais que se aplicam à toda a organização e os perfis de usuário são perfis predefinidos que representam conjuntos de usuários de leve até muito pesado. Os perfis de usuário são personalizáveis e devem ser editados para refletir seu próprio ambiente para um prognóstico preciso.
Depois de ter preenchido a Planilha de entrada, você pode passar para a planilha do Client Mix. É nela que você pode listar o número de cada cliente e definir seus sites. A planilha é composta de três seções;
A seção Definição do site permite configurar um modelo representativo de sua tipologia do site de rede físico; isso deve representar sites físicos e o perfil de uso do usuário esperado para esse site. A seção Definição do cliente permite configurar quantos usuários existirão em cada site e qual tipo de cliente do Exchange eles usarão. A seção Prognósticos da rede mostra o requisito de rede previsto para cada site definido.
Para facilitar um pouco as coisas, vou mostrar um exemplo bem básico para começar.
Neste exemplo, temos um cliente que está mudando para o Office 365. Ele quer saber quanto de largura de banda de Internet será necessário para oferecer suporte a seus clientes do Exchange depois da conclusão da migração.
Informações da organização
Londres e Manchester compartilham a mesma conexão de Internet, mas Paris tem sua própria sessão local.
Observação: Para este exemplo, vou usar os dados de perfil de usuário integrado para simplificar as coisas, no entanto, recomenda-se definir seus próprios dados de perfil de usuário com base na pesquisa em sua solução de mensagens.
A primeira coisa a fazer é configurar a Planilha de entrada. Os padrões são muito bons neste exemplo, mas o tamanho de OAB é, na verdade, 10MB em vez de 100MB, então, vou configurar o Tamanho do catálogo de endereços offline para 10MB.
Geralmente, edito os perfils de usuário, mas neste caso vou deixá-los em suas configurações padrão e passar para a planilha do Client Mix. A planilha do Client Mix nos dá os totais, então, eu geralmente agrupo sites que compartilham a mesma conexão de Internet. Nessa instância, isso significa que podemos colocar Londres e Manchester na mesma planilha, mas precisamos de uma nova planilha para Paris. Para fazer uma cópia da planilha, clique com o botão direito do mouse na guia na parte inferior e selecione Mover ou Copiar; no diálogo Mover ou Copiar, destaque a planilha Client Mix, marque a caixa para Criar uma cópia e clique em OK.
Agora, sua pasta de trabalho do Excel conterá “Client Mix (2)” e “Client Mix” – eu, geralmente, renomeio isso para algo significativo; nessa instância, vou renomear um como Sites UK e o outro Sites FR.
Vamos começar definindo os sites na planilha Sites UK. As informações que temos sugerem que temos dois sites, Londres e Manchester, e que há dois tipos de perfil de usuário em cada site. Como podemos usar apenas um único site de perfil de usuário, isso significa que vamos precisar de quatro entradas de site…
Precisamos, então, definir os tipos de clientes que existirão em cada site. Eu ocultei algumas linhas e colunas que não precisamos para que a leitura dos dados fique mais fácil. Inseri o número de cada tipo de cliente na planilha – sabemos que deve ser OA-cached para o Outlook 2007 já que o Office 365 fornece apenas uma conexão Outlook Anywhere e sabemos que OWA deve ser 2010 já que, novamente, o Office 365 é baseado no Exchange Server 2010.
Se ocultarmos mais algumas células, podemos ter uma visão melhor dos valores de prognóstico.
Primeiro, estamos geralmente interessados nos requisitos “Exchange to Client” já que são mais altos e a maioria dos links ainda é fornecida com a mesma capacidade de carregamento e de download. Onde você tem uma linha assíncrona, talvez seja necessário ver também a largura de banda de “Client to Exchange”. Neste exemplo, o cliente tem uma conexão síncrona.
Londres tem dois conjuntos de usuários definidos e a calculadora prevê que os usuários do Outlook precisarão de 3,66Mbits/seg de largura de banda e ue os usuários do OWA exigirão um adicional de 0,93Mbits/seg. O total para Londres é 4,59Mbits/seg (é necessário fazer isso manualmente neste caso).
Manchester também tem dois conjuntos de usuários definidos e a calculadora prevê um total de 3,53Mbits/seg.
Como Manchester e London compartilham a mesma conexão de Internet, a calculadora está prevendo que o cliente precisará garantir que 8,12Mbits/seg de largura de banda de rede estejam disponíveis para suportar essa carga de trabalho e que a latência máxima do link de rede seja 320ms ou menos.
Se repetirmos isso para nossa guia Sites FR…
A calculadora prevê que a conexão de Internet em Paris exigirá 1,88Mbits/seg de largura de banda de rede disponível para suportar seus 1100 usuários OWA do Office 365.
Este é, obviamente, um exemplo muito simples, mas eu o incentivaria a modelar sua própria organização para conferir a calculadora e fornecer feedback sobre como a calculadora está funcionando para você.
A calculadora não fornece informações sobre o seguinte…
Nós publicamos outro guia de largura de banda de rede no TechNet, o guia mais comumente usado está em White Paper: Outlook Anywhere Scalability with Outlook 2007, Outlook 2003 and Exchange 2007. Este guia foi produzido usando-se o Loadgen durante o teste de laboratório da escalabilidade CAS. Os prognósticos desse teste variam um pouco daqueles na nova calculadora devido à maneira como os dados foram reunidos em cada caso. Como os dados de teste mais novos foram especificamente gerados e analisados para permitir o prognóstico de largura de banda de rede, os valores mais novos devem ser mais precisos; a nova calculadora também leva em conta muitas outras variáveis e perfis de usuário do que o guia no Outlook 2007 White Paper; portanto, novamente, este deve fornecer um prognóstico mais preciso.
Durante o processo Beta, recomendamos que você use o White Paper antigo e a calculadora nova para determinar seus requisitos.
Como eu disse no início desta postagem (que está muito mais longa do que eu gostaria!), estou realmente interessado em seu feedback depois que você usar a calculadora; positivo, negativo e solicitações para ajuda ou solicitações de recursos, etc. Envie seu feedback (por favor, seja gentil!) para…
netcalc@microsoft.com
Vou fazer mais algumas postagens relativas a esta calculadora nos próximos meses, com mais exemplos e um aprofundamento que explica como os dados de prognóstico foram gerados.
Obrigado pela leitura e espero que você ache útil esta nova calculadora.
Neil Johnson Senior Consultant, MCS UK
Esta é uma plostagem em blog localizado. Localize o artigo original em Announcing the Exchange Client Network Bandwidth Calculator Beta
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….”
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;
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 http://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 é…
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.
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…