Articolo originale pubblicato mercoledì 1 febbraio 2012

Il team del supporto tecnico di Exchange riceve relativamente spesso segnalazioni di casi in cui i dispositivi mobili che utilizzano il protocollo Exchange ActiveSync (EAS) inviano troppe richieste al server di Exchange, producendo una situazione in cui il server esaurisce le risorse e generando un attacco Denial of Service (DoS). La conseguenza peggiore di questa situazione è che il server si rende non disponibile anche per altri utenti che potrebbero non utilizzare il protocollo EAS per connettersi. Abbiamo documentato questo problema e le possibili soluzioni nell'articolo della Knowledge Base seguente:

2469722 Non è possibile connettersi tramite Exchange ActiveSync a causa di un utilizzo troppo elevato delle risorse di Exchange

Un esempio recente di questo problema si è verificato con dispositivi Apple iOS 4.0 che eseguivano ripetuti tentativi di sincronizzazione completa ogni 30 secondi (vedere TS3398). Un altro esempio può riguardare alcuni dispositivi che non sono in grado di gestire una risposta "Cassetta postale piena" dal server di Exchange, producendo diversi tentativi di riconnessione. Questo problema può far sì che tali dispositivi tentino la riconnessione e la sincronizzazione con la cassetta postale oltre 60 volte al minuto, riducendo notevolmente la durata della batteria del dispositivo e causando problemi di prestazioni nel server.

La gestione di dispositivi mobili e il bilanciamento delle risorse del server disponibili tra diversi tipi di client può essere una sfida molto impegnativa per gli amministratori IT. Il tentativo di tenere traccia dei dispositivi che provocano problemi di svuotamento delle risorse nel server Accesso client di Exchange 2010/2007 o nel server front-end di Exchange 2003 non è un'attività facile. Benché, come indicato nell'articolo precedente, sia possibile utilizzare Log Parser per estrarre utili statistiche dai log di IIS (vedere la nota di seguito), la maggior parte degli amministratori non ha né il tempo né l'esperienza per creare query per l'estrazione di tali informazioni da log di grandi dimensioni.

Lo scopo di questo post consiste nel presentare ai partecipanti della community di Exchange un nuovo script di PowerShell, che può essere utilizzato per identificare i dispositivi che provocano il problema di svuotamento delle risorse, aiutare a individuare le tendenze relative alle prestazioni e generare automaticamente report per un monitoraggio continuo. Utilizzando questo script potrete approfondire facilmente e rapidamente l'attività di EAS per gli utenti, un aspetto importante quando si affrontano log di IIS in grado di raggiungere diversi gigabyte di dimensioni. Lo script semplifica l'identificazione degli utenti con più dispositivi EAS e può essere utilizzato come strumento per stabilire una base durante periodi di normale attività di EAS, da utilizzare per il confronto e la creazione di report in presenza di situazioni con altre tendenze. Lo script offre inoltre una funzionalità di monitoraggio automatico che è possibile utilizzare per ricevere notifiche tramite posta elettronica.

Nota: lo script funziona con log di IIS in server di Exchange 2010, Exchange 2007 ed Exchange 2003.
Tutta la comunicazione tra dispositivi mobili che utilizzano il protocollo EAS e Microsoft Exchange viene registrata in log di IIS in server Accesso client/front-end in formato W3C. I campi W3C predefiniti abilitati per la registrazione variano tra IIS 6.0 e 7.0/7.5 (i campi di IIS 7.0 sono gli stessi di quelli di 7.5). Questo script funziona con entrambe le versioni.

Log di IIS

Poiché EAS utilizza HTTP, tutte le richieste EAS vengono registrate in log di IIS per impostazione predefinita. Talvolta gli amministratori possono disabilitare la registrazione di IIS per risparmiare spazio nei server. È necessario verificare se la registrazione è abilitata o meno e individuare la posizione dei file di log eseguendo i passaggi seguenti:

IIS 7

1. In Gestione IIS espandere il nome del server, ad esempio ExchangeServer (Contoso\Administrator)
2. In Visualizzazione funzionalità fare doppio clic su Registrazione nella sezione IIS.

IIS 6

1. In Gestione IIS fare clic con il pulsante destro del mouse sul nome del sito Web (in genere Sito Web predefinito) e scegliere Proprietà
2. Fare clic sulla scheda Sito Web.

Dispositivi mobili responsabili nelle comunicazioni con il server

Prima di approfondire le specifiche dello script, esamineremo alcuni requisiti importanti per i dispositivi mobili che utilizzano EAS per comunicare con Microsoft Exchange.

