Exchange 2003 – Troubleshooting delle code e consegna dei messaggi


Una delle richieste che ci viene fatta più spesso è il troubleshooting dei messaggi che non vengono consegnati ai destinatari.

Questa tipologia di problematiche ha 3 ambiti:

  • Il messaggio non arriva da internet verso la nostra infrastruttura
  • Il messaggio raggiunge la nostra infrastruttura ma non viene consegnato alla casella di posta
  • Il messaggio non esce dall’infrastruttura

Vediamo insieme come comportarci nei vari casi.

Il messaggio non arriva da internet verso la nostra infrastruttura

In questo caso il 90% dei problemi è dovuto a problemi di rete. Se non vedete le mail arrivare al vostro server di Front-end o al vostro Edge, controllate le seguenti cose:

  • Verificate con IntroDNS il vostro MX record “intoDNS: checks DNS and mail servers health http://www.intodns.com/
  • Ottenuto il record mx (ogni tanto c’è qualche confusione su chi prende le email per chi 🙂 ) si parte con i tests:

E’ necessario capire se il record punta direttamente alla vostra infrastruttura Exchange, o se c’è uno smarthost che prende le email per voi.

  • Digitate da Command Prompt:
    telnet mx_record 25 [invio]
    Dovreste ottenere il banner del server smtp che accetta la connessione
  • Inviate un’email di prova con la seguente sequenza di comandi:
    helo test
    mail from:utente@dominio.com
    rcpt to:utente@dominio.com
    data
    subject:test email
    test email

Se il server è il vostro Exchange, e vi viene restituito un codice di errore (e la descrizione di cosa succede non è chiara) cercate su http://support.microsoft.com il codice ottenuto.

Se il server non è il vostro Exchange, e vi viene restituito un codice di errore che non sia esplicativo, è necessario contattare il gestore del servizio, o il produttore dell’appliance (nel caso utilizzaste dei moduli hw\sw antispam)

Nel caso di un appliance o software\servizio di terze parti, si possono prendere 2 strade:

  • Collegarsi sull’appliance\server-servizio e verificare se ci sono dei diagnostic loggings che indicano in che stato è il messaggio
  • Verificare sui logs smtp del server di Front-end\Edge se ci sono delle sessioni smtp in ingresso dall’appliance\server-servizio (vedi http://blogs.technet.com/itasupport/archive/2008/10/10/smtp-analisi-del-protocol-logging.aspx per come abilitare\analizzare il log smtp) (per il server edge, è necessario abilitare il logging dalle proprietà del receive connector –> verbose logging)
  • L’apppliance deve in ogni caso comunicare con il server front-end\edge tramite una sessione SMTP, quindi si può provare a ripetere il tests della sessione telnet, questa volta dal server Exchange verso l’appliance\server-servizio e viceversa (ove possibile) per verificare eventuali problemi con apparati di rete.

Nel caso in cui il record MX sia il server Exchange:

  • Aprire l’Exchange System Manger e posizionarsi sul server –> Queue (Ex 2003) o il Queue Viewer (Ex 2007\2010). Se il messaggio è stato ricevuto, lo troveremo in una di queste code.
  • Se il messaggio non è presente nelle code, utilizzare il Message tracking per verificare se il messaggio è stato stato inviato ad un altro server o se sia stato generato un Non Delivery Report.
  • Utilizzate il log del protocollo SMTP per verificare la corretta sequenza di ricezione del messaggio.

Il messaggio raggiunge la nostra infrastruttura o è già nell’infrastuttura stessa ma non viene consegnato alla casella di posta

Dal punto precedente è necessario a quindi capire su quale server il messaggio è fermo. Una volta individuato il server con il message tracking, è necessario controllare le code di Exchange sul server incriminato per capire lo stato del messaggio:

Se il messaggio è pendente nella coda Awaiting Directory lookup

  • Indagare\verificare la connettività con l’infrastruttura Active Directory (connettività di rete verso i domain controller e global catalog (porte tcp 389 e 3268)
  • Verificare che i domain controllers e global catalogs non abbiamo problemi di performances
  • Aumentare il diagnostic logging del server per il componente Categorizer (proprietà del server –> diagnostic logging –> MsExchangeTransport Ex 2003 o Manager Diagnostic logging –> MsExchangeTransport –> categorizer Ex2007Sp2) a Maximum e verificare nell’application log eventuali avvisi\errori.

Se il messaggio è pendente nella coda Remote delivery

  • verificare la connettività di rete con il server\connettore riportato nel nome della coda (verificare anche la risoluzione nomi dns)

Se il messaggio è pendente nella coda Failed Message retry

  • il messaggio potrebbe essere corrotto o sono installati event sync di terze parti che possono interferire con la consegna del messaggio (antivirus o antispam). Provare a disabilitarli.

Se il messaggio non compare nelle code

  • Usare il message tracking per determinare a che punto del message flowing il messaggio è sparito. Se l’ultimo evento è la categorizzazione del messaggio, potrebbero essere coinvolti Event Sync di terze parti, come al punto precedente (gli Event Sync si agganciano alla fase di PostCategorize del messaggio).

    Message flow through an Exchange 2003 server

    From:Exchange Message Flow
    http://technet.microsoft.com/en-us/library/bb123864(EXCHG.65).aspx

In generale in questo caso potete utilizzare i seguenti articoli per il troubleshooting delle code di Exchange:

E’ interessante notare che uno dei problemi che si presenta maggiormente è l’accodamento dei messaggi sul server di Back End, in particolare nelle code: Local Delivery e Awaiting directory lookup.

In questo caso ci sono 3 grandi famiglie di problematiche:

  • Performance del server: In particolare il systema dischi, in questo caso è necessario verificare i contatori logical discs –> average read\sec e average write\sec. Entrambi devono essere sotto i 0.02s
  • Antivirus: Se gli scanning threads sono pochi o i controlli vanno per le lunghe, si può generare il problema.Un dump del processo store.exe in genere rileva la problematica.
  • Varie: Qui si raccolgono alcuni problemi, anche relativi a Store event Syncs, che possono essere analizzati tramite la verifica di un dump del processo Store.exe

Performance del server

Per i problemi di performance utilizziamo il seguente articolo come base di partenza:

Troubleshooting Microsoft Exchange Server Performance
http://technet.microsoft.com/en-us/library/aa997270(EXCHG.65).aspx

Prendiamo ad esempio la parte relativa ai dischi. Vi riporto un esempio reale:

clip_image002clip_image002[7]

In questo caso vi era l’accodamento dei messaggi nella Local Delivery queue.

Come potete osservare il valore delle letture per buona parte dei dichi è scarso, in quanto è superiore ai 20ms(0.02s), mentre il valore delle scritture è assolutamente intollerabile da parte del sistema in quanto è praticamente sempre oltre gli 50ms(0.05s). Al superamento della soglia dei 20ms comincerete ad avere degli accodamenti sporadici di emails, a seconda del traffico e del message rate sperimentato.

Oltre i 50ms le code cominceranno a crescere fintanto che il problema sui dischi non sarà risolto. Considerate la vostra infrastruttura dischi come la colonna portante del vostro server Exchange. In questo caso la problematica era dovuta ad un alimentatore rotto sulla SAN!!!

Antivirus e varie

Se sospettate un problema con l’antivirus o uno Store Sync (la modalità di gestione dei sync, è sincrona (da non confondere sincrona con sync, in quanto la voce “sync” indica l’oggetto che si aggancia ad una funzione specifica e viene attivato solo nel caso specifico), ciò significa che nel processo vengono generati un certo numero di threads, detti Worker  Threads che si occupano di eseguire la funzioni  specifiche. La dll del sync object passerà la chiamata al worker thread libero e aspetterà la restituzione del controllo, prima di far continuare il processo padre.

Detto in temini semplici: se il processo dello store.exe ha 100 email da processare e l’antivirus ha 3 threads, ciò singnifica che verrano processate parallelamente 3 email per volta. Il primo thread che finisce, viene marcato come libero e può processare la mail successiva nella coda dello store.exe. Se per qualche ragione tutti e 3 i processi dell’antivirus si bloccano, da un dump in hang mode del processo store.exe, avrete un sacco di threads in questo stato:

ChildEBP RetAddr
4a7bf2d4 7c59a0a2 NTDLL!NtWaitForSingleObject+0xb
4a7bf2fc 7c57b40f KERNEL32!WaitForSingleObjectEx+0x71
4a7bf30c 00648dd6 KERNEL32!WaitForSingleObject+0xf
4a7bf394 00426a4f store!EcCheckVirusScanStamp+0x687 <—- in questo momento viene passato la chiamata all’antivirus e il thread di elaborazione della mail resta in attesa del completamento.

4a7bf3c4 00415d4d store!OMSG::EcCheckVirusScanStatus+0x130

Se vi ritrovate con un centinaio di thread in questo stato, allora il problema è esattamente li! 🙂

Nel caso di Syncs che non siano l’antivirus, nello stack trovere, nei primi frames di molti threads il riferimento alle funzioni chiamate. (ps. un analisi di questo tipo prevede di verificare lo stato del processo ad alcuni minuti di distanza, non è sufficiente una sola cattura del dump dump di processo in hang mode).

Il messaggio non esce dall’infrastruttura

In questo caso è necessario verificare dove il messaggio si blocca e avere ben presente l’infrastruttura di routing configurata (send connectors e smtp connectors).

Prima cosa verificare sempre se i messaggi raggiungo il server che fà da bridgehead per i connettori, e testare la connettività verso quel server (telnet alla porta 25).

Se il messaggio è fermo sul bridgehead server, verificare il log del protocollo smtp per eventuali errori, provare a fare a fare un telnet verso lo smart host configurato sul connettore smtp, o verso il record mx di un dominio esterno (se utilizzate la risoluzione dns).

Utilizzate un tool di cattura del traffico di rete (network monitor o equivalente) se sospettate problemi con device di rete:

Verificate sempre se la problematica è simmetrica (ovvero otre a non uscire, la posta non entra).

Verificate con il message tracking, in quale parte della delivery il messaggio si blocca (per esempio advanced queue o mta transfer).

Riepilogo

La guida presentata vuole essere semplicemente uno scheletro generico che può essere utilizzato per indirizzare il troubleshoting della problematica. Le modalità di approccio al problema possono essere varie e dipendono molto dall’esperienza passata di chi esegue il troubleshooting.

 

Francesco Poli
Support Escalation Engineer
Microsoft Enterprise Exchange Support

Comments (0)

Skip to main content