Databse Exchange smontato senza apparenti motivi : errore 665

Caso pratico occorso a un infrastruttura Exchange 2016 mono-istanza installata su una macchina virtuale Windows 2016.

Sintomo: i client di Outlook risultano disconnessi e non sincronizzati, non arrivano ne partono mail. Al contempo però la Vm Server risulta up & running, senza criticità di performance o di storage. Superati i controlli superficiali si verifica lo stato del DB tramite EMC, il DB risulta Smontato.

Per prima cosa si procede con il tentativo manuale di mount, il DB resta montato per qualche secondo poi torna in stato di errore.

A questo punto andando a seguire vari case studies sono stato fuorviato dai vari tentativi di verificare e sanificare il DB con l’eseutil, questi tentativi che ho parzialmente percorso sono risultati però inutili in quanto il problema non era nel DB; analizzando i log di sistema infatti ci si è imbattuti in questo errore :

Il log parla di errori di I/O tali da non consentire il failover e poi prosegue:

segnalando l’errore di sistema 665 – che Microsoft identifica come File System limitatiton. Piu nello specifico l’errore spiega che i DB non sono corrotti ma sono stati smontati per limitarne la crescita eccessiva determinata dalla frammentazione del file system NTFS. Esiste infatti un parametro di crescita che una volta superato provoca questo errore e di conseguenza l’impossibilità di proseguire le attività sul disco.

A questo punto, appurato la sanità dei DB e la loro consistenza, la strada unica da percorrere è la seguente :

  1. Aggiungere un nuovo .vmdk alla macchina virtuale, grande a sufficienza per contenere il DB.
  2. Stoppare tutti i servizi inerenti Exchange;
  3. Copiare tramite robocopy tutti i files contenuti nel disco delle mailbox nel nuovo disco appeso alla vm; (in questa fase ricordarsi di utilizzare l’attributo /sec per la copia sicura ) ;
  4. A copia ultimata, assegnare la lettera dell’unità del vecchio disco a quello nuovo;
  5. Riattivare i servizi inerenti a Exchange;
  6. Riavviare la vm e testare il funzionamento.

Essendo il DB sano, questa procedura dovrebbe essere efficace nel 99% dei casi. Una volta testata la ricezione/invio e la solidità del nuovo DB, è poi possibile eliminare il vecchio disco in modo da liberare lo spazio.

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *