Enterprise Networking Planet content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
In this article, I’ll discuss some methods you can use as a last resort to get your Exchange Server back up and running, should you find yourself in this situation.
The default Exchange databases
If the various Exchange services fail to start, the problem may be a corrupt database file. If you suspect a corrupt database file, you must first determine which file is actually corrupt. You can do this by running the tests described in “Microsoft Exchange disaster recovery.” Once you know which database is corrupt, you should try to repair the database using the technique I outline in that article. If the Exchange services still won’t start, try restoring an older backup and repairing the database from that older backup. If this technique doesn’t work, you’ll probably have to accept the fact that you’re going to lose some data; you can then cut your losses and focus on getting the server back up and running.
When a database is too severely damaged to start the Exchange services, your final option is to replace the database with a known good database. You can do this by stopping any running services and deleting the damaged database. As you may recall, the directory service database is called dir.edb and is located in EXCHSRVRDSADATA. The private information store database is called priv.edb, and the public information store is called pub.edb. Both of these databases are located in the EXCHSRVRMDB directory. Keep in mind that it’s common practice in Exchange to spread the Exchange-related files across multiple partitions. Therefore, if these directories appear to be empty, try checking for a duplicate directory on a different partition.
Once you’ve located the damaged database file, replace it with a file of the same name from the Exchange Server CD. Now, the exact method of getting your server back online will depend on which database was damaged:
If the dir.edb file was damaged, you’ll lose all information about mailbox names, connectors, and other servers within the site. Fortunately, there’s a way to get most of this information back; I’ll discuss this method later.
If the pub.edb file was damaged, you’ll lose any information that was stored in a public folder on that server. If the contents of your public folders were replicated to another Exchange server within the same site as the server you’re repairing, it may be possible to rehome the public folders onto the server that’s functional. If you don’t rehome the public folders, the replicated copies will eventually disappear after the damaged server is brought back online. Once you’ve rehomed the public folders, you can disable replication. After the damaged server is brought back online, you can replicate the public folders back to the original server, and then have the original server rehome the public folders, to take ownership of the public folders.
If the priv.edb file was damaged, anything in the private information store will be lost–including messages in users’ mailboxes. Unfortunately, once information from the private information store is gone, you can’t get it back–this information isn’t stored anywhere else on the system. The priv.edb file contains the only copy of the messages and other items that may be stored in individual mailboxes.
Replacing the database file
Once you’ve determined which database is permanently damaged, and you’re aware of the consequences of replacing that database, it’s time to get started:
1. Start the System Attendant service. If the dir.edb file is damaged, replace it at this time. Also delete any log files that may be associated with the directory service.
2. Start the directory service once you have a good copy of the dir.edb file.
3. Open Exchange’s Administrator interface. If you’re using the original dir.edb file, you should see all the usual information within Exchange Administrator, such as your connectors, mailboxes, and so on. If you had to use the dir.edb file from the Exchange CD, Exchange Administrator will appear to be empty. You now have a choice for getting the directory information back. If you have comma-separated value (CSV) files (discussed in the section “Creating your own directory service database”), use them now. Otherwise, leave the directory service alone until after the other services have started.
4. Start the information store service. If it won’t start, you may have to replace the priv.edb or pub.edb file, depending on which part of the information store is damaged. If you replace priv.edb or pub.edb, you must delete all associated log files. Then, switch to the EXCHSRVRBIN directory and run the following command: isinteg -patch. If you replaced the pub.edb file, rehome any replicated public folders. The information store service should now start.
5. Regenerate the directory service if the directory service database was replaced and you didn’t have a CSV file to rebuild it with; I explain how in the next section.
Regenerating the directory service
Before you regenerate the directory service, I must mention that the technique I’m about to describe is dangerous. Before you use this technique, all Exchange servers within your organization must be online and able to communicate with each other. Otherwise, when you rebuild the directory service database on the damaged server, the server will take possession of all public folders on servers it can’t communicate with. After this occurs, it’s sometimes impossible to return the public folders to their original server. So, before proceeding, make sure that all other Exchange servers in the organization (not just the site) are functional and that any connectors (such as site connectors or x.400 connectors) between them are also functional.
The technique you’ll perform is called a DS/IS consistency check. It analyzes the local public and private information store databases and the directory service databases on other servers within the site for information related to the damaged server. Exchange can then use this information to rebuild a portion of the directory service database. For example, all the mailboxes will be restored; often, site connectors or directory replication connectors are also restored. What will not be restored is information about the individual mailboxes. The mailbox itself will be restored; and because the mailbox has been restored, the private information store can associate mail that it contains with the appropriate mailboxes. Unfortunately, after the DS/IS consistency check, the users will still be unable to access their mailboxes–information such as the primary Windows NT account associated with the mailbox isn’t restored along with the mailbox itself. Other mailbox attributes (such as the name and phone numbers of the mailbox owner) also are not regenerated. Therefore, unless you have a CSV file (explained in the next section) that you can use to fill in the missing information, you have a lot of typing ahead of you.
Perform the DS/IS consistency check as follows:
1. Open Exchange Administrator and select the damaged server from Organization|Site|Servers|Server. With the damaged server selected, choose File|Properties to open the server’s properties sheet.
2. Select the Advanced tab. On this tab, click the Consistency Adjuster button. A dialog box will open that provides several basic options for adjusting the database’s consistency.
3. Select the options that you want to use (be sure to select the Synchronize With The Directory and Create New Directory Entries For Mailboxes That Do Not Have A Corresponding Directory Entry check boxes), and click OK. You’ll see a warning message; click OK again to acknowledge the warning, and the consistency check will begin.
Creating your own directory service database
So far, I’ve mentioned CSV files several times. A CSV file is a basic ASCII text file that can be imported into Excel because of the placement of the commas. As a result, you can use it to rebuild the Exchange directory structure. Using functionality built in to Exchange Administrator, you can create a CSV file that can restore your Exchange Server to a functional state; however, you’ll lose most of the mailbox attributes, such as phone numbers and other e-mail addresses. You can create a more full-featured CSV file by using a template found in the Exchange Resource Kit. However, doing so is a lot of work, and even the more full-featured CSV file isn’t perfect. To fill in all the gaps, I recommend using both types of CSV file in sequence: First use the basic CSV file to regenerate the basic account information, and then use the bigger CSV file to fill in the extended attributes.
Everything needed to create the basic file is located within Exchange. However, you’ll need a file from the Exchange Resource Kit called header.csv to create the other file. The header.csv file is nothing more than a text file that outlines the schema of the dir.edb database.
Create the first CSV file as follows:
1. Copy the header.csv file to a floppy disk. Also copy header.csv to a file called phone.csv.
2. Open Exchange Administrator and select Tools|Directory Export. The Directory Export dialog box will open.
3. Select the Mailbox, Custom Recipients, Distribution Lists, and Include Hidden Objects check boxes. Also select the name of the server you’re working with from the Home Server drop-down list. Click the Export File button and specify A:phone.csv.
You’re now ready to generate one of the two CSV files. Begin the export process by clicking Export.
The export process can take a long time, and it may appear to lock up occasionally. This process also may generate warnings and errors–these are normal, and you can ignore them. The only exception is an error stating that a certain attribute is unknown. This error occurs in situations where not every schema item in the phone.csv file is used. You can get around this problem by loading phone.csv into Excel and deleting the column to which the error message refers. Once you’ve deleted the offending column, try the export process again. You’ll probably have to repeat this process many times before you have a usable CSV file.
To create the second CSV file, run the export process again in the exact same way, but this time, specify A:data.csv for the Export File. A:data.csv shouldn’t already exist, so don’t perform the step in which you copy the header.csv file. Because you’re creating a brand-new CSV file that isn’t based on a template, the file will contain a default Exchange database schema.
The idea behind creating the two CSV files is that neither file contains all the directory information. Once you’ve created both files, you have all the means necessary to rebuild the directory service–you can replace virtually any information that might be destroyed. Just keep in mind that any time you make a change to the directory service, such as creating a new mailbox, you should create new CSV files; that way you always have a good backup of the most recent directory structure.
If the time comes that you can’t restore the directory service database through conventional means, you can use your CSV files. Do so as follows:
1. Open Exchange Administrator and select Tools|Directory Import. The Directory Import dialog box will open.
2. Normally, the default options in this dialog box work fine, but you may have to select the Exchange Server you want to work with. Also specify the Import File. The first file you should import is A:data.csv. Specify this file, select any other import options you want to use, and click Import. Exchange will now apply the information stored within data.csv directly to the directory service database.
3. Repeat the import process using the phone.csv file. The import process will usually generate a lot of warning and error messages. This is normal, unless a message stops the import process midstream. If this happens, it’s usually because the import process is trying to replace critical information that’s already found in the directory services database. Delete the column mentioned in the error message from the phone.csv file and try the import process again. (Normally you’ll have to remove two columns, but there’s always the chance that you may have to remove more or less.)
Once the import process completes, the directory service should be usable. You can now have a handful of users test their mailboxes. If the users can’t access the mailboxes, double-check the mailbox properties to make sure that the proper Primary Windows Account and security permissions have been restored to the mailbox. //
Brien M. Posey is an MCSE who works as a freelance writer and as the Director of Information Systems for a national chain of health care facilities. His past experience includes working as a network engineer for the Department of Defense. Because of the extremely high volume of e-mail that Brien receives, it’s impossible for him to respond to every message, although he does read them all.
