• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1280
  • Last Modified:

where are emails stored?

Can someone tell me where to find a users mailbox on the exchange server?
I need to restore a certain users emails from a backup tape but don't know which folder to look into.
I only need to restore emails for one person and not the rest of the users.

  • 13
  • 9
  • 4
  • +4
1 Solution
All of the mail is stored in one of two single instance databases, the priv.ebd and the pub.edb.  Without using a special backup agent that allows "bricks" level or granular backup, you cannot restore a single users mail.  It is all or nothing.  What are you using to backup the server?
andy98Author Commented:
using arcserver but don't think it is for exchange....

You should be able to select an individual mailbox to restore from ArcServe manager.
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

andy98Author Commented:
andy98Author Commented:
I need all the details that I can get because I have never done this before... thanks

From ArcServe manager select restore,then Restore by Tree.
Expand "My Computer" and see if you have Exchange Server brick level listed.If so,select it and you should see individual mailboxes.Select the box to restore,then select Destination to restore to.
If yo uare not using the ArcServe Agent for Exchange, that option will not be available..
If you were using Arcserve without the Exchange connector you ar stuck.

using NT Backup and/or BackupExec you can backup and restore using NT Restore and/or BackupExec allways using the same Tapes - the run comatible.

NT Backup does also backup the EXCHANGE information Store.

Lothar Gores
andy98Author Commented:
Can I do this instead....

1- backup the latest files for exchange
2- restore the last backup copy I have
3- Make a pst file from the one individual who lost the emails
4- restore the latest files that I backed up in step 1
5- import the pst files for that individual

will this work?
Using Arcserve witout the Exchange connector, does not
allow you to backup the informatiopn store of Exchange.

so there will be no restore from a old backup!!!

LotharGores is right.  Unless you have the Exchange Agent or the Open File Agent, the Exchange DBs are considered open files and are not backed up by ArcServe.
andy98Author Commented:
I have a tape backup from yesterday and it shows (by expanding the tree) that the last time that thePRIV.EDB and PUB.EDB
where backed up on was last night.
Can I restore them from this or not?
andy98Author Commented:
this is what I see when I expand the tree:

   + imcdata

where can I find the individual mailboxes?
this is exchange 5.5
Those are the directories.  If you do not have two files called priv.edb and pub.edb, you do not have a backup of any mail.
andy98Author Commented:
Yes I do have these... but I can't see any individual mailboxes.... where can I find the individual mailboxes?????
andy98Author Commented:
andy98Author Commented:
andy98Author Commented:
andy98Author Commented:
                    can you post your comments once more... it look like there was
a problem with the system earlier.


"priv.edb and pub.edb" is your store for the emails boxes.

the emails are stored in the "priv.edb" - that is one
big file with all mailboxes.
the puplic store is pub.edb which includes all public folders and their contents.

sorry to say but for your problem there is no restore option unless you have used an exchange connector for your backup.

Lothar Gores
Here a Print out from the MS Exchange Technet.
It is a long one, but you might find an alternitive route
restoring date ot of the transaction logs.

Have fun
Lothar Gores