• Quando a un dispositivo mobile viene restituita una risposta imprevista dal server, il dispositivo deve gestire la risposta e ritentare nel modo appropriato a un intervallo ragionevole. I dispositivi sono inoltre responsabili della gestione dei timeout che si verificano esternamente a IIS, che possono essere provocati dalla latenza di rete.
• Con ogni richiesta inviata da un dispositivo a IIS/Exchange, deve essere segnalato anche il parametro User-Agent.

Risultati visualizzati quando si utilizza lo script

Lo script utilizza Microsoft Log Parser 2.2 per analizzare i log di IIS e generare risultati e crea query SQL diverse per Log Parser in base ai parametri (vedere la tabella di seguito) utilizzati. In un post di blog precedente su Log Parser, Exchange 2003 - Active Sync reporting, vengono affrontati aspetti simili. Le informazioni contenute nel post si applicano a Exchange 2010 e 2007. Dopo questo post sono stati aggiunti altri comandi al protocollo EAS utilizzati anche in questo nuovo script per l'elaborazione dei log.

Di seguito sono elencati i comandi di EAS contenuti nei risultati dello script:

Sync, SendMail, SmartForward, SmartReply, GetAttachment, GetHierarchy, CreateCollection, DeleteCollection, MoveCollection, FolderSync, FolderCreate, FolderDelete, FolderUpdate, MoveItems, GetItemEstimate, MeetingResponse, Search, Settings, Ping, ItemOperations, Provision, ResolveRecipients, ValidateCert

Per ulteriori informazioni su ogni comando EAS, vedere Specifiche del protocollo HTTP di ActiveSync in MSDN.

Oltre a questi comandi, nello script vengono registrati anche i parametri seguenti.

1. Utente
2. Nome utente
3. Tipo di dispositivo
4. ID dispositivo
5. User-Agent
6. sc-bytes: disponibile solo se è stato abilitato questo tag nella registrazione di IIS.
7. cs-bytes: disponibile solo se è stato abilitato questo tag nella registrazione di IIS.
8. time-taken (in millisecondi): disponibile solo se è stato abilitato questo tag nella registrazione di IIS.
9. Numero totale di richieste o richieste in base all'ID dispositivo
10. Numero totale di tutti i codici di stato 4xx
11. Numero totale di tutti i codici di stato 5xx. Per ulteriori informazioni, vedere l'articolo della Knowledge Base 318380 per IIS 6.0 e l'articolo della Knowledge Base 943891.
12. Codici di stato 409: 409 (conflitto): non è possibile eseguire una raccolta in Request-URI fino a quando non vengono create una o più raccolte intermedie. Il server NON DEVE creare automaticamente queste raccolte intermedie (rif.: RFC 4918).
13. Codici di stato 500: dopo che un dispositivo invia il comando OPTIONS, è possibile ottenere una risposta 500 dal server con errore 'MissingCscCacheEntry'. Questo errore può verificarsi come conseguenza di un problema relativo all'affinità, in presenza di un array CAS con connessione Internet che inoltra una richiesta a un array CAS interno. Quando l'array con connessione Internet invia la richiesta all'array interno, un server CAS risponde con il primo errore 401. Nella comunicazione successiva la richiesta viene gestita da un server CAS diverso nell'array interno. La risoluzione del problema di affinità con l'array CAS interno consente di risolvere il problema.
14. Codici di stato 503: il server non è in grado di gestire la richiesta a causa di una manutenzione o un overload temporaneo del server. È sottinteso che si tratti di una condizione temporanea, che verrà attenuata dopo un certo intervallo di tempo. Se è noto, l'intervallo di tempo POTREBBE essere indicato in un'intestazione Retry-After. Se Retry-After non è specificato, il client DOVREBBE gestire la risposta come una risposta 500.

    Nota: la presenza del codice di stato 503 non implica che un server debba utilizzarlo quando è soggetto a overload. Alcuni server potrebbero semplicemente rifiutare la connessione (rif.: RFC 2616).

15. Codici di stato 507: il codice di stato 507 (archiviazione insufficiente) indica che non è stato possibile eseguire il metodo nella risorsa perché il server non è in grado di archiviare la rappresentazione necessaria per completare la richiesta. Questa condizione viene considerata temporanea. Se la richiesta che ha ricevuto questo codice di stato è il risultato di un'azione di un utente, la richieste NON DEVE essere ripetuta fino a quando non viene eseguita tramite un'azione di un utente separato (rif.: RFC 4918).
16. Codici di stato 451: Exchange 2007/2010 restituisce una risposta HTTP 451 a un client EAS quando determina che è necessario che il dispositivo utilizzi un server CAS 'migliore' per la connettività EAS. La logica utilizzata per determinare il server CAS 'migliore' è basata su siti Active Directory e sul fatto che un server CAS sia considerato o meno dotato di una connessione Internet. Se è specificata la proprietà ExternalUrl nella directory virtuale Microsoft-Server-ActiveSync, il server CAS è considerato dotato di connessione Internet per la connettività EAS (rif.: articoli di TechNet Exchange ActiveSync ha restituito l'errore HTTP 451 e Concetti relativi all'inoltro e al reinstradamento).
17. Errori TooManyJobsQueued: per ulteriori informazioni su 'TooManyJobsQueued' fare riferimento all'articolo della Knowledge Base 2469722 citato sopra.
18. OverBudget: per budget si intende l'allocazione di accesso di cui dispone un utente o un'applicazione per un'impostazione specifica. Questa allocazione rappresenta la quantità di connessioni di cui può disporre un utente o di attività consentite a un utente per ogni periodo di un minuto (rif.: articolo di TechNet).
19. Subset seguente di codici di stato comuni:

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

