So recently encountered a problem in our Exchange 2003 environment where mailstores on one particular server kept dismounting at in opportune times. Snooped around awhile to figure this one out so I figured I’d post about it to make sure I could look it up again. Besides, I haven’t been posting much lately, changing responsibilities at work and all that, so I probably need to get back in the habit.
Event Type: Error
Event Source: MSExchangeIS
Event Category: General
Event ID: 1159
Date: 7/8/2010
Time: 4:35:52 AM
User: N/A
Computer: SMB01
Description:
Database error 0xfffffd9a occurred in function JTAB_BASE::EcUpdate while accessing the database "SG1\STORENAME".
For more information, click http://www.microsoft.com/contentredirect.asp.
Looking up the error on the event log promptly guided me to the problem. Found a Microsoft Article with the same symptoms. http://support.microsoft.com/kb/925817 This particular article was Exchange 2007, but the same hard limit applies for Exchange 2003.
Log files are only committed after a full backup has been performed. Turns out this box had been having backup troubles for about a week and the server administrative group didn’t let us know. Simple solution. Get a successful backup.
As an Exchange administrator we have probably all had that panic call from an administrative assistant want to recall a message that was inadvertently sent to the wrong group. Every end-user knows that Outlooks “Re-Call” capability stinks. Microsoft’s Exchange Mailbox Merge tool can be used to perform this function (Available as a download from Microsoft Here). You’ve probably used this tool before to extract a single user’s mailbox from the Exchange Recovery Storage group to a PST.
We can use a similar technique to extract and delete all of the messages that match a criteria like “SUBJECT” to a PST and then simply throw away the PST.
Before we begin make sure the account you are using is NOT a Domain Admin and has read access to the mailstore and all of the mailboxes. I like setting this permission on the SERVER level and letting it propagte down to the individual mailboxes. You can’t use a Domain Admin account because Exchange explicitly denies Domain Admins read access at the mailbox level.
Startup exmerge, and choose the “Extract or Import (Two Step Procedure).
This allows us to extract the messages that meet our criteria first before trying to import or restore the messages.
Select "Extract or Import (Two Step Procedure)
So first we perform step 1 to extract the messages. (more…)
Recently I had a major hardware failure on the server that houses my Exchange 2003 mailbox store. My company, like many smaller organizations, did not spend the extra capital to setup a clustered environment and therefore we had to endure the downtime while the machine was repaired/recovered. Needless to say, this is not the optimal environment to be working in to recover your exchange environment. I believe upper management will now be more open to spending a little more to avoid prolonged downtime.
So our exchange machine has two RAID controllers, one with a 70 GB mirrored drive with the OS, and another with a number of different RAID disks configured for Exchange performance. All of the disks are locally attached. So our hardware failure was on the controller that services the OS. Essentially the cache on the controller partially failed and was writing corrupt data to the mirrored disks. The system crashed because the “C:” drive became corrupt and wouldn’t boot.
My Exchange Server Disk Layout
The good news was that all of the Exchange data was on the disks/controller that were not damaged so there was no data loss. So all we needed to do was recover the OS and remount the databases. Since our last system backup was off site and in the interest of reducing the number of panicky “How much longer” SMS messages I was receiving from upper management, I decided it would be quicker to rebuild the OS, reinstall Exchange, and point Exchange at the existing database. Sounds scary doesn’t it! This turns out to not be that difficult because all of the Exchange configuration information is stored in Active Directory and the Exchange setup program has a handy little “/DisasterRecovery” switch that essentially tells the installation program to make use of the configuration that is already populated in AD.
(more…)