This chapter describes techniques that can be used for Microsoft Exchange Server disaster recovery and disaster recovery planning. For quick answers to many frequently asked questions, see the ?Frequently Asked Questions? section later in the chapter.
Because Exchange uses Microsoft Windows NT security for authentication, you must include Windows NT operating system backup and restoration procedures in your planning, as well as procedures for Exchange backup and restoration. Because of this relationship, Exchange disaster recovery cannot be considered independently from Windows NT disaster recovery.
For complete information about Windows NT disaster recovery, see your Windows NT documentation. This chapter describes the aspects of recovery that are unique to Exchange.
Disaster Recovery Planning
Although Exchange is a robust and stable messaging platform, it is essential that you have a working plan to restore Exchange computers and data in a timely way if a system crash or another disaster occurs. Recovery planning includes not only planning what to do after the disaster occurs but also what steps to take during the initial setup of a system to minimize the possibility of disaster later.
Developing a Recovery Plan
By developing a recovery plan, you can minimize downtime for your organization and provide the quickest possible data recovery. However, it is important that you do not take this information for granted. Instead, you should test, formulate, and verify your disaster recovery plans.
Determining Downtime Cost
Determining the cost of downtime is useful when you must justify the purchase of recovery equipment. There are different models for calculating the per-hour downtime cost, which varies for each business. These calculations include lost orders per hour, delayed financial transactions, and the cost of delayed time-sensitive market decisions. For more information on justifying disaster recovery expenditures, see the National Computer Security Association News (July 1996).
Analyzing Server Computer Roles
When deploying equipment, avoid making your Exchange computer a primary domain controller. If the primary domain controller becomes unavailable, an alternate domain controller must be promoted to the role of primary domain controller. If the Exchange computer is not the primary domain controller, you do not have to worry about promotions and demotions of domain controllers in a recovery situation.
Some companies prefer to place the Exchange server on a backup domain controller in the Accounts domain so that a second computer is not required for Windows NT authentication in remote offices. This can save the cost of purchasing another computer. However, make sure you take into account the additional RAM overhead required for the Windows NT security accounts manager as well as the Exchange memory requirements. Windows NT domain controllers require RAM equal to two and a half times the size of the security accounts manager.
If the Exchange computer is a member server and not a primary domain controller or backup domain controller, additional memory overhead for the domain security accounts manager is not required. However, for remote offices, companies can save money by using the local Exchange server to provide authentication, serve as a backup domain controller, and provide messaging services.
Important   For a proper directory service restore, access to the original security accounts manager is required. Do not install a Exchange computer in a domain that does not have a backup domain controller.
An alternative is to place the Exchange computer in a large resource domain that trusts each account?s domain. In this case, Exchange  can be placed on a backup domain controller without incurring significant memory overhead because the security accounts manager for the Exchange resource domain will be relatively small.
Dedicating Recovery Equipment
It is important to dedicate recovery hardware. If you have a dedicated recovery server at each location, you can install Exchange before a recovery is necessary, greatly reducing recovery time.
Dedicating recovery hardware might be less expensive. Using the ESEUTIL troubleshooting utility to recover and defragment a database requires up to twice the disk space of the information store database on the largest production server. Thus, it might be more cost effective for an organization to maintain a single recovery server that has sufficient disk space rather than equipping all production servers with sufficient disk space to perform a recovery.
If you decide to dedicate recovery equipment, do not allow that equipment to become production equipment without replacing it. Make sure recovery equipment is always in working order and is available at a moment?s notice. Some companies purchase recovery equipment, but then install test-only software. They become dependent on this equipment for production use. In short, keep recovery equipment in dedicated recovery mode.
If the recovery server will be shared among sites, maintain a copy of the Windows NT installation code and service pack on the hard drive of the recovery computer. By doing so you can install Exchange based on the required site and organization without having the paths for this Exchange installation match the paths of the production Exchange being recovered. For information on settings for protocol addresses, partitioning information, protocols, options, tuning, and other options, see your production Windows NT Server configuration data.
Creating a Disaster Recovery Kit
Planning ahead reduces recovery time. It is critical to build a kit that includes the following:
?An operating system configuration sheet
?A hard drive partition configuration sheet
?A hardware configuration sheet
?An Extended Industry Standard Architecture/Micro Channel Architecture (EISA/MCA) configuration disk
?A Exchange configuration sheet that includes the following:
?Windows NT tuning settings
?Path information
?Protocol addresses
?Exchange connector configurations
?Windows NT emergency repair disk
?Microsoft Exchange Performance Optimizer settings sheet
?Any other items you might need for your site configuration
Maintaining Off-Site Tapes and Equipment
Store backup tapes at an off-site location. For legal or security reasons, some companies choose not to send backup tapes to a third-party, off-site location. One alternative is to send tapes to an off-site location within the same company.
Devising an Archiving Plan
Implement an archiving plan that enables your users to move server-based messages either to their local store files or to a disk or server that is separate from the information store. This reduces the size of the server-based information store. Otherwise, data is reduced in the information store but added to another area of the same disk or logical drive.
The impact of storing .pst files on the server disk is considerable because .pst storage maintains messages in both rich text format (RTF) and ASCII format. Because you cannot set disk space limits on .pst files, you might want to dedicate a file server for archiving them. Include all sensitive data in backup strategies, including users? .pst files. Use encryption when creating .ost files and .pst files.
Keeping Accurate Records of All Configurations
Keeping accurate records is necessary when you configure the recovery server. Records should include:
?Windows NT tuning settings
?Path information
?Protocol addresses
?Exchange connector configurations
These records should be part of your disaster recovery kit.
Additional Information Sources
The following references are sources of additional information for planning or maintaining a disaster recovery plan in your organization:
?Microsoft TechNet: (800) 344-2121; technet@microsoft.com
?Microsoft Knowledge Base: http://www.microsoft.com/kb
?Microsoft Knowledge Base Article Q154792: ?Exchange and Schedule+ White Papers and Their Locations?
?Microsoft Knowledge Base Article Q155269: ?Microsoft Exchange Administrators? FAQ?
?Microsoft Exchange Server Maintenance and Troubleshooting
?Microsoft Exchange Server Concepts and Planning
?Microsoft Exchange home page: http://www.microsoft.com/Exchange
?Public Listserver (not maintained by Microsoft):
E-mail msexchange-request@insite.co.uk (use the word SUBSCRIBE in the message body). This list can generate several dozen messages per day.
?Microsoft Press? Books (MSPRESS): In the United States (800) MSPRESS;
In Canada (800) 268-2222
?Microsoft Consulting Services (MCS): In the United States (800) 426-9400;
In Canada (800) 563-9048
?Microsoft Solution Provider Program: (800) SOLPROV
?National Computer Security Association: http://www.ncsa.com
Configuring and Deploying Resources
How you configure and deploy your equipment can affect your ability to recover quickly from a disaster. Careful planning can not only reduce the time required for recovery but also reduce the risk of a disaster.
Deploying and Testing a UPS
Make sure you are protected by an uninterruptible power supply (UPS). Do not assume that if the Exchange computer did not fail during a power outage, no other servers failed. Although many computer rooms are supposedly UPS protected, it is possible that not all of the outlets are UPS protected. If you do not have a dedicated UPS, talk to the local electricians or operations personnel about how the circuits are configured and test the outlets. Also note that server-class UPS batteries have a life expectancy of approximately three years and might require replacement.
Configuring Disks
For optimal performance and recoverability, the operating system drive should be mirrored, the transaction logs placed on a dedicated physical drive (which can also be mirrored), and the Windows NT swap file and Exchange information store placed on a mirror or RAID 5 disk set. Because off-line maintenance and repair routines require up to twice the disk space of the database file being administered with the ESEUTIL utility, be sure you allow sufficient disk space.
Configuring MTA Frequency
Configure the message transfer agent (MTA) frequency so that queues are cleared quickly. This prevents queued messages from accumulating in the information store. Also, design a redundant MTA path so that messages keep flowing if a link outage occurs. It is important that MTAs be able to keep up with the traffic that flows through them. Because it takes considerably more time to process messages from the information store than it does from memory, it is important to keep messages in the information store to a minimum to ensure timely message delivery.
Placing Transaction Log Files on Dedicated Physical Disks
Placing transaction log files on dedicated physical disks is the single most important key to Exchange performance. There are also recovery implications in maintaining transaction log files on separate dedicated physical disks, because transaction logs provide an additional mechanism for recovery if a disk failure occurs.
Disabling SCSI Controller Write Cache
Recoverability is the only consideration in deciding whether write cache should be disabled. If you have a RAID controller or if the disk controller has a battery back up, it does not matter whether write cache is on or off.
In the absence of either of the above, disable the small computer system interface (SCSI) controller write cache to avoid the possibility of losing data. At a programming level, if the SCSI write-through flag is set, Windows NT does not use buffers but writes directly to disk. When a program receives a write-complete signal from Windows NT, it has a guarantee that the write was completed to disk. This guarantee is critical to the Exchange transaction logging process. If write cache is enabled, Windows NT cannot discriminate between whether the SCSI controller cached the data or wrote it to disk. This causes it to erroneously inform the calling application that a write has been made, which could result in data corruption if your computer crashes before this lazy-write operation makes it to the disk.
Disabling Circular Logging
If you have a solid backup strategy in place, transaction log files will be purged on a regular basis, freeing up disk space and eliminating the need for circular logging. Because the total size of the active transactions are less than the total amount of RAM on a given computer, with circular logging enabled, the system has complete recoverability with respect to hard and soft crashes. However, circular logging sacrifices the protection against media failure.
Circular logging writes log files, but after the checkpoint has been advanced, the inactive portion of the transaction logs is discarded. The discarded portion usually represents the majority of the potential log data. Since transaction log history is cyclical under these conditions, it cannot be restored. In addition, although circular logging can help conserve disk space, incremental and differential backups are not possible when it is enabled.
Placing Limits on Information Store Attributes
Configure mailbox storage limits and the maximum age of server-based messages. Also, limit MTA message sizes and the size of messages that users can send. These precautions limit the amount of data you must back up and restore in case of a disaster.
Evaluating the Environments in Which Server Computers Are Placed
Inspect the area when deploying servers. Be sure there is enough power, and, if possible, dedicate power lines for your equipment. Review existing amperage and new amperage requirements. Make sure that servers are not placed under fire sprinklers. Also, make sure that your servers are in a physically secure location and that the room has adequate cooling capacity for additional equipment.
Disaster Prevention
Modifying your daily operations can reduce your risk of disaster. In addition to planning for recovery, you can implement the risk reduction procedures discussed in this section to minimize the chance of a disaster occurring.
Creating and Verifying Daily Backups
Creating and verifying daily backups is a critical step in successful disaster recovery. However, you can only recover valid data if the backup is valid. Failure to verify backups is one of the most common mistakes administrators make because they often assume that backup tapes are being swapped and that data is being backed up properly. Make it part of your daily routine to review all backup logs, and then follow up on any errors or inconsistencies.
Although the information store and directory can be backed up online, files in directories that are accessed by other services, such as the directory synchronization component or Microsoft Mail Connector (AppleTalk) MTA, should be backed up when the respective service is not running. You can automate and schedule backups using the At.exe utility provided with Windows NT.
For more information about backups, see Part 4, ?Administering and Maintaining,? and Microsoft Exchange Server Maintenance and Troubleshooting.
Standardizing Tape Backup Formats
Recovery equipment must be compatible with production tape equipment. If you deploy a new type of tape drive, make sure that you use a compatible model for your recovery equipment. You should also test reading and restoring production tape backups on the tape drive you are using for recovery.
Performing File-Based Backup
To capture all configuration data, it is best to perform a full file-based backup periodically. Services should be shut down so that open files can be backed up. This ensures that you have backed up all possible Exchange-related files. You might want to perform this backup during scheduled maintenance. File-based backup is not required for backing up the information store and directory databases; online backups are recommended for backing up the information store and directory.
Checking Windows NT Event Logs
Take a proactive approach; review logs daily. This can help you identify problems before they have a serious impact on your system.
Monitoring the Information Store
Take a proactive approach to monitoring server performance and the growth of the information store. Prepare a plan to remedy any issues. Set up Windows NT disk space alerts to monitor remaining disk space. Windows NT Performance Monitor objects exist for the information store and should be used. The LogicalDisk object, along with the % Free Space and Free Megabytes counters, is used to monitor and trigger alerts when disk space is low.
Log files accumulating on the disk can cause the information store or directory to run out of operating space. To prevent this, do one of the following:
?Write the log files to a different drive.
?Change the location where the information store or directory store transaction logs are written. To do so, select the server object. On the File menu, click Properties. Then click the Database Paths tab. Change the path names for the information store and directory transaction logs, and then click OK.
?Use Ntbackup.exe to perform a normal (full) or incremental online backup of the server. This utility automatically deletes transaction logs that are no longer needed (they have been committed to disk). If you do not run Ntbackup, the log files continue to accumulate.
Note    This method is not supported on servers where circular logging is enabled because the transaction logs are required for incremental and differential backups.
?If possible, delete any sample applications to increase disk space.
Publishing a Maintenance Schedule
It is important to set user expectation levels by publishing the maintenance schedule, especially when users expect service 24 hours a day, 7 days a week. Maintenance is inevitable because the nature of the data processing business includes service pack updates, software upgrades, and hardware upgrades. Although rare, it might be necessary to take down the information store service to reduce the size of store files using the ESEUTIL troubleshooting utility, which is available on the Exchange compact disc in the \Exchsrvr\Bin directory.
Performing Fire Drills
Periodic fire drills are an effective way to measure your ability to recover from a disaster and to validate your disaster recovery plans. This is the most valuable experience you can have in your disaster recovery planning. Conduct the fire drill in a test environment, and attempt a complete recovery. For the maximum effect, provide no notice to your staff that you are performing a drill. Make sure you use data from production backups. Record the time it takes to recover. This information will assist you in estimating the time it would take to recover after a real disaster. Up to one-third of your recovery time can be spent preparing and getting the correct tools in place to complete the job.
Data Recovery Procedures
You can use the procedures for data recovery scenarios discussed in this section to recover the following:
?An information store to a different server
?An information store from an offline backup
?A transaction log file
?A single mailbox
?A full Exchange computer
Notes on Restoring an Information Store to a Different Server
An information store can be restored to a Exchange other than the one from which it was backed up. Use this method as a last resort to recover individual items (messages or folders) from a backup without restoring on a server that is in use. This method requires an additional computer that meets the hardware requirements to run Exchange. The server should not be connected to the organization and should have enough disk space to restore the entire backup. In addition, note the following:
?Do not use this method when a server fails. This method restores only the information store; it does not restore the directory.
?When you are finished restoring the backup, reconfigure permissions on the mailboxes.
Notes on Recovery from Offline Backup
After running an offline information store restore, but before starting the information store service, run the isinteg -patch command.
During startup, Exchange validates a globally unique identifier (GUID) in the information store with an entry stored in the Windows NT Registry and the Exchange directory. The information store service cannot be started if the GUIDs do not match in each of the three places. Mismatches can occur if the information store has been restored from an offline backup.
If a copy of the information store (Pub.edb and Priv.edb) is restored from an offline backup and isinteg -patch has not been run, it fails and a -1011 error is generated when the service is restarted. The -1011 error produces an entry in the Windows NT Event Viewer Application Log with source ID 2048. The error message reads as follows: ?The information store was restored from an offline backup. Run isinteg -patch before restarting the information store.?
This error occurs because the GUIDs used by the information store that was restored are old and matching GUIDs might already exist. The GUID for this restored information store must be replaced to ensure that it is unique.
An error message, DS_E_COMMUNICATIONS_PROBLEM, will also appear.
When run with the Patch option, ISINTEG resets the entries for the GUIDs in the database, directory, and registry. It also patches information used during replication to prevent incorrect backfilling. After it has been patched, the information store service can be started again.
Patching the Information Store
To replace the GUIDs used by the restored information store, run isinteg -patch. This command enables the ISINTEG utility to run in patch mode against the entire information store (Pub.edb and Priv.edb) and generate new GUIDs. Replication information is also patched to prevent incorrect backfilling.
To run the isinteg -patch command
1. Ensure that the directory and system attendant services are running. If these services are not running, ISINTEG fails, displaying the following message:
2. At the command prompt, switch to the Exchsrvr\Bin directory, and then type isinteg -patch. At this point, the GUIDs have been replaced, and the ISINTEG will report that the information store has been updated.
3. Restart the information store service.
Patching the Information Store on a Microsoft Cluster Server
Before you run isinteg -patch on a Exchange running on a Microsoft Cluster Server, you must set the environment variable _CLUSTER_NETWORK_NAME_ to the network name of the cluster. If _CLUSTER_NETWORK_NAME_ is not set, the ISINTEG utility displays the following error: ?The private store could not be updated Reason: JET_errKeyDuplicate?
For example, to configure a cluster network name as EXCLUSTER, type the following at the command prompt:

Be sure to use the correct network name or the patch will fail.
Transaction Log Recovery
The following example describes how transaction logs are recovered.
The circumstances are as follows:
?Circular logging is not enabled.
?The transaction logs are stored on a disk separate from the database files.
?The last full (normal) backup took place two days ago.
?Because of a hardware failure (such as a bad hard disk), the information store databases have become damaged, but the transaction log drive remains intact.
Will you lose two days of production data? The answer is no. Because the transaction logs are complete, they contain all transactions from the point of the last full backup.
After you have restored the hardware, you need to perform a full restore. Do not select Erase All Existing Data. Not selecting this option will instruct the backup program to keep any existing log files. The full restore writes the database files and the log files that were backed up with the last full backup.
The restored log files include any log file saved up to the first log file on the current transaction log drive. For example, suppose that the full backup copied Edb00012.log through Edb00014.log. The log files on the transaction log drive would be Edb00015.log and up. The full restore will copy Edb00012.log through Edb00014.log and the information store database files that are part of the backup set.
When the information store service is started, it restores transactions from Edb00012.log through the last log file (such as Edb00019.log) and Edb.log, the most recent log file. When the process is complete, the database will be up-to-date. The log files contain signatures, which ensure that they are included in the sequence to be restored.
Single Mailbox Recovery
Data recovery for a single mailbox might be necessary in the event of an accidental mailbox or mailbox data deletion. The procedures in this section enable single mailbox recovery for any server in your organization, regardless of the server name. In a centrally supported organization, affiliate offices can mail tapes to an internal recovery center.
A single mailbox recovery server can be maintained online with production servers because the recovery server name does not need to be the same as the production server running Exchange. This recovery server, however, should not perform directory service replication with the production servers.
To recover individual mailboxes, you must restore the entire information store and then retrieve data from the desired mailbox.
Caution   This procedure should not be performed on a server that is in production. As noted below, this procedure requires restoring data to a server that is not part of your production Exchange site. The dedicated recovery server is installed using the same site and organization name as the production site; however, it is installed by selecting Create New Site.
The following items are required to recover a single mailbox:
?A dedicated server with enough capacity to restore the entire private information store database
?A backup of the private information store database
?Microsoft Outlook Client and Exchange installation code
?Windows NT and the latest Windows NT Service Pack installation code (Exchange version 5.5 requires Service Pack 3 for Windows NT version 4.0)
The overall process for recovering a single mailbox is as follows:
1. Prepare a server running Windows NT Server, Exchange, and the Microsoft Outlook client on the recovery server.
2. From a backup tape, restore only the information store.
3. Log on with Microsoft Exchange Administrator permissions.
4. Assign the Windows NT Administrator ID access to the desired mailbox.
5. Restore mailbox data to a .pst file.
6. Attach the .pst file to the desired user profile.
Use the following procedures to implement recovery.
Note   In these recovery procedures, it is assumed that you are using a tape from an online backup. If you are using an offline tape, do not start the services after the restore.
To prepare the nonproduction recovery computer
For the fastest recovery, the nonproduction computer should be running and available for recovery at all times. If you do not already have a dedicated recovery server, prepare one using the following procedure.
1. Run Exchange Setup, and select Complete Installation. Use the same site and organization names as those of the mailbox you are restoring. The server name of the restore computer does not matter because for this procedure, you are only restoring the information store, not the directory.
2. Do not join the existing production site. The recovery computer should be a stand-alone computer.
3. Make sure there is enough disk space for restoring the entire information store from your backup tape.
To restore the information store from tape
1. Insert the backup tape, and then log on to the recovery domain as an administrator.
2. From the Administrative Tools program group, run Ntbackup.exe.
3. On the Operations menu, click Microsoft Exchange.
4. Select the Tapes icon, and then double-click the tape name.
5. On the right side of the Tapes window, select Org, select Site, select Server, and then select Information Store.
6. In the Backup dialog box, click Restore.
7. In the Restore Information window, type the name of the destination server in the Destination Server box.
8. Select Erase All Existing Data, select Private, select Public, select Verify After Restore, and then select Start Service After Restore. Then click OK.
The following message appears:
You are about to restore Microsoft Exchange components. The Microsoft Exchange services on the destination server will be stopped.
9. Click OK.
10. In the Verify Status dialog box, click OK.
If you are restoring from a full backup, you can skip step 11 and go directly to step 12.
11. At the command prompt, switch to the Exchsrvr\Bin directory, and then type isinteg -patch. This runs the ISINTEG troubleshooting utility in patch mode. After you run ISINTEG, a message appears stating that the databases have been successfully updated. Now you can start the Exchange information store and the other services.
12. In Control Panel, double-click the Services icon, and then verify that the relevant Exchange services are running.
To recover a user?s mailbox
1. Log on to the recovery server as an Administrator.
2. In the Microsoft Exchange Administrator window, click Servers; then select the server on which the user?s mailbox is located.
3. On the File menu, click Properties.
4. Click the Advanced tab, and then click Consistency Adjuster.
5. Click All Inconsistencies.
6. Click OK. Click OK again for each message that appears. Then click OK.
7. In the Microsoft Exchange Administrator window, click Recipients. On the right side of the window, double-click the user?s mailbox name.
8. Click the General tab, and then click Primary Windows NT Account.
9. Click Select an existing Windows NT account, and then click OK.
10. Under Names in the Add User or Group dialog box, select Administrators, and then click Add. Click OK. Click OK again for each message that appears.
11. In the mailbox?s General properties page, click OK.
12. In Microsoft Outlook, start the Exchange services.
13. Configure a profile for the appropriate user.
14. Add a .pst file to the profile.
15. Restart Microsoft Outlook.
16. In the left side of the window, click Mailbox - Username.
17. In the right side of the window, select the first folder or item in the list.
18. On the Edit menu, click Select All.
19. On the File menu, click Copy.
20. In the Copy dialog box, select the appropriate .pst file.
21. Click OK. All data will be copied to this .pst file.
22. Copy the .pst file to the destination location.
23. Add this .pst file to the user?s profile on the production server or send the .pst file to the user with instructions. If you have network access, you can copy the recovered .pst file to the appropriate server.
Full Server Recovery
You can restore data from one Exchange computer to a different computer, as well as move Exchange data from one computer to a new computer. This section describes how to restore data from one Exchange computer to a different computer. For more information about moving data to a different computer, see Part 4, ?Administering and Maintaining.?
A full server recovery is more complex than a single mailbox recovery. Full server recovery is defined as restoring an original production Exchange so that all Windows NT security and configuration information as well as Exchange configuration information and other data is recovered. A full server recovery enables users to use their current passwords to log on to their mailboxes when the recovery server is deployed.
Although single-mailbox recovery requires that only the information store be restored, full server recovery requires that both the information store and directory service be restored. Exchange relies on Windows NT security for providing access to mailbox data. Exchange uses Windows NT account SID information in object properties within the Exchange directory.
A full server recovery is a special case because Windows NT is reinstalled and a new registry is created. In this situation, a new Windows NT security identifier (SID) must be created for the recovery computer in the domain.
Note   The Windows NT Registry can be restored to the same physical computer. This can be useful when you are replacing a hard drive on the same computer. In this case, if you restore the Windows NT Registry, the computer maintains its unique security identifier (SID), so you do not need to create a new SID.
In addition to performing a full restore of the Exchange databases (information store and directory), it might also be necessary to restore the Windows NT security accounts manager (SAM) database. Exchange automatically adds two accounts upon initial installation ? the Windows NT service account and the Windows NT account. Although both accounts receive special privileges during installation, to restore the Exchange directory service, you need only the Windows NT account SID used during the original installation. The Exchange directory service will not be accessible unless this SID exists in the Windows NT environment. If no domain controllers for the original domain are available, you must restore the Windows NT primary domain controller security accounts manager.
You need the following items to implement a full server recovery:
?A full backup of the information store and directory
?A replacement computer with the same or greater hardware capacity as the production server
?Access to the original Windows NT security accounts manager
?A Windows NT Server production server configuration sheet
?Exchange installation code
?Windows NT Server and the latest Windows NT Service Pack installation code
?An Exchange production server configuration sheet
For a successful directory service recovery, two key conditions must be met:
?The directory service must be restored to a Windows NT Server computer that has the same site, organization, and server name as the production server.
?The recovery server must have access from the domain in which Exchange was originally installed.
A full server recovery usually involves three computers?two computers in production and one nonproduction or non-essential computer (meaning that such a computer is in production performing some other task but is available at any time for recovery). One computer is a primary domain controller. The second computer, usually an Exchange computer, has been configured as a backup domain controller. The third computer is designated as the recovery server.
Note   It is not necessary to configure a backup domain controller as long as the primary domain controller is available to authenticate account and password information.
The requirement for a configuration that incorporates a primary domain controller, backup domain controller, and recovery server is because of the way in which Exchange uses the Windows NT security accounts manager database to provide authentication to directory objects. Because full server recovery includes the information store and directory, it requires access to the security accounts manager from the domain in which the Exchange computer was first installed. When the Exchange directory is restored, it expects the security properties of all directory objects to match the Windows NT security accounts manager for the respective accounts.
As an example, suppose there is a dedicated primary domain controller, a production Exchange computer that acts as a backup domain controller, and a recovery server. The production Exchange  computer (which is also a backup domain controller) fails. You can build a Windows NT domain controller from the recovery server with the same computer name as the Exchange computer that failed. You can then connect this computer to the domain as a backup domain controller, which provides you with a copy of the security accounts manager from the domain in which the production Exchange computer resided. To do this, use Server Manager. First delete the original computer name, the backup domain controller definition, from the primary domain controller. Then add it again during the backup domain controller installation. This procedure is necessary because each computer name receives a unique SID when it is added to the domain; you also must have a new SID for the recovery computer. After you have done this, install Exchange using the same site and organization name. By default, the same server name is used because Exchange uses the computer name to create the Exchange name. If you are recovering a server and joining an existing site during this reinstallation, see Microsoft Exchange Server Operations.
Recovery Procedure
The following procedure describes how to recover a failed Exchange using a backup tape of the production server information store and directory service. It assumes that a normal (full) online backup of the information store and directory was performed.
To prepare the recovery computer
1. Install Exchange on the new or repaired server computer. Make sure this computer is equipped with a tape drive that is compatible with the tape drives deployed on production servers. If the production server is a backup domain controller, make sure there is a primary domain controller or backup domain controller available.
2. Run Setup. Do not join an existing site.
Note   Use the Setup command to install Exchange. Do not type setup /r. This creates a problem that you will encounter when you attempt to upgrade this recovery server to the latest Exchange Service Pack.
3. Give the server computer its original organization and site name. Site and organization names are case-sensitive.
4. When prompted, select Create New Site. Even though you have chosen to create a new site, when you restart the server, it will synchronize automatically with other servers in the site because you have a backup copy of the Exchange directory database.
5. Select the same service account that you used for the production server.
6. Upgrade the recovery server to the same Microsoft Exchange Service Pack as the production server.
7. Run the Microsoft Exchange Performance Optimizer to optimize Exchange for the same configuration that was used on the production server. For more information, see your production server configuration documentation.
8. First delete and then re-add the computer name on the primary domain controller to create a new SID for the recovery computer.
9. Install Microsoft Outlook on the recovery server.
To perform the restore
1. Insert the restore tape.
2. In the Administrative Tools group, double-click the Backup icon.
3. Double-click the Tapes icon.
4. Double-click Full Backup Tape.
5. In the right side of the window, select the directory and information store that you want to restore.
6. Click Restore.
7. In the Restore Information dialog box, select the following check boxes: Erase all existing data, Verify After Restore, and Start Service After Restore.
Note   If the public information store is on a separate computer, do not select the Erase all existing data check box. Instead, select these check boxes: Private, Public, Verify After Restore, and Start Services After Restore. If you inadvertently erase the public store, contact Microsoft Technical Support.
8. Type the name of the destination server in the Destination Server box.
9. Click OK.
10. If the directory service and information store were backed up using separate backup jobs, do not start these services until both have been restored.
11. When the restore prompt appears, click OK. This opens the Restore Status dialog box.
12. After the restore is completed, click OK.
13. Click Close to close the Backup program.
14. After the restore, at the command prompt, type isinteg -patch to run the ISINTEG tool. Make sure that the directory service is started before you start the information store service.
To verify that each user?s mailbox has an associated Windows NT account
1. In the Exchange Administrator program, select a server, and then click Recipients.
2. Double-click the first user?s name.
3. Review the Primary Windows NT Account box to verify that the Windows NT account matches the mailbox.
4. Repeat this procedure as needed for each user.
Note   If you have a .csv file (from a Directory Export on the server before it went down), you can use the Directory Import feature to import all the information for each mailbox, including the primary Windows NT account. This allows you to update all mailboxes quickly without having to update each one manually. The Directory Import and Directory Export options are found on the Tools menu in the Administrator program.
To test a user?s logon password from Microsoft Outlook
1. Start Microsoft Outlook.
2. Verify that the user?s password is accepted.
Authoritative Restore
The Authoritative Restore tool (Authrest.exe) that is available on the Exchange compact disc enables you to force a restored directory database to replicate to other servers after restoring from a backup. For assistance in using this tool, contact Microsoft Technical Support.
A restored database is usually assumed to be less current than the collective information held on all other directory replicas in the organization. Therefore, a restored directory normally replaces its information with more recent data held by other servers. Although this functionality is appropriate when the reason for the restore is that a database or server was destroyed, it is not always appropriate. For example, if an administrative error deleted thousands of mailboxes or vital configuration information, the goal of restoring from backup is not to restore one server to functionality but to move the entire system back to where it was before the error was made.
Without the Authoritative Restore tool, you would have to either restore every server in the organization from a backup that predates the error or restore every server in the site and then force all bridgeheads in other sites to resynchronize from scratch. If only one server is restored, or if servers are restored one at a time, the restored server quickly overwrites its restored data with the more recent (incorrect) information held by all other servers in the site.
The Authoritative Restore tool enables you to restore one server (presumably the server with the most recent pre-mistake backup) rather than all servers. Normal replication then causes the restored information to spread to all servers throughout the organization. The Authrest.exe file is available from the Support\Utils\<platform> directory on the Exchange compact disc.
Frequently Asked Questions (FAQs)
This section provides answers to frequently asked questions regarding disaster recovery and Exchange.
Q: If I have a good backup of the directory and information store and I am restoring a server to an existing site by reinstalling Exchange, should I create a new site or join an existing site during the Exchange installation?
A: Create a new site. Do not select Join Existing Site. If you attempt to join the existing site, an error occurs because other servers in the site already have knowledge of the server you are restoring. When the server is restarted after the restoration of the databases, the restored server automatically synchronizes with existing servers in the site, even though you selected Create a New Site during server installation.
Q: If I want to keep a spare server online for performing single mailbox recovery, should I select Join Existing Site or Create a New Site during the installation of Exchange?
A: Select Create a New Site. Also, use a unique computer name when installing Windows NT. Do not select Join Existing Site. When maintaining a single mailbox recovery server, you must configure the server with the same organization and site name as the site from which you plan to recover single mailbox data. It is important that you do not select Join Existing Site during the installation. If you inadvertently join a site and then complete the single mailbox recovery procedures, undesired replication behavior will result after you run the DS/IS consistency adjuster because you have two sets of mailbox data for the same users within the site after restoring a Priv.edb.
Q: I have some users that use .pst files and remain logged on at night. How can I back up their .pst files?
A: The client automatically disconnects from the .pst file after 30 minutes of inactivity. When activity resumes, the client automatically reconnects to the .pst file. Because of this feature, you can back up .pst files during periods of inactivity (usually at night) while the client is logged on to Exchange.
Q: I know that I need to run isinteg -patch after restoring an offline information store backup to patch the globally unique identifiers (GUIDs), but what is a GUID?
A: A GUID is a hexadecimal string that uniquely tags an object in time and space. Within the information store, the private and public information stores have base GUIDs that they use to generate GUIDs for all other objects in the information stores, including folders, messages, attachments, and so on. The patch that the ISINTEG tool performs changes the base GUIDs in the information store. The patch must be run because when you restore an information store, you are essentially rolling back time on that server. If you roll back the server and do not change the base GUID, new objects created in that information store could have GUIDs that are identical to other existing objects in the organization. This would cause problems in referencing objects because they could no longer be uniquely identified. If you only have one server in your organization, this is not a problem because when you restore, there are no other objects in the organization that have IDs that might be generated again for new objects.
Q: What is the tradeoff regarding location of log files? I have computers with a total of five disk drives. The first two drives are mirrored and the other three are set up in a RAID 5 stripe set. Should I not mirror the operating system and use one of those drives to dedicate for transaction log files to gain performance?
A: In Microsoft Exchange Server, the best performance is gained through dedicating a physical drive for transaction log files. This is because transaction log files are written sequentially on a dedicated drive and the disk read/write head does not have to respond to calls from other processes. However, it might not be worth sacrificing operating system mirroring in favor of performance. In this case, it is best to maintain the Windows NT swap file and the Exchange database files on the three-disk stripe set (RAID 5) and to maintain the transaction log files on the mirror set. With enough RAM in the system, there should be little disk head contention on the operating system drives and transaction log performance should be high.
Q: How important is transaction log file redundancy?
A: In general, transactions are committed to the databases quickly. However, on a very busy system, transactions written to log files can accumulate before being committed to the database files. If the transaction log drive crashes before transactions are written, this data is lost.
Q: How can I shut down Exchange services without using Control Panel? Sometimes these services take a long time to shut down.
A: You can issue commands from the command line to shut down services, or you can use the batch file example shown below. If you want to shut down the entire system from a batch file, use the shutdown command, which is available on the Microsoft Windows NT Resource Kit compact disc. The purpose of this command is to shut down services in reverse dependency order. To shut down a Microsoft Mail (PC) message transfer agent (PCMTA) service that includes spaces in the name, use quotation marks.
     REM // stop all services
     echo Stopping Services...
     net stop MSExchangeMSMI
     net stop MSExchangePCMTA*
     net stop MSExchangeFB
     net stop MSExchangeDX
     net stop MSExchangeIMC
     net stop MSExchangeMTA
     net stop MSExchangeIS
     net stop MSExchangeDS
     net stop MSExchangeSA
     REM - call the shutdown command here. (This command requires
    "that you have the Windows NT Resource Kit compact disc.)
    *service name is user defined
Q: My tape drive is not working, but I need to back up the databases. How can I do this?
A: If you have enough disk space, shut down services and copy the Priv.edb and Pub.edb files from the Exchsrvr\Mdbdata directory (the default installation point). Also copy the Dir.edb file from Exchsrvr\Dsadata (the default installation point). You do not have to copy the transaction log files because when services are shut down normally, outstanding transactions are committed to the database. If you need to restore from this backup method, remove the log files and Edb.chk from their respective directories, copy the previously copied files back in, and follow the procedure for running isinteg -patch. When the services start up, a new Edb.chk file is created, along with new transaction log files. Make sure to back up files before you purge them. If you need additional assistance with these procedures, contact Microsoft Technical Support.
Q: How long does it take to defragment a database?
A: Approximately 10 gigabytes per hour using the ESEUTIL utility.
The databases are defragmented automatically as a background process, so unless the file size of the databases must be reduced, you should not have to run offline compaction (defragmentation with file size reduction).
Q: Do I need a backup of the directory database to recover a server?
A: You need at least one backup of the directory service for each computer. Regardless of how old the backup is, the directory service rebuilds itself on that computer and becomes current from the other directory services in the site after the restore. After installing a new server in a site and ensuring that it is replicated and current, you should make a backup of the directory service.
After a restore, run DS/IS (Directory Services/Information Store) consistency adjuster after the directory service has been synchronized. This ensures that all objects in the information store on that computer are restored back into the directory service.
Note   Make sure all directory replication connectors are working properly before running DS/IS consistency adjuster. It is possible to rehome public folders to this server as a result. For more information, see these Knowledge Base articles: Q156705 and Q141342.
If you don?t have a backup of the directory service for a server to restore from, your only option is to delete the server from the site and then reinstall it. However, this option is not advisable because you will lose all of your information store data. Instead, make a backup of the directory service as soon as possible after you install a new server, and then lock the backup in a safe place. Replace the backup with more up-to-date backups on a regular basis. This way, you do not have to wait long for the directory service to resynchronize after a restore.
Q: Why do I need to back up the system following the migration of users to the server? Also, why do I need to back up the system after running an offline ESEUTIL operation?
A: If a server crashes after a migration and you have not backed up the system data, you must perform the migration again. This can be time-consuming. After you run an offline ESEUTIL operation, the database is in a new state. If your system experiences a crash, you must perform the operation again. This can also be time-consuming.
Q: When I shut down services, they keep trying to restart. Why does this happen, and what can I do?
A: This problem is most likely caused by a server monitor session that is configured for the server on which you are trying to shut down services. By running the Administrator program admin/t (maintenance mode) command at least one polling interval before stopping services, you ensure that the server monitor is notified that subsequent polls of the server in maintenance mode will not result in alerts or alarms. After running this command, you can stop services and perform maintenance. When maintenance is complete, rerun admin /t to re-enable monitoring. For command-line Help on Administrator program command-line switches, change to the Exchsrvr\Bin directory and type admin /?.
Q: Is it a good idea to periodically perform a directory export?
A: Yes. It is a quick operation that saves time if you are unable to restore your directory database in the future. You should never have to rely on this procedure, but it is an extra safety measure that enables you to add users quickly if necessary.
Q: Where can I find more information about information store startup problems?
A: Articles in the Microsoft Knowledge Base can be provide additional information about information store startup problems and other issues. For access to the Knowledge Base, visit http://www.microsoft.com/kb. Perform a search on ?Microsoft Exchange,? and then enter relevant keywords.
Q: What are lazy and non-lazy commits, and how does Exchange use them?
A: After transaction logs are flushed to disk, the transaction is durable. If your system crashes, these logs can be restored and nothing is lost. Non-lazy commits retain data on the hard drive; lazy commits indicate that the transaction logs have not been saved.
Q: Should I disable the SCSI controller write cache?
A: Yes, unless you have RAID or a disk controller with a battery backup, in which case data loss is not an issue. Disabling write cache enables you to avoid the potential for data loss where you do not have either RAID or battery backup. At a programming level, if the write through flag is set, Windows NT does not use buffers. Therefore, when a program receives a write complete signal from Windows NT, it is guaranteed that the write was completed to disk. This is critical to the Exchange transaction logging process. If write cache is enabled, Windows NT responds as if a write has made it to disk and informs the calling application of this ?false? information. This could result in data corruption if the system crashes before this lazy write operation makes it to disk.
Q: When is a transaction committed to the database and how does this work? Is it first cached in memory so that it is virtually available, or is it necessary to read back from log files before writing to the database files?
A: Transactions are on both log files and fast memory pages. Log disk heads are never moved back to read old data, so only sequential writes occur on log files. After transactions are written to a log file, an operation is considered complete. The transaction is immediately available in server memory before it is actually committed to the database files. Remember that an operation is not complete (that is, the client does not receive an acknowledgment) until all transactions are written to the transaction log (on disk).
Q: How can I measure how the transaction logging process is doing?
A: Use Performance Monitor and select the MSExchangeDB object. Configure the following counters:
?Log Bytes Write/sec?The rate at which bytes are written to the log.
?Log Checkpoint Depth?A number proportional to the time that recovery will take after a system crash, depending on the performance of the individual system. A data page might be cached and not flushed to the .edb file for a long time. The earliest logged operations on the page can date back a significant time. To ensure that your system recovers from a crash, do not restore too many logs, and set the checkpoint depth to determine how many logs you can expect to replay during recovery.
?Log Sessions Waiting?The number of sessions waiting on a log commit to complete a transaction.
Q: What is the advantage of disabling circular logging?
A: Disabling circular logging provides for additional recoverability. This is because a history of transaction logs are maintained for all transactions. These log files are purged only when a full or incremental online backup is performed and they are no longer needed. For example, suppose your last good backup occurred on Monday, and on Thursday your database drive crashes. If you disabled circular logging and your transaction log files are configured on a separate physical drive from the drive that crashed, you can restore the Monday backup. In this case, you should not erase existing data, and you should verify that the log files created since the Monday backup have been restored back into the database. This process restores your data to the point immediately before the crash.
Q: When I try to run the isinteg -patch command, it does not run and I receive the following error message: DS_E_COMMUNICATIONS_PROBLEM. How do I solve this problem?
A: Make sure the directory service is started before running the command.
Q: How can I back up an Exchange computer if the Windows NT Server computer I am using does not have the Administrator program installed?
A: If you are copying files from an existing Exchange computer, find and copy to the backup machine the Edbbcli.dll file found in the Winnt Root\System 32 directory on the existing server. This file is necessary in order for Ntbackup.exe to back up an Exchange. The Edbbcli.dll file is also available on the Exchange installation compact disc.
Q: Do I need to run the DS/IS consistency adjuster after restoring the directory and information store?
A: No. You only have to run the DS/IS consistency adjuster if you restore only the information store. The consistency adjuster scans the information store and ensures that a directory service object exists for each information store object. If the  directory service object does not exist, one is created. The consistency adjuster also scans the directory service and ensures that a corresponding information store object exists. If it does not exist, the directory service object is deleted. Finally, the consistency adjuster also verifies the access control list (ACL) for each object and strips any invalid entries from the list. You can also set the DS/MDB Sync diagnostic logging level to maximum and then check the application log.
Q: Should I avoid running the DS/IS consistency adjuster?
A: If you restore only the information store and must run the DS/IS consistency adjuster to re-create the directory service object for the mailboxes in the store, this sets the HOME-MDB attribute on all public folders in the hierarchy (replicas or not) to this server. In addition, it strips the public folder ACLs of any invalid entries (that is, users who do not exist in the current directory).
If you do this and then re-create a replication connector into the organization, there will be a conflict. The new server will probably win because it has newer changes to the public folder property. Accordingly, the public folder will be homed on the new server, and the new server?s ACL will most likely be the ACL that is kept. This will result in lost permissions for some users.
Q: I cannot find the backup set on my tape. What might cause this?
A: Make sure that you catalog the tape before restoring any data. This process enables you to gather information on the files available on the tape, and it enables the restore process to take place. After the catalog is complete, you can start the restore process. To load a catalog of the backup sets on a tape, follow this procedure:
?In the Tapes window, select the tape whose catalog you want loaded.
?Choose Catalog in one of three ways: double-click the icon for the appropriate tape, click Catalog, or click Catalog on the Operations menu.
After you search the tape, a complete list of backup sets appears in the Tapes window. Question marks are displayed in each icon to indicate that their individual catalogs have not been loaded.
Q: If you delete a computer name from the domain, re-add it to the domain, and then restore the Windows NT Registry from tape, is it true that the local SID from the restored Windows NT Registry will not match the new SID created in the domain?
A: Yes. You should delete and re-add the name of an Exchange computer in the domain only if a new server is required for recovery. The Windows NT Registry should be restored only to the same physical computer because the Windows NT Registry contains computer-specific data. This situation can occur if only the operating system hard disk was replaced and a Windows NT restore is performed.
Another issue to consider is that the Exchange directory database maintains information about Windows NT IDs in the domain, such as ACL information. If you cannot access the security accounts manager from the original domain and you create a new security accounts manager by installing a new domain, and then restore the directory service, you have a disconnect between the object security in the directory service (such as the Exchange service account, user mailboxes, and administrator?s account) and the new domain security accounts manager. As a result, you do not have access to any object in the Exchange directory.
Q: What is the impact of configuring Exchange computers as backup domain controllers?
A: Configuring Exchange computers as backup domain controllers can increase recoverability and reduce costs. However, the memory requirements for these computers are also increased. For example, suppose that a Exchange computer configured as a primary domain controller has to be replaced. Although the Windows NT domain controller can be rebuilt and the information store restored, the directory service cannot be restored successfully to a domain that does not have the original security accounts manager.
Q: Does a full server restore to a different physical computer require the recovery server to be configured as a backup domain controller or primary domain controller?
A: No. The important thing is that the computer account is deleted and then re-added to the production domain so that the recovery computer can obtain a new SID that uses the same name as the original production server.
Q: How do you defragment the information store databases?
A: Exchange automatically defragments the information store and directory databases without interruption to messaging. Online defragmentation takes place in the background, marking items for deletion and defragmenting the database files. The resulting empty pages are returned back to the file system.
You can also use the ESEUTIL utility to compact the information store databases. Running the eseutil /D command reduces the size of the information store database files and defragments the database. In contrast, online defragmentation defragments the database files but does not decrease their size. If you use the /D (defragment) command-line option when running ESEUTIL, you must first stop the information store service.
Q: How do compaction, defragmentation, and information store maintenance differ?
A: By default, information store maintenance occurs between 1:00 A.M. and 6:00 A.M. The following tasks are typically completed during information store maintenance: tombstone compression, column aging, index aging, clean per user read, and message expiration. To view these settings from within the Administrator program, select the appropriate server under Org, Site, and Configuration. On the File menu, click Properties and then click the information store Maintenance tab.
Defragmentation is the online process that optimizes the structure of the database.
Compaction is the offline process of reclaiming disk space and defragmenting the database files. The process is accomplished using the eseutil /D command and reclaims space, having reduced the size of the database files.
Q: At what point do log files wrap around when database circular logging is used?
A: This is usually limited to four files, but if there is a heavy load on the server, such as during a large import/migration operation or a public folder backfill, the checkpoint and window grow to more than four log files.
Q: What is the Temp.edb file and why does it get created?
A: If long-term transactions are taking place, the Temp.edb file is used to store transactions that are in progress. This file is also used for transient storage during online compaction.
Q: When should the eseutil /P command be used?
A: You should use ESEUTIL only in consultation with Microsoft Technical Support. This command can delete data. Before running eseutil /P, you should always attempt a restore.
Q: What are the Res1.log and Res2.log files used for?
A: These are reserve log files that are not used unless the transaction log hard disk fills up. They are reserved for transactions that might be required to shut down the information store if the disk fills up. This way, even if the hard disk fills up, there is reserved space to record transactions from memory to disk. These files are 5 MB each, regardless of the number of transactions in the log files.
Q: If an information store is in recovery after a system crash, will Exchange be smart enough not to duplicate pre-existing transactions in the database and only play back uncommitted transactions?
A: Yes. Log files are read and this is a fast operation. If the transaction version number is already in the database, the transaction is not recommitted.
Q: Will Exchange automatically play back uncommitted transactions from logs when the services come up the first time following a crash?
A: Yes. If the database shut down was not clean, Exchange records that and replays all transactions from the checkpoint forward at startup.
Q: If circular logging is enabled, is it true that you cannot play back logs (those that are present in the circular window)?
A: Yes. With circular logging enabled, you cannot restore from a backup and play forward. You can only restore from backup at the point the backup was taken. By default, Exchange is configured with circular logging enabled.
Q: If circular logging is disabled, how can you play back transaction log files if required?
A: With circular logging disabled, you can play back logs from the last full backup. It depends on how you are performing backups. For example, suppose that you perform a full weekly backup on Sunday and incremental backups on Monday through Saturday. If you lose a hard drive or other data on Thursday, you need to restore tapes in the following order:
?Sunday: Full restore. Don?t start services.
?Monday: Incremental restore. Don?t start services.
?Tuesday: Incremental restore. Don?t start services.
?Wednesday: Incremental restore. Don?t start services.
After these restore operations are completed, start the information store service. You can restore all of these backup sets in one job and then select Start Services after the restore. When you do so, Ntbackup.exe does not start services until the files from all sets are restored. Ntbackup.exe restores the data and log files from Sunday and adds the log files for Monday through Wednesday when the services restart. Finally, Ntbackup.exe replays all log files from after the point of the full backup on Sunday until the present time (that is, Monday through Wednesday, plus any log files created after the Wednesday backup).
Incremental backups delete log files after a backup is completed. Differential backups do not delete log files; instead these files are written to tape. If you were performing differential backups, you would not have to restore the Monday through Wednesday backup because you would still have those log files on the system.
Incremental and differential backups back up all log files since the last backup, as well as the Edb.chk file. The difference between these two backup types is that differential backups do not delete log files from the system.
Q: What is the difference between running the isinteg - fix command and the eseutil /P command?
A: The eseutil /P command should only be run as a last resort in order to repair a database file. You should use the ESEUTIL tool only in consultation with Microsoft Technical Support. The isinteg - fix command repairs high-level objects, while eseutil /P repairs low-level database corruption. The isinteg - fix command repairs any ?scheme? and other high-level data or structure problems. If you have to run both commands, run eseutil /P first; then run isinteg - fix. Only run both commands if you do not have a backup from which to restore and log files to play forward.
Restoring data from a backup and then playing logs forward is the recommended way to restore a corrupted database due to hardware failure. These procedures are recommended because they enable you to recover all your data. If you do not have a backup to restore and run the eseutil /P and isinteg - fix commands instead, you will lose all of your data.
Q: Can Exchange perform information store compression on the fly? Should administrators perform manual compression on a periodic basis?
A: Exchange can perform online defragmentation, which is different than compression.
Exchange reuses the space before growing the file, so database defragmentation takes place in the background on a running server. The only time you should have to shut down a server for offline compaction is when you want to physically recover the free space on the disk. To reduce .edb file size, stop Exchange services and then run the eseutil /D command.
Q: What is the purpose of log files?
A: On an Exchange computer, the public information store, private information store, and directory service each have log files. These files are the transaction logs for all transactions that occur on the database. In the event of a system crash, hard drive failure, power failure, or another disaster, these files can be used for soft and hard recovery and for restore after backup. The Priv.edb file on a running server is always inconsistent because of the database cache that is in RAM on the server. The consistent state of a server is made up of the data in the .edb file and the data in the memory cache on the server. If a server computer crashes and you don?t replay the logs, this results in a corrupt database.
The log files permit automatic playback of transactions that have occurred on the database but are not yet committed to the .edb file. There is a check-point file, Edb.chk, that contains the current transaction point in the log files that have been committed to disk.
Log files continue to consume disk space until you do one of the following:
?Back up the server (by performing a full backup or an incremental backup). This writes all logs to the tape up to the check point and then deletes the logs written to tape from the hard drive. If you have to restore the database, the backup copies the database file from the tape, replays the logs on the tape, and then replays all the logs on the disk.
?Run with circular logging enabled.
If you browse the .edb file directories, you also see *.pat files. These files are created when a backup is performed and contain all the changes (patches) since the backup started. You can write the patch file when performing a backup and be completely current. The following table lists files that you see in the Exchsrvr\Mdbdata directory.
File      Description

Priv.edb       Private database file
Pub.edb      Public database file
Edb.log      Current log file being written to
Edbxxxxx.log       Previous log files no longer opened or being used; new .log file every 5 MB
Res1.log      Log file reserved in case the database or log file drive fills up the server
Res2.log      Log file reserved in case the database or log file drive fills up the server
Priv.pat      Backup patch file for Priv.edb
Pub.pat      Backup patch file for Pub.edb
Edb.chk       Checkpoint file
Q: When I am restoring a server in a site, if I do not have a backup of the directory (Dir.edb ) for the server, can I backfill the directory from a replica on another server in the site?
A: No. It is critical that you have a backup of the directory for each Exchange computer because the directory is unique for each computer. Even if you have only the original directory backup, you can restore this backup and then backfill changes from another server in the site.
Q: What is the purpose of the Exchange setup /r command?
A: The setup /r command enables recovery of an existing Exchange computer to new hardware. Restoration of a valid database backup is also required. Run the setup /r command when you want to move a server installation to a different computer or if you are restoring data to a new computer.
Q: Is a differential backup required only when both the transaction drive and the .edb drive must be recovered?
A: Yes. If circular logging is disabled and the transaction logs are intact, you can restore the last full backup. When the service is started, logs from the point of the full backup are played through the current Edb.log file to bring the database up-to-date. In this case, do not select Erase all existing data during the restore, or the transaction logs will be erased and you will have to restore the differential tape.
Q: Why can?t I start services between restoring a full tape and a differential or incremental tape, or between sequential tapes being restored?
A: This is because at the end of a restore, Exchange plays back all logs in sequential order. After it does this, the database is set to a new state. For example, if the services are started between a Monday incremental tape restore and a Tuesday incremental tape restore, a new state is set. When you attempt to perform the Tuesday incremental restore, the restore is not possible because the state of the database is expected to be exactly what it was at the point of the Tuesday backup. This behavior prevents overwriting new operations that have occurred on the database after services have been started.

andy98Author Commented:
What if I have the priv.edb and pub.edb from couple of
days ago and I try to copy them to the current location?
Will this restore emails to what they were couple of day ago or it would not help? Please let me know.
I have all the directory under exchsrvr and all the subfolders backedup, what will happen if I restore them on my system.
I only need to recover one mailbox.....
If you do that, you will probably blow up Exchange.  The log files and DS must be consistent with the .edb files.  If you replace the files you will replace everyones mail, not just the user you are trying to recover.  What you might want to do is build another Exchange server with the same server and site name, offline, of course and restore your files to it.  You will need to go through the entire Exchange server recovery procedure.

andy98Author Commented:
How about if I restore all the directories and folders under the exchsrvr from the backup tape from couple of days ago? will this be ok? I don't mind replacing all emails for everyone for few hours, make a pst file for the one user, then restore the whole thing again form another backup tape that I just made... will this work?
Thank to all of your for the help...
I'm trying to find an eay way of doing this before I take the looooooong road
There is no easy way to do this.  If yo ureplace your existing and working Exchange files with the backup you risk corruption of the install, and then even if it works you are risking everything again by going back to the current rev.
There is a thirdparty tool that allows you to extract a pst single users mailbox from an exchange priv.edb.  I have used it and it is worth every penny (999.00).

The tools is made by Ontracks and is called powercontrols 1.1 , check it out, every good exchange admin should have a copy.  Its handy in more cases then the disaster.

You Can probably user Symantec backup Exec - It has the feature of restoring at Brick Level - meaning you can restore a particular email or even a single mailbox.

Or you may also mount the stores in the Recovery Storage Group and can get the emails from it for that user.
This was an interesting post I found, describing how to do brick level backup/restore using Microsofts own Exmerge-tool, as well as providing some other noteworthy tips...

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 13
  • 9
  • 4
  • +4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now