Supporto Tecnico Enterprise : Francesco Poli

Exchange 2003 - Troubleshooting delle code e consegna dei messaggi

itentblg — Mon, 05 Oct 2009 02:00:00 GMT

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

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:

Troubleshooting Mail Flow and SMTP
http://technet.microsoft.com/en-us/library/aa996805(EXCHG.65).aspx
Managing Queues
http://technet.microsoft.com/en-us/library/bb125022.aspx

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:

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:

Microsoft Network Monitor 3.3
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=983b941d-06cb-4658-b7f6-3088333d062f

Fare una cattura utilizzando il filtro “.protocol.smtp” se volete verificare la sessione smtp

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

Exchange 2010 – Rilasciata la RELEASE CANDIDATE

itentblg — Wed, 19 Aug 2009 02:00:00 GMT

La Release Candidate di Exchange 2010 è stata rilasciata ieri al pubblico dal sito download Microsoft:

Microsoft Exchange Server 2010 Release Candidate

Brief Description

Microsoft Exchange Server 2010 helps you achieve new levels of reliability and performance by delivering features that help to simplify your administration, protect your communications, and delight your customers by meeting their demands for greater business mobility.
http://www.microsoft.com/downloads/details.aspx?FamilyID=c6d27da1-ba2c-4570-a491-c0d7b39ede8b&displaylang=en

Il rilascio della Release Candidate significa che il prodotto ha raggiunto un livello di stabilità tale per cui la build è considerata il punto di partenza per la successiva versione definitiva RTM.

Tutte le build successive saranno delle minor version, senza grossi cambiamenti in termini di funzionalità del prodotto e d’interfacce di gestione.

Attualmente, è disponibile solamente la versione in lingua Inglese.

Francesco Poli
Support Escalation Engineer
Microsoft Enterprise Exchange Support

Exchange 2010 – Disponibile la Beta: vediamo insieme i cambiamenti

itentblg — Thu, 16 Apr 2009 18:21:55 GMT

Il gruppo di supporto Exchange e lieto di annunciare che è disponibile la versione Beta di Exchange 2010.

Il download è disponibile nel sito ufficiale Microsoft per Exchange 2010

Il TechNet contiene la documentazione ufficiale per Exchange 2010 anche se è in fase di completamento.

Di seguito riporto le nuove funzionalità che sono state introdotte, nei prossimi giorni scenderemo nel dettaglio di ogni singola caratteristica.

Protezione delle Email con i servizi di Active Directory Right Management Services

Possibilità di utilizzo delle Transpor Rules per applicare le protezioni RMS condizionalmente.
Protezione continua degli allegati nei messaggi protetti con RMS.
Supporto per i templates di Active Directory RMS .
Templates RMS per la protezione delle mail inviate esternamente all’infrastruttura.
Protezione dei messaggi Vocali

Miglioramenti e aggiunte relative alle Transport Rules e Routing Functionalities

Segmentazione delle infrastruttua di Posta Elettronica = E’ possibile implementare una segmentazione dell’infrastruttura di emailing decidendo di mantenere parte del deployment dell’infrastruttura “in House” e utilizzare parte dei servizi On-Line di Exchange Hosted Services.
Disclaimer!!! = Sono state migliorate le funzionalità di aggiunta dei disclaimer, permettendo ora l’inserimento di Links, formattazioni HTML, Immagini e un interfaccia di integrazione con Active Directory
Transport Rules e integrazione con AD RMS = E’ stata aggiunta la possibilità di integrare la protezione AD RMS in automatico tramite delle Transport rules
Email, con “Moderazione” = E’ possibile implementare dei workflow di consegna per determinare dei processi di approvazione del contenuto delle email per decidere se un messaggio si possa essere consegnato al destinatario (questo è il genere di regole che piace agli uffici legali :) )
Ridondanza nella consegna = Il messaggio email viene mantenuto come copia di backup nell’Hub server fintato che il successivo Hub\smtp server non ne decreti la corretta ricezione. Nel caso in cui non venisse rilevata la corretta consegna, il messaggio verrebbe reinvitato.
Rimozione dei messaggi dal Transport Dumpster in base allo stato della copia dei log = Il messaggio verrà rimosso dal transport dumpster dell’Hub server, solamente nel momento in cui tutte le copie del mailbox database avranno ricevuto il messaggio.
Definizione di uno SLA per latenza nel transporto del messaggio = Il nuovo sistema di Transport permette di valutare lo SLA sulla latenza nelle tempistiche di consegna dei messaggi tra i vari Hops e per il tempo totale di consegna del messaggio, dalla partenza alla ricezione da parte del destinatario.
Miglioramenti nelle performance del database del Transport = Sono state notevolmente migliorate le performance del servizio di trasporto delle mail, riducendo, come nel caso dei server mailbox, il numero di IOPS necessari per il database del transport.

