Um Script para resolver problemas com o Exchange ActiveSync

Artigo original publicado na quarta-feira, 01 de fevereiro de 2012

• Script ActiveSyncReport
• Baixar

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.

Logs IIS

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

1. No IIS Manager, expanda o nome do servidor, isto é, ExchangeServer (Contoso\Administrador)
2. Em Exibição de Recursos, clique duas vezes em Registro em Log na seção IIS.

IIS 6

1. Em Gerenciador do IIS, clique com o botão direito no nome do site da Web (na maioria das vezes deve ser Site da Web Padrão) e escolha Propriedades
2. Clique na guia Site da Web.

Qual é a responsabilidade dos dispositivos móveis na comunicação com o servidor?

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.

• Quando é devolvido uma resposta inesperada do servidor para um dispositivo móvel, depende do dispositivo lidar com a resposta e tentar novamente de forma adequada a um intervalo razoável. Além disso, os dispositivos são responsáveis por lidar com os tempos limites que ocorrem fora do IIS, que podem ser causados por latência de rede.
• Com cada solicitação que um dispositivo envia para o IIS/Exchange, também deve relatar o Usuário-Agente.

O que você verá quando usar este script?

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.

1. Usuário

2. Nome de Usuário

3. Tipo de Dispositivo

4. ID do Dispositivo

5. Usuário-Agente

6. sc-bytes: Está apenas disponível se você habilitou esta guia no registro em log IIS.

7. cs-bytes: Está apenas disponível se você habilitou esta guia no registro em log IIS.

8. time-taken (em milissegundos): Está apenas disponível se você habilitou esta guia no registro em log IIS.

9. Número total de solicitações ou solicitações por ID do Dispositivo

10. Número total de todos os códigos de status 4xx

11. Número total de todos os códigos de status 5xx (para obter mais informações, veja a base de dados de conhecimento: 318380 para o IIS 6.0 & Base de Dados de Conhecimento: 943891)

12. Códigos de status 409: 409 (Conflito) - Uma coleção não pode ser realizada na Solicitação-URI até que um ou mais coleções intermediárias tenham sido criadas. O servidor NÃO DEVE criar estas coleções intermediárias automaticamente (Ref: [RFC 4918](https://tools.ietf.org/html/rfc4918#section-9.8.5 "See section 9.8.5 (Status Codes) in 'RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)'

    "))

13. Códigos de status 500: Após o dispositivo enviar o comando OPÇÕES, é possível obter 500 respostas de volta do servidor com o erro ‘MissingCscCacheEntry’. Isso pode ocorrer como resultado de um problema com a afinidade, onde você possui uma matriz CAS com a Internet para fazer proxy uma solicitação para uma matriz CAS Interna. Quando a matriz com Internet envia uma solicitação para a matriz Interna, um servidor CAS responderá com o primeiro 401. Na próxima comunicação, a solicitação é lidada por um servidor CAS diferente na matriz Interna. A solução é resolver o problema de afinidade com a matriz CAS Interna.

14. Códigos de status 503: O servidor atualmente não pode lidar com a solicitação devido a uma sobrecarga temporária ou manutenção do servidor. A implicação é que esta é uma condição temporária que será diminuída após algum atraso. Se conhecido, o comprimento do atraso PODE ser indicado em um cabeçalho Tentar Novamente-Após. Se Tentar Novamente-Após não é fornecido, o cliente DEVE lidar com a resposta como lidaria com 500 respostas.
    https:// 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) https://

15. Códigos de status 507: O código de status 507 (Armazenamento Insuficiente) significa que o método não pode ser realizado no recurso porque o servidor não pode armazenar a representação necessária para concluir com êxito a solicitação. Esta condição é considerada temporária. Se uma solicitação que recebeu este código de status foi o resultado de uma ação de usuário, a solicitação NÃO DEVE ser repetida até que seja solicitada por uma ação do usuário separada. (Ref: [RFC 4918](https://tools.ietf.org/html/rfc4918#section-11.5 "Veja seção 11.5 (Armazenamento Insuficiente 507) em 'RFC 4918: Extensões HTTP para a Criação Distribuída da Web e Controle de Versão (WebDAV)'

    "))

16. Códigos de status 451: O Exchange 2007/2010 retorna uma resposta HTTP 451 para um cliente EAS quando determina que o dispositivo deveria estar usando um CAS "melhor" para a conectividade EAS. A lógica usada para determinar o "melhor" CAS é baseada em sites do Active Directory e se o CAS é considerado "Com a Internet". Se a propriedade ExternalUrl no diretório virtual Microsoft-Server-ActiveSync é especificada, o CAS é considerado Com-Internet para a conectividade EAS. ( Ref: Artigos do TechNet O Exchange ActiveSync Retornando um Erro HTTP 451 e Compreendendo o Proxy e Redirecionamento)

17. Erros TooManyJobsQueued: Para obter mais informações sobre o "TooManyJobsQueued", consulte à Base de Dados de Conhecimento: 2469722 referenciada acima

18. OverBudget: Um orçamento é a quantidade de acessos que um usuário ou aplicativo pode ter para uma configuração específica. Um orçamento representa quantas conexões um usuário pode ter ou quanta atividade pode ser permitida para um usuário em um período de um minuto. (Ref: Artigo TechNet )

19. Próximo subconjunto de Códigos de Status Comuns:

    InvalidContent, ServerError, ServerErrorRetryLater, MailboxQuotaExceeded, DeviceIsBlockedForThisUser, AccessDenied, SyncStateNotFound, DeviceNotFullyProvisionable, DeviceNotProvisioned, ItemNotFound, UserDisabledForSync

O que você pode fazer com esse script?

É possível processar logs usando este script para recuperar os seguintes detalhes:

1. Ocorrências por usuário/ID do dispositivo (usuários/dispositivos com um número máximo de solicitações enviadas ao servidor)
2. Ocorrências por hora/dia (ajuda a determinar a frequência das solicitações enviadas por usuário/dispositivo, o valor de tempo é inserido em segundos)
3. Ocorrências por dispositivo com o limite especificado (aqui você pode especificar um limite para as ocorrências/solicitações, isto é, todos os usuários estão enviando 1000 solicitações por hora/dia, etc.
4. Exportar CSV dos resultados
5. Relatório HTML dos resultados
6. Relatórios de email para monitoramento (formato CSV/HTML)

Pré-requisitos:

Certifique-se de ter o seguinte instalado na sua máquina antes de usar este script:

• Log Parser 2.2.
• Windows PowerShell 2.0 (instalado por padrão no Windows 7 & Windows 2008 R2)

Parâmetros de Script

Como você usa o script?

Abaixo estão alguns exemplos (com comandos) sobre como você pode usar o script e por que deve usá-los.

Ocorrências superiores a 1000

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

Isolando uma ID de dispositivo específica

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

Saída:

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.

Isolando um único dia

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

Saída:

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.

O que devemos procurar?

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".

Criando relatórios para monitoramento

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

Agrhttps://ntos 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