Alle volte può accadere che i backup non siano disponibili oppure validi e che un database di fondamentale importanza sia danneggiato e il servizio ad esso legato non parta: quando questa situazione si verifica con Microsoft Exchange c'è una possibilità alternativa di ripristinare i dati.

Nel caso specifico di Exchange 2003 quando non è possibile montare il Mailbox e/o il Public Folder Store compaiono nel registro degli eventi errori che chiariscono il motivo:

Event Type: Error
Event Source: MSExchangeIS
Event Category: General
Event ID: 9518
Description:
Error Current log file missing starting Storage Group /DC=xx/DC=xx/DC=internal/CN=Configuration/CN=Services/CN=Microsoft Exchange/CN=internal/CN=Administrative Groups/CN=First Administrative Group/CN=Servers/CN=exchange-server/CN=InformationStore/CN=First Storage Group on the Microsoft Exchange Information Store.
Storage Group - Initialization of Jet failed.

Event Type: Error
Event Source: MSExchangeSA
Event Category: MAPI Session
Event ID: 9175
Description:
The MAPI call 'OpenMsgStore' failed with the following error:
The Microsoft Exchange Server computer is not available.  Either there are network problems or the Microsoft Exchange Server computer is down for maintenance.
The MAPI provider failed.
Microsoft Exchange Server Information Store
ID no: 8004011d-0526-00000000

Event Type: Error
Event Source: ESE
Event Category: Logging/Recovery
Event ID: 455
Description:
Information Store (324) First Storage Group: Error -1811 occurred while opening logfile X:\xxx\ExchSrv\Mdbdata\E000011A.log.

L'ultimo errore, solitamente quello con Event ID 455, chiarisce cosa impedisce allo store di essere montato correttamente. Nell'esempio riportato c'è un errore nel file di log E000011A.log. I motivi possono essere i più disparati, comunque vi riporto brevemente i più comuni (che poi sono quelli che direttamente ho dovuto affrontare):

• Il file indicato risulta illeggibile oppure non è possibile accedervi
• Il file indicato non esiste
• Non è possibile accedere al disco dove sono contenuti tutti i file di log

Nel primo e nel secondo caso, sempre in assenza di backup, la procedura che illustro di seguito vi dovrebbe consentire di recuperare la maggior parte dei dati presenti all'interno dei database. Nel terzo caso il problema potrebbe essere decisamente più grave e la procedura di ricostruzione dei database potrebbe ripristinare gran parte dei dati ma in alcuni casi potreste anche trovarvi d'innanzi a una massiccia perdita di mail degli utenti.

Prima di illustrare nel dettaglio la procedura che ho eseguito mi preme specificare ancora un dettaglio: in alcuni casi potreste essere tentati di far girare Eseutil su una macchina più performante, sia per qualità del processore che per dimensione dei dischi, rispetto al server Exchange aziendale. Questa postazione alternativa, specie se si tratta di un PC, potrebbe non avere Exchange installato, quindi ecco cosa serve copiare dal server Exchange per poter eseguire Eseutil dove più ci fa comodo:

http://support.microsoft.com/kb/244525/en-us

Fate attenzione che la lingua del sistema operativo sia la stessa del server Exchange, in caso contrario riceverete un errore da JET. Tenete presente che questa soluzione, nonostante rappresenti in alcuni casi un notevole risparmio di tempo in termini di elaborazione, vi costringe a copiare i database dal server Exchange al PC di riparazione, quindi tenete in considerazione tutti i fattori prima di procedere in questo modo.

Il problema era che il server era andato in crash ed Exchange non era riuscito a completare le operazioni nei transaction logs e il file E000052A.log risultava mancante. Per ripristinare la situazione, in assenza di un backup valido, era necessario riparare il database.

Per prima cosa ho verificato dove fosse il problema. I database (Mailbox e Public Folder) erano entrambi in stato di “dirty shutdown”. Per effettuare la verifica ho usato eseutil, in combinazione con lo switch /mh.

eseutil /mh priv1.ebd
eseutil /mh pub.ebd

Eseutil mi ha confermato ciò che già Exchange System Manager mi diceva (non era possibile  montare alcun database): i database erano in stato di “dirty shutdown”  ed andavano ripristinati.

Come secondo step mi sono assicurato che non fosse eseguita la mount dei database all’avvio al fine di evitare spiacevoli inconvenienti durante le varie fasi del ripristino. A questo punto ho bloccato l’Information Store ed ho eseguito la  copia della cartella mdbdata per sicurezza. Avere una copia dei database che si sta tentando di ripristinare e dei relativi transaction logs è fondamentale! In seguito è possibile fare ripartire l’Information Store.

A questo punto si inizia il processo di riparazione vero e proprio. Assicuratevi di avere spazio disponibile sul disco, servirà circa il 20% dello spazio occupato dal database. Lanciate i seguenti comandi:

eseutil /p priv1.edb
eseutil /p pub.edb 

Nel caso lo spazio disco non fosse sufficiente conviene redirigere altrove con il flag /T. Infine, casomai fosse danneggiato anche il file .stm, è possibile utilizzare il flag /createstm per generare un file .stm vuoto. Potete infine leggere (e cancellare) il file di log prodotto (pub1.integ.raw). Ovviamente, a seconda della dimensione dei database da riparare l'operazione potrebbe richiedere diverse ore. Al termine verificate il buon esito dell’operazione digitando nuovamente il comando:

eseutil /mh

A questo punto conviene eseguire la deframmentazione del database. Servirà parecchio spazio per effettuare quest’operazione,  calcolate circa il doppio del database più il 10% (il database viene replicato con una sorta di cut and paste, ovvero viene creato un nuovo db, vi si copia il vecchio, infine il nuovo creato viene rinominato come il vecchio). La deframmentazione ricostruirà gli indici del database e eliminerà i “buchi” creatisi nel db. Al termine dell'operazione di deframmentazione eseguite per l'ultima volta il comando:

eseutil /mh

per verificare lo stato dei database. Ora stoppiamo e poi facciamo ripartire l’Information Store. E’ fondamentale, a  questo punto, cancellare i transaction logs presenti nella cartella mdbdata, altrimenti gli archivi postali continueranno a non installarsi,  e ripeteranno l’errore già visto in precedenza:

Information Store (324) First Storage Group: Error -1811 occurred while opening logfile E:\ProgramFiles\ExchSrv\Mdbdata\E000052A.log.

Alcuni messaggi andranno persi, ma questo è inevitable (manca il transaction log!). Ora apriamo l’Exchange System Manager e montiamo gli archivi postali. Fatto questo li disinstalliamo nuovamente! La ragione di questo mount/dismount è spiegata nella KB Microsoft e serve ad evitare questo errore:

Isinteg cannot initiate verification process.

Finalmente possiamo utilizzare isinteg. Isinteg è un’utility Exchange database aware, ovvero a differenza di eseutil conosce la logica del database di Exchange ed è in grado di associare correttamente i messaggi che contiene. Omettere di eseguire isinteg potrebbe generare strani comportamenti all'interno di Outlook, tipo messaggi non leggibili o discrepanza tra il numero di messaggi dichiarati  nella cartella e quelli effettivamente presenti. Il comando da usare è il seguente:

Isinteg -fix -test alltests 

Saranno generati parecchi warning, l’importante è che non vengano generati error. Nel caso, ripetete l’operazione nuovamente:

Isinteg -fix -test alltests

Successivamente all'esecuzione del comando Isinteg sarà possibile procedere al mount definitivo dei database danneggiati. Ricordatevi di ripristinare il mount automatico dei database interessati che era stato disattivato in precedenza.