- 1 -Check database Header to database statusEseutil /mh Use Eseutil /mh to examine the database header. You are looking for three particular lines:

DB Signature Log Signature Log Required

For example:

DB Signature: Create time:12/30/2002 16:51:49 Rand:606486607 Computer:

Log Signature: Create time:12/30/2002 17:01:27 Rand:607052340 Computer:

Log Required: 44-46

If a database has been disconnected normally, the Log Required value is 0-0, meaning that no soft recovery is required to start the database. In this example, the database was unexpectedly stopped, and logs 44, 45 and 46 are required for recovery.

The Log Required range is in decimal format, so you must convert the numbers to hexadecimal format to correlate them with actual log file names. In this case, the hexadecimal equivalents of 44, 45, and 46 are 2c, 2d, and 2e. Exchange therefore typically names the required logs Enn00002c.log, Enn00002d.log and Enn.log. When Enn.log is full, Exchange automatically renames it Enn00002e.log. You can verify this by examining the lGeneration line of the Enn.log header, which reads:

lGeneration: 46 (0x2E)You know from the Log Required values shown that you must have at least these three log files to restart this database. If you use Eseutil /mk and read the header of the checkpoint file, you will see that the checkpoint is at log 44 (0x2c). The Log Required value acts as an internal checkpoint in the database file itself, listing not only the first log required for recovery, but also the last log.

If the Log Required line reads 0-0, you do not need any log files to restart the database. Nonetheless, you can play log files forward into the database, as long as you have the Enn.log to which the database was attached when last shut down. If you have this log file and subsequent log files, you can play forward as long as log files are available. To do this, there must be no checkpoint file, or the checkpoint must be at or before the lowest log required.

Note: There is no internal value in the database header that tells you which log files are required for replay when the database has been shut down cleanly because no log files are required. However, you may still want to play additional log files. The Last Consistent value in the database header lists the log file that was in use at the time the database was last running. You can start with this log file and play forward. In Exchange 5.5, if you made a guess about which log file to start with, you could damage the database by attempting replay. Starting with Exchange 2000 Server, additional safeguards prevent inappropriate log file replay without damaging the database.

Using Eseutil to Determine Which Logs Have Been Committed (Exchange 2000/2003 Server)

In Exchange 2000/2003, there is one checkpoint file for each storage group and one for the directory. When you try to

identify the last committed log file for a storage group, note that the storage group prefix applies to the checkpoint file

and to all of the log files. For example, the default first storage group's checkpoint file name is E00.chk, and its log files

are E00xxxxxx.log (where xxxxx is the hexadecimal sequence number of the log file).

To display the Exx.chk (checkpoint) file on the screen, run the following command from a command prompt (from the

Exchsrvr\Bin folder):

eseutil /mk the_full_path_to_the_checkpoint_file

Eseutil

- 2 -For example, you may run the following command:

eseutil /mk "C:\Program Files\Exchsrvr\MDBDATA\E00.chk"

Note that you must use the quotation marks if there is a space in the path to the checkpoint file.

The output of this command is similar to: Microsoft(R) Exchange Server(TM) Database Utilities

Version 6.0

Copyright (C) Microsoft Corporation 1991-2000. All Rights Reserved.

Initiating FILE DUMP mode...

Checkpoint file: C:\Program Files\Exchsrvr\MDBDATA\E00.chk

LastFullBackupCheckpoint: (0x0,0,0)

Checkpoint: (0x6A,1119,3D)

FullBackup: (0x0,0,0)

FullBackup time: 00/00/1900 00:00:00

IncBackup: (0x0,0,0)

IncBackup time: 00/00/1900 00:00:00

Signature: Create time:09/24/2001 17:10:26 Rand:522553071 Computer:

Env (CircLog,Session,Opentbl,VerPage,Cursors,LogBufs,LogFile,Buffers)

( off, 202, 30300, 1365, 10100, 128, 10240, 97940)

Operation completed successfully in 1.192 seconds.

Take the first number in the parentheses for the Checkpoint field. The hexadecimal number is the file name of the

first uncommitted log for the appropriate database; in this example:

Checkpoint (0x6A,1119,3D) = E000006A.log

How to use Eseutil to test transaction log files for damage in Exchange 2000 Server and in Exchange Server 2003To test a log file for suspected damage, run the following command:

