Exchange Server Recovery

Microsoft's Exchange Server application is corporate messaging system that supports internal and external electronic messages. This client/server system has many installations throughout the world. Exchange is an incredibly complex client/server system that is doing more than passing messages; it is also managing communication between other Exchange servers in the domain, using complex queuing algorithms to manage message transport and finally storing all data in a highly organized relational-database.

Electronic messaging has become an integral part of the business environment. Archived messages are becoming just as important as stored documents. If there is a problem with the Exchange database and the Information Store will not mount or if there is internal corruption, your client's solution is Ontrack. We have invested heavily into research and development to be able to have a suite of data recovery tools to work with the Exchange Database Information Store.

Let's first look at the inner workings of the Exchange message server and database engine. Understanding this will help you to appreciate the complexity of this system.

How Does Exchange Server Work?

As previously mentioned, Exchange is a client/server messaging system. Exchange Server's current versions are 5.5, 2000 and the yet to be released Exchange 2003 (codenamed: Titanium). Previous versions are 4.0 and 5.0.

Here are the basic steps Exchange Server goes through to process messages:

1. The sending client connects to the server and sends the message.
2. The server processes the message by determining the appropriate message storage location in the messaging database.
3. The server notifies the recipient of the message's arrival.
4. The recipient client connects to the server to retrieve the message.

There are a number of components that make this happen. Here are the main ones:

Core Components to Exchange

These core components are assisted by many other processes and operations to organize, distribute, and receive messages.

The Information Store Service manages the Information Store. This is where user mailboxes reside. The Information Store Service is split between two processes. One process manages the organizing and message storage. Think of this process as the logical, or business side of organizing and storing messages and attachments. The second process is the Extensible Storage Engine (ESE). This manages the internal structure of the database file. The ESE handles the requests from the first process and writes the message data into the file. We'll go over more about the Information Store later on.

The System Attendant works at a number of different levels within Exchange Server. This component manages a number of details regarding email addresses and link support services. The System Attendant also communicates with the domain controller's Active Directory and updates the properties of users who have mailboxes.

Simple Mail Transfer Protocol (SMTP) is the routing and messaging processing functions that are needed to deliver messages between servers.

The domain controller manages the Active Directory service. Exchange 2000 and 2003 use this service to manage user's mailboxes, distribution lists, and server properties.

All of this plus a complex message queuing, sorting, and routing operation make up the internal workings of Exchange. There are more functions that Exchange performs from an organizational, security, system policy, and user management perspective.

Information Store Details and Corruption

The Information Store is really at the heart of the system and is composed of the database files. In earlier versions of Exchange, there were two files that made up the Information Store; the "priv.edb" contained user mailboxes and the "pub.edb" contained the public folders. Exchange Database files (EDB) are rich text database files. It is this file that the Extensible Storage Engine manages.

Exchange 2000/2003 adds another file to the Information Store. That is called the Streaming database file (STM). This file contains all external messages that are received from outside of the server organization. Just as the name implies, messages are "streamed" together inside of this file. The references to these messages and to whom they are sent to are kept in the Exchange Database file (EDB). These files work together to store messages.

Internally, the Exchange Database file (EDB) is amazing complex. Because it is a relational database, there are many tables and indexes that the Extensible Storage Engine manages and updates. The file intricacy is like this by design so that it can handle multiple, interleaved transactions all at once.

Exchange server incorporates a "transaction based" or "Write-Ahead Logging" method in an effort to provide complete and verified updates to the Information Store. These types of complete transactions are called ACID transactions. ACID stands for:

• ATOMICITY: Atransaction should be done or undone completely. In the event of a failure, all operations and procedures should be undone, and all data should rollback to its previous state.
• CONSISTENCY: Atransaction should transform a system from one consistent state to another consistent state.
• ISOLATION: Each transaction should happen independently of other transactions occurring at the same time.
• DURABILITY: Completed transactions should remain permanent, even during system failure.

Exchange uses log files to complete this purpose. All messages coming into or going out of the server will follow this flow:

1. Message stored in memory
2. Message written to log file
3. Message committed to Information Store from the log file

In the event of a failure, Exchange server will perform a "Soft-Recovery" as it is starting the Information Store Service. The log files are checked against what is actually in the database file. Any messages that did not get written from the log files will then be written to the database. If a message was to be deleted from a mailbox, but that transaction was not completed according to the log files, then Exchange will "play" that transaction and update the database file.

Even with these safeguards, an Information Store can become corrupted internally. The log files can become corrupt or the wrong ones used during a restoration of a server. Whatever the case, damage to the Information Store can occur. There are repair utilities that come with Exchange server. The goal of these tools is to make the database file ready for transactions. Sometimes during that repair process, messages or attachments can be lost. Ontrack's recovery model is different-our tools go through the file and find the data. This process yields excellent results and does not change the inner workings of the database file itself.

Ontrack's Recovery Solution

Our software development staff has worked hard to produce Exchange recovery tools. The software tools are complex and require in an experienced data recovery engineer to operate. Our goal is to find as much of the data as possible. The evaluation for an Exchange server can take a number of hours to complete and this is due to the internal complexity of the file.

Ontrack has provided excellent recoveries for Exchange server owners. Your client's rely on this messaging system and their users require their archived messages and attachments in their day-to-day activities. When failure occurs, call Ontrack, start the evaluation process, and minimize data loss for your clients.

The fastest evaluation solution for Exchange servers is Ontrack's Remote Data Recovery process. We have successfully used this in many different networking environments. Using this service, will avoid losing time by sending this the server or drives in. Once the evaluation is complete and a recovery is requested, the user mailboxes will be recovered as Personal Folder Files (PST). At this point Exmerge can be used to import those mailboxes back into a working Exchange server.

All of this comprises Ontrack's solution to Exchange data loss situations.