Risultati dello script

È possibile elaborare i log con questo script per recuperare le informazioni seguenti:

1. Accessi in base a utente/ID dispositivo (utenti/dispositivi con un numero massimo di richieste inviate al server)
2. Accessi per ora/giorno. Consente di determinare la frequenza delle richieste inviate da ogni utente/dispositivo, con un valore di tempo immesso in secondi.
3. Accessi per dispositivo con il limite di soglia specificato. È possibile specificare un limite per accessi/richieste, ad esempio tutti gli utenti che inviano 10000 richieste al giorno o all'ora e così via.
4. Esportazione in formato CSV dei risultati
5. Report HTML dei risultati
6. Report tramite posta elettronica per il monitoraggio (formati CSV/HTML)

Prerequisiti:

Verificare che nel computer siano installati i componenti seguenti prima di utilizzare lo script:

• Log Parser 2.2.
• Windows PowerShell 2.0 (installato per impostazione predefinita in Windows 7 e Windows 2008 R2)

Parametri dello script

Come utilizzare lo script

Di seguito sono disponibili alcuni esempi, con i relativi comandi, su come e perché utilizzare lo script.

Accessi superiori a 1000

Il comando seguente analizza tutti i log di IIS nella cartella W3SVC1 e restituisce solo gli accessi da utenti e dispositivi superiori a 1000.

.\ActiveSyncReport.ps1 -IISLog "C:\inetpub\logs\LogFiles\W3SVC1" -LogparserExec "C:\Programmi (x86)\Log Parser 2.2\LogParser.exe" -ActiveSyncOutputFolder c:\EASReports -MinimumHits 1000