eseutil /ml Log File Name

For example, to test a log file that is named E00123ab.log, type:

eseutil /ml e00123ab.log

If the log file passes the test, the following response appears:

Integrity check passed for log file: Log File Name

If the log file fails the test, the following response appears:

Eseutil

- 3 -CORRUPTION DETECTED in log file: Log File Name

Operation terminated with error -501 (JET_errLogFileCorrupt, Log file is corrupt)

You can use a single command to test all the log files in a folder. To do this, open a command prompt window, and

then change to the folder where the log files are located. Type the following command:

eseutil /ml Enn

In this command, "Enn" signifies the log prefix. The log prefix is the first three characters of the log file name that are

shared by all logs that belong to a particular storage group. For example, the eseutil /ml E00 command scans all

transaction log files in a folder that share the same log prefix. Additionally, the command reports if any transaction log

files are damaged, out of sequence, missing, or mismatched with the other log files.

Torn writes and E00.log

A torn write is an incomplete physical write that is left in the E00.log file after the database service suddenly stops. A

torn write may be caused by a power failure, by an operating system crash, by invoking End Process on the database

process, or by using a termination utility such as Kill.exe. A torn write causes checksums on the affected transactions

in the log file to be calculated incorrectly, and the log is then detected as damaged by Eseutil.

Torn write detection is a sophisticated process whereby Exchange determines whether a transaction was damaged

because of a torn write or because of other factors. If a torn write is the problem, Exchange repairs the log file when

the database is restarted.

Exchange cannot repair damage to log files that is the result of factors other than torn writes. Hardware failures that

randomly damage a log file cannot be overcome because the lost data cannot be reliably reconstructed.

Torn writes only occur in the E00.log file because the E00.log file is the only log file that is open and is being written to.

When an E00.log file is full, it is closed and renamed with a sequential number. Exchange cannot repair a log file that

has been closed and numbered (for example, E00123ab.log).

There is no risk of causing additional damage to the database when you try to replay an E00.log file that the

eseutil /ml command reports is corrupted. If the problems in the log file are only torn writes, they will be corrected. If

the problems cannot be repaired, the database rejects the data instead of applying the data, and an event that is

similar to the following is logged in the application log:

Event Type: Error

Event Source: ESE98

Event Category: Logging/Recovery

Event ID: 465

Date: 12/9/1999

Time: 2:48:48 PM

Eseutil

- 4 -User: N/A

Computer: Computer_Name

Description: Information Store (2428) Corruption was detected during soft recovery in log file E:\exchsrvr\THIRD\

E00123ab.log. The failing checksum record is located at position 8189:328. Data not matching the log-file fill pattern

first appeared in sector 8195.

This event indicates that there is damage that cannot be repaired. In such a case, you can use one of the following

recommended solutions: Locate a good copy of the damaged log file. Another copy may exist either on an Exchange online backup or

on a recent server backup. Discard the damaged log file together with all the log files that are newer than the damaged log file. Then

restore a known good online backup of the Exchange database. You will lose any data that was logged after

the damaged log file was created.

If these solutions are not workable, you can repair the database by using the "hard repair" (/p) functionality of the Eseutil utility. Before you do this, make sure that you back up all the database files in a storage group (*.log files, *.edb files, and *.stm files), and then contact Microsoft Product Support Services (PSS) for additional advice. Hard repair always causes at least some data loss.

Understanding Exchange Databases Disk ConsumptionExchange databases need disk space, once they run out of disk space they can not continue to function. My aim in this article is not to describe methods of preventing or solving the disk space problem(even though I will provide a tip or two)- my aim is to describe and explain the way that Exchange databases uses disk space.

As a direct evolutionary phase that stems from my first article the subject I would like to address in my second article is again disk space consumption but this time by the Exchange databases.

What will you gain from this you ask?

The answer is simple - a better understanding of how databases consume disk space which will enable you to manage the disk space you control in a more efficient manner.

Uncovering the databases

Exchange databases are based on the JET engine, actually a variant of the JET engine called Extensible Storage Engine (ESE). ESE is a multi-user database that supports full Data Manipulation Language (DML) and Data Definition Language(DDL). ESE is optimized for fast retrieval of data since this is the main function that the database performs.

