It’s nice to see that “The Register” continues to support Exchange 2003 administrators with advice such as that offered in the article “Help my Exchange server just rebooted” posted on June 18, 2011.I’m assuming that the article was about Exchange 2003 because the screen shot displayed system files dated from 2005, so we’re definitely not in Exchange 2007 or Exchange 2010 territory.
To me, the tale of woe outlined was a flashback to the bad old days of depending on an all-too-fragile single database, tape backups that perhaps were never verified, and multiple single points of failure. Even though the point wasn’t made, the article also outlined a compelling case for the advantages of migrating Exchange 2003 servers to either on-premises Exchange 2010 or into the cloud with Office 365. After all, if you elect to upgrade to on-premises Exchange 2010, you can deploy a Database Availability Group (DAG) and protect mailbox databases that way, or if you choose to move to Office 365, you pass the problem over to Microsoft, who will reassure you that Office 365 maintains copies of databases in “pods” split across two datacenters.
Reading the article transported me back to the days when ESEUTIL was regarded as an essential tool for Exchange administrators. Early versions of Exchange had databases that weren’t particularly efficient at reusing white space (empty pages) in the database and the only way to return space to the file system was to rebuild the database with ESEUTIL. This was deemed to be a good thing in the days when big disks were expensive and administrators fretted about available disk space.
Indeed, there were those who espoused the goodness of a regular database rebuild with the same vigor that colonic irrigation enthusiasts look forward to a good clean-out. Of course, a rebuild database was more compact and this helped somewhat with tape-based backups because the databases took less time to copy to tape, but the compacted databases had some downside as well: it wasn’t possible to replay old transaction logs into the new database; the recovered space was invariably swiftly reclaimed as the database grew to accommodate user traffic; and running ESEUTIL to rebuild databases required all users to log-off and not reconnect to Exchange until the rebuilt database was brought online.
ESEUTIL has never been a sparkingly fast program and it was common to achieve throughout in the 5-10GB/hour range – barely acceptable in an era when Exchange servers boasted mailbox databases sized less than 50GB (remember the speed of tape backups – it was a brave administrator who trusted Windows disk systems and the security of tape backups enough to allow databases grow more) and certainly unacceptable today when mailbox databases commonly run > 500GB.
The version of ESE included in Exchange 2003 is actually pretty good at internal database management and there was a lot less call for database rebuilds after Exchange 2003 appeared. However, as the article covers, ESEUTIL/R (recovery mode) could be needed to convince a database that it was OK to mount.
In the normal course of events, you should never have to resort to ESEUTIL with Exchange 2010. If your company is able to afford to deploy at least two servers, you can run a DAG and have the mailbox databases replicated between the servers to ensure basic redundancy. The HP E5000 Messaging System remains the only appliance-type Exchange 2010 system on the market and it contains two multi-role servers configured in a DAG, so that’s a good choice for a low-end deployment. Two copies of a database is good, three is much better, and four is a warm blanket of security for any administrator, so if you can afford the extra servers and disk, the ideal situation is to build and deploy a DAG where each mailbox database has at least three copies. Microsoft’s latest mailbox role storage requirements calculator contains the ability to visualize the layout of databases and copies in a DAG and is worth investigating, if you haven’t seen it before.
But what if you’re a small company who feels rather similar to the tale of woe exposed in the article – just a single Exchange 2003 mailbox server, still running tape backups, and looking nervously towards the UPS in the hope that it can protect your hardware should a disaster strike. Well, you’re a prime candidate to stop running on-premises email and move quickly to the cloud by migrating to Office 365. Sure, you might have to upgrade some PCs because Office 365 doesn’t support older Outlook 2003 clients and probably make some changes to your network infrastructure to make sure that your clients can all reliably connect to Office 365, but you’ll end up with a far more functional email capability that’s protected in a way that you simply cannot in any cost-effective manner.
Moving into the cloud won’t cure all problems and there have been some well-documented instances when all of the major cloud providers including Microsoft and Google have suffered outages that affect users. Although network glitches are always possible for any service that depends on the Internet, I think that the datacenters where services like Office 365 run are pretty safe from the affect of a truck hitting a pole and a resulting power spike. At least, that’s the theory… and anyway, if something does happen, you’ll never have to run ESEUTIL again and that’s something worth looking forward to.
– Tony
If you’re an Exchange 2003 administrator who’s trying to figure out how best to upgrade to Exchange 2010, you might like to read Microsoft Exchange Server 2010 Inside Out
Thoughtsofanidlemind's Blog 