[Nel comando precedente lo script 'ActiveSyncReport.ps1' si trova nella radice dell'unità C, il parametro -IISLog specifica il percorso predefinito dei log di IIS, il parametro -LogparserExec punta al percorso del file eseguibile dell'applicazione Log Parser, il parametro -ActiveSyncOutputFolder specifica il percorso in cui deve essere salvato l'output o il file dei risultati e MinimumHits con il valore '1000' è il parametro dello script illustrato nella tabella precedente]

Output:

In genere, se un dispositivo invia oltre 1000 richieste al giorno, si determina un 'utilizzo elevato'. Se gli accessi (richieste) sono oltre 1500, può verificarsi un problema nel dispositivo o nell'ambiente. In tal caso, il dispositivo e l'attività del relativo utente devono essere indagati ulteriormente.

In un esempio reale, in un caso abbiamo notato che diversi utenti si connettevano spesso al server di Exchange EAS (circa 25000 accessi, 1000 accessi all'ora), provocando lo svuotamento delle risorse nel server. Dopo un'ulteriore indagine, abbiamo notato che tutte queste richieste degli utenti producevano un errore 507 nel server delle cassette postali nel back-end. Parlando con questi utenti di EAS, abbiamo scoperto che durante quel periodo di tempo stavano raggiungendo i limiti di dimensioni delle proprie cassette postali (25 MB) e tentavano di eliminare elementi di posta da diverse cartelle per rientrare nel limite. In situazioni di questo tipo, è possibile visualizzare anche risposte HTTP 503 ('TooManyJobsQueued') nei log di IIS per le richieste EAS, come descritto nell'articolo della Knowledge Base 2469722.

Isolamento di un ID dispositivo specifico

I comandi seguenti analizzeranno tutti i log di IIS nella cartella C:\IISLogs e cercheranno l'ID dispositivo xxxxxx visualizzandone le statistiche orarie.

.\ActiveSyncReport.ps1 -IISLog " C:\inetpub\logs\LogFiles\W3SVC1" -LogparserExec "C:\Programmi (x86)\Log Parser 2.2\LogParser.exe" -ActiveSyncOutputFolder c:\EASReports –DeviceID xxxxxx -Hourly

Output:

Con le informazioni precedenti è possibile selezionare un utente/dispositivo e individuarne le tendenze orarie. In questo modo, è possibile determinare se si tratta di un'azione di un utente o un'azione a livello di programmazione.

In un esempio reale, in un caso abbiamo dovuto individuare quali dispositivi stessero modificando elementi del calendario. Abbiamo osservato l'attività dell'utente o del dispositivo, ordinandola in base ai comandi diversi inviati al server. Ci siamo quindi concentrati su quali utenti o dispositivi stessero inviando un comando 'MeetingResponse' e con quali frequenza, intervallo di tempo e altre informazioni correlate. Questo ci ha aiutati a limitare il problema agli utenti interessati e alla loro attività specifica del calendario per risolvere meglio il problema del calendario sottostante.

Un comando correlato ai dispositivi da cercare, con l'errore corrispondente, è il comando 'Options' che, se ha esito negativo per un dispositivo, restituisce il codice errore HTTP 409 nel log di IIS.

Isolamento di un singolo giorno

Il comando seguente analizzerà solo i file che corrispondono alla data 12-24-2011 nella cartella W3SVC1 e segnalerà solo gli accessi superiori a 1000.

.\ActiveSyncReport.ps1 -IISLog "C:\inetpub\logs\LogFiles\W3SVC1" -LogparserExec "C:\Programmi (x86)\Log Parser 2.2\LogParser.exe" -ActiveSyncOutputFolder c:\EASReports -MinimumHits 1000 –Date 12-24-2011

Output:

Con le informazioni precedenti è possibile identificare gli utenti che inviano un alto numero di richieste. All'interno delle colonne è anche possibile determinare il tipo di comandi inviati da tali utenti e, in questo modo, definire tecniche di risoluzione dei problemi più dirette ed efficaci.

Che cosa cercare

Nell'analizzare i log di IIS con l'aiuto dello script, dovreste cercare un comando specifico inviato più volte. La frequenza di determinati comandi inviati è importante, come ogni comando che ha spesso esito negativo, che deve essere ulteriormente indagato. Dovremo anche osservare e confrontare i tempi di attesa tra le esecuzioni di determinati comandi. I comandi la cui esecuzione richiede più tempo o che producono un ritardo nella risposta dal server sono sospetti e devono essere ulteriormente indagati. Tenete comunque presente che il comando Ping rappresenta un'eccezione e che benché venga visualizzato spesso nel log e la sua esecuzione richieda più tempo, si tratta di un comportamento previsto.

In caso di continui errori di connessione per un dispositivo con un codice errore 403, il dispositivo potrebbe non essere abilitato per l'accesso basato su EAS. Gli utenti di dispositivi mobili lamentano talvolta problemi di connettività senza rendersi conto di non aver immesso le credenziali corrette, un errore comprensibilmente frequente nei dispositivi mobili. Nell'osservare i log, potete concentrarvi sull'utente specifico e scoprire l'errore del dispositivo dell'utente dopo l'invio del comando 'Provision'.

Creazione di report per il monitoraggio

Potreste voler creare un report o generare un messaggio di posta elettronica contenente tali report e informazioni dettagliate sull'attività di un utente.

Il comando seguente analizza tutti i log di IIS nella cartella W3SVC1 e segnala solo gli accessi superiori a 1000. Crea inoltre un report HTML dei risultati.

.\ActiveSyncReport.ps1 -IISLog "C:\inetpub\logs\LogFiles\W3SVC1" -LogparserExec "C:\Programmi (x86)\Log Parser 2.2\LogParser.exe" -ActiveSyncOutputFolder c:\EASReports -MinimumHits 1000 -HTMLReport

Il comando seguente analizza tutti i file nelle cartelle C:\Server1_Logs and D:\Server2_Logs e invia tramite posta elettronica il report generato a 'utente@contoso.com'.

.\ActiveSyncReport.ps1 -IISLog "C:\Server1_Logs","D:\Server2_Logs" -LogparserExec "C:\Programmi (x86)\Log Parser 2.2\LogParser.exe" -ActiveSyncOutputFolder c:\EASReports -SendEmailReport -SMTPRecipient utente@contoso.com –SMTPSender utente2@contoso.com -SMTPServer mail.contoso.com

Ci auguriamo davvero che i nostri lettori trovino utile questo script. Segnalateci se vi ha semplificato la vita e come possiamo migliorarlo ancora di più.

Konstantin Papadakis e Brian Drepaul

Ringraziamenti speciali:
M. Amir Haque, Will Duff, Steve Swift, Angelique Conde, Kary Wall, Chris Lineback e Mike Lagase

Questo è un post di blog localizzato. L'articolo originale è disponibile in A script to troubleshoot issues with Exchange ActiveSync