It started with a telephone call from the client at about 9:20 today, after they'd found that Outlook was telling them that the Exchange server had been taken down for maintenance.
(Exchange Server 2000 on Windows Server 2000; a mixture of Office 2000 and Office XP, on Windows XP)
This usually means that all the Exchange services are running, but that the mailbox store had failed to mount. I connected up to the server and that's exactly what was going on -- both the public and private message stores had been dismounted for the overnight backup, and then they'd failed to mount again. In Exchange System Manager we had our favourite Exchange error message:
The database files in this storage are inconsistent
ID no: c1041739
So I told the client to live without emails for the time being, rolled my sleeves up, and set to work. Fortunately, Microsoft are accustomed to seeing their Exchange message stores falling over, and they've provide engineers like me with two tasty little command-line tools to sort them out: "eseutil" and "isinteg".
You'll need to know where these tools live. They're usually in C:\Program Files\exchsrvr\bin, so you open up a command prompt window and make that your current folder. You then need to know where the database files that go together to make your corrupt message store: on this server they were in G:\exchsrvr\mdbdata.
The first thing to do is to check the state of the database file.
eseutil /mh g:\exchsrvr\mdbdata\pub1.edb
As expected, one of the lines in the output said "State: Dirty Shutdown". So then you need to repair it:
eseutil /p g:\exchsrvr\mdbdata\pub1.edb
And, since you've got it offline anyway and your users have already given up and gone shopping for the morning, you might as well defragment it:
eseutil /d /t:g:\temp\pub1.edb g:\exchsrvr\mdbdata\pub1.edb
(You need to give it a temporary filename somewhere with loads of space.) And finally, having got the database structure nice and clean, you need to repair the internal logical consistency of the Exchange structures in the database:
isinteg -s SERVER1 -fix -test alltests
It'll ask you which database it's supposed to be checking. In this case, it's the public store.
Then, you have to do it again for any other files which won't mount: in this case, the private message store priv1.edb.
Then, at last, you can mount them again in System Manager.
I phoned the client back, and told them it was all sorted, and they were grateful. They said things like "oh good", and "send me a bill". There's an outside chance that some messages have fallen through the gaps during the repair, but without a spare server to work on, and lots more of my reasonably costly time ... they think they can do without if that happens.
I'm intending to use this for bits of writing that are to do with the things I do for a living: things like building and maintaining firewalls, mailservers, spam filters, database servers, web servers, file servers, terminal servers and all sorts of other back-end office systems, together with desktop computers, laptops and mobile devices to enable users to access those services. You're likely to find me talking about Microsoft systems, Linux systems, and the occasional handheld OS. I'm not going to make any especial effort to be entertaining, but I do hope to be informative.
If you're expecting to read about my day-to-day life, or hoping to see me writing about anything that's not to do with mucking about with computers, then you should probably be reading my Live Journal. It shouldn't be too hard for you to find.
on An everyday tale of corrupt databases