Examining the versions of the ESE engines used by the different versions of Exchange server will uncover the fact that there is a difference between Exchange 5.5 and Exchange 2000/2003.

Exchange 5.5 uses a version of the ESE called ESE97 while Exchange 2000/2003 uses a version called ESE98. Now this may seem a subtle difference but it's not.

To understand the differences just take a look at the database file types in the different versions…

Eseutil

- 5 -EDB files

The rich-text database (EDB) is the database type we are used to seeing in pre-2000 Exchange servers. The EDB database may also be called the MAPI database since it hosts all information submitted by the MAPI client(Outlook). The data itself is stored in a proprietary format called Microsoft Database Encapsulated Format (MDBEF).

It is worthwhile to mention that all messages (whether they are MAPI messages, SMTP or HTTP messages) have some of their properties saved in the rich-text database.

STM files

The native content database (STM) or the streaming database holds messages that were submitted by non-MAPI clients (post Exchange 5.5). The file is called a streaming file since data is added to it sequentially in its native format. The data itself inside the STM file is not encoded or encrypted in any way so if a store is dismounted the file can be viewed using a text editor.

Dealing with the files

The process of understanding how disk space is consumed by Exchange 5.5 databases is more straightforward since there is only one file type that consumes disk space. Exchange 2000/2003 on the other hand is a bit more complex since it uses two types of files for each "store". 

Nevertheless, when looking at disk space consumption the two files in use by Exchange 2000/2003 (EDB & STM) should be regarded as one entity- the store.

Dissecting disk space usage

To understand disk space consumption by Exchange databases follow figure 1 and the description for each section.

Fig 1: Description of disk space

1. Hard Drive/Disk Space – The information is saved on –you guessed it - a hard drive!!! Any unused space on the hard drive can be used for the databases/store.

2. Database/Store – The database is the placeholder for the information. The database files grow by 2MB increments. To prevent excessive fragmentation of the database on the hard drive you can change the increments to 16MB. This change can be done by using ADSIEDIT and accessing a specific storage group through the Configuration partition of the Active Directory. On the storage groups properties edit the msExchESEParamDbExtensionSize parameter and set it to 4096.

Eseutil

- 6 -3. Data- This part of the database is the actual data that users will access and update. 4. Recoverable Items - Restoring a specific item on an Exchange server can be quite a pain (even though using a

Recovery Storage Group makes it a lot easier). To help system administrators deal with this problem each store can retain items for a specific time (specified by the administrator). Items that are past their retention time (and under specific circumstances backed-up) will be tombstoned and removed from the database/store.

5. Recyclable Space - Space that is free and can be reused by new messages. Keep in mind that this space may be fragmented and spread inside the database. In figure 1 the space is at the end of the database since the database has undergone online maintenance.

Show me the numbers

Checking the space used by the database itself is quite straightforward - use any tool such as the Windows Explorer to check the database file size and/or the free space on the disk.

To be on top of things Exchange administrators should always know the size of the different parts of their Exchange databases.

Measuring Recyclable Space

Measuring the recyclable space can be done by either searching for event 1221 in the Application log or by using ESEUTIL to provide the information.

Event 1221 provides a conservative estimate of recyclable space in the database. If the database will be defragmented (offline) then you will gain at least the space specified in the event.

Currently there is some controversy around the question of event 1221 including both the EDB and the STM file for Exchange 2000/2003. It seems that this event only includes the EDB file.

Fig 2: Event 1221 on Exchange 5.5

To receive a more accurate estimate of the white space the ESEUTIL tool can be used. Invoking the ‘ESEUTIL.EXE /MS [database.edb] command on an unmounted store will provide you with a more accurate estimate on the recyclable space found in the store. The output of the command is similar to the following one:

Eseutil

- 7 -

The first part of the output called “SLV SPACE DUMP” provides information about the STM file. By multiplying the value of “Free:” with 4096 bytes you will receive the size of the recyclable space in the STM file.

The second part of the output called “SPACE DUMP” provides information about the EDB file. By multiplying the number at the bottom of the “Available” column with 4096 bytes you will receive the size of the recyclable space in the EDB file.

Measuring the size and quantity of recoverable items

When you are pressed for disk space you will use any and all items at your disposal to gain disk space -this may include jettisoning the Recoverable Items. To measure the size of the recoverable items you can use Performance Monitor. The specific counter you use is called: “Total Size of Recoverable Items”.

