 |
|
I've been running a departmental Exchange server since early 1996, and recently became indirectly responsible for the Exchange network for an entire health system -- 15 servers, 5500 users, and still growing. Tending a farm of Exchange servers is strongly reminiscent of caring for premature infants (my "other" career). Both have a lot of potential, but both are complex organisms based on a large number of loosely coupled, immature systems, both are fragile and unpredictable, and both can go from a state of good health to death's door in a matter of minutes.
Every Exchange administrator learns quickly that, in order to survive, one must regard Exchange updates and service packs as a game of Russian Roulette, subscribe to Exchange mailing lists, search the Microsoft knowledge bases on TechNet on a regular basis, examine each successive Exchange Resource Kit diligently for the tools and capabilities that should have been included in the base system, and exhibit the patience and persistence of Job when wrangling with Microsoft phone support. Only a monopoly like Microsoft could dominate the email market with such a flaky product!
In the course of my own efforts to keep Exchange from falling over (or getting it back on its feet afterwards), I've looked through a lot of different books on Exchange administration. From my own experience, I've developed a short checklist of things to look for that tell me whether the author's objectivity and depth of experience make the book worth buying:
It's a sad commentary on technical trade book publishing that, until now, all of the Exchange administration books I've seen have failed the above checklist miserably, even though these are issues that are faced by every Exchange administrator. Why? Because most of the books are simply rehashes of Microsoft's own Exchange documentation, which also fails to provide accurate or complete information on the above topics (and many others).
Paul Robichaux's new book Managing Microsoft Exchange Server, on the other hand, passes nearly item on my checklist with flying colors, coming up short only on the Exchange-on-NT clustering topic (Paul discusses it briefly, but does not warn potential users away from it strongly enough, and omits the crucial fact that Microsoft does not officially support Exchange on their own clustering solution). The short excerpt below alone contains several pearls that almost every Exchange administrator has learned the hard way, but can't be found in any Microsoft Exchange manual.
True to form for O'Reilly and Associates, Managing Microsoft Exchange Server is eminently practical and accurate, well structured, carefully edited, and a pleasure to read. Every Exchange administrator will want to have a copy of this book readily available at home and at work. Highly recommended.
-- Ray Duncan (duncan@cerfnet.com)
I hate it when this happens. You will, too. Fortunately, not all instances of IS startup failures are fatal. Anytime the IS detects that the the priv.edb or pub.edb files are in an inconsistent state, it refuses to start. This inconsistency may be because a transaction couldn't be committed, because the database file is corrupt, or because the moon is in the wrong phase; there are too many possible causes to enumerate here.
The key to identifying why the IS won't start is the system event log. Whenever a startup failure occurs, the IS will log an event with a source of ESE97. In most cases, the error message logged is self-explanatory. For example, here's what the error message for event 193 says:
MSExchangeIS ((424)) The database engine failed with error -510 while trying to log the commit of a transaction. To ensure database consistency, the process was terminated. Simply restart the process to force database recovery and return the database to a consistent state.
As error messages go, that's a great one: it tells you what happened, what the consequences are, and how to fix it.
In general, the Information Store will keep running without incident. There are several common reasons why the IS fails to start.
There are other causes to consider, too. If the SA doesn't start (usually because someone has changed the service account credentials), the IS can't run; in addition, if core NT services fail because there's a problem with a low-level driver or component, that may cause the SA or a service that depends on it to fail.
What if your store won't start and none of the problems listed above is to blame? Relax. First, stop all the Exchange services on your server, then reboot it. Make sure to allow adequate time for the services to stop normally; if you forcibly reboot the server before the services have stopped, you will worsen any underlying database problems. The IS automatically tries to restore the database to a consistent state when it's started after a reboot, so as long as you shut down the services cleanly, the IS will have a chance to play back any logged transactions that haven't been stored in the database. (If the IS stopped cleanly, there won't be any unlogged transactions.) Make sure you wait long enough for the IS to replay the logged transactions, and don't forget that the Services control panel won't automatically update its display to show what services are currently running if a service stops or starts while it's open.
If rebooting doesn't restart the store properly, surf over to the Microsoft Knowledge Base to look for possible causes before you panic and make the problem worse with a hasty recovery attempt. The Knowledge Base is currently located at support.microsoft.com/support/search/c.asp?FR=0, but it seems to move around on Microsoft's site from time to time.
Search for the specific error number you see in the event log. That will almost always lead you to an article detailing the root cause for that particular failure so you can fix it. Before you try to fix anything, make a full offline backup, including all the log files and databases. This is critical, since you may need the backup information to restore your server later.
If your server has suffered from OS or hardware crashes, including sudden loss of electrical power, it's possible that the IS or DS database files may be damaged. It's critical that you carefully review any messages in the event log to determine what's wrong with the store before you attempt to recover it. In some cases, it can be best to move your mailboxes and public folders to another server before attempting to repair a damaged store, assuming you can restart it; if you can't, you won't be able to move anything. See the section "Recovering Your Data" in Chapter 17 for more details.
-- From Managing Microsoft Exchange Server, Chapter 15, pages 482-484.
| Readability |
|
| Originality |
|
| Organization |
|
| Accuracy |
|
| Consistency |
|
| Depth |
|
| Timeliness |
|
| Editing |
|
| Design |
|
| Overall Value |
|
Explanation of ERCB rating scale: No stars = unacceptable, 1 Star = marginal, 2 Stars = average, 3 Stars = above average, 4 Stars = exceptional.