Artigo original publicado na quarta-feira, 01 de fevereiro de 2012
A equipe de suporte do Exchange com frequência relativa recebe casos onde os dispositivos móveis usando o protocolo Exchange ActiveSync (EAS) envia muitas solicitações para o servidor do Exchange resultando em uma situação onde o servidor fica sem recursos, causando efetivamente um ataque "negação de serviço" (DOS). O pior resultado de tal situação é que o servidor também se torna indisponível para outros usuários que podem não estar usando o protocolo EAS para se conectar. Documentamos esse problema com possíveis migrações no seguinte artigo da Base de Dados de Conhecimento:
2469722 Não é possível conectar usando o Exchange ActiveSync devido ao consumo de recursos do Exchange
Um exemplo recente deste problema foi os dispositivos Apple iOS 4.0 tentando novamente uma sincronia completa a cada 30 segundos (consulte TS3398). Outro exemplo pode ser alguns dispositivos que não compreendam como lidar com uma resposta de "caixa de correio cheia" do servidor do Exchange, resultando em várias tentativas para reconectar. Isso pode fazer com que tais dispositivos tentem conectar & a sincronia com a caixa de correio mais de 60 vezes em um minuto, acabando com o tempo de vida da bateria do dispositivos e causando problemas de desempenho no servidor.
Gerenciar os recursos do servidor disponível de balanceamento de & dispositivos móveis entre diferentes tipos de clientes pode ser um desafio intimidante para os administradores de TI. Tentar rastrear quais dispositivos estão causando problemas de degradação de recursos no servidor do Exchange 2010/2007 Client Access (CAS) ou no servidor do Exchange 2003 Front-end (FE) não é uma tarefa fácil. Como citado no artigo acima, é possível usar o Analisador de Log para extrair estatísticas úteis dos logs do IIS (veja observação abaixo), mas a maioria dos administradores não tem a & experiência para rascunhar consultas para extrair tal informação de logs longos.
O objetivo desta publicação é introduzir todos na comunidade do Exchange a um novo script do PowerShell que pode ser utilizado para identificar os dispositivos que estão causando o problema de degradação do recursos, ajudar na identificação das tendências de desempenho e gerar automaticamente relatórios para monitoramento contínuo. Usando este script é possível buscar rapidamente e & facilmente nas atividades EAS dos usuários, que pode ser uma grande tarefa quando lidar com os logs IIS que podem chegar até vários gigabytes. O script torna mais fácil identificar os usuários com vários dispositivos EAS. É possível usá-lo como uma ferramenta para estabelecer uma linha base durante os períodos de atividade EAS normal e usá-lo para comparação e emissão de relatórios quando as coisas passam para outras direções. Também oferece um recurso de monitoramento automático que você pode usar para receber notificações de email.
Observação: O script funciona com logs IIS no servidor no Exchange 2010, Exchange 2007 e Exchange 2003. Todas as comunicações entre os dispositivos móveis usando o protocolo EAS e o Microsoft Exchange é registrada nos logs IIS nos servidores CAS/FE no formato W3C. Os campos W3C padrões habilitados para registro em log variam entre o IIS 6.0 e o 7.0/7.5 (o IIS 7.0 possui os mesmos campos que o 7.5). Este script funciona em ambas as versões.
Como o EAS usa HTTP, todas as solicitações EAS são registradas em logs IIS, que são habilitados por padrão. Algumas vezes, os administradores podem desabilitar o registro em log IIS para economizar espaço nos servidores. Você deve verificar se o registro em log está habilitado e encontrar o local dos arquivos de log seguindo estas etapas:
IIS 7
IIS 6
Antes de falarmos sobre os detalhes do script, vamos rever alguns requisitos importantes para os dispositivos móveis que usam o EAS para se comunicarem com o Microsoft Exchange.
O script utiliza o Microsoft Log Parser 2.2 para analisar os logs IIS e gerar resultados. Cria diferentes consultas SQL para o Analisador de Log baseado nos interruptores (veja tabela abaixo) que você usa. Uma publicação anterior Exchange 2003 - Emissão de relatórios do Active Sync fala sobre o Analisador de Logs que toca em pontos similares. A informação nesta publicação ainda se aplica ao Exchange 2010 & 2007. Desde esta publicação, foram adicionados mais comandos para o protocolo EAS ), que também são utilizados por este novo script durante o processamento dos logs.
Aqui está uma lista dos comandos do EAS que o script relatará nos resultados:
Sync, SendMail, SmartForward, SmartReply, GetAttachment, GetHierarchy, CreateCollection, DeleteCollection, MoveCollection, FolderSync, FolderCreate, FolderDelete, FolderUpdate, MoveItems, GetItemEstimate, MeetingResponse, Search, Settings, Ping, ItemOperations, Provision, ResolveRecipients, ValidateCert
Para obter mais detalhes sobre cada comando EAS, consulte Especificação do protocolo HTTP do ActiveSync no MSDN.
Além destes comandos, os seguintes parâmetros também são registrados em log pelo script.
Observação: A existência do código de status 503 não implica que um servidor deve usá-lo quando ficar sobrecarregado. Alguns servidores podem apenas recusar a conexão. (Ref: RFC 2616)
InvalidContent, ServerError, ServerErrorRetryLater, MailboxQuotaExceeded, DeviceIsBlockedForThisUser, AccessDenied, SyncStateNotFound, DeviceNotFullyProvisionable, DeviceNotProvisioned, ItemNotFound, UserDisabledForSync
É possível processar logs usando este script para recuperar os seguintes detalhes:
Certifique-se de ter o seguinte instalado na sua máquina antes de usar este script:
Cabeçalhos IIS CSV para Exportar no –HTMLReport.
Padrões: "DeviceID,Hits,Ping,Sync,FolderSync,DeviceType,User-Agent"
Diretório de Log IIS. Por exemplo.- IISLogs D:\Server,'D:\Server 2'
Maiores ocorrências para retornar. Por exemplo: TopHits 50. Não pode ser usado com Por Hora ou ReportBySeconds
Abaixo estão alguns exemplos (com comandos) sobre como você pode usar o script e por que deve usá-los.
O seguinte comando irá analisar todos os Logs IIS na pasta W3SVC1 e relata apenas as ocorrências por usuários & dispositivos superiores a 1000.
.\ActiveSyncReport.ps1 -IISLog "C:\inetpub\logs\LogFiles\W3SVC1" -LogparserExec “C:\Program Files (x86)\Log Parser 2.2\LogParser.exe” -ActiveSyncOutputFolder c:\EASReports -MinimumHits 1000
[No comando acima, o script ‘ActiveSyncReport.ps1’ está localizado na raiz da unidade C, o interruptor -IISLog especifica o local padrão dos logs IIS, o interruptor -LogparserExec aponta para o local do arquivo de aplicativo executável do Analisador de Logs, o interruptor -ActiveSyncOutputFolder oferece o local onde a saída do arquivo de resultado precisa ser salva, MinimumHits com um valor de "1000" é o parâmetro de script explicado na tabela abaixo]
Saída:
Geralmente, se um dispositivo estiver enviando acima de 1000 solicitações por dia, nós consideramos um "alto uso". Se as ocorrências (solicitações) são acima de 1500, poderá haver um problema no dispositivo ou no ambiente. Neste caso, o dispositivo & sua atividade de usuário deve ser mais investigada.
Como um exemplo real, em um caso observamos vários usuários que estão atingindo demais o servidor Excel através do EAS (~25K ocorrências, 1K ocorrências por hora) resultando em diminuição dos recursos no servidor. Após maior investigação, nós vemos que estas solicitações do usuário estavam resultando em um erro 507 em servidores da caixa de correio no back-end. Falando sobre estes usuários EAS, descobrimos que durante esse período de tempo eles estavam atingindo os limites de tamanho da caixa de correio (25 MB) & estavam tentando excluir emails de diferentes pastas para permanecer abaixo do limite de tamanho. Em tais situações, você também pode ver as respostas HTTP 503 (‘TooManyJobsQueued’) nos logs IIS para solicitações EAS como descrito na Base de Dados de Conhecimento: 2469722
Aqui, o seguinte comando irá analisar todos os Logs IIS na pasta C:\IISLogs e irão procurar pela ID do dispositivo xxxxxx e exibir suas estatísticas por hora.
.\ActiveSyncReport.ps1 -IISLog " C:\inetpub\logs\LogFiles\W3SVC1" -LogparserExec “C:\Program Files (x86)\Log Parser 2.2\LogParser.exe” -ActiveSyncOutputFolder c:\EASReports –DeviceID xxxxxx -Hourly
Com a informação acima, é possível escolher um usuário/dispositivo e ver suas tendências por hora. Isso pode ajudar a identificar se é uma ação do usuário ou programada.
Como um exemplo real, em um caso temos que descobrir quais dispositivos estavam modificando os itens de calendário. Portanto, olhamos para a atividade do usuário/dispositivo e classificamos por comandos diferentes que estavam enviando ao servidor; Após isso, apenas nos concentramos em quais usuários/dispositivos estavam enviando o comando ‘MeetingResponse’ e sua frequência, período de tempo & mais detalhes relacionados. Isso nos ajudou a diminuir o problema para os usuários relacionados e sua atividade específica do calendário para resolver melhor o problema de calendário subjacente.
Outro comando relacionado ao dispositivo & o erro para procurar é o comando "Options",se não tem êxito para um dispositivo e se o código de erro HTTP 409 é retornado no log IIS.
O comando a seguir analisará apenas os arquivos que correspondem a data 24-12-2011 na pasta W3SVC1 e relatará apenas ocorrências maiores que 1000.
.\ActiveSyncReport.ps1 -IISLog "C:\inetpub\logs\LogFiles\W3SVC1" -LogparserExec “C:\Program Files (x86)\Log Parser 2.2\LogParser.exe” -ActiveSyncOutputFolder c:\EASReports -MinimumHits 1000 –Date 12-24-2011
Com a informação acima, é possível identificar usuários enviando um alto número de solicitações. Além disso, dentro das colunas, é possível ver quais tipos de comandos esses usuários estão enviando. Isso ajuda a resultar em técnicas de resolução de problemas eficientes e & mais diretas.
Quando analisar os logs IIS com a ajuda de um script, você deve procurar por um comando específico sendo enviado continuadamente. A frequência dos comandos particulares sendo enviados é importante, qualquer comando com falha frequente também é muito importante & isso deve ser analisado. Devemos também & comparar os tempos de espera entre as execuções de determinados comandos. Geralmente, os comandos que levam mais tempo para executar ou resultam em um atraso de resposta do servidor serão suspeitos & devem ser mais investigados. Mantenha em mente, o comando Ping é uma exceção que leva mais para executar e você o verá frequentemente no log, o que é esperado.
Se você observar falhas contínuas para conectar em um dispositivo com um código de erro 403, o que pode significar que o dispositivo não está habilitado para o acesso baseado em EAS. Algumas vezes, os usuários de dispositivos móveis reclamam de problemas de conectividade sem perceber que eles realmente não estão inserindo suas credenciais corretamente (é fácil realizar esses erros em dispositivos móveis). Quando verificar os logs, é possível focalizar que esse usuário & pode descobrir que o dispositivo do usuário está falando após emitir o comando "Provision".
Você pode desejar criar um relatório ou gerar um email com relatórios e detalhes da atividade do usuário.
O seguinte comando analisará todos os Logs IIS na pasta W3SVC1 e irá apenas relatar ocorrências superiores a 1000. Além disso, criará um relatório HTML dos resultados.
.\ActiveSyncReport.ps1 -IISLog "C:\inetpub\logs\LogFiles\W3SVC1" -LogparserExec “C:\Program Files (x86)\Log Parser 2.2\LogParser.exe” -ActiveSyncOutputFolder c:\EASReports -MinimumHits 1000 -HTMLReport
O seguinte comando analisará todos os arquivos nas pastas C:\Server1_Logs e D:\Server2_Logs e também enviará por email o relatório gerado para "user@contoso.com".
.\ActiveSyncReport.ps1 -IISLog "C:\Server1_Logs",”D:\Server2_Logs” -LogparserExec “C:\Program Files (x86)\Log Parser 2.2\LogParser.exe” -ActiveSyncOutputFolder c:\EASReports -SendEmailReport -SMTPRecipient user@contoso.com –SMTPSender user2@contoso.com -SMTPServer mail.contoso.com
Esperamos sinceramente que nossos leitores achem este script útil. Conte-nos sobre como esses scripts tornaram sua vida mais fácil e o que mais podemos fazer para melhorá-lo.
Konstantin Papadakis e Brian Drepaul
Agradecimentos especiais para: M. Amir Haque, Will Duff, Steve Swift, Angelique Conde, Kary Wall, Chris Lineback & Mike Lagase
Essa é uma publicação localizada. Encontre o artigo original em A script to troubleshoot issues with Exchange ActiveSync