I happened to notice that I stopped receiving external emails on my Exchange 2010 instance.  The strange thing was that internal messaging continued to work fine.  Outlook connected, Cacti was sending notifications, etc.  Normally if I do something to break my lab Exchange, it is completely down.

Even though my Cacti installation sends mail through my smtp server which runs postfix.  The mail.log file provided this error upon a test message sourced from an external domain:

Jan  4 16:23:20 smtp0 postfix/smtp[2051]: A4220A24AE: to=<a.li as.@destephen.com>, relay=exchange0.destephen.local[192.168.0.34]:25, delay=10, delays=0.35/0/5/5, dsn=4.3.1, status=deferred (host exchange0.destephen.local[192.168.0.34] said: 452 4.3.1 Insufficient system resources (in reply to MAIL FROM command))

Off to the Exchange server and everything looks OK at first glance.  A little searching turns up some disk space issues.  Apparently the deferred errors will begin to happen when the drive with the disk begins to fill up.  The disk never completely filled up – I had 2GB free on the primary drive.  I was able to get to 3.5GB with a little file maintenance, but it wasn’t enough.  The database should have been put on a separate drive to begin with anyways :).

With that, it was time to move the database to a new drive.  Simple process thanks to VMware’s ability to add an additional disk on the fly.  After I went to move the database and logs to the new drive, the database simply would not remount. I would receive a pop-up error including the error code “hr=0x80004005 ec=-539”.  The database did get unmounted cleanly by issuing the “ESUTIL /mh <full path to *.edb>” command.

It turns out the solution was to move the existing log files from the expected directory.  Once moved to a archive folder, the database mounted properly within the management console. I imagine that there is some logging and configureable alerting, it is interesting that the esutil checks could not reconcile or detect that the logs were creating the issue when it appears they perform some sort of checks the database logs. Either way, hopefully my crude Exchange troubleshooting helps someone in the future.