Eseutil

- 8 -

Fig 3: Monitoring the size of recoverable items.

If you need to jettison the items you can lower the retention time on the store and configure the online maintenance process to occur - this is not recommended unless you are really pressed for space.

Defragmenting an Exchange 2000 or Exchange 2003 databaseNote Defragmenting a database requires free disk space equal to 110 percent of the size of the database being processed.

1. In Exchange System Manager, right-click the information store that you want to defragment, and then click Dismount Store.

2. At the command prompt, change to the Exchsrvr\Bin folder, and then type the eseutil /d command, a database switch, and any options that you want to use.

For example, the following command runs the standard defragmentation utility on a mailbox store database: C:\program files\exchsrvr\bin> eseutil /d c:\progra~1\exchsrvr\mdbdata\priv1.edbUse the following database switch to run Eseutil defragmentation on a specific database: eseutil /d <database_name> [options]

Defragmentation/CompactionPerforms off-line compaction of a database.

Syntax: eseutil /d <database_name> [options]

Parameters: <database_name> is the file name of the database that you want to compact.

You are not required to use any of the following options, but you can use one or more (separated by a space) to specify the operations that you want to perform on the database. Option Description----------------------------------------------------------------/b<database> Make a backup copy under the specified name

/t<database> Set the temporary database name (the default is Tempdfrg.edb)

/s<file> Set the streaming file name (the default is NONE)

/f<file> Set the temporary streaming file name (the default is Tempdfrg.stm)

/p Preserve the temporary database (in other words, do not instate)

/o Suppress logo

/i Do not defragment streaming file

Eseutil

- 9 -Note If instating is disabled (for example, if you use the /p option), the original database is preserved uncompacted, and the temporary database contains the defragmented version of the database.

Transaction Log File Replay: Soft Recovery and Hard Recovery in Exchange Server 2003As used in Microsoft® Exchange Server 2003, the word recovery must be distinguished from the word restore. Restore is the act of putting database and log files back into place on a server, and recovery is the act of replaying transaction logs into the restored database.

 Types of Recovery There are two forms of recovery:

Soft recovery   A transaction log replay process that occurs when a database is re-mounted after an unexpected stop, or when transaction logs are replayed into an offline file copy backup of a database.

Hard recovery   A transaction log replay process that occurs after restoring a database from an online backup.

 Soft Recovery In the default soft recovery scenario, an external event unexpectedly stops an Exchange database, but the database and log files remain intact and in place. When the database is mounted again, Exchange reads the checkpoint file and begins to replay the transaction log that is listed as the checkpoint log. If no checkpoint file exists, replay begins with the oldest log file available in the transaction log folder for the storage group.

Exchange writes to the database files completed transactions found in the log file that have not already been written and reverses any incomplete transactions. Exchange never begins writing a transaction into the database files until all the operations composing it have been secured to the log files. You do not need to physically undo or back out a transaction in the database if all uncommitted transaction logs present at the time of the unexpected stop are present when replay begins.

Important: A fundamental assumption of the soft recovery process is that no database or log files have been moved, deleted, or destroyed by the failure—or by the administrator after the failure.

If you remove any required transaction logs from the replay sequence, Exchange fails soft recovery immediately. If needed transaction logs are missing, you must either perform recovery with an older, restored copy of the database (one that does not require those logs), or you must repair the database with the Exchange Server Database Utilities (Eseutil.exe) tool.

Some of the fundamental rules of transaction log file replay are:

You cannot replay log files from one database against a different one.   The operations inside a log file are low-level. You will not see anything inside a log file such as "Deliver Message A to Mailbox B." A better example of a log file operation is "Write this stream of 123 bytes to byte offset 456 on database page 7890." Imagine that you gave someone instructions for editing a document, and your instructions are "On page five, paragraph four, in the third sentence, insert the phrase 'to be or not to be' after the second word." If these instructions were applied to a document other than the one intended, the result would be random corruption of the document. Likewise, if the wrong log files were played against an Exchange database, a similar result would occur. Exchange therefore has multiple safeguards to prevent such corruption. If you defragment or repair an Exchange database, transaction logs that previously were associated with this database can no longer be replayed into it. If you try to replay log files after a defragmentation or repair, Exchange skips the inappropriate transaction logs. Again, consider the analogy of editing the document. If a paragraph has been moved, edited, or deleted since the instructions were created, applying the out-of-date instructions would be as destructive as applying them to an entirely different document.