Nuove funzionalità e migliorie nella gestione dei permessi

E’ stato introdotto il nuovo modello di gestione basato sui ruoli che rimpiazza il vecchio modello di permessi precedentemente implementato.
In questo modo è possibile avere una segmentazione molto precisa e semplice di chi può fare cosa nell’infrastruttura Exchange.
Questo modello permette di implementare delle restrizioni di accesso anche ai comandi powershell che l’utente può eseguire, in base al ruolo che è stato assegnato.

Nuove funzionalità per l’Alta Disponibilità

Questa è una delle parti più interessanti (e non lo dico solo perché mi piace l’area di disaster recovey e alta affidabilità :) )

Nella versione 2007 di Exchange, sono state introdotte molte modalità di gestione della ridondanza per garantire l’alta affidabilità dei sistemi, in particolare abbiamo:

LCR: Local Continuos Replication: Implementa in locale, su un singolo server della copia di un database, in modo da garantire la protezione del database in caso di un problema sull’istanza fisica (es. si rompe il disco rigido)

SCC: Single Copy Cluster: Implementa il vecchio modello di cluster, in cui abbiamo una Storage Area Network condivisa tra più nodi di un cluster.

CCR: Cluster Continuos Replication: Implementa una modalità di replica dei database tramite un cluster geografico di tipo Majority Node Set e un servizio di replica gestito da Exchange, che permette la sincronizzazione dei database su 2 nodi fisici, senza avere uno storage condiviso.

SCR: StandBy Continuos Replication: Implementa una modalità (introdotta con la Sp1 di Exchange 2007) che permette di mantenere un infrastruttura simile a quella di produzione (intesa a livello di server Exchange, quindi server o cluster group) in StandBy tramite un meccanismo di replica simile a quello de CCR.

Database portabilty: a differenza delle versioni 5.5,2000 e 2003, dalla versione 2007 in avanti di Exchange non è più necessario che il database delle mailbox sia vincolato al server sul quale è stato creato, ma è possibile spostare i database tra i vari server, a seconda delle necessità

Vediamo ora cosa è cambiato con Exchange 2010!

Come avrete notato tutte le sigle dei vari sistemi replica, possono generare un po' di confusione, quindi… ABBIAMO ELIMINATO I CLUSTERS

In pratica è stato rivoluzionato completamente il modello di alta affidabilità, non esistono più le seguenti modalità: LCR,SCC,CCR e SCR, lo stesso concetto di Mailbox server clusterizzato non esiste più.

Exchange 2010 implementa una modalità di replica dei database che unisce le funzionalità del sistema CCR e SCR.

E’ stato implementato un modello denominato Continuos Availability (disponibilità continua) per cui ogni singolo database può essere replicato su ben 16 server diversi in modalità continua.

l failover è stato reso più granulare, quindi adesso abbiamo la possibilità di eseguire un Database Failover, invece del classico server failover che prevedeva lo spostamento di tutti i database di un server (il server failover sarà disponibile comunque dalla prossime release di Exchange 2010, in pratica sarà comunque un failover di tutti i database del server)

Le tempistiche di failover sono nettamente diminuite rispetto alle versioni precedenti, a prodotto finito si stima un tempo di failover di meno di 30 secondi, contro i circa 2 minuti attuali.

I backups possono essere fatti da una qualsiasi delle copie del database, oltre che dal nodo attivo.

Nei prossimi post approfondiremo gli aspetti tecnici dell’alta disponibilità.

Nuove funzionalità e miglioramenti nell’Information Store (lo “Store” per gli amici)

Storage Group: Non esiste più il concetto di storage group come gruppo logico per raggruppare i database, ma ogni database vive singolarmente.
I Mailbox database non sono più direttamente collegati ai server, ma sono considerati oggetti “stand alone”. Anche in Active Direcotry, l’oggetto mailbox database è stato spostato, nella struttura del configuration container, allo stesso livello del server.
Extensible Storage Engine (ESE) è stato modificato e aggiornato, introducendo delle modifiche che ne migliorano il comportamento in termini di performance e ne estendono le funzionalità per l’alta affidabilità e per la il Database Mobility.
La struttura dello Store è stata ristrutturata in modo da incrementarne le performance e rimuovendo delle strutture che ne appesantivano l’utilizzo.

Nuove funzionalità per la Compliance e Messaging Policy

Sono state implementate nuove interfacce per l’applicazione delle policy.
E’ stato implementato un sistema di tagging automatico per le policy di conservazione delle Email.
Aggiunte alcune funzionalità che permettono di eseguire delle ricerche in più Mailbox contemporaneamente con il supporto per l’Advanced Query Sintax
Nuove predicati e azioni per la creazione delle Transport Rule.

Nuove funzionalità di OWA (Outlook Web Access)

Utilizzo dei Favoriti nel pannello di Navigazione
Cartelle di ricerca
Filtri sui messaggi
Possibilità di impostare le categorie nelle liste di messaggi
Il Web Managent permette di impostare le configurazioni per OWA
Possibilità di visualizzare i calendari affiancati
Supporto Multi lingue per i clients
Possibilità di fare l’attach di un messaggio ad un nuovo messaggio ed inviarlo come allegato.
Nuove funzionalità e menù con il tasto destro del mouse.
Integrazione con Office Communicator, visualizzazione della presenza, chat e liste di contatti.
Possibilità di visualizzare una conversazione (ordinamento email)
Possibilità di inviare e ricevere SMS da OWA
Policy mailbox per OWA

Nuove funzionalità per l’Unified Messaging

Configurazione di regole per la risposta automatica (Auto Attendants Rule)
Aggiunto il supporto per altre lingue relativo all’Outlook Voice Access e per il Voice Mail Preview
Miglioramenti nella risoluzione dei nome del chiamante tramite l’identificativo del chiamante
Possibilità di farsi leggere le email da una voce automatica (Voice Mail Preview)
Notifica di un messaggio in attesa
Notifica di conversazioni perse o di chiamate vocali tramite SMS
Chiamate vocali protette
Ruoli di gestione dell’Unified Messaging predefiniti

Nuova Interfaccia di gestione Web

Integrazione con servizi telefonici quali SMS
Integrazione con il Voice messaging
Funzionalità di ricerca Mailbox
Possibilità di creazione e gestione delle liste di distribuzione
Regole Moderazione e approvazione per l’invio alle liste di distribuzione

Nuove funzionalità per la console di gestione (Exchange Managemet Console)

Integrazione con il programma Customer Experience Improvement Program (CEIP)
visualizzazione dello stato di funzionamento dell’Organizzazione Exchange
Collegamento con le Communities e con Risorse web
Possibilità di loggare i comandi eseguiti

Nuove funzionalità nella shell (Exchange Management Shell)

Powershell v2: L’utilizzo della versione 2 della powershell, permette di creare script di gestione molto elaborati.
Amministrazione remota: Grazie alla nuova shell sarà possibile collegarsi remotamente al server Exchange per eseguire i comandi senza necessità di essere loggati direttamente sul server.
Logging: Possibilità di loggare tramite Audit i comandi che vengono eseguiti e che comportano un cambiamento di configurazione degli oggetti collegati all’infrastruttura Exchange.

Questo è solo una veloce review delle modifiche che saranno introdotte da questa nuova versione di Exchange, nei prossimi giorni faremo dei post di approfondimento relativi ai vari componenti qui citati.

Francesco Poli
Senior Support Engineer
Microsoft Enterprise Exchange Support

Exchange 2007 - I servizi non si avviano dopo l'installazione della Roll Up 1, 2, 3 o 4

itentblg — Mon, 01 Dec 2008 03:00:00 GMT

In questo articolo vorrei trattare una problematica nota che però genera ancora qualche chiamata al supporto tecnico.

Il problema si presenta nel seguente modo: dopo aver installato una delle Roll Up dalla 1 alla 4 di Exchange 2007 Service Pack 1, può capitare che alcuni dei servizi di Exchange, o anche dei tools di monitoraggio e troubleshooting (ExBPA o ExTRA) non riescano improvvisamente più ad avviarsi sul alcuni server.

Il servizio sembra andare misteriosamente in timeout senza un errore specifico e l'application log non segnala nessun tipo di errore specifico, a parte i seguenti generici:

Event Type: Error
Event Source: Service Control Manager
Event ID: 7000
Description: The Microsoft "service name" service failed to start due to the following error:
The service did not respond to the start or control request in a timely fashion.

Il problema si genera per quei servizi o applicativi che sono stati sviluppati in managed code, ovvero in .NET, generalmente fanno capo ai seguenti eseguibili:

[Percorso di installazione di Exchange]\
Bin\ExBPA.exe
Bin\ExBPACmd.exe
Bin\ExTRA.exe

Bin\EdgeTransport.exe

Bin\Microsoft.Exchange.Cluster.ReplayService.exe
Bin\Microsoft.Exchange.EdgeSyncSvc.exe
Bin\Microsoft.Exchange.Monitoring.exe
Bin\Microsoft.Exchange.Search.ExSearch.exe
Bin\Microsoft.Exchange.ServiceHost.exe
Bin\EdgeTransport.exeBin\MSExchangeMailboxAssistants.exe
Bin\MSExchangeMailSubmission.exe
Bin\MSExchangeTransportLogSearch.exe
ClientAccess\PopImap\Microsoft.Exchange.Imap4.Exe
ClientAccess\PopImap\Microsoft.Exchange.Pop3.Exe

Bin\Microsoft.Exchange.AntispamUpdateSvc.exe
Bin\MsExchangeFDS.exe
Bin\MSExchangeTransport.exe

Per quale motivo i servizi dovrebbero andare in timeout?

La problematica è di per se tanto misteriosa quanto di semplice risoluzione!

Intanto il problema si presenta per quei server che non hanno accesso diretto ad internet e devono passare obbligatoriamente tramite un web proxy.

In sostanza all'avvio del programma viene caricato dal .NET Framework l'assembly del programma che a sua volta cerca di verificare la firma Authenticode con cui è stato firmato il codice. Per fare questa attività deve essere verificato che il codice non sia stato firmato con un certificato non valido, e per poter fare questa verifica la funzione del CryptoAPI cerca di collegarsi al sito http://crl.microsoft.com per scaricare la Certificate Revocation List con cui fare il controllo.

Nel caso in cui non vi sia l'accesso ad internet o tale accesso sia vincolato al passaggio attraverso un proxy server, questa operazione fallisce fintanto che i continui tentativi superano il tempo massimo che il Service Control Manger ha definito come validi per l'avvio di un servizio.

Soluzione

Prima Soluzione

Su un server 2003 è possibile utilizzare il comando proxycfg.exe per settare un proxy a livello di sistema e utilizzabile dal server stesso. Putroppo questa soluzione ha il problema che se il proxy è autenticato, il comando non può essere utilizzato in quanto non permette di specificare le credenziali da usare.

Seconda soluzione

Questa è la soluzione consigliata e raccomandata, si può applicare in 2 modi, uno manuale e uno automatico, entrambi richiedono l'installazione di una delle seguenti fixes e in pratica evitano che venga eseguita la verifica di validità tramite la CRL:

FIX: A .NET Framework 2.0 managed application that has an Authenticode signature takes longer than usual to start
http://support.microsoft.com/kb/936707/
FIX: You may notice that the memory load is very high when you run an application that is built on the .NET Framework 2.0
http://support.microsoft.com/kb/942027/

Consiglio di installare il Service Pack 1 per la .NET Framework che contiene entrambi gli aggiornamenti sopra indicati:

Problems that are fixed in the .NET Framework 2.0 Service Pack 1
http://support.microsoft.com/kb/945757/

Manuale

La soluzione manuale consiste nel creare, dove non esistesse già, un file di configurazione per il servizio\programma che non parte.

Questo file di configurazione sarà nominato con lo stesso nome completo di estensione dell'eseguibile, ma avrà appesa un estensione aggiuntiva ".config".

Per fare un esempio: se il programma si chiamasse "Microsoft.exchange.transport.exe", il file di configurazione dovrebbe risultare "Microsoft.exchange.transport.exe.config"

Il file di configurazione dovrà contenere la seguente entry:

Se il file fosse già presente con una struttura simile o con informazioni maggiori, è sufficiente aprirlo con notepad, trovare il percorso in <Configuration><runtime> e inserire la entry <generatePublisherEvidence enabled="false" />

Automatico

La versione automatica è la migliore, e si tratta semplicemente di installare la Roll Up 5 di Exchange 2007 Sp1.

Description of Update Rollup 5 for Exchange Server 2007 Service Pack 1
http://support.microsoft.com/?kbid=953467

Download the Update Rollup 5 for Exchange Server 2007 Service Pack 1 package now.

L'installer della RU5 provvede in automatico a fare il controllo di esistenza e bontà dei files di configurazione per i servizi riportati all'inizio dell'articolo.

Nel caso il file di configurazione non fosse presente, l'installer provvede a creare il file stesso e a compilarlo. Se il file fosse già presente, verrà modificato con l'aggiunta della entry corretta per evitare il controllo.

Maggiori informazioni e approfondimenti:

Exchange Server 2007 managed code services do not start after you install an update rollup for Exchange Server 2007
http://support.microsoft.com/kb/944752
Exchange 2007 managed services might time out during certificate revocation checks
http://msexchangeteam.com/archive/2008/07/08/449159.aspx

Francesco Poli
Senior Support Engineer
Microsoft Enterprise Exchange Support

SMTP: Analisi del Protocol Logging in Exchange 2003

itentblg — Fri, 10 Oct 2008 17:47:00 GMT

L'SMTP virtual server ha un suo protocol logging che offre anche la possibilità di farci analizzare qualche informazione utile sul nostro sistema Exchange. Spesso ci si dimentica di ciò, relegando tale attività al Diagnostic logging di Exchange nel caso si debba analizzare qualche problematica o, al Message tracking, quando si voglia verificare il percorso di un messaggio all'interno dell'infrastruttura.

Parlando di Exchange 2003 spesso ci troviamo ad aver bisogno di analizzare il pattern di traffico SMTP per capire cosa sta succedendo durante il rallentamento del flusso del traffico mail su un server specifico, e spesso il logging non risulta essere attivato oppure risulta essere attivato ad un livello troppo basso per poter estrapolare informazioni utili.

Detto questo, ciò non è un problema fintanto che non si presenti la necessità di fare un analisi temporale di una problematica. L'incremento del livello di logging è un operazione semplice e veloce, ma la mancanza di dati anteriori al presentarsi del problema rende impossibile analizzare il potenziale momento zero in cui l'anomalia si è presentata.

Queste informazione possono essere utili, nel momento in cui si hanno i dati di più sistemi da aggregare (event log di più sistemi, protocol log di vari server, router e firewall log) per fare il punto della situazione su una problematica in corso.

Abilitazione del protocol log

La configurazione del protocol logging si esegue dalla console di Exchange seguendo il percorso:

Organizzazione -> Servers -> Protocols -> Smtp -> Proprietà del virtual server SMTP -> Enable logging

Come tipologia di logging, io preferisco il formato w3c in quanto è facilmente manipolabile sia con Excel, sia con LogParser

I log sono salvati in: C:\Windows\System32\logfiles\SMTPSVCxxx

Come configurazione per la gestione dei file, preferisco il logging giornaliero per 2 motivi:

I file non sono mai troppo grossi da rallentare le operazioni di manipolazioni come nel caso del log settimanale o mensile.
Il logging orario genera troppi file che devono poi essere uniti.

I campi da includere nel logging sono i seguenti:

date; time; c-ip; cs-username; s-sitename; s-computername; s-ip; s-port; cs-method; cs-uri-query; sc-status; sc-bytes; cs-bytes; time-taken.

Interpretazione del log file

Per interpretare correttamente i campi tenete presente i suffissi del nome dei campi:

c- : Client
s- : Server
cs- : comunicazione dal Client al server
sc- : comunicazione dal Server al client

Date e Time ci indicano il momento in cui stato loggato l'evento, considerate che l'orario è sempre in GMT (Greenwich Meridian Time)

c-ip: Indirizzo ip del client.

cs-username: Nome macchina con cui il client si presenta al server.

s-sitename: Qui troverete il nome del virtual server smtp da cui parte la chiamata.Il nome è lo stesso della cartella in cui è salvato il log. es:SMTPSVC1

s-computername: Nome del server (qui è possibile trovare l'indirizzo ip della macchina remota)

s-ip: Server ip addres (quello associato al virtual server smtp).

s-port: Porta tcp utilizzata

cs-method: Generalmente il verbo smtp inviato dal client, es: ehlo, mail, data, quit etc.

cs-uri-query: Parametro del comando smtp, es: from:utente@dominio.dom nel caso di un verbo mail from

sc-status: codice di ritorno che il server genera a fronte del comando inviato, es. 250 (ok)

sc-bytes: numero di bytes inviati dal server al client

cs-bytes: numero di bytes inviati dal client al server

time-taken: durata della comunicazione in millisecondi

Durante l'analisi di un log SMTP, generalmente viene analizzato un sottoinsieme di verbi, nel complesso si guarda lo stato della sessione nella sua integrità. Vi riporto il sotto insieme più utilizzato durante l'analisi con la descrizione del verbo.
Per la lista completa dei verbi SMTP, fare riferimento a: SMTP Protocol Extensions

HELO e EHLO

Helo indica l'inizio di una sessione SMTP base, mentre ehlo indica che sono supportati i verbi avanzati SMTP.

MAIL

Identifica l'identità del mittente. Lo troverete come: MAIL FROM.

RCPT

Indica la lista dei destinataria cui è diretta la mail. Nella forma RCPT TO.

DATA

Indica l'inizio del trasferimento dati del contenuto della mail.

BDAT, CHUNKING

Comando alternativo a DATA, usato in sessioni EHLO.

Con il verbo CHUNKING il server indica che è utilizzabile il verbo BDAT e quindi è possibile suddividere il messaggio in pezzetti.

Il vantaggio del comando BDAT è che che per ogni chunk inviato, il server remoto ne notifica la dimensione. Questo permette al server locale di non controllare continuamente i dati ricevuti per ricercare la fine del messaggio, ma in questo caso si limita a fare un conteggio dei byte ricevuti: questo migliora le performance del server in ricezione.

QUIT

Indica la fine della sessione SMTP.

RSET

Resetta il buffer della sessione SMTP.

Sessione SMTP

Di seguito riporto un esempio di sessione SMTP tra Front-end e Back-end in cui il front-end passa una mail al back-end con Ehlo

#Fields: date time c-ip cs-username s-sitename s-computername s-ip s-port cs-method cs-uri-query sc-status sc-bytes cs-bytes time-taken
2008-09-23 13:38:54 172.16.10.15 OutboundConnectionResponse SMTPSVC1 FRONTEND - 25 - 220+back.monkey.island+Microsoft+ESMTP+MAIL+Service,+Version:+6.0.3790.3959+ready+at++Tue,+23+Sep+2008+15:38:54++0200+ 0 125 0 15
2008-09-23 13:38:54 172.16.10.15 OutboundConnectionCommand SMTPSVC1 FRONTEND - 25 EHLO frontend.monkey.island.int 0 4 0 15
2008-09-23 13:38:54 172.16.10.15 OutboundConnectionResponse SMTPSVC1 FRONTEND - 25 - 250-back.monkey.island+Hello+[172.16.10.17] 0 50 0 15
2008-09-23 13:38:54 172.16.10.15 OutboundConnectionResponse SMTPSVC1 FRONTEND - 25 - 334+GSSAPI+supported 0 20 0 31
2008-09-23 13:38:54 172.16.10.15 OutboundConnectionResponse SMTPSVC1 FRONTEND - 25 - 334+[CUT] 0 224 0 47
2008-09-23 13:38:54 172.16.10.15 OutboundConnectionResponse SMTPSVC1 FRONTEND - 25 - 235+2.7.0+Authentication+successful. 0 36 0 47
2008-09-23 13:38:54 172.16.10.15 OutboundConnectionCommand SMTPSVC1 FRONTEND - 25 X-LINK2STATE LAST+CHUNK={0000006a}+MULTI+(5)+({00000051}+DIGEST_QUERY+05996d955a6b194d96b4bdc96a3edb91+59f38b59d328aeb71e6e0cd01c35e32b++)++ 0 12 0 47
2008-09-23 13:38:54 172.16.10.15 OutboundConnectionResponse SMTPSVC1 FRONTEND - 25 - 200+LAST+CHUNK={00000029}+MULTI+(5)+({00000010}+DONE_RESPONSE++)++ 0 66 0 47
2008-09-23 13:38:54 172.16.10.15 OutboundConnectionCommand SMTPSVC1 FRONTEND - 25 MAIL FROM:<elaine@booty.island>+AUTH=<> 0 4 0 47
2008-09-23 13:38:54 172.16.10.15 OutboundConnectionResponse SMTPSVC1 FRONTEND - 25 - 250+2.1.0+elaine@booty.island....Sender+OK 0 41 0 47
2008-09-23 13:38:54 172.16.10.15 OutboundConnectionCommand SMTPSVC1 FRONTEND - 25 RCPT TO:<GUYBRUSH@MONKEY.ISLAND> 0 4 0 47
2008-09-23 13:38:54 172.16.10.15 OutboundConnectionResponse SMTPSVC1 FRONTEND - 25 - 250+2.1.5+GUYBRUSH@MONKEY.ISLAND+ 0 46 0 47
2008-09-23 13:38:54 172.16.10.15 OutboundConnectionCommand SMTPSVC1 FRONTEND - 25 XEXCH50 1092+2 0 7 0 47
2008-09-23 13:38:54 172.16.10.15 OutboundConnectionResponse SMTPSVC1 FRONTEND - 25 - 354+Send+binary+data 0 20 0 47
2008-09-23 13:38:54 172.16.10.15 OutboundConnectionResponse SMTPSVC1 FRONTEND - 25 - 250+XEXCH50+OK 0 14 0 62
2008-09-23 13:38:54 172.16.10.15 OutboundConnectionCommand SMTPSVC1 FRONTEND - 25 BDAT 21089+LAST 0 4 0 62
2008-09-23 13:38:54 172.16.10.15 OutboundConnectionResponse SMTPSVC1 FRONTEND - 25 - 250+2.6.0++<1e7932b22686$25501dfb$0c18149e@bxzenisl>+Queued+mail+for+delivery 0 77 0 62
2008-09-23 13:38:54 172.16.10.15 OutboundConnectionCommand SMTPSVC1 FRONTEND - 25 RSET - 0 4 0 93
2008-09-23 13:38:54 172.16.10.15 OutboundConnectionResponse SMTPSVC1 FRONTEND - 25 - 250+2.0.0+Resetting 0 19 0 93
2008-09-23 13:38:58 172.16.10.15 OutboundConnectionCommand SMTPSVC1 FRONTEND - 25 QUIT - 0 4 0 2937
2008-09-23 13:38:58 172.16.10.15 OutboundConnectionResponse SMTPSVC1 FRONTEND - 25 - 221+2.0.0+back.monkey.island+Service+closing+transmission+channel 0 72 0 2937

Da notare le ultime 4 righe, in particolare la sequenza RSET -> 250 resetting -> QUIT -> 221 closing trasmission channel.

In questo caso ho tagliato il log riportato per motivi di lunghezza. Il front-end aveva più email da consegnare al back-end e quindi ha proceduto a fare il reset del canale dopo il quint'ultimo comando(queued mail for delivery), e ha ricominciato la sequenza di comandi da “Mail from” per il successivo messaggio in coda.

Log Parsing

Un tool molto comodo per fare un parsing dei log SMTP è il LogParser, scaricabile gratuitamente.

LogParser è un processore intelligente di log che supporta una sintassi query SQL per l'interrogazione di vari formati di file e permette l'export del risultato della query in vari formati, testuali e grafici.

Alcuni si chiederanno come mai utilizziamo LogParser quando abbiamo a disposizione strumenti come Excel, che permettono una manipolazione grafica del file?
La risposta è tutto sommato semplice: è possibile creare script! Potete creare script Batch, Vbs o Powershell che, a titolo di esempio, vi crei dei reports durante la notte e li pubblichi su un sito intranet o li invii tramite email.

Vediamo qualche elaborazione che può esserci utile:

Top 10 client che hanno "occupato" il server per più tempo (aka: somma dei tempi della sessione)
logparser -i:w3c "select Top 10 c-ip as ClientIp,div(div(sum(to_real(time-taken)),1000),60) as TotalMinutes,div(sum(to_real(cs-bytes)),1024) as ClientSentKb,div(sum(to_real(sc-bytes)),1024) as ServerSentKb from example.log where ((cs-method not like 'quit') and (cs-method <> NULL)) group by ClientIp order by TotalMinutes desc" -q:on -o:datagrid
Top 10 client che hanno trasferito più dati (sempre somma totale dei byte di tutte le sessioni):
logparser -i:w3c "select Top 10 c-ip as ClientIp,div(div(sum(to_real(time-taken)),1000),60) as TotalMinutes,div(sum(cs-bytes),1024) as ClientSentKb,div(sum(sc-bytes),1024) as ServerSentKb from example.log where ((cs-method not like 'quit') and (cs-method <> NULL)) group by ClientIp order by ClientSentKb desc" -q:on -o:datagrid
Top 10 command che hanno impiegato più tempo:
logparser -i:w3c "select Top 10 c-ip as ClientIp,cs-username as ClientName,cs-method as Verb,cs-uri-query as Command,div(to_real(time-taken),1000) as CommandSeconds,div(to_real(cs-bytes),1024) as ClientSentKb,div(to_real(sc-bytes),1024) as ServerSentKb from monkey.log where ((verb not like 'quit') and (verb <> NULL)) order by CommandSeconds desc" -q:on -o:datagrid
Top 10 command che hanno trasferito più dati:
logparser -i:w3c "select Top 10 c-ip as ClientIp,cs-username as ClientName,cs-method as Verb,cs-uri-query as Command,div(to_real(time-taken),1000) as CommandSeconds,div(to_real(cs-bytes),1024) as ClientSentKb,div(to_real(sc-bytes),1024) as ServerSentKb from example.log where ((verb not like 'quit') and (verb <> NULL)) order by ClientSentKb desc" -q:on -o:datagrid
Tutte le sessioni di un client:
logparser -i:w3c "select * from example.log where c-ip like '172.16.10.15'" -q:on -o:datagrid
Comandi che hanno ricevuto una risposta negativa temporanea (es. timeout):
logparser -i:w3c "select * from example.log where((sc-status > 400) and (sc-status < 500))" -q:on -o:datagrid
Comandi che hanno ricevuto un errore:
logparser -i:w3c "select * from example.log where (sc-status > 500)" -q:on -o:datagrid
Indicativamente quanti byte sono transitati in SMTP:
logparser -i:w3c "select sum(cs-bytes) as ClientSentKb, sum(sc-bytes) as ServerSentKb from example.log where ((cs-method not like 'quit') and (cs-method <> NULL))" -q:on -o:datagrid
Logparser bonus NeuroView :

Provate a sostituire nei comandi precedenti l'ultimo parametro:
-o:datagrid

con
-o:neuroview -looprows 100

Riepilogo

L'analisi di un log SMTP può fornire qualche informazione utile anche riguardo allo stato del nostro sistema Exchange, oltre a fornirci una visione dettagliata di quello che sta accadendo a basso livello.

Possiamo per esempio verificare se una sessione SMTP ha dei problemi di performance magari dovuti all'infrastruttura di rete, ad esempio link VPN o DSL, molto usati nelle grosse infrastrutture dove la topologia dell'infrastruttura Exchange è composta da svariati siti e routing group: quindi routing group connector e SMTP connector.

Per fare un esempio verificando il trasferimento di una mail da un sito all'altro, potremmo renderci conto di essere di fronte ad una situazione del genere:

cs-bytes: 10240; time-taken:35000

Dipendentemente dalla tipologia di link di rete che abbiamo a disposizione, 35 secondi per inviare 10kb potrebbero essere accettabili, ma nella maggior parte dei casi, sarebbe indicativo di un problema lato network piuttosto che un problema di processi Exchange. Anche se la prima impressione dovuta alle code SMTP in crescita, avrebbe potuto far pensare il contrario.

Francesco Poli
Senior Support Engineer
Microsoft Enterprise Exchange Support