You cannot replay log files unless all uncommitted log files from the time the database was last running are available.   You must have all log files starting from the checkpoint at the time the database was backed up. You can then replay log files from this point as long as they follow an unbroken sequence. If there is a single log file missing in the middle or from the beginning of the sequence, replay stops there.

Eseutil

- 10 - You cannot replay log files if the database files have been moved to a different file path location.   This

restriction does not apply if you are using Exchange 2000 Server SP2 or later because Eseutil.exe handles replay even if there has been a path change. The sections below describe how the replay process works in more detail.

You cannot replay log files if the checkpoint file points to the wrong log.   Exchange treats a checkpoint log as if it were the first log available and ignores all older log files. If you restore an older file copy of the database, the checkpoint will be too far ahead, and Exchange tries to start log file replay from a log file that is too new. You can solve this problem by removing the checkpoint file; thus forcing Exchange to scan all available logs. (If you restore an online backup, hard recovery ignores the checkpoint file.)

You cannot replay log files if any database files for the storage group have been removed.   All databases that were running at the time of an unexpected stop must still be present for soft recovery to succeed. This limitation can be overcome by using Eseutil.exe to run soft recovery. If soft recovery runs for other databases in a storage group while one database is missing, future log file replay situations may be complicated. By failing soft recovery, Exchange gives the administrator a chance to analyze the situation and decide whether to proceed without the database.

 Advanced Soft Recovery Scenarios In most cases, the best way to run soft recovery is to mount any database in a storage group. Because all databases in a storage group share a single stream of log files, soft recovery occurs at the level of the entire storage group and not at the level of the individual database.

In some special circumstances, there are advantages to running soft recovery using Eseutil.exe. The most common scenarios are:

You want to recover a storage group that has a missing database. You want to recover an individual database "out of place" without affecting other databases or the storage group's

log files.

The complete syntax for the Eseutil.exe soft recovery function, listing all possible switches, is:

ESEUTIL /r enn /L[path to log files] /s[path to checkpoint file] /d[path to database file] /i

Example: ESEUTIL /r e01 /Lf:\mdbdata /sc:\exchsrvr\mdbdata /dg:\mdbdata /i

Note: Eseutil.exe command line parameters are not case sensitive; they are mixed in case as shown above to avoid confusion between the "L" and "I" characters.

The above example shows the recovery of the databases for a storage group in which the log file prefix is E01, the log files reside in f:\mdbdata, the checkpoint file resides in c:\exchsrvr\mdbdata, the database and streaming files reside in g:\mdbdata, and missing databases are ignored (because of the /i switch at the end of the command).

The minimum Eseutil.exe command line needed to run soft recovery is:

ESEUTIL /r EnnThis command works only if run from a prompt set to the transaction logs directory. You should also be aware of the following when using Eseutil.exe to run soft recovery:

If you do not specify any file paths on the command line, Eseutil.exe uses your current command prompt directory as the default for both log files and the checkpoint file.

Database files do not have to be in the log file path. The log files record the database paths, and therefore Eseutil.exe discovers all database paths by reading the log files. Use the /D switch to override the paths stored in the log files only when you are sure the paths in the log files are incorrect.

If the checkpoint file is not present in the same path as the transaction logs, all log files are scanned during replay, rather than starting replay from the checkpoint log. You can copy an existing checkpoint file temporarily to the log file path. After soft recovery is complete, Exchange no longer uses this copy of the checkpoint file in normal database operation. If the information in the checkpoint file is incorrect, soft recovery fails but does not harm the database. You can try

Eseutil

- 11 -recovery again after removing the checkpoint file or finding the correct one. A checkpoint file is not essential to successful recovery, but it can save significant time if you have a large number of log files.

If you want to begin recovery when a database is missing from the storage group, you can use the command:

ESEUTIL /r Enn /iThe /i switch means ignore missing databases. If you use this switch and then mount the missing database, Exchange prompts you to create a new database. If you intend to restore the old database at some point, you will not be able to replay the new data into it. You now have two separate versions of the same logical database.

This scenario, where one database in the storage group has been replaced by an empty database, is one in which the recovery storage group can help. You can mount the extra database in the recovery storage group, and use ExMerge to add the contents of one database to the other.

If you want to begin recovery "out of place" to recover a single database without affecting other databases in the storage group, you should create a new, empty folder and move the database files that you want to recover, the transaction logs that you want to replay, and a checkpoint file (if desired) into this path. This path must not contain other database files.

Once you have isolated your databases and logs together into a folder by themselves, run the following command from that folder:

ESEUTIL /r Enn /i /dBy using the /d switch with no path designation, you override the database path set in the log files. In addition, because no other databases are available in this folder, you hide the other databases on the server from this particular recovery process.

If you do not use the /d parameter correctly, the recovery process can affect other databases on the server. Even in the worst case, the recovery process will not damage other databases. However, recovery may fail on the database that you are working with. This recovery operation may even impact future log file replay capabilities against other databases.

Note: The likelihood of errors increases as the command line becomes more complex. As a general rule, then, minimize the specified path information on the command line when using Eseutil.exe. In this case, change to the directory where the files are located and include the \exchsrvr\bin directory in your system path.

To run soft recovery, the last log file in the replay sequence must be named Enn.log. If the final log file has already been closed and numbered, you must rename the log before soft recovery will succeed. This requirement does not mean that, where the current Enn.log file has been damaged or destroyed, you can ignore it and rename the previous log in the sequence Enn.log. In Exchange 2000, the Logs Required value in the database header lists the minimum sequence of logs required for recovery, starting from the checkpoint log and continuing to the current log. In earlier versions of Exchange, although no Logs Required value existed to enforce the presence of required logs, recovery still failed if the last log needed was not found. The only difference between Exchange 2000 and later versions was that recovery would fail at the end of log replay instead of at the beginning.

 Hard Recovery Hard recovery must be completed after restoring from online backup. Hard recovery is a log file replay process that is similar to soft recovery, but there are some important differences. In hard recovery:

Patch information must be applied to the database during log file replay. The checkpoint file is ignored. Restore.env is used instead of the checkpoint file to determine from which log file

recovery should start. Exchange 5.5 administrators may be familiar with the Restore in Progress registry key. Restore.env replaces the functionality of that key in Exchange 2000. You can view the contents of the Restore.env file by running the command Eseutil /cm.

If the database has been restored to a different path than that from which it was backed up, log file replay succeeds, ignoring the database paths listed in the log files.

Restored transaction log files replay first from a temporary folder designated by the administrator before restore. Log files from the normal transaction log folder may also be replayed.

Hard recovery does not fail if other databases in the storage group are missing.

Database files (.edb and .stm) restored from an online backup set are restored to the normal paths defined for the database. Restore begins by overwriting existing databases files. If there is any chance that you might need the existing database files in the future, you must move them or back them up before restoring from online backup. Take into consideration that restore of

Eseutil

- 12 -the online backup could fail for any number of reasons. Even if the existing database files cannot be started at the moment, they are probably still repairable, and data could still be salvaged if necessary.

As you begin restoration of an online backup, Exchange prompts you to provide a temporary folder location. The backup program restores transaction log files from the backup set to this location, not to the normal transaction log file path. The backup program also creates the Restore.env file in the temporary folder.

The function of Restore.env in hard recovery is similar to that of the checkpoint file in soft recovery. Restore.env defines the range of transaction log files that should be present in the temporary folder for hard recovery. If you place extra logs in the temporary folder—logs that are outside the range listed in Restore.env—they are not replayed and the recovery process may delete them automatically.

You may have extra log files to replay that are not from an online backup set. In this case, place those logs in the normal transaction logs folder for the storage group and not in the temporary folder. After hard recovery finishes replaying the logs restored from the backup set, the process checks the normal transaction log folder to see if the next log in sequence is available.

Note: If you are restoring to an alternate server, or you have deleted and re-created the original database, only transaction logs in the temporary folder are replayed. Transaction logs in the normal database folder are not replayed. This distinction avoids transaction log replay conflicts in cases where Exchange knows that the database to which it is restoring is not the same as that from which it was backed up. A database restored in this circumstance is called a victimized database.

Note: You can play additional transaction logs for a victimized database by placing them in the temporary folder. In this special case, the recovery process does not delete or ignore them, but does replay them. If you are in doubt about the environment to which you are restoring, place copies of additional transaction logs in both the temporary folder and the normal database folder. Regardless of the victimization status of the database, the recovery process will replay one or the other set of logs. When you restore to a recovery storage group, replay works the same as if you were restoring to an original storage group. You can place additional logs in the recovery storage group database folder, and additional logs placed in the temporary folder will be ignored and deleted.

For example, suppose that six log files, E0000003.log through E0000008.log, are restored from backup into the temporary folder. After these log files have been played, recovery now looks in the running log folder for an E0000009.log file that belongs to the same log sequence. Internal markers in the log files identify them as belonging together. The decision to keep replaying is not made only on the basis of the log file name.

If log file 9 is found, replay continues as long as the next log in the series is available. If log file 9 does not exist, the recovery process creates a new log file called E00.log in the temporary folder. This log file is used only to record the changes in the database needed to shut it down in a consistent state. At this point, the database is completely recovered. It automatically restarts and attaches to the most recent log file in the storage group. The recovery process then deletes all files in the temporary directory.

Eseutil /R what does this mode do and when would you use Eseutil /R ? The Eseutil /R mode is used when you need to perform a soft recovery of your Exchange Database/s ( Information Store ). This mode of the tool should not be confused with the hard recovery mode Eseutil /C

What is the Difference between Hard and Soft recovery with Eseutil?

As mentioned above there are two recovery modes hard and soft recovery, the Hard recovery mode Eseutil /c is only used after performing an online restore (restore database because of corruption, or system failure; basically an online restore from media) and is used to playback to transaction log files so that you have a current database.

Normally Soft Recovery happens automatically after the Exchange Information store service starts and manual soft recovery using Eseutil /r is rarely required as it is run automatically, in fact manual soft recovery is not recommended at all with Exchange 5.5, yet there are some instances when you will need to perform a soft recovery manually, below are the scenarios where you would perform a soft recovery manually with Eseutil /r

Eseutil

- 13 -         Database drive that contains one of a storage groups Information Store fails

This causes the storage group and other Exchange Information stores (on other drives) to go offline (Dirty shutdown)

o   In this scenario if you intend on later restoring your missing database your can, still recover (soft recovery) the remaining Information stores with the use of the /r mode along with the /I (Ignore) switch.

         To perform an Out of Place Restore of an Information Store

Using the recovery mode together with the /D switch will allow you to recover an information store out of place, either to a Recovery Storage Group and would be particularly useful when you are ready to restore the missing database from the previous scenario above. The D switch basically allows you to specify an alternate locate (Other than the original) for the Exchange Database files

         After a restore you see Event ID 494, 454, 101, 904, 903 the following description: Information Store (1352) ….. as outlined in the following Microsoft Kb Article: http://support.microsoft.com/kb/843092

The valid options and syntax for use with Eseutil /R is as follows:

Eseutil /R <E00>

This is normally E00 but in different scenarios may be different

/L<Path> Path to the log file location

/s<Path> Location of the System files (Checkpoint file, etc)

/IIgnore errors missing/mismatched database files (Exchange 2003 and above only)

/D [Path]

Path to the location of the database files, if switch is not specified path will use the original local of database files, if switch is specified without a path the current working directory is used, if switch and path is specified the path specified is used.

/8 Set 8k database page size (the default is 4k)

/o Suppress logo

Now that you have seen the options that can be used with Eseutil /R let’s look at it in action:

Suppose we had a scenario as one above where a drive failed that contained one of your storage groups databases, and this failure caused the storage group and remaining databases (located on another drive)to go offline. Now you want to get these remaining information stores back online ASAP and worry about restoring the missing database later. Figure 1 below show the Eseutil /R command and its output.

Eseutil

- 14 -

Figure 1: Eseutil Soft Recovery

The inclusion of the /D switch makes it possible to run this command against your database/s file in just about any location, it no longer needs to be in the original location. You can see how this switch can make Out of Place Restores and restores/recoveries of Recovery Storage groups possible. This feature however is only available in Exchange 2003 and above.

Before running Eseutil /R with the /I option is highly recommended that you make a backup copy of your transaction log files, especially in a scenario when you are recovering databases but you plan to use these log files in the future after you have restored the missing database file, as the use of Eseutil /r makes changes to your Transaction log files and may change them so that future recovery of your missing database files is impossible.

Eseutil /C Restore ModeThe Exchange Server Database Utilities (Eseutil.exe) restore mode can only be run on mailbox and public folder databases restored from legacy streaming backups. This topic does not apply to transport queue databases on the Edge and Hub Transport server roles because the queue databases are not backed up. The Eseutil restore mode also allows you to view the Restore.env file. The Restore.env file is created when restoring an online backup of the database, and it controls the hard recovery process.

Hard recovery is the process that changes a restored database back to its clean shutdown state by playing transactions into the database from transaction log files. The hard recovery process controls transaction log file replay into a database that has been restored using the legacy streaming backup application programming interface (API). This process is different from a soft recovery that takes place after restoring a database using the Volume Shadow Copy Service (VSS) backup API as well as after recovering from a failure.

Backup applications that implement the Exchange legacy streaming backup API provide a setting in the user interface to start hard recovery after the last backup set has been restored. In Microsoft Windows NT NT Backup, this is called Last Backup Set.

If you fail to trigger hard recovery from the backup application, you must run hard recovery manually from the command prompt with Eseutil before a restored database can be mounted. To initiate hard recovery, you can select the Last Backup Set check box in the backup API when you restore your last database, or you can use the Eseutil /CC command. In this command, the first /C indicates restore mode and the second C is the mode modifier to start the hard recovery process. The hard recovery process uses the Restore.env file that is generated during the restore process to determine how to restore the database files and to determine what transaction log files must be replayed from the temporary directory that the backup was restored to. After the databases are copied to their destination location, and the transaction log files from the temporary directory are replayed into them, hard recovery continues to replay any additional transaction log files that it finds in the transaction log file path specified for the storage group of the restored database.

For instructions and syntax for running Eseutil /C, see How to Run Eseutil /C (Restore).

 Controlling Transaction Log File Replay

Eseutil

- 15 -Transaction log file replay behavior using Eseutil /CC depends on whether the database has been victimized. If you are restoring to an alternative server, or you have deleted and re-created the original database, only transaction logs in the temporary folder are replayed. Transaction logs in the normal database folder are not replayed. This distinction avoids transaction log replay conflicts in cases where Exchange Server knows that the database to which it is restoring is not the same as that from which it was backed up. A database restored in this circumstance is called a victimized database.

Important: After hard recovery succeeds, all files in the temporary folder (where Restore.env was created) are deleted. Never place your only copy of a log file in the Restore.env temporary folder.

Note: If you are unsure about the victimization status of a database, copy log files into both the temporary and running folders. This will ensure that one log copy or the other will be considered for replay.

If a database has not been victimized, transaction logs will be replayed as follows:

The sequence of log files listed in the Restore.env file will be replayed first. If additional log files exist in the Restore.env location, they will not be replayed under any circumstances. If additional matching log files exist in the running storage group log folder and they are in contiguous sequence with

the files listed in Restore.env, they will be replayed. If additional log files exist in the running storage group log folder, and they do not match or are not in contiguous

sequence, and circular logging has been disabled, an error will occur and hard recovery will fail. To resolve such errors, matching and contiguous log files must be located, or you can use Eseutil /CC /T switches to ignore log files in the running folder and to replay only log files listed in Restore.env.

If circular logging is currently enabled or was enabled at the time the backup was made, only log files listed in Restore.env will be replayed.

If no log files exist in the running storage group log folder, recovery will complete successfully using only the log files listed in Restore.env.

If a database has been victimized, transaction logs will be replayed as follows:

The sequence of log files listed in the Restore.env file will be replayed first. If additional log files exist in the Restore.env location and they match and are contiguous with the logs listed in

Restore.env, they will also be replayed. Additional log files in the running storage group log folder will not be replayed.

If a database has been restored to a recovery storage group, transaction logs will be replayed as follows:

Any other databases in the recovery storage group must be dismounted before beginning any transaction log file replay.

The sequence of log files listed in the Restore.env file will be replayed first. If additional matching log files exist in the running log folder for the recovery storage group and they are in

contiguous sequence with the files listed in Restore.env, they will be replayed. If additional log files exist in the Restore.env location, they will not be replayed under any circumstances.

Eseutil