- 1 -

Exchange Server

Database structure, repair tools usage in detail. Backup restore process in detail. Exchange migration 5.5to 2000, 5.5 to 2003and 2000 to 2003. Exchange connectors, troubleshooting details. Differences (improvements) between exchange versions. Exchange tools in detail.

Database structure, repair tools usage in detail.

Exchange Storage ArchitectureExchange servers store data in two files: an .edb file and an .stm file. Together, the .edb file and the .stm file form an Exchange store repository. For example, the default mailbox store on an Exchange server uses files named Priv1.edb and Priv1.stm. The default public folder store uses the files Pub1.edb and Pub1.stm. The .edb file contains many tables that hold metadata for all e-mail messages and other items in the Exchange store, in addition to the contents of MAPI messages. The .edb file is an ESE database, and because it is used primarily to store MAPI messages and attachments, it is also referred to as the MAPI-based database. The .stm file, in contrast, stores native Internet content. Because Internet content is written in native format, there is no need to convert messages and other items to Exchange format (as in Exchange 5.5 and earlier). The .stm file is also an ESE database, referred to as the streaming database. The .edb and .stm files function as a pair, and the database signature (a 32-bit random number combined with the time that the database was created) is stored as a header in both files. The internal schema for the .stm pages is stored in the .edb file.

Note   You can rename the .edb and .stm databases and move them to different directories in Exchange System Manager. Because the .edb and .stm files together create a complete Exchange store repository, you should keep them together and assign them a common name with different extensions (that is, .edb and .stm).

Exchange Server 2003 uses transactions to control changes in storage groups. These transactions are recorded in a transaction log, similar to the way transactions are stored in traditional databases. Changes are committed or rolled back based on the success of the transaction. If there is a failure, you use transaction logs (together with the database files and, in some cases, the checkpoint file) to restore a database. The facility that manages transactions is the Microsoft Exchange Information Store service (Store.exe). Any uncommitted transaction log entries are also considered part of a current Exchange database, as illustrated in Figure 10.1.

Figure 10.1   Current Exchange Server 2003 database

The following two types of databases are available in Exchange Server 2003: Private store databases   These databases store mailboxes and message queues for MAPI-based

messaging connectors. Public store databases   These databases store public folder hierarchies and public folder contents.Figure 10.2 illustrates the internal Exchange store architecture. The Microsoft Exchange Information Store service (Store.exe) uses Extensible Storage Engine (ESE) to access the database files in the file system, and provides access to the data through various interfaces, such as MAPIsvr, ExPOP, ExIMAP, ExSMTP, and ExOLEDB. Client application and application programming interfaces, such as Collaboration Data Objects

- 2 -

for Exchange (CDOEX), can use these interfaces or communicate with the messaging database (MDB) module.

Figure 10.2   Exchange store architecture

Storage GroupsEach storage group is made up of a set of log files and auxiliary files (internal temporary databases, the checkpoint file, and reserve logs) for all the databases (.edb files, .stm files) in the storage group. Exchange Server 2003 supports multiple storage groups and multiple databases in each storage group. In Exchange Server 2003, a single server supports up to four storage groups and a single storage group supports up to five databases. Support for multiple databases enables you to distribute numerous mailboxes and public folders across numerous, smaller databases, thus making database management easier. Exchange 2000 Server and Exchange Server 2003 can support up to 20 mailbox and public folder databases on a single server.

Storage Group ArchitectureAs illustrated in Figure 10.3, all storage groups are hosted from the same Store.exe process. Each storage group is represented by an ESE instance.

Figure 10.3   Storage group architecture

Within each storage group, each .edb and .stm database pair represents a mailbox store or a public folder store. As shown in Figure 10.3, all mailbox and public folder stores in a particular storage group share a common set of log files and other system files. These files enable transaction-oriented processing.

- 3 -

Direction of inheritance of permissions for Exchange Full Administrators, Exchange Administrators, or

Exchange View Only Administrators

File Structure of the Exchange StoreYou manage the Exchange store by working with its logical components. However, Exchange Server 2003

actually stores data in a specialized set of data files. Unless you are backing up or restoring data, you will

rarely interact with the files directly.

Each storage group corresponds to an instance of the Extensible Storage Engine (ESE). The ESE is a

method that defines a low API to the underlying database structures in Exchange Server 2003. On each

Exchange server, Exchange Server 2003 creates a data directory for each storage group. Each data directory

contains the database files for each of the stores in the storage group and the log files for the storage group.

The following figure shows the file structure that corresponds to a specific logical structure as defined in

Exchange System Manager.

- 4 -

Logical structure of the storage groups and stores on a single server and the resulting file structure

The storage group files perform the following functions: The log files and other system files in each storage group have the following purposes: <Log Prefix>xxx.chk   This is the checkpoint file (for example, E00.chk) that determines which

transactions require processing to move them from the transaction log files to the databases. Checkpoint files are updated when ESE writes a particular transaction to a database file on a disk. This update always points the checkpoint file to the last transaction that was transferred successfully to the database. This update provides a fast recovery mechanism. However, checkpoint files are not required to commit transactions to databases. ESE has the ability to process transaction log files directly and to determine for itself which transactions have not yet been transferred. This process takes significantly more time than using checkpoints.

Note   Extensible Storage Engine guarantees that transactions are not written to a database multiple times.

Exx.log   This is the current transaction log file for the storage group. Transaction log files give ESE the ability to manage data storage with high speed efficiency. ESE stores new transactions, such as the delivery of a message, in a memory cache and in the transaction log concurrently. The data is written sequentially. New data is appended to existing data without the need for complex database operations. At a later time, the transactions are transferred in a group from the memory cache to the actual databases, which update them.By default, the default storage group, named First Storage Group, uses the prefix E00, which results in a transaction log file name of E00.log. The E00.log is used for all mailbox and public stores in this storage group. If you create additional storage groups, the prefix number is incremented to E01, E02, and E03.

- 5 -

<Log Prefix>XXXXX.log   These are transaction log files that have no room remaining for further data. By default, transaction log files are always exactly 5.242.880 bytes (five megabytes) in size. It is theoretically possible to change the log file size, but this is not recommended. When a log is full, it is renamed to allow the creation of a new, empty transaction log file. Renamed transaction log files are named previous log files. The naming format of previous log files is <Log Prefix>XXXXX.log (such as E00XXXXX.log), where XXXXX represents a five-digit hexadecimal number from 00000 to FFFFF. Previous log files reside in the same directories as the current transaction log file.

Res1.log and Res2.log   These are reserved transaction log files for the storage group. Reserved log files are an emergency repository for transactions. They provide enough disk space to write a transaction from memory to the hard disk, even if a server's disk is too full to admit new transactions to a log file. The reserved log files can be found in the transaction log directory. They are created automatically when the databases are initialized. They cannot be created later.ESE uses reserved transaction log files only to complete a current transaction process. It then sends an error notification to Store.exe to dismount the Exchange store safely. In the application event log, there is an entry that indicates the issue. In this situation, you should create additional free hard disk space (for example, add a new hard disk) before you mount the database again.

Tmp.edb   This is a temporary workspace for processing transactions. Tmp.edb contains temporary information that is deleted when all stores in the storage group are dismounted or the Exchange Information Store service is stopped.

Note   Tmp.edb is not included in online backups.

<file name>.edb   These are the rich-text database files for individual private or public stores. The rich-text database file for the default private store is named Priv1.edb. The file for the default public store is named Pub1.edb.

<file name>.stm   These are the streaming Internet content files for individual databases. The streaming database file for the default private store is named Priv1.stm. The file for the default public store is named Pub1.stm.

Repairing Exchange DatabasesTry to repair an Exchange database only as a last resort, because such an attempt can lead to loss of data.

You can repair Exchange database files (.edb files) by using Eseutil.exe and Isinteg.exe. You can also use

recovery storage groups to salvage data from damaged databases. For information about using recovery

storage groups, see Using Exchange Server   2003 Recovery Storage Groups .

Running Exchange Tools Globally on a ServerBy default, some tools such as Eseutil and Isinteg are installed to the ..\exchsrvr\bin directory during

Exchange setup. To run these tools globally on your server (from any command prompt), add the full path

of ..\exchsrvr\bin to your Windows Server 2003 system path.

For detailed instructions, see How to Add the ..\exchsrvr\bin Directory to Your Windows Server 2003

System Path. After adding \bin to your system path, you should be able to run Eseutil and Isinteg from any

command prompt on your server. You should also be able to run any other tools stored in the ..\exchsrvr\bin

directory.

Top of page

Using Eseutil and Isinteg to Repair an Exchange DatabaseThis section contains general information that you should know about if you use Eseutil or Isinteg to repair

Exchange databases.

- 6 -

For more information about using Eseutil or Isinteg, see Microsoft Knowledge Base articles 812357,

"XADM: Maintain Your Exchange Database After You Repair By Using the Eseutil /p Tool" and 182081,

"Description of the Isinteg utility." Consider the following information when repairing Exchange databases:

• Repairing Exchange databases with Eseutil and Isinteg can cause lost data in the Exchange databases you

repair. For this reason, copy the database files you are repairing before attempting the repair process. (For

information about how to copy your database files, see "Moving or Copying the Existing Versions of the

Database Files That You Are Restoring (Optional)" in Recovering an Exchange Database.) Because you

cannot undo changes that were made to a database during the repair process, only use Eseutil and Isinteg

as a last resort. As discussed earlier, it is recommended that you recover a damaged database by restoring

a backup set instead of repairing a database. • If you use Eseutil to repair an Exchange database, you must have sufficient free disk space for Eseutil to

run. If you are running Eseutil /P you must have approximately 20 percent of the size of the database you

are repairing on the same drive. If you do not have that much room, you can use command-line switches

to redirect the temp files to a different location. If you are using Eseutil /D, you must have 110 percent of

the size of the database. While you can redirect the temp files to another drive as you can with the /P

switch, it will dramatically increase the time it takes to repair your database. If it is possible, have ample

free space when using the /D switch.

• Using the Eseutil and Isinteg utilities to repair a database file takes a substantial amount of time.

Typically, it takes much longer to repair a database than it does to restore a database from backup.

• If both utilities run successfully (for example, if there are not any errors at the end of the last Isinteg run),

the database is generally considered to be repaired and ready to replace the damaged database. If you plan to put the repaired database back in production you must:

1. Run Eseutil /P.

2. After Eseutil /P completes successfully, run Eseutil /D.

3. After Eseutil /D is completed successfully, run Isinteg –fix –test alltests.

If you only plan to salvage data from the disk, and do not plan to put it back in production, you can skip

step b earlier in this section. Skipping step b will save time in your recovery process but might cause the

database to have indexing and space allocation errors. These errors are not what you want in a production

environment, but are unlikely to affect your ability to salvage data from the database.

• If Eseutil and Isinteg cannot fix every error in the database, it is best not to discard a repaired database.

After Isinteg is completed, it should report zero errors in the database. If the error count is greater than

zero, run Isinteg again until the count becomes zero or the count does not decrement on successive runs.

If you cannot get the error count to zero, do not leave the database in production. Salvage data from it by

merging or replicating folders to a new database or by moving mailboxes to a new database.

• You can restore data from a damaged database by using another server. For example, you can restore a

damaged database to another server, extract data from it using the Exmerge utility, and then insert the data

into a new database file. You can also use a recovery storage group on the same server to restore data

from a damaged database. For more information about recovery storage groups, see Using Exchange

Server   2003 Recovery Storage Groups .

- 7 -

By default, Eseutil and Isinteg are both installed into the <drive>\Program Files\Exchsrvr\bin directory

when Exchange is installed.

Using the Exchange tools ISINTEG and ESEUTIL to Ensure the Health of your Information Store

In this article I will give you some information on how to use the Exchange tools ISINTEG and ESEUTIL. With the help of ESEUTIL you can defragment your Exchange information store offline, check the integrity of the store and repair the information store in case of emergency. ISINTEG is used to perform some tests on the information stores and to fix some errors.

Before we start using ESEUTIL and ISINTEG ensure the following:

Make a backup of your Exchange databases even if you think the files are damaged and lost. Use ISINTEG and ESEUTIL with some understanding about what these tools really do. Ensure that you have done all other tests before you use ESEUTIL and ISINTEG. Dismount the store (then it is accessible for offline defrag, tests and more).

Figure 1: Dismount the information store

ESEUTILESEUTIL is a tool to defragment your exchange databases offline, to check their integrity and to repair a

damaged/lost database.

ESEUTIL is located in the \EXCHSRVR\BIN directory. This directory is not in the system path so you

must open the tool in the BIN directory or enhance the system path with the \EXCHSRVR\BIN directory.

- 8 -

Figure 2: Change the system path to point to the \EXCHSRVR\BIN directory

ESEUTIL /D parameters

Figure 3: ESEUTIL parameters

DefragExchange 2003 defragments the Exchange database every night. But this is only an online defrag of the

database. An online defrag doesn’t reduce the size of the information store. To reduce the size of the

databases, you must use an offline defrag.

- 9 -

When should I use an offline defrag?Under normal conditions you don't need an offline defrag, but when you add tons of new users due to a

merger or aquisition or when you delete many objects from the store it can be necessary to do an offline

defrag.

You can do a space dump with ESEUTIL /MS to determine the space. Also ensure that you have 110% free

diskspace associated with the Exchange database size.

Figure 4: ESEUTIL /MS

ESEUTIL parameters for defragmentation

Figure 5: ESEUTIL Defrag parameters

Depending on the size of the information store and your hardware, the defrag process can consume a lot of

time.

- 10 -

Figure 6: ESEUTIL defragmentation status

Check the integrity of the Exchange databaseYou can check the integrity of your Exchange database with ESEUTIL /G.

Please read NOTE 1 carefully in the following screenshot.

Figure 7: ESEUTIL integrity check

To start the integrity check for the PRIV1.EDB database, type the following command:

ESEUTIL /G „C:\Program files\exchsrvr\mdbdata\priv1.edb“

- 11 -

Figure 8: ESEUTIL integrity check status

Disaster recoveryWith a good backup in hand and Exchange databases and logfiles on different hard drives, it is no problem

to recover from an Exchange disaster.

Just restore the data from backup and initiate a roll forward of the transaction logs. Well done, the Exchange

information store goes online.

But what should you do when your backup isn't readable or you don't have a backup? Here's how these tools

come to play.

Before you start:

Make sure that the databases are really not startable Check the Application log for Exchange events that can tell you the cause of the failure Make a backup of the database Restart the server so that a soft recovery can be done

ESEUTIL /P parameters

ESEUTIL /p repairs a corrupted or damaged database. Ensure that you have a minimum of 20% free disc

capacity in association to the Exchange database size.

- 12 -

Figure 9: ESEUTIL repair modus

Example:

ESEUTIL /P „c:\program files\exchsrvr\mdbdata\priv1.edb“ /Se:\exchsrvr\mdbdata\priv1.stm /Te:\

tempdb.edb

This command will repair the database PRIV1.EDB. If you have no .STM file, you can create one with

ESEUTIL /CREATESTM. Read more about this here.

After running ESEUTIL, you can open a detailled logfile called >database<.integ.raw to see the results.

As a last Step run ISINTEG –fix -test alltests. You can read more about ISINTEG later in this article.

ISINTEGISINTEG is used to do some tests on your information store and to fix some detected errors and problems.

- 13 -

Figure 10: ISINTEG parameters

ISINTEG is the only repair utility that understands the Exchange database as an Exchange database.

What does this mean? ESE is a generic database engine that can be used by different applications

(Exchange, Active Directory).

ESEUTIL looks into the database as just another ESE database, and can see their tables and indexes.

ESEUTIL just fixes the database tables.

Now it is time for ISINTEG. ISINTEG is aware of the relation between database tables and records that turn

them into folders and messages.

After you run ISINTEG –FIX, you will see many warnings but you can safely ignore these messages. You

should only pay attendtion to the end of ISINTEG. There should be zero errors reported. If there is an error,

run ISINTEG again.

This example shows ISINTEG –test folder

Figure 11: ISINTEG –test folder

- 14 -

ConclusionESEUTIL and ISINTEG are two powerful tools for ensuring the health of your Exchange information store

and a good resource to recover from failures in the store.

Use these tools with caution when you want to repair your information store. It is always a good idea to

make a backup before you use ESEUTIL to repair your Exchange databases.

In this article I have explained only a few features of ESEUTIL and ISINTEG. For a full understanding of

these tools, read the following KB articles.

Chapter 17 Recovery and RepairI do not believe in recovery.

Lillian Hellman

Scoundrel Time

In some organizations, email has become more important than the telephone--consider how a business like Microsoft or Amazon.com would operate internally without email. Microsoft and its partners have been pushing hard to make Exchange into a single messaging source, unifying voice mail, fax, and email into a single inbox. This unification makes disaster recovery even more critical.

Disaster recovery is a complicated topic. I'm not going to address the basics of recovering a crashed NT server, nor will I discuss the low-level preparations (like keeping a copy of your backup tapes offsite) you should already be doing. The Exchange documentation makes very little mention of disaster recovery; instead, the BORK and two white papers are usually cited as canon. I'll outline what you need to know about the fundamentals of disaster recovery and explain where you can find specifics for unusual tasks like recovering one system in a cluster.

Understanding Server Recovery

Let me begin with a simple but often overlooked truth, which I've formatted as a warning to catch your eye if you're just skimming.

WARNING: If you don't have good Exchange backups, your ability to recover your servers will be extremely limited. You must make sure your backup procedures work, and you must continually monitor the process to ensure that your backups are usable.

Exchange Server's normal backup procedures are primarily geared toward single-server disaster recovery; they're designed to help you replace an entirely failed member server, no matter what caused the original loss. The IS and directory databases are highly specialized, which is what gives them so much functionality, but the recovery and repair procedures necessary to fix a downed server are very specific to Exchange. You can't just pop in a tape, run ntbackup, and go.

Exchange is easy enough to set up and configure that it's possible to overlook some fundamental steps that ensure your configuration will be recoverable if something happens. There are three key requirements:

Plan your recovery strategy to make sure you have everything you'll need to do a recovery: hardware, software, and backups.

Understand the specifics of your configuration and how to best recover it. Practice recovery procedures so that when it's time to do a real recovery, you're not flustered or

frazzled by the unfamiliar procedures.

- 15 -

Planning Your Recovery Strategy

Failure to plan is the most common cause of permanent Exchange data loss. Why? Consider a typical single-site environment with two servers. One server is lost in a fire. Its backup tapes were sitting next to it on a desktop instead of in an offsite (or even fireproof) vault. Oops. That server's not recoverable, because its administrator didn't plan adequately, not because the server got roasted. The key points you have to consider when planning your recovery strategy are straightforward:

How long can I afford for my server to be down? Later in this chapter, you'll learn how to estimate backup and restore times; on top of that, you have to factor in the time it takes to run Exchange's database repair tools, if needed, plus any time to get hardware set up and organized.

Do I have adequate replacement hardware? If your primary server is a large quad-processor box with a 60GB store, what happens when you need to restore all 60GB of data to another machine? The best possible outcome is to keep a clone of your standard server configuration in your test lab so that you can use it as a recovery server (this implies that you have to budget accordingly, as discussed in Chapter 3, Exchange Planning).

This also extends to backup hardware. For example, if you back up your servers to DLT, you'd better make sure you have more than one DLT drive, because if your sole drive fails you won't be able to back up or restore until it's fixed or replaced.

Am I making regular backups? Do they happen often enough to capture all the changes made to my server? Do they include system information like the domain SAM and server registry?

Are my backup tapes secure? Ideally, you should have multiple sets of backup tapes, some of which should be stored in a secure offsite location. See the Nutshell Handbook Windows NT Backup and Restore, by Jody Leber (O'Reilly & Associates) for more details.

Am I making the right kind of backups? There's a difference between offline and online backups, and in general online backups are more useful and easier to restore. Do you know what kind you're making right now?

Steal this white paper

Microsoft has prepared a terrific 84-page white paper titled "Exchange Disaster Recovery." It was originally written for Exchange 4.0 by a group from Microsoft Consulting Services; since then, it's been updated several times and is still the canonical source of disaster recovery knowledge. One reason it's so long is that it consolidates in one place much of the information spread throughout this book.

Stop reading this book right now and go get the white paper; it's available from http://www.microsoft.com/Exchange/techinfo/administration/55/backuprestore.asp. Once you've got a copy, come back and resume reading; I'll be making reference to the white paper throughout the rest of this chapter, and it's a very handy reference to keep right next to each of your servers.

Estimating recovery space requirements

Some recovery procedures use more space than others. In particular, any time you have to run the isinteg or eseutil tools, it's likely that you'll need a significant amount of extra disk space. A good heuristic is that you should always have at least as much free space as your largest store file; some repairs require twice as much space as your largest database file, so be prepared to juggle things around or use a network shared drive, as described later, to leave yourself enough room.

- 16 -

Don't forget that this extra storage is required for most database maintenance tasks, too; if you plan to do offline defragmentations or inspections with isinteg, you'll need the extra space.

Estimating recovery time

To know how long it'll take to recover your system, you first must know how long it will take to physically move your backed-up data to the recovery system. Once your store gets bigger than about 5GB, recovery time is driven primarily by the speed of your I/O subsystem. Even with a Fibre Channel RAID array, an 18GB file copy between two separate controllers and disk arrays can take more than an hour. Over a 100Mbps switched full-duplex network, a 16GB file copy time still takes around 90 minutes. When you consider the sad fact that restoring data takes at least as long as backing it up, and that running the Exchange utilities can push the total recovery time to twice as long as the original backup requirement, knowing how long things take is critical.

It's prudent to establish a baseline for the speed of your network and servers. I recommend the following tests, using at least a 2GB store file:

If you intend to run eseutil or isinteg on the same disk partition as the databases, do a disk-to-disk copy on that partition.

If your system has multiple controllers, do a disk-to-disk copy between the two controllers on one server.

Do a disk-to-disk copy between two unique servers; this will tell you what sort of network throughput you can reasonably expect during a restore.

Back up your stores from disk to tape using your backup software. For best performance, put your tape drive on a different controller than your database disks. With some systems and backup software, local backups will be faster than doing backups over the network; on others, CPU load and other overhead will actually make a local backup slower.

Back up your stores from their home on one server to a tape drive on another. This offers you superior flexibility when it's time to restore, since you aren't limited to restoring onto a machine with a tape drive.

These tests take time to run, but one late night or Saturday spent doing them provides real-world data on how long restores will take in your environment. These tests will tell you how long it takes to restore the data, but not how long it takes to play back the log files. There's no really good way to estimate that, since many short transactions take longer to play back than an equal-size block of a few large transactions.

TIP: Note that these tests may show that your I/O system isn't well optimized for copying large files. That's okay, since most Exchange I/O is made up of small (4KB to 64KB) requests. See Chapter 18, Managing Exchange Performance, for more details.

One interesting note: Exchange 5.5 has been tuned to make the database backup APIs significantly faster. Microsoft claims that Exchange supports speeds up to 30GB/hour, so if you can't back things up that fast the problem is likely that your backup hardware can't keep up.

Logging and the Databases

Chapter 2, Exchange Architecture, covers database transaction logging in detail, including a general overview of backups; you may find it helpful to flip back there if you need a refresher. The logs often actually grow faster and consume disk space faster than the database files themselves. Every transaction generates a log entry. For example, if you send a message containing a 24MB video clip to your inbox, then delete the message, you'll have generated more than 24MB of log files: one set of log data records the new message, while a separate set records its deletion.

- 17 -

The biggest stumbling block to successful Exchange recovery is circular logging; when you enable it, you're giving Exchange permission to throw away log data. With circular logging off, as long as you have a good copy of your transaction logs, you can restore your database to a consistent and correct state. If being able to recover your data is more important than the cost of having to buy enough disk space, turn circular logging off on your IS servers. There's no excuse for leaving it on when you can buy a 10GB drive for U.S. $150 or less.

A recovery scenario

Even if you lose the entire public or private IS--say the single disk it's on crashes beyond repair--you may still be able to restore the server with no data loss. For this to happen, there are two ironclad requirements:

You must have a complete backup: either a full backup or a full backup combined with appropriate incremental and differential backups. If you use differential backups, all the differential tapes must be available and complete.

Circular logging must be turned off, and you must have access to the log files either on their original disk or from a recent backup. (Remember, according to what you learned in Chapter 3, your logs should always be on a separate disk from your IS databases.) Exchange 5.0 and 5.5 turn circular logging on by default, so you must manually turn it off.

As long as you meet these requirements, data loss can be zero. Let's say that the primary server for your workgroup is highly active; it has a 24GB priv.edb and logs grow at a rate of about 40MB per hour. A full backup is performed each night, starting at 11:00 p.m. and ending around 12:30 a.m. The logs and databases are stored on separate drives.

At 3:05 p.m. on Tuesday, a cleaning lady is working in the server room and accidentally pulls the power cord out from the back of a server. This happens right when Exchange is updating a table in the private IS, so the IS ends up corrupted. Upon reboot, the IS service fails to start. You review the event log and determine that the IS won't start because the database is corrupted. You opt to restore from your backups.

Although the IS is down, the DS and SA services are running. You start ntbackup, pop in last night's backup tape, and select to restore the priv.edb from last night and start the restoration. Approximately 70 minutes later, the file is restored.

Now, let's stop to consider what's happened so far. Your Exchange server now has a priv.edb from 12:30 a.m. on Monday, but the server last saw activity at 3:05 p.m. Hundreds (if not thousands) of new messages, sent items, and user changes have altered the database in those 14 hours and 35 minutes. There's good news, though: since you still have pristine copies of the log files, once you restart the IS, it begins to play back the approximately 560MB of log data that has accumulated since the backup finished. Each transaction in the log is rerecorded in the private IS, so when the IS finishes its job, your store is returned to its exact pre-unplugging condition.

How likely is this scenario? Very! If the drive with your IS had failed, or if you had to repair some other component, you'd still be able to restore things the same way. Even if you have to rebuild a server from scratch, as long as you have good backups, you'll be able to make things right. Note that this recovery wouldn't have been possible without proper planning and execution, and time was still required time for the recovery itself.

TIP: Depending on what caused the original corruption, it's conceivable that replaying the logs will lead to the identical circumstances and again corrupt the store. Be sure to pin down the cause of failure before you try to recover from it.

- 18 -

It is worth noting here that a $200 call to PSS for a helpful walkthrough of the recovery process may be the cheapest insurance you ever buy. If you don't practice recoveries regularly, and if you don't have a detailed plan written by you and customized for your environment, it is cheaper to get help beforehand than after a bungled restoration.

Backing Up Exchange

Exchange is designed to be backed up while running. These online backups give you maximum access to your data, since you don't have to stop Exchange's services to do a backup, provided you use an Exchange-aware backup product. (See the sidebar "Third-Party Backup Tools" for more on that touchy subject.) Before you start making backups, though, you need to know what to back up.

What to Back Up

How do you know what to back up? You can go the easy route and just back up everything on your server; even then, you need to understand what specific items are most important. You may also want or need to be more selective about what you preserve on your backups. Here's a suggested list:

The public and private IS databases and the directory database. To do a successful online backup, you must use an Exchange-aware backup tool.

Transaction logs. The public and private databases share one set of logs, so they are backed up together, but the directory logs are separate.

The Key Management Server database. You must stop the KMS before you back up its data, then restart it when you're done. Remember that the KMS data is stored in its own directory, and that it's not backed up as part of the Exchange backup process.

Other miscellaneous files in the Exchange directory trees, including MS Mail and other connector files, the GWART files, IMS archive messages, and so on.

The Windows NT registry on the Exchange server. ntbackup includes a checkbox you can use to specify that you want this backed up; you should also keep your emergency repair disks current.

The Windows NT SAM database. Exchange depends on Windows NT security information for the service accounts and user access to mailboxes, so to restore a server you must have access to the SAM context it formerly lived in.

If you're allowing your users to use PST or OST files, and if you're storing them on a central server, be sure to back them up, too. Better yet, don't allow your users to use them.

Backup Considerations

Exchange Server supports three forms of backup: full (also known as normal), incremental, and differential. If you insist on using circular logging, you can only do full backups; incremental and differential backups depend on the log files.

Full

A full backup, as the name implies, is a complete backup of the data: everything you specify is backed up in its entirety. All Exchange recovery depends on having a full backup plus any incremental or differential backups you use. Since a full backup captures everything on your server, it has the advantage of being complete, but the disadvantage that each full backup requires the same amount of time.

Exchange-aware backup applications purge the transaction logs after the backup completes; that's safe, because by the time the backup finishes, all logged transactions have already been applied to the store and backed up to tape.

- 19 -

Differential

Differential backups capture only those changes since the previous full backup. Exchange-aware products implement differential backups by storing only the log files that have changed since the previous full backup, not any of the IS or DS database files themselves. Differential backups don't purge the log files.

Because differential backups preserve all changes since the previous full backup, you don't have to keep all of them together. Let's say you do a full backup every Sunday and differentials Monday through Friday. You can use the full backup plus any one of your differential backups to do a complete restoration. This means that as the week progresses, your differential backups will take longer.

Incremental

Incremental backups are similar to differential backups, with a major twist: at the end of the backup, the transaction log files are purged. This is a lot more aggressive than differential backups, since if anything goes wrong with your backup media, you no longer have log files! Incremental backups have to be used together; if you make a full backup on Sunday and incrementals the rest of the week, restoring a server that fails on Wednesday requires the full backup plus Monday and Tuesday's incrementals.

Choosing the right backup strategies

Instead of focusing on saving tapes or labor when doing the backup, focus on saving yourself trouble and effort when you need to restore your servers. That's when the availability of the right backup data really pays off. If doing a daily full backup takes too long or uses too many tapes to be feasible for your site, get new backup hardware. When the time comes to do a restore, the last thing you want to worry about is chasing down all the incremental or differential tapes you need.

If you can't do full backups every day, do a couple per week and do differentials on the other days. If your disk space situation forces you to use incremental backups, you can do so, but I'd only recommend it until you can get a bigger drive for your log files.

Safeguarding your backup tapes

While a complete discussion of the pros and cons of tape rotation and offsite storage doesn't belong in this book, I can give you an abbreviated version: use three sets of tapes, which I'll call A, B, and C. Each week, rotate the sets. For example, if you use A this week, then B should be in a fireproof vault at your facility, and C should be in a similar vault in a different location. Next week, you'd start using C, you'd move B offsite, and you'd put A in your office vault. This shuffling may seem like a terrific hassle, and it is, but it's also excellent protection against losing or damaging one set of tapes.

I also strongly recommend that you establish a periodic audit of your backup procedures and their implementation. Check to make sure that your scheduled backups are actually happening, that data is being written to the tapes, and that you can restore it. I once was called in to restore a system that had failed; the system's tape drive was slightly out of alignment, so that it could read tapes it had written, but other drives couldn't. That put a quick stop to the restoration until we figured out what was wrong.

Content considerations

In some environments, email requires special attention for backup procedures and data recovery ability. For legal and business liability reasons, efforts may be made to ensure that long-term backups are not retained. In the United States of America, it is not uncommon to hear of companies who have policies on how long tapes may be kept. The contents of email "conversations" can be used in legal proceedings, from sexual

- 20 -

harassment cases to establishing that an organization had a specific intent during dealings with a partner company.

Using ntbackup

Exchange includes a version of the ntbackup utility that has been modified to understand how to find Exchange servers in an organization, connect to them, and back up their data without stopping the server's Exchange services. When you install Exchange or Exchange Administrator on a machine, you get this modified version of ntbackup. You can tell when you have it because there will be a new Microsoft Exchange... command in the Operations menu.

What ntbackup can do

Although it's not as sophisticated as some of the available third-party products, ntbackup is still my favorite solution for backing up Exchange servers, because its integration with Exchange is seamless: to back up a server's DS or IS, just pick the server and items to back up, then sit back and relax. You don't have to stop your Exchange services or otherwise fiddle with things.

ntbackup supports a wide variety of IDE and SCSI tape devices, but it doesn't support removable media or hard disks, so you can't use it to do an online backup to another disk somewhere. In addition, ntbackup doesn't have a lot of fancy tape management features. It doesn't know about autoloaders, striped DLT arrays, or other exotica. However, it's robust, reasonably fast, and free.

Using the GUI

ntbackup is pretty easy to use, so I'm not going to spend time explaining its basic functionality. The online help is good, and you can learn a lot from just poking around. Instead, let's dive into the Exchange-specific changes.

When you run ntbackup and select the Operations Microsoft Exchange... command, you'll see a window ➝split into two panes, just as in Exchange Administrator. The left pane shows your organization, sites, and servers. When you select a server in that pane, the right pane shows what items you can back up for that server. The DS and IS are shown separately, but no distinction is made between the public and private IS files.

To specify a server or database to back up, just click the checkbox next to it. Once you've selected everything you want to back up (bearing in mind that recovery will be easiest if you back up each server separately), you can click the Backup button or use the Operations Backup... command to start the ➝festivities. The familiar Backup Information dialog will appear; it looks just like the standard ntbackup dialog, except that you'll see each server's DS or IS as a separate backup set labeled "Microsoft Exchange" plus the server name (for example, "Microsoft Exchange: Information Store \\HSV1"). You can use the Backup Type pull-down to select a backup type of normal, incremental, or differential. If you're running ntbackup on the Exchange server itself, you can use the Backup Local Registry checkbox to force it to back up your registry as part of the session. When you're done specifying what you want backed up, press the OK button and the backup will begin. As things progress, the Backup Status window will show you which organization, site, and server it's backing up, and it will log any errors it finds.

WARNING: Don't assume that your entire backup will fit on a single tape; it might not, and ntbackup will dumbly sit there waiting for the next tape. In the meantime, incoming transactions will pile up in your Exchange server's database.

- 21 -

Exchange-specific command-line switches

ntbackup has a bunch of command-line switches, all of which are well documented in its online help. Oddly, the Exchange-specific switches aren't documented at all. Since you need them to do command-line backups, this is a pretty major omission, but there are only two pertinent switches: DS and IS. These work as you'd expect: in your ntbackup command line, you use the switches along with the machine name you want to back up. For example, this command line backs up drives c, d, and e, along with the DS and IS, on the server named HSV:

ntbackup backup c: d: e: DS \\hsv IS \\hsv /v /d "HSV DS/IS/drive" /b /t Normal /l c:\backup\daily.log

Testing your backup

You can and should verify the integrity of your backups. Microsoft's recommended approach is covered in Knowledge Base article Q178308; in brief, they recommend that you do the following:

1. Set up a test server onto which you can restore the backup. 2. Restore the backup onto your test server. 3. Stop the IS and DS services on the test server. 4. Use the eseutil /g command (described in the later "eseutil" section to verify the integrity of the

restored data. You'll need to run it three times, once for each of the database files.

If the restore was successful, none of the above steps will report any errors. I also recommend some basic sanity checks on the database content: consider checking mailboxes or public folders with known content to be sure everything is there. You could also use Outlook's Advanced Find command to search for random strings on the entire mailbox, searching both subject and body; this is a good test of the IS random-access indices. When you're done, check the test server's application event logs for any unusual errors.

Restoring from your backups

Restoring from a backup made with ntbackup is pretty easy; it's the other steps involved in the recovery process that are tricky, like knowing when to start the Exchange services. To restore from an online backup, run ntbackup. When the Tapes window opens, double-click your backup tape or use the Operations ➝Catalog... command) to force it to catalog the tape. Once the catalog has been loaded, use the Tapes window to check the databases you want to restore, then use the Operations Restore... command to start the ➝restore. The Restore Information dialog will appear, and you'll need to fill it out properly:

You can only restore a DS to the server it was backed up from; by filling out the Destination Server field, you can restore an IS to another server.

You can restore the private and public IS databases separately by checking the appropriate boxes. If you check the "Erase all existing data" checkbox, ntbackup will replace the existing databases on

the target server with the new ones you're restoring. Use this option only when you're sure you want to overwrite what's already on the server.

The "Start Service After Restore" checkbox lets you choose whether to automatically restart the DS or IS service once the restore finishes. Don't check this unless you're sure you don't need to run isinteg.

Once you've set the restore options the way you want them, click the OK button and the restore will start. Since ntbackup has to stop the Exchange services before doing the restore, it will ask you to confirm that you want them stopped.

- 22 -

Offline Backup

If the Exchange IS service is cleanly stopped, then the priv.edb and pub.edb files will be closed normally and all logged transactions will be correctly posted. Once you've done this, it's possible to save the priv.edb, pub.edb, and dir.edb files to disk or tape, in effect making a backup using the filesystem as a backup tool. Since the Exchange services aren't running while you do this backup, it's called an offline backup.

Generally, online backups are best; they preserve your ability to back up your data while still keeping your server operating. However, there are circumstances where offline backup and recovery are useful, as when you're constructing an alternate server or running tests that require a complete copy of the database files.

The critical ingredient to doing a successful offline backup is to make sure that the IS is correctly shut down. If the stop attempt fails, or if the service stops as the result of a crash, the database files will not be suitable for an offline backup. At a minimum, you should restart the IS and stop the service correctly before making a copy of the files.

If you're using a third-party backup solution that doesn't support Exchange, you may be tempted to rely on offline backups as your primary safety net. I don't recommend it. Offline backups don't delete the log files, as online backups normally do. In addition, Exchange-aware backup programs run a page-level integrity check on the database as each page is backed up. When an offline backup is performed, the database pages are not checked; the file is just copied, so database damage can go unnoticed until you need to restore from your offline backup.

TIP: If you keep daily watch on your event logs, you'll notice any unusual developments associated with the backups before they can do permanent harm. Microsoft Knowledge Base article Q188646, titled "XADM: Unable to Back Up Exchange Server 5.5 with Event ID 105," explains what to do when you encounter underlying database problems while doing a backup.

Restoring from an offline backup

There are four key steps to successfully restoring from an offline backup:

Safeguarding the existing database files, in case you want to undo the restore. To accomplish this, copy the contents of the exchsrvr\mdbdata directories on all your system drives to a safe location.

Finding the correct location for the IS and DS databases and logs. These paths are stored in the registry: the HKLM\System\CurrentControlSet\Services\MSExchangeIS key has separate entries for the database log path (ParametersSystem\DB Log Path), public IS database (ParametersPublic\DB Path), and private IS database (ParametersPrivate\DB Path); there are separate entries for the directory in the MSExchangeDS key.

Copying the files from wherever you backed them up to back to the correct location. The public and private IS databases, IS log files, directory database, and directory logs can all be in different directories, and it's critical to get them in the correct location.

TIP: You can't restore log and database files to a different path than the ones they came from, because they contain internal signatures; you can, however, restore them to different drives, as long as the relative path remains the same.

Running isinteg -patch after the restore finishes, but before you try to restart the IS. See the section "Using the -patch switch" for more details.

- 23 -

Third-Party Backup Tools

Many of the enhancements on the backup management front aren't particularly beneficial to Exchange administrators. For example, for normal Windows NT file backups, it may be desirable to have a web interface to the backup program allowing a user to search hundreds of thousands of files to specify which one to restore. One area where third-party backup tools really look good is hardware support. Many products support autoloading tape drives, multiple tape drives configured in striped arrays, or backup devices that ntbackup doesn't support. Apart from hardware support, many larger organizations have chosen backup solutions that can handle multiple operating systems or special needs like hierarchical storage management.

While third-party products can often do things that ntbackup can't, many of them have a history of problems with their Exchange support interfaces. Microsoft has provided a set of API routines that third-party products can use to scan the IS, but not every vendor has been able to successfully decipher Microsoft's documentation and build a usable backup tool.

Most third-party products that advertise Exchange support are usable, provided that you're careful. Make sure you get the correct agent or plugin module to properly back up Exchange, and make sure that the version you're using is the right one for the combination of Exchange, NT, and service packs you're running. Spend some time researching the msexchange list archives, the Microsoft Knowledge Base, and your peer network to find out whether other sites with similar configurations have had good luck with the solution you want to use.

No matter what else you do, always test your backup and restore setup on a complete copy of your database (with a recovery server, of course). It's imperative that you find problems with your backup software or hardware in the controlled environment of your test lab, not during a real service outage.

Maintenance and Repair Tools

As discussed in Chapter 11, Managing the Information Store, Exchange can perform many database maintenance tasks either on its own or according to a schedule you set. These tasks include tombstone cleanup, online defragmentation, index expiration and aging, and other tasks associated with regular preventative database maintenance. However, there are times when offline tools are required for database compaction, testing, and repair.

Don't use offline tools unless absolutely necessary. Like firearms, they're irreplaceable when you really need them, but they can be dangerous in careless or untrained hands.

eseutil

eseutil is a command-line program that performs a variety of functions on the database, including compacting, testing and repair. It operates on individual 4KB database pages, not on messages, mailboxes, or folders. Exchange 5.5's version of eseutil can check database integrity at about 10GB/hour and repair databases at 8-10GB/hour; isinteg can defragment databases at 4-5 GB/hour.

TIP: eseutil replaces edbutil, the utility program used on Exchange 4.0 and 5.0 databases. In Exchange 5.5 SP1 and later, it is located in the winnt\system32 directory instead of in exchsrvr\bin.

When to use it

Ideally, you'd never run eseutil. I always cringe when I see people running it as a preventative maintenance tool. This is somewhat like doing preventative maintenance on your car with a welding torch: it gets the

- 24 -

gunk off, but one wrong move and your engine will be a melted lump of slag. There are only three circumstances in which I recommend running it:

When you want to check the integrity of a database, either in situ or from a backup. When you need to defragment a database to free up disk space. For example, if you move several

dozen mailboxes to another server you can reclaim their space by an offline defragmentation. Don't do this routinely, however; there's no reason to do so, since the online defragmentation process runs daily.

When you need to fix a corrupted database because you can't restore it from a backup, or because Microsoft tells you to.

I can't overemphasize that this is not a tool for casual or everyday use. It can be dangerous, especially in repair mode.

How to use it

eseutil works in six distinct modes. For most Exchange systems, the only modes you'll be interested in are the defragmentation, integrity check, and repair modes. The six modes are described individually in the following sections.

The first thing you have to cope with are the mode switches that control what eseutil does, shown in Table 17-1.

Table 17-1: eseutil Command-Line Switches

Switch What It Does

/D Defragmentation mode: copies the specified database to a new file, then defragments the file to make its data contiguous. When defragmentation finishes, copies the new file back to the original location.

/G Integrity check mode: validates checksum and header information against the actual database contents. Nondestructive.

/M File dump mode: dumps the database file's contents in (mostly) human-readable form.

/P Repair mode: validates the database table structure and links, truncating or changing things where necessary. May cause data loss. Use as a last resort.

/R Recovery mode: attempts to put databases in a consistent state by repairing bad table links, but doesn't truncate or otherwise modify data in the tables.

/U Upgrade mode: rarely used, since it's designed to update an older database schema to the current revision. Normally, Exchange's setup and service pack installation programs do this.

Here's a complete breakdown of the eseutil options:

eseutil | /D database [/L logPath] [/S systemPath] [/B backupName]

[/T tempName] [/P] [/O]| /G database [/T tempName] [/V] [/X] [/O]| /M[mode] fileName | /P database [/T tempName] [/D] [/V] [/X] [/O]

- 25 -

| /R { /IS | /DS } [/L logPath] [/S systemPath] [/O]| /U database /D dllPath [/B backupName] [/T tempName] [/P] [/O]

Defragmentation mode

Exchange normally defragments the IS databases while the IS runs. However, you can do an offline defragmentation with eseutil; since the services aren't running, the utility can do a better job of compacting the database. Microsoft recommends that you do a full online backup after doing an offline defragmentation, because any outstanding log files will have the wrong database signature after the defragmentation finishes. In my opinion, you should do one before the defragmentation, too, just in case something goes wrong.

Defragmentation mode has its own set of switches:

eseutil /D database [/L logPath] [/S systemPath] [/B backupName] [/T tempName] [/P] [/O]database

Specifies the database you want to defragment. Use /ds, /ispub, or /ispriv as the database name to tell eseutil to look up the database name and path in the registry, or provide the full path and database name.

/L logPathSpecifies the location of the transaction log files for this database. Defaults to the current directory if not specified; not required when using the /ds, /ispub, or /ispriv switches.

/S systemPathTells eseutil where to find the checkpoint file. Defaults to the current directory.

/B backupNameForces eseutil to make a backup of the database being worked on, using the specified name and path.

/T tempNameSpecifies a name for the temporary database that eseutil creates. Useful for redirecting the temporary database to another disk where you have more space. Defaults to tempdfrg.edb in the current working directory.

/PTells eseutil to preserve the temporary database, so it will create it but not replace the original with the newly created file. You would then need to manually replace the original file with the newly created temporary file.

/OSuppresses the eseutil version and copyright message.

Integrity check mode

eseutil can verify the low-level integrity of the database and its pages. Note that this is different than isinteg, which checks the integrity of message and mailbox items in the database. This mode is nondestructive, but it assumes that the database is in a consistent state when you run it; if not, you'll get an error. Integrity check mode has the following syntax:

eseutil /G database [/T tempName] [/V] [/X] [/O] database

Specifies the database you want to check. Use /ds, /ispub, or /ispriv as the database name to tell eseutil to look up the database name and path in the registry, or provide the full path and database name.

/T tempnameAs in the defragmentation mode, specifies where to store the temporary file.

- 26 -

/VTurns on verbose mode, which provides a wealth of information about what the utility is doing.

/XForces eseutil to provide detailed error messages instead of its usual terse ones.

/OSuppresses the eseutil version and copyright message.

Dump mode

The dump mode tells eseutil to print some information about either the database header or the checkpoint file. It's mostly useful if you're curious about what's in those files or if you're asked to dump the files during a call to Microsoft support. The dump mode has the following syntax:

eseutil /M[mode] filename  mode

Specifies the dump mode you want to use. The K modifier specifies a checkpoint dump, and the H modifier (the default value) specifies a header dump.

filenameSpecifies the full path and filename of the file whose contents you want to see.

Repair mode

eseutil can attempt to repair a damaged database by checking the database's links between various tables of information and fixing those links if it can tell that they're bad. This repair operation is nondestructive, but it's not guaranteed to return the database to a consistent state when you run it. Repair mode has the following syntax:

eseutil /P database [/T tempName] [/D] [/V] [/X] [/O] database

Specifies the database you want to repair. Use /ds, /ispub, or /ispriv as the database name to tell eseutil to look up the database name and path in the registry, or provide the full path and database name.

/DSpecifies that eseutil should test the database for errors without repairing it.

The /T, /V, /X, and /O switches have the same function here as in the previous modes.

Recovery mode

The recovery mode is scary because it can cause data loss. When you tell eseutil to recover a database, it will freely truncate any database page it can't cleanly recover. While this will normally restore your database to a consistent and usable state, it will also normally cause you to lose some message and/or mailbox data. Don't use this mode except as a last resort. If you run an integrity check and it shows errors, always run a repair first. If that doesn't fix everything, you have two choices: restore from a good backup (hopefully with no data loss), or run a recovery. Any time you're tempted to choose the latter option, call Microsoft support first to see whether there are any other alternatives for recovery. Microsoft has an array of specialized tools to fix specific problems, but these are available only if you call them. Recovery mode has the following syntax:

eseutil /R { /IS | /DS } [/L logPath] [/S systemPath] [/O]

- 27 -

The interesting switch here is the one that controls whether the recovery runs against the IS or DS. You can specify either, but not both, and eseutil will automatically look up the location of the log and database files in the registry; you can't manually override those values. The /L, /S, and /O switches work the same way here as in the other modes.

Update mode

The update mode is rarely used. Microsoft's documentation says its use will usually only be required "with the release of a major, new revision of Microsoft Exchange Server." Update mode has the following syntax:

eseutil /U database /D dllPath [/B backupName] [/T tempName] [/P] [/O] database

Specifies the database you want to upgrade. You have to give the full path and database name; there aren't any shortcut switches.

/D dllPathSpecifies the full path to the database DLL for the version of Exchange you're upgrading from.

The /B, /T, /P, and /O switches work the same as in other modes.

isinteg

The isinteg utility does two things:

It can test the IS databases for logical errors and fix them. In this mode, it verifies the integrity of information in the database, not of the database itself (that's eseutil 's job). To do this, it cross-checks information in about 20 tables to determine what state the database is in. More specifically, it searches the IS databases for table errors, incorrect reference counts, and orphaned objects, none of which should exist in a consistent database.

It can patch the IS after you restore it from an offline backup. This is necessary because restoring an offline backup of the IS databases doesn't restore some internal fields of the database, but the patch mode will.

Microsoft recommends against using isinteg to fix database errors unless they tell you to. As with eseutil, there's some risk involved with running isinteg ; however, I think it's reasonably safe to run it if you know what you're doing. However, be forewarned that running isinteg may cause data loss, so don't do it unless it's necessary.

When to use it

The most common use for isinteg is to patch the store after running an online backup, as discussed in the "Using the -patch switch" section. Apart from that, any time the IS won't start, you should run isinteg in test mode so it can check the IS for errors, particularly if you see IS errors in the event log.

There are other circumstances when you might suspect that something's amiss:

An inconsistent message count on private or public folders. For example, a folder may show five new messages when only three exist. isinteg 's reference count tests are used to address such issues.

An unexplained crash of the Information Store when a user accesses a given folder or message. A user is unable to access a message or folder from any client due to client error. Event log entries

may also be present on server containing messages.

- 28 -

It never hurts to run isinteg in test mode; however, you should only run it with the -fix switch if you've got a recent backup.

How to use it

The full set of isinteg options looks like this; they're explained in Table 17-2:

isinteg [-pri] [-pub] [-fix] [-L [logFile]] [-detailed] [-verbose] [-test { alltests | testName} ] [-dump] [-[patch]

Table 17-2: isinteg Command-Line Switches

Switch What It Does

-detailed Provides additional detail on any database problems found.

-dump Verbose dump of store data. Interesting, but not always useful.

-fix Fixes problems found during the integrity check. Without this switch, a read-only check is performed.

-L Specifies the name of the isinteg log file. Defaults to isinteg.pub or isinteg.priv in default directory.

-patch Patches Information Store after an offline restore.

-pri Specifies that isinteg should check the private Information Store, priv.edb (it gets the file's location from the registry).

-pub Specifies that isinteg should check the public IS, pub.edb.

-T Specifies path to database files; normally extracted from registry.

-test

Specifies which tests will be performed. -test alltests is recommended, since it runs all tests in sequence. You can also name individual tests. The following tests are named:

Folder/message tests : folder, message, aclitem, delfld, acllist, timedev, rowcounts, attach, morefld, global, searchq, dlvrto, search, dumpsterprops, namedprop

Private IS only : rcvfld , mailbox, oofhist

Public IS only : peruser, artidx, newsfeed

Reference count tests : msgref, msgsoftref, attachref, acllistref, aclitemref, newsfeedref (public only), fldrcv (private only) fldsub, dumpsterref

Groups tests : allfoldertests, allacltests

Special tests : deleteextracolumns

-verbose Provides verbose progress messages.

- 29 -

Using the -patch switch

isinteg is also used to patch the database when you restore it from an offline backup. This is necessary because of how the IS allocates object IDs: each object in the public and private IS databases has a globally unique identifier, or GUID. Object GUIDs are derived from the base GUID of the store they live in. Microsoft uses GUIDs in Exchange to uniquely identify an object's location and creation time. When you do an offline restore, you're reloading an "old" version of the database: in effect, you're turning back time. If you don't change the store's base GUIDs, newly created objects could accidentally get GUIDs that match items already in the store, which would cause major trouble for replication.

When you do an online backup, ntbackup fixes the GUIDs as it does the restore; for an offline backup, you must manually fix them by running isinteg -patch. If you don't run this command after doing an offline restore, the IS won't start, and it will record error -1011 in the event log. The message for that event says (paraphrased) "You restored an offline backup. Go run isinteg -patch or I won't start."

To use the -patch switch, make sure that the DS and SA services are running, then run isinteg -patch from the command line. It will replace the GUIDs, after which you can safely restart the IS. Note that you can't patch one IS or the other; isinteg will always patch both databases.

Recovering Your Data

Chapter 15, Troubleshooting Exchange Server, covers basic troubleshooting of the Exchange Server environment; it is a good reference point to start from. Once you've determined what's wrong, how do you fix it? Understanding how to fix specific problems is useful only if you can match your specific problem to the corresponding solution. Table 17-3 summarizes common problems and their solutions; the rest of this chapter will discuss the solution steps in detail.

Table 17-3: Troubleshooting Guide

Problem Server Condition Procedure

Directory database (dir.edb) damaged or missing

NT installation is okay.

Exchange installation is okay.

The server's directory is corrupted or unavailable (including disk failures).

Restore the directory database from a known good backup.

Public and/or private IS database damaged, logs okay

Windows NT and Exchange are undamaged.

The priv.edb and/or pub.edb files are lost or damaged.

Circular logging is off.

You have a usable backup.

Restore the IS and log files to the failed server. Restart the IS to force it to play back the log files.

Private IS damaged or lost, no logs

Windows NT and Exchange are undamaged.

The priv.edb and/or pub.edb files are lost or damaged.

Full logs are unavailable (log

Prepare for data loss! Restore from most recent full backup, then restart IS to play back any remaining log files. Some changes made since full backup will be lost.

- 30 -

drive has failed, backup is bad, or circular logging was on).

You have a usable backup of the IS.

Public IS damaged or lost, no logs

Windows NT and Exchange are undamaged.

Replicas of the public folders exist.

Restore the old public IS database, then allow public folder replication to bring the contents up to date.

Single mailbox deleted by human error

Server is undamaged.

No OST is available.

Create a new mailbox for the user on the production server, then see the section "Recovering Data from One Mailbox."

One of the more challenging aspects of dealing with recovery is the combination of losing Windows NT and Exchange Server at the same time. There are basically only a few considerations:

Is the hardware working, or was it the cause of the failure? If the hardware is safe, the cause of the problem was human error, software, or some other factor that was removed. If the hardware caused the failure, are you reusing the old hardware, or do you need to acquire new or spare hardware?

Can the data be recovered from the system? If the database files can be copied off, you may wish to bypass any tape restoration solutions and jump right to a offline restoration. If the system won't boot to access NTFS, one technique to get to the .edb files is to boot up from a Windows NT CD-ROM and install a second copy of NT on another partition to get NTFS access long enough to copy the files. Options here depend on the specifics of the failure and the disk layout. I've also seen drives moved off one computer and connected to a controller of a different computer. Consult your NT experts, as this is just a simple file retrieval; when the Exchange services aren't running, .edb files are just like any other files on a Windows NT system.

How long do you have? If rebuilding a server will take time, do you have another suitable machine already running that could either join the domain or be renamed in the domain?

Recovering Data from One Mailbox

The biggest surprise to most new Exchange Server administrators is the inability to easily restore a single mailbox, folder, or message. In fact, the Exchange design requires that an entire priv.edb or pub.edb file be restored at once. Practically speaking, this means that the entire server's mailbox contents must be restored to retrieve a single user's deleted mailbox.

To recover a single message in a single mailbox or public folder, you have to restore the entire private or public IS--a huge amount of effort. Exchange 5.5's deleted item recovery feature means that most of the time you can get away without having to go through the whole process, so I recommend that you turn this feature on and give it a liberal retention period. (Note that it won't help you if the client is using PSTs, POP3, or IMAP4.)

What if you need to recover an item that has been removed but isn't in the dumpster? You can't restore the IS to your production server, because that'll overwrite changes to everyone else's mailbox. Instead, you need a separate recovery server. A separate server will come in handy for other recoveries, too, so if at all possible, you should keep one handy.

- 31 -

The recovery server

Your recovery server needs to have enough disk space to install NT and Exchange with all the service packs you use on your production servers, plus enough space to restore the private IS. It can be on the same LAN as your production network; however, if you leave the recovery server up you must be sure that it doesn't try to participate in directory replication.

Before you can recover anything, you must prepare the server appropriately:

1. Install Windows NT and any service packs. This computer can be a PDC, BDC, or member server; its network name is unimportant because you will only be restoring the IS, not the DS.

2. Install Exchange. When prompted, create a new site, using the organization and site name from the server whose backup you're restoring. Don't join the existing site.

3. Install whatever Exchange service pack was installed on the server at the time of the backup. For example, if you're restoring from a backup made while SP1 was installed, install SP1 on the recovery server even if you've since upgraded your production machine to SP2.

4. Install the Exchange or Outlook client on the recovery server.

You may or may not need to repeat these steps in the future; if you have a dedicated recovery server, you may be able to leave it alone once it's set up, or you may have to reinstall Exchange or even NT to match the configuration of the server you're trying to restore from.

Recovering a single item

Once your recovery server is up and going, the actual recovery is straightforward. The following steps assume that you've logged on to the recovery server as an administrator:

1. Restore the IS to your recovery server, either from an offline or online backup. Make sure the IS starts when you're done.

2. Run Exchange Administrator, then start the DS/IS consistency adjuster. (It's in the Advanced tab of the server's properties dialog). This is required to populate the directory, since you didn't restore it.

3. Open the Recipients container, find the mailbox you want to restore, and open its properties dialog. Use the Primary Windows NT Account button to select the account you logged on with as the mailbox owner.

4. Configure a messaging profile for the new user account, making sure to add the Exchange and Personal Folder services to it.

5. Launch the Outlook or Exchange client. If you're using the Exchange client, select the user's folder and copy it, then paste it to the Personal Folders item. If you're using Outlook, use the File ➝ Export... command to export the desired data to a PST.

6. Deliver the PST to the original client, or move the PST contents into the user's mailbox. Warn the user sternly not to lose any more data.

These steps work whether you want to restore an individual message or an entire mailbox.

Restoring Data When Your Machine Is Okay

Restoration is where backup solutions test their mettle. You are strongly advised to test your backup solutions as much as you can tolerate, as there is no point in doing a backup if the restore is unsuccessful. All too often, automated backup solutions get out of hand and errors are not caught until it is too late.

- 32 -

The act of restoring itself can present a risk. Accidentally restoring over an active server can have disastrous results. In fact, Microsoft's documentation advocates a dedicated recovery server as a primary means of recovery. The following excerpt is from the documentation:

When a mailbox or information store is corrupted, you can use backups to recover the information store to a dedicated recovery server and then restore the mailbox or information store to the production server. When a server fails, you can use backups to restore the server's information store, directory, and configuration to a recovery server and then place the recovery server in production to replace the failed server.

Before attempting any restore or recovery efforts, make copies of all the existing database and log files. In fact, it may be simplest to stop all of the Exchange server programs, then xcopy the various \exchsrvr file trees, which may be on multiple partitions. With large stores, this could take some time, but it could be of considerable use if the restoration is problematic or in determining the cause of the failure.

Restoring from a failed database drive

This is probably the easiest type of recovery, because if you have a good backup and a good copy of the log files, Exchange can cleanly repair itself. If you lose the public or private IS or directory databases because the drive they're on fails, here's what to do:

1. Use the Services control panel to disable and stop the SA service. 2. Replace the failed drive. Create a new logical drive with the same name as before, then format it. 3. Create a directory structure for Exchange identical to the one on the failed drive (you can cheat and

look in the registry to get the correct structure). Normally, this means you need to create the exchsrvr directory with subdirectories named mdbdata and dsadata.

4. Restore the databases from your last backup. If possible, use an online backup. Don't worry about restoring the transaction logs (if they were on the same drive, you'll need to follow the steps in the next section).

5. Enable the SA service, then start the SA, DS, and IS services. When the IS starts, it will replay the transaction logs and bring the restored IS or DS up to date.

6. Check the event log to make sure everything went smoothly.

Restoring from a failed log drive

When your log disk fails, you're probably going to end up losing some data unless your most recent backup is very recent indeed, although you may be able to recover some data using a separate procedure that I'll get to in a minute. First, here's what you need to do when you lose the disk with the IS logs on it:

1. Use the Services control panel to disable and stop the SA service. 2. Replace the failed drive, then create a new logical drive with the same name as before. 3. Format the new disk and create a directory structure for Exchange identical to the one on the failed

drive. In particular, you need the exchsrvr\mdbdata directory. 4. Back up the IS databases, either online or offline. 5. Restore the most recent online backup of your IS databases. 6. Enable the SA service, then start the SA, DS, and IS services. When the IS starts, it will contain only

the data from the time of the last backup. 7. Check the event log to make sure everything went smoothly.

TIP: When you lose the DS log disk, you're in better shape because the directory can repair itself via replication. All you have to do in that case is fix the broken disk (following steps 1-3 in the previous list), back up your existing directory, then restore the most recent online backup of dir.edb. Once you do that, and restart the SA and DS services, the normal replication process will backfill any missing data.

- 33 -

If you want to try your luck at extracting additional data from the IS itself, you can. Some data that would normally be available from the logs might be available in the IS, in which case you can retrieve it by using the consistency adjuster. However, you must attempt this on the recovery server, not your production machine.

1. Set up your recovery server using the instructions in the section "The recovery server," earlier in this chapter. As in that section, be sure to use the same organization and site names as the production server, but don't join an existing site. Create a new site with the same name.

2. Make a backup copy of all files in the exchsrvr\mdbdata directories on your server. 3. Copy the private and public IS databases from the production server to the recovery server. 4. If necessary, use isinteg and/or eseutil to repair the databases. Once the databases are consistent,

start the IS. 5. Run the DS/IS consistency adjuster. This may make changes to your IS and directory, which is what

you're hoping for. 6. Use the exMerge tool (covered in Appendix A, BORK Tools) to merge whatever data the adjuster

adjusted from the recovery machine back to your production server.

Restoring Exchange When NT Is Damaged

As long as you can accurately recreate the underlying NT configuration of your Exchange server, restoring to it is not significantly harder than restoring when a disk fails. Restoring the IS is exactly the same, in fact; the difference is that you normally need to restore the DS as well, and that's a little more complicated. There are two new requirements that you must be able to meet to successfully restore the directory:

The recovery server must have the same organization, site, and server name as the original machine. You must have access to the original domain's SAM database.

Of course, the server you're restoring onto has to have adequate capacity to hold the databases, enough disk space to install Exchange and Windows NT, and so on. Be careful to accurately replicate the server's original NT configuration: install the same hotfixes, service packs, and third-party services in the same order as the original installation.

Restoring domain controllers

You have to be especially careful during recovery if you've installed Exchange on a domain controller, because having access to the domain SAM is a prerequisite for a successful recovery. If your failed machine was a BDC, you're in good shape; as long as the PDC or another BDC is still on the network, you can reinstall NT on your Exchange server as a BDC, and you'll be okay. The same is true if the server you were restoring was a member server.

The sticky part comes when you try to restore Exchange onto a machine that was formerly a PDC. If you reinstall NT as a PDC, it will create a totally new SAM database that won't match the original; although you'll be able to restore the IS and DS from a backup, you won't be able to start the Exchange services or use the restored directory, since it depends on the original security context. Without a directory, you can't do anything except restore individual mailboxes.

The key is to make sure that you have an available PDC when you do the restore. It may be a BDC that you've promoted (in which case you make your newly reinstalled server a BDC and promote it later), or it may be the original PDC. As long as one domain controller is available, you won't have any problem.

- 34 -

Restoring Exchange

The steps involved in restoring Exchange to a server that has been reloaded with a fresh copy of NT are as follows:

1. Remove the computer's old domain account on the PDC/BDC, then add it back. 2. Log on to the target machine as a domain administrator. 3. Run Exchange Setup using the /r switch. (See Chapter 4, Installing Exchange, for details.) 4. Make sure the server name matches the original server name; it should, as long as the NT names are

the same. 5. Create a new site using the exact same site and organization name as the original server. Upper- and

lowercase letters are different to Exchange, so make sure you have the capitalization right. 6. When prompted, use the same service account as the original server. 7. Install the same connectors that were on the original server. 8. Install the same Exchange service pack as was on the original server. 9. Configure the IMS, INS, MS Mail connector, and any third-party connectors, since they may store

their configuration parameters in the registry instead of the directory. 10. Run Performance Optimizer. 11. If KMS was installed on the original machine, reinstall it. 12. Install Outlook or the Exchange client.

Don't start the Exchange services. At this point, you've got a fresh installation of Windows NT and Exchange, but you still have to reload your data from your backups.

Restoring your data

The restoration procedure varies slightly, depending on whether you have an online or offline backup and whether you have any log files generated after the original backup. I'll note the differences where they occur. Here's how to restore your data:

1. If you have transaction logs generated after the original backup, copy them to the log directories of the recovery server.

2. If you have an online backup, restore it using ntbackup. Tell ntbackup to back up the private and public IS, turn on the "Start Services After Restore" checkbox, and make sure the "Erase all Existing Data" box is checked unless you have transaction logs from after the original backup.

If you have an offline backup, stop the Exchange services on the recovery server and copy the database and log files to their proper locations, then restart the DS and SA and run isinteg -patch. Once that finishes, restart the IS.

3. If you're running KMS, stop the KM service and restore its data, then restart it. 4. Verify mailbox account associations by opening a mailbox's properties dialog and checking the

Primary Windows NT Account field. If you used the correct domain SAM, you should see that the account is correct.

5. Use the client software you installed in step 11 of the previous section to make sure that you can log on as a user, see calendar data, and exchange mail with other users.

6. Repeat the previous step using someone else's workstation. 7. Reconfigure Exchange and NT to match the original configuration: 8. Increase the size of the application event log. 9. Make sure the page file is set to the correct size. 10. Turn off circular logging. 11. Add any alternate service accounts.

- 35 -

12. Set diagnostic logging levels, INS, and IMS settings as desired; they're stored in the registry, not the directory.

Restoring Exchange to a Different Computer

There are circumstances where you may be willing to lose configuration data but are more concerned with mailbox (priv.edb) content. As long as you keep the server name the same and get a new domain account for that name, you can restore Exchange to a new server. But what if you want to move it somewhere else? Perhaps your Exchange installation is damaged, but the server is still able to run other services, and you are unwilling to rebuild the entire system; instead, you want to move Exchange to another system with a new name.

This is not an ideal solution, as configuration data will be lost, all clients will need to be told about the new server, and so forth. It is best suited for testing of restore procedures, single mailbox restore, and other data-only restores where clients and other servers never directly connect to this restored data.

One variation of an offline restore is an alternate server restore. The normal Exchange restore procedure doesn't allow you to create a priv.edb or pub.edb file directly. To accomplish this, you would need to restore your database to an alternate server, stop that server, and manually copy the file you desire. If you do this, the server name and other aspects of the server won't be identical to the one you intend to deploy the store database on.

The fastest way to do this is to do a restore as outlined above. When you try to restart the IS, Exchange will complain via event log entries, including event ID 143, that the logs and the databases don't match. Your only possible response to that is to remove the log files, then restart the IS. This costs you the data in the log files; whether that's acceptable or not depends on what you're trying to do; be sure not to do anything until you have a good backup of the log files!

Once you've restarted the IS, you still need to use the DS/IS consistency adjuster to bring the directory in line with what's in the mailboxes. Figure 17-1 shows the DS/IS Consistency Adjustment screen. In this case, we want to synchronize the private IS and the directory, so the "Synchronize with the directory, and create new directory entries for mailboxes that do not have a corresponding directory entry" box is checked. It exactly describes our situation, as we used the restoration from tape to put the mailboxes in place without restoring the directory.

Figure 17-1. DS/IS Consistency Adjustment screen, options selected to discover users from the alternate server priv.edb file

- 36 -

 

One last step is to change the Filter setting to "All inconsistencies" from the default of "Inconsistencies more than 1 days." Press OK to start the adjustment. After the adjuster finishes running, the directory entries will appear. You will notice that the directory entries are missing all their normal fields; most of the mailbox information is stored in the directory, and we didn't restore it. However, the information that was restored is enough to allow you to recover data from the mailbox and print it, look it over, or whatever.

Directory Recovery

Complete recovery of the database is often not as much of an issue. Given the directory's relatively small file size and its replication with other servers in the same site, most directory issues are not related to total file loss or corruption.

This is not to say that problems do not exist: since the directory is central to the server's behavior, it is critical to take care in changes or actions that impact the directory. For specific recovery procedures, the Microsoft white papers and Knowledge Base articles should be referenced. In particular, Knowledge Base article Q196406, titled "XADM: Replication Fails After Disaster Recovery," covers much more than the title implies. It includes a further reference to KB Q15960, titled "XADM: Rebuilding the Site Folders in a Site."

Another good reference is KB Q162353, titled "XADM: Restoring an Exchange Directory," which outlines a strategy to rebuild the directory. Although this article somewhat oversimplifies the operation, it does emphasize how basic tools such as file copy and directory import/export can be used when proper backup solutions fail. When no copy of the directory is available, data in the IS can still be recovered. A call to Microsoft support or consultation with someone who has done this procedure is in order for such a situation, as there are several options and version-dependent concerns.

One of the most important steps is to quarantine the server. If new mail delivers or directory replication takes place, irreversible changes can be made.

- 37 -

Preventative Medicine

How can you ensure that your recovery goes smoothly? Practice makes perfect, but adequate documentation and good configuration control helps, too. You should maintain the following items and audit them periodically to make sure that the documentation and the real-world implementation match:

If you're using a TCP/IP environment, keep HOSTS and LMHOSTS files for all the Exchange servers, backup servers, domain controllers, and other critical systems the Exchange server system may require.

Keep documentation on backup locations and procedures, including where offsite tapes are stored and how to get to them. Include details such as contact information for all responsible persons and companies.

Export the entire directory to a CSV file every week or every night as a precaution. Make sure records of each server installation, including the service account username and password,

are available. This information should be secured, but it is also important to ensure that the current service account password is available for server recovery.

Make regular (at least weekly) registry backups. Be sure to make additional backups after hardware, operating system, or Exchange configuration changes.

Verify the backups at least once after every Exchange Server service pack, version upgrade, or other major change.

Put your databases and logs on separate physical disks. Turn off database circular logging. Consider procedural issues when a mailbox is terminated. For example, hiding a mailbox for 30 days

before deletion could prevent the need to restore the mailbox if an employee returns or a replacement staff member requires access to content.

Have a basic plan on how to react if a database becomes corrupted or a system needs to be otherwise restored. For example, do you want to take the time to do a full file-by-file tape backup of the system before you start any attempts to recover or restore? This could be of use later, when attempting to find out why the failure took place.

Have a suitable null modem cable on hand at all times, and familiarize yourself with use of the kernel debugger to trace system boot-up. This will be valuable one day when you find that your NT server won't boot due to a device driver, hardware device that failed, or corrupt system file.

Make sure you run rdisk after each configuration change. It may be best to do so weekly or daily as part of routine maintenance.

As I mentioned at the start of this chapter, when your backups are properly planned and implemented, the next challenge is to help cut the recovery time down to the minimum. You can do this by buying backup hardware sized appropriately to the task at hand; in some cases, you may want to consider splitting up large private or public IS databases by moving some of their data to another server. Chapter 14, Managing Exchange Servers, discusses some of these issues and explains what solutions and practices make sense.

Offline Defragmentation

If you are concerned that the store may have minor problems, one way to regain assurance is to run an offline defragmentation or integrity check on your recovery server. This is also a good way to establish performance baselines for a particular system.

If you do decide to defragment your store, you must make a full online backup after the defragmentation finishes. When the offline defragmentation process runs, it changes the signature on the database, making it incompatible with older log files.

- 38 -

Reducing the Risk of Mailbox Loss

What can you do to reduce the risk of losing mailbox data? Assuming you have good backups, and that you've turned on deleted item retention to guard against accidental deletions, what else can you do? There are several potential solutions, some of which are pretty creative:

Use scripts or an alternate mail client to copy the mailbox contents on a message-by-message basis. Exchange 5.5 does not support server-to-server replicas of a mailbox, but you can deliver this type of feature with some clever scripting.[1]

For mailboxes with critical data, consider offering users their own public folder for longer-term storage. Most users create various folders for storage based on projects, work areas, and other organizational methods. By leveraging the Outlook shortcut bar and the public folder Favorites category, you can make it easy for them to use a tree of individual public folders instead of mailbox folders. Part of this solution involves overcoming the literal meaning of "public folder" by establishing a good tree structure and proper permissions to make these folders as secure as the mailbox. One big advantage of this solution is that public folders can be replicated, limiting the bulk of the mailbox and simplifying backup and recovery.

Use the alternate recipient features to tie the mailbox to a second mailbox on another server or a public folder. This provides a backup copy of the mailbox contents; one trick is to create a public folder, set the permissions to default write, unhide the folder from the Global Address List, then put that public folder in as an alternate recipient.

Use Outlook's ability to clone the user's mailbox contents with an OST. With a little scripting, you can establish a way to automate opening the mailbox, selecting all folders, synchronizing them all, then copying the OST to a safe location. This way, just the OST can be restored.

Use a third-party product that supports mailbox-by-mailbox, or "brick-level," backup. These backup applications actually open each mailbox and download individual items. The restore process involves an automated fetching of the mail and uploading it back into the mailbox. These applications are slow, and they often don't work very well, but they may be worth investigating if none of the other alternatives meets your needs.

Backup restore process in detail

Backing Up Exchange Server 2003 DataThe Exchange 2003 data that you must back up depends on which components are installed on your Exchange 2003 server. This section provides detailed descriptions and procedural information about the following types of backups: • Backing up Exchange Server 2003 databases.

• Backing Up the Microsoft Exchange Site Replication Service (MSExchangeSRS).

• Backing Up the certification authority (CA).

• Backing up connector-specific information.

  

Note

 

To locate the Microsoft Information Store options that are mentioned in this section, open

Windows Backup. In the console tree, expand Microsoft Exchange Server, expand the name of the

server that you want, and then expand Microsoft Information Store.    

- 39 -

Backing Up Exchange Server 2003 DatabasesThe mailbox store and public folder store data in your Exchange 2003 databases and transaction log files are

the most important data to back up in your Exchange organization. You can use an Exchange database

backup to restore damaged mailbox or public folder stores to a functioning server that is running

Exchange 2003. You can also use Exchange database backups to restore your Exchange databases to a

different server. For more information about how to restore Exchange databases to a different server, see

"Restoring Exchange Databases to Another Server."

Backing Up Remote Exchange Server 2003 DatabasesFor the backup utility (Backup) in Windows Server 2003 to successfully back up the databases of an Exchange 2003 server, you must run it on a computer that meets at least one of the following requirements: • The Microsoft Exchange Messaging and Collaboration Services component has been successfully

installed on the computer.

• The Microsoft Exchange System Management Tools component has been successfully installed on the

computer. (This is typically referred to as an admin only Exchange installation.) For information about

installing the Exchange System Management Tools, see "Preparing to Administer your Exchange Server

2003 Environment" in the Exchange Server 2003 Administration Guide. • The computer must be manually configured to make remote backups of Exchange databases. For the

- 40 -

manual configuration steps, see Microsoft Knowledge Base article 275876, "XADM: How to Use

NTBackup from a Non-Exchange   2000 Computer XADM: How to Use NTBackup from a Non-

Exchange 2000 Computer." If your computer meets at least one of these requirements, an option named Microsoft Exchange Server

appears on the Backup tab in Backup. This option shows you all the Exchange servers in the forest that you

are connected to. If you do not see this option on the Backup tab, use the Remote Store option on the Tools

menu to manually connect to an Exchange server that is on the network. For detailed instructions, see How

to Use the Remote Store Option.

Assuming that the account that you are logged into has the necessary permissions to back up the server, you

will populate the Microsoft Exchange Server option on the Backup tab with all the servers in the Exchange organization. In this way, you can add servers from multiple Exchange organizations to the list of servers that you can back up. This is especially useful for a dedicated backup server that is used to back up databases in multiple Exchange organizations.

  

Note

 

If there is a similar option named only Microsoft Exchange above the Microsoft Exchange Server

option, you can ignore it. This option is only for backing up Exchange databases on Exchange 5.5

or earlier versions.    

If you still cannot connect to any Exchange servers or see any in the list, make sure that you have logged in

to an account that has the required permissions to back up the server. If the problem persists, see the

information in Microsoft Knowledge Base article 275676, "XADM: Troubleshooting a Remote Online

Backup of Exchange   2000 ."

Top of page

How Exchange Server 2003 Backup WorksThis section explains the online backup process step-by-step.

Normal (or Full) BackupsThe following is a step-by-step description of the normal (or full) backup process. 1. The backup agent establishes communication and initializes a backup with the MSExchangeIS service

on the target Exchange server. (In Exchange 5.5, the backup was established with the Microsoft

Exchange System Attendant (MSExchangeSA) service process.)

2. The checkpoint is frozen. New changes will still be accepted and written to the database files, but the

checkpoint will not move again until the backup ends.

3. The first log that must be copied to tape with the backup is recorded in the database header in the

Current Full Backup section. This might not be the current checkpoint log, depending on the backup

status of other databases in the storage group.

4. Copying the database files to tape begins. Page changes made to the database during backup that cannot

be reconstructed fully from the log files are not flushed to the disk during backup. (In versions of

Exchange earlier than Exchange 2000 Server Service Pack 2 (SP2), these changes are stored in a .pat

- 41 -

file that is in the same location as the database file. The .pat file is copied to tape after the database files

have finished being copied, and then it is deleted.)

  

Note

 

In Exchange 2000 Server SP2 and later, there is no patch file. Instead, a single extra page is

constructed and appended to the very end of the .edb file. This page is a mini header that

contains information about the transaction log files needed to recover this database. It

overrides the Log Required field in the database header, although it will often list the same log

range.

    

If you run Eseutil /MH on a database that has been restored from an online backup, but on which

recovery has not yet run, you will see the mini header information displayed as the Patch Current Full

Backup section.

The current Enn.log file is forced to roll over immediately after all database files have been copied to

tape. This happens regardless of how full the log is.

The reason that the log is forced to roll over is that log files cannot be backed up while they are open.

The log needs to be on tape, because it contains operations applicable to the databases that were just

backed up. Therefore, the log is closed so that it can be appended to the tape. You will never see a log

file called Enn.log in an online backup set. Only closed, numbered log files are backed up.

5. The range of logs needed to reliably recover the backup are copied to tape. These will include at least all

the logs starting from the frozen checkpoint up through the log that was just forced to close.

  

Note

 

If all databases are mounted in the storage group and all databases have been selected for

backup, this range of logs will only be from the checkpoint log to the highest available

numbered log. However, if some databases are dismounted, or not all the databases are being

backed up, the range of logs copied to tape might start before the current checkpoint.

Exchange ensures that all logs needed for replay into the backed up databases will be present

on the tape.

    

6. Log files that no database in the storage group needs to roll forward beyond the backup logs are

truncated (deleted from disk). The headers of all the databases in a storage group keep track of the last

backup time for each database, and also which logs were required. If any database in a storage group is

dismounted, its header will not be read and Exchange will make no calculations about which log files

can be safely deleted.

7. There are two factors that affect which log files will be truncated after a backup:

• Databases can be backed up individually.

• Not all databases in the storage group may be mounted at the time the backup occurs.

If you back up some databases but not others in a storage group, only the transaction logs not needed

- 42 -

by the database least recently backed up will be truncated. This means that if you never back up one

particular database in a storage group, no transaction logs will ever be deleted. If you have two

databases in a storage group, and you back up one of them on Tuesday and the other on Thursday, the

Thursday backup will truncate logs only up to Tuesday. If you then back up the Tuesday database on

Friday, the logs from Thursday will be truncated.

   Note

 If any database in a storage group is dismounted at the time of backup, no log files will be

truncated.     

8. The Previous Full Backup section of the database header is updated to reflect the time and log range of

the backup that just completed.

Copy (or Full Copy) BackupsA copy backup is the same as a normal backup, except that the last two steps of truncating the logs and

updating the Previous Full Backup section of the header are not done.

Incremental BackupsThe following is a step-by-step description of the incremental backup process: 1. The backup agent establishes communication and initializes a backup with the MSExchangeIS service

on the target Exchange server. (In Exchange 5.5, the backup was established with the MSExchangeSA

service process.)

2. The checkpoint is frozen. New changes will still be accepted and written into the database files, but the

checkpoint will not move again till the backup ends.

3. The current Enn.log file is forced to roll over regardless of how full the log is. The reason that the log is

forced to roll over is that log files cannot be backed up while they are open. Therefore, the log is closed

so it can be appended to the tape. You will never see a log file named Enn.log in an online backup set.

Only closed, numbered log files are backed up.

4. When you perform a normal or copy backup, the log file is rolled over near the end of the backup, after

the databases have all been copied to tape. For an incremental backup, the rollover happens at the very

beginning.

5. All existing numbered log files are copied to tape.

6. Log files that no database in the storage group needs to roll forward are truncated (deleted from the

disk).

7. If any database in a storage group is dismounted at the time of backup, no log files will be truncated.

8. The Current Incremental Backup section of the database header is updated to reflect the time and log

range of the backup that just completed.

Differential BackupsA differential backup is similar to an incremental backup, except that the last two steps of truncating the logs and updating the Current Incremental Backup section of the header are not done.

- 43 -

  

Note

 

One of the most important daily tasks of an Exchange administrator is to examine the application

event log and verify that backups have completed successfully. Microsoft Product Support Services

frequently receives calls from customers who are experiencing problems because their backups

have been failing for weeks, and they did not notice it. Failed backups are not the only problem that

will arise if you do not verify the success of your backups. A backup job that never completes

leaves the checkpoint frozen. If a server crashes, the transaction log replay time after the crash can

be extended up to several hours. In Exchange 2003, if the checkpoint is more than 1,000 log files

behind, Exchange will automatically dismount the Exchange store. In previous versions of

Exchange, the dismount will occur at approximately 256 logs.

    

The Exchange 2003 backup process

How to Use the Remote Store Option in BackupThis topic explains how to use the Remote Store option in Backup to connect to a remote Exchange server

on your network.

Procedure

To use the Remote Store option1. In Backup, make sure that you are on the Backup tab.

2. Click Tools.

3. Click Remote Store.

4. Type the name or IP address of an Exchange server in the organization that you want to back up.

5. Click OK.

How to Back Up Exchange Server 2003 DatabasesThis procedure explains how to backup Exchange Server 2003 Databases.

Procedure

To back up Exchange 2003 databases1. Start Backup in Advanced Mode.

For detailed instructions, see the following procedures:

• How to Start the Backup Utility

• How to Switch Backup to Advanced Mode

- 44 -

2. Click the Backup tab.

3. On the Backup tab, in the console tree, expand Microsoft Exchange Server, and then expand the server

that contains the Exchange databases that you want to back up.

If you do not see the Exchange server whose databases you want to back up in the list of servers on the

Backup tab, use the Remote Store option on the Tools menu to connect to a server in the organization

that you want to back up. For more information about using the Remote Store option, see How to Use

the Remote Store Option in Backup.

4. To back up the Exchange databases, perform one of the following steps:

• If you want to back up all the storage groups on the server, select the check box next to Microsoft

Information Store

• If you want to back up specific storage groups in their entirety, expand Microsoft Information Store,

and then select the check boxes next to the storage groups that you want to back up.

• If you want to back up specific mailbox stores and public folder stores in a storage group, expand

Microsoft Information Store, select the storage group that contains the databases you want to back up.

(Select the label, such as "First Storage Group," in addition to the check box. For more information,

see the following figure.) Then, in the details pane, select the check boxes next to the databases that

you want to back up.

- 45 -

Select the specific mailbox stores to back up

5. Click Browse to select the location for your backup. For more information about how to select the media

for your backup, see Selecting the Destination for a Backup.

6. Click Start Backup.

7. In Backup Job Information, in the Backup description text box, type a backup description, set the

appropriate options, and then click Start Backup. For more information about the options for the backup,

see Selecting Options for a Backup.

8. After the backup is completed, verify that it was successful. For more information about how to verify

the success of a backup, see Checking the Success of a Completed Backup.

Backing Up the Microsoft Exchange Site Replication Service (MSExchangeSRS)You will only have to back up the Microsoft Exchange Site Replication Service (MSExchangeSRS) if you

have coexistence between Exchange 5.5 and Exchange 2000 or later servers. Use Backup to back up the

MSExchangeSRS service on the server that is running it. By default, the server that is running the

MSExchangeSRS service is the first Exchange 2000 or later server that was installed into an Exchange 5.5

site, although you can create new instances of the MSExchangeSRS service to distribute the replication

load. Use Exchange System Manager to determine which Exchange server is running the MSExchangeSRS

service in your site. For detailed instructions, see How to Determine Which Exchange Server Is Running the

MSExchange SRS Service.

  

Note

 

You can also back up the MSExchangeSRS service database (Srs.edb file) manually. The Srs.edb

file is located in the SRSData folder under the folder where you installed the first Exchange 2000

Server or later server. You can also rebuild the SRS database after a disaster by following the

instructions in Microsoft Knowledge Base article 822453, "How to Rebuild a Site Replication

Service in Exchange   2003 When You Do Not Have a Backup of the SRS Database ."

    

- 46 -

The Microsoft Exchange Site Replication Service (MSExchangeSRS) Database

How to Determine Which Exchange Server Is Running the MSExchange SRS serviceThis procedure explains how to determine which Exchange server is running Site Replication Service

(SRS).

Procedure

To determine which Exchange server is running the MSExchangeSRS service

1. Start Exchange System Manager. (Click Start, point to Programs, point to Microsoft Exchange, and then

select System Manager.)

2. In Exchange System Manager, expand Tools, and then expand Site Replication Services to locate the server

that is running the MSExchangeSRS service. If an Exchange 5.5 site exists in your organization, under Site

Replication Services, you will see at least one entry named Microsoft Exchange Site Replication Service

(computer name), where (computer name) is the name of the server that is running the MSExchangeSRS

service.

- 47 -

How to Back Up the MSExchangeSRS Service DatabaseThis topic explains how to back up the Site Replication Service (SRS) database.

Procedure

To back up the MSExchangeSRS service database

1. On the server that is running the MSExchangeSRS service, start the Services MMC snap-in. (Click

Start, point to Programs, point to Administrative Tools, and then select Services.)

2. In Services, double-click Microsoft Exchange Site Replication Service.

3. In Microsoft Exchange Site Replication Service Properties, in the Startup Type list, select Automatic.

If Service status is currently Stopped, click Start to start the MSExchangeSRS service. After the

service starts, close the Services MMC snap-in.

4. On any computer in your Exchange organization, start Backup in Advanced Mode.

For detailed instructions, see the following procedures:

• How to Start the Backup Utility

• How to Switch Backup to Advanced Mode

5. In Backup, click the Backup tab.

6. On the Backup tab, in the console tree, expand Microsoft Exchange Server, expand the server that is

running the MSExchangeSRS service, and then select the check box next to Microsoft Site Replication

Service

- 48 -

Backing up the Microsoft Exchange Site Replication Service (MSExchangeSRS)

7. Click Browse to select the media for your backup.

8. Click Start Backup.

9. In Backup Job Information, in the Backup description text box, type a description of the backup, set the

appropriate options, and then click Start Backup. For more information about how to set the options for

the backup, see Selecting Options for a Backup.

10. After the backup is completed, verify that it was successful. For more information about how to verify

the success of a backup, see Checking the Success of a Completed Backup.

Backing Up the Certification Authority (CA)If you have to recover a server that is running Certificate Services, you must first back up the computer that

is the certification authority (CA). Although you can configure a computer to be both the CA and a server

that is running Exchange2003, it is better to run Certificate Services on a separate server to make sure that

you meet your standards for reliability and performance.

It is recommended that you back up the CA by creating a full computer backup set of your server that is

running Certificate Services. If you cannot create a full computer backup set of your server, you can also

back up the CA by creating a Windows backup set on the server that is running Certificate Services. (The

System State data part of a Windows backup set includes the Certificate Services database.) For more

- 49 -

information about how to perform full computer and System State backups, see "Creating Full Computer

Backup Sets" and "Creating Windows Backup Sets."

You can also use the Certification Authority Backup Wizard to back up keys, certificates, and the

certificates database. You access this wizard from the Certification Authority MMC snap-in. If you use the

Certification Authority MMC snap-in to back up the CA, make sure to back up the Internet Information

Services (IIS) metabase also. You back up the IIS metabase file when you create a Windows backup set.

(The System State data part of a Windows backup set includes the IIS metabase.) You can also use the IIS

snap-in to back up the IIS metabase independently. For more information, see the following resources: • "Backing up and restoring a certification authority" in the Windows Server 2003, Standard Edition Help.• Windows Server   2003 PKI Operations Guide .• "Backing Up and Restoring the Metabase" in the IIS 6.0 online product documentation.To use the Backup or Restore Wizard in the Certification Authority MMC snap-in, you must be a Backup

Operator or a Certification Authority Administrator, or you must have local administrator permissions on

the CA. The Backup or Restore Wizard requires you to supply a password when you back up public keys,

private keys, and CA certificates. You must have this password to restore data from the backup.

For more information about using CA and Windows Server 2003 public key infrastructure (PKI) with

Exchange 2003, see "Implementing an Exchange 2003-Based Message Security System in a Test

Environment" in the Exchange Server 2003 Message Security Guide.

Backing Up Connector-Specific InformationExchange servers that include connectors to other messaging systems, such as Novell GroupWise or Lotus

cc:Mail, contain connector-specific configuration data. Connector-specific configuration data is stored in

the registry of the computer where the connector is installed, and also in Active Directory. If your disaster

recovery strategy includes restoring either a Windows backup set or a full computer backup set, the

connector-specific data is automatically restored to your server when you run the Exchange Setup program

in disaster recovery mode. However, for specific e-mail connectors, you must manually back up and restore

additional files, such as the contents of the CONNDATA directory and subdirectories.

For more information about how to back up and restore connectors, see Microsoft Knowledge Base article

328835, "XADM: How to Back Up and Restore Connectors on Exchange   2000 ." This information is

relevant to Exchange Server 2003.

Restoring Exchange Mailbox or Public Folder StoresWhen you use Backup to restore Exchange databases, application programming interface (API) calls are made to the Exchange Extensible Storage Engine (ESE) to restore Exchange database files and their associated log files. You can use Exchange database backups to restore one or more damaged mailbox or public folder stores. In a disaster recovery scenario that involves rebuilding a server, use Backup to restore your Exchange databases after you run Exchange Setup and any Exchange service packs in Disaster Recovery mode.

  

Note

  Installing Exchange (and any service packs that were running on your server before the disaster) in     

- 50 -

Disaster Recovery mode prevents the Setup program from mounting the databases after the Setup

program is completed. You can then correctly restore and mount your Exchange database backups

at the end of the setup process. Before you restart your server, as prompted by Exchange Setup,

make sure that the log files have completed replaying.This section contains the following information about restoring Exchange databases: • Overview of the database restore process.

• Recovering an Exchange database.

• Resolving Exchange database restore problems.

• Restoring Exchange databases to another server.

Overview of the Database Restore ProcessWhen a restore operation begins, Backup informs the ESE that the process has begun, causing ESE to enter

restore mode. The database (made up of a pair of files: an .edb file and an .stm file ) is then copied from the

backup media directly to the database target path. The associated log files are copied to a temporary folder,

and a separate instance of ESE is started to replay the transaction logs from their temporary location into the

restored database.

The restore process creates the Restore.env file, which keeps track of the storage group that the database

belongs to, the paths of the database files when they were backed up, the path to the database when they

were restored, the range of log files that were restored, and other pertinent data.

You must restore a full backup set (either a normal or copy backup) before you can restore a differential or

incremental backup set. This is because restoring a full backup set creates the Restore.env file. Restoring a

differential or incremental backup set only updates the Restore.env file; it does not create one. If the

Restore.env file does not exist, the differential or incremental updates cannot restore.

Always use different temporary folders for each full backup set that you are restoring. For example, if you

were to restore two normal backups to the same temporary folder the second Restore.env file that would be

created would overwrite the first Restore.env file. Therefore, always specify a different temporary folder for

each normal or copy backup set that you are restoring.

However, when you restore an incremental or differential backup, specify the same temporary folder you

used for the full backup that the incremental or differential backup belongs with, so that they are paired with

the correct Restore.env file.

After the database files are copied back to their original locations and the Restore.env and transaction log

files have been copied to the temporary folder, ESE initiates a hard recovery to replay log files into the

database. This brings the database up-to-date with the time that it was lost if all the log files since the

backup was taken are available. First, Restore.env is used to determine which transaction logs will be

played from the temporary folder. Then, if it is possible, additional transaction logs from the target storage

group are also replayed.

Following hard recovery, the temporary instance of ESE is stopped. If you select the Mount Database After

Restore check box in Backup, the newly restored database is automatically mounted in the target storage

group.

- 51 -

The following figure illustrates the Exchange restore process.

How to Dismount Mailbox and Public Folder StoresThis topic explains how to dismount mailbox and public folder stores.

Before You BeginBefore you perform the procedure in this topic, consider the following:

When mailboxes and public folders are dismounted, they are inaccessible to users and applications. Because

Exchange supports multiple storage groups and multiple mailbox and public folder stores, you should

dismount only the databases necessary.

Top of page

- 52 -

Procedure

To dismount the mailbox and public folder stores that you are restoring

1. Open Exchange System Manager. Click Start, point to Programs, point to Microsoft Exchange, and then

click System Manager.

2. In Exchange System Manager, navigate to the database that you want to dismount, right-click the

database, and then click Dismount Store.

How to Configure the Exchange Databases so That the Restore Process Overwrites ThemThis topic explains how to configure Exchange databases so that they will be overwritten during a restore

using Backup.

Before You BeginBefore you perform the procedure in this topic, be aware that you should not use this option unless you are

certain that you must overwrite the database.

Top of page

- 53 -

Procedure

To configure the Exchange databases so that the restore process overwrites them

1. Open Exchange System Manager. Click Start, point to Programs, point to Microsoft Exchange, and then

click System Manager.

2. In Exchange System Manager, navigate to the database that you want to restore, right-click it, and then

click Properties.

Mailbox store properties

3. On the Database tab, select the This database can be overwritten by a restore check box.

- 54 -

Enabling the database to be overwritten during a restore

How to Determine the Database and Log File Locations of the Files You Are RestoringThis topic explains how to determine the database and log file locations of files you are restoring.

Procedure

To determine the database and log file locations of the files you are restoring

1. Open Exchange System Manager. Click Start, point to Programs, point to Microsoft Exchange, and then

click System Manager.

2. In Exchange System Manager, navigate to the storage group that contains the database that you want to

move or copy, right-click the storage group, and then click Properties.

- 55 -

Storage group properties

3. On the General tab, note the paths in the Transaction log location and System path location boxes, and

then click OK. Record these paths for each storage group that contains a database that you want to move

or copy.

The Transaction log location is the path where log files are written for the whole storage group. These

log files record every change made to a database in that storage group. The System path location is

where other files critical to the storage group are kept, such as the storage group's checkpoint file.

- 56 -

Log file locations and system path locations

4. In Exchange System Manager, right-click the database that you want to move or copy, and then click

Properties.

5. On the Database tab, note the paths of both the Exchange database file and the Exchange streaming

database file, and then close the dialog box.

- 57 -

Exchange database file locations

How to Copy or Move the Existing Versions of the Database Files You Are RestoringThis topic explains how to copy or move a database file that you are trying to restore.

Before You BeginBefore you perform the procedure in this topic, consider the following:

Moving database files from their original location to a different folder on the same logical disk is almost

instantaneous, as the only data that must be written to disk is an update to the NTFS Master File Table

(MFT). Moving the files to a different logical disk (even if both drives share the same physical disk) or

making a copy of them in any location takes much longer because each database file must be rewritten to

the new location. Moving or copying the database files to a different location over the network takes even

more time, and can use a lot of your network bandwidth. This is just one reason why making full use of the

4 storage group and 20 database capabilities of Exchange Server 2003 (more databases of smaller sizes) is

actually more manageable and can decrease the time that you spend on backup and restore-related tasks.

Top of page

- 58 -

Procedure

To copy or move the existing versions of the database files you are restoring

1. Make sure that the databases that you are moving or making a copy of are dismounted. For more

information about how to dismount databases, see "Dismounting the Exchange Databases That You Are

Restoring" in Recovering an Exchange Database.

2. Make sure the databases you are copying have been shut down in a clean state. Use Eseutil /mh to dump

the header information for the database. Look for State: Clean Shutdown in the dumped information.

If the database is in a dirty state, try to restore the database to a clean state before you repair it. This task

entails playing any required transaction logs into the database. The Log Required field in the dump file

from Eseutil /mh will show you the logs that are required to restore the database to a clean state. The

logs shown in this field are shown in decimal, you must convert these values to hexadecimal to find the

appropriate transaction log files.

In many cases, remounting the database causes soft recovery to start so that the database can be shut

down in a clean state.

3. Create a folder to store the database files that you want to move or copy. You can create the folder either

on a local hard disk or on your network. Make sure the destination location has sufficient room before

you start the copy process. Remember that moving the file to another location on the same logical drive

is the fastest way to preserve the damaged database.

Copying database files before the restore process

- 59 -

How to Ensure that Storage Group and Database Display Names Match the Names of the Files You Are RestoringThis topic explains how to ensure that storage group and database display names match the names of the

files you are restoring.

Procedure

To ensure that storage group and database display names match the names of the files you are restoring

1. In your backup or restore device, insert the backup media that contains the backups that you want to restore.

2. Start Backup in Advanced Mode: Click Start, click Run, type ntbackup, and click OK. Then click the Advanced

Mode link on the Welcome screen.

3. Click the Restore and Manage Media tab, and then in the console tree, click the backup media that you want to

restore.

4. If the correct media does not display in the console tree, you might have to rebuild the catalog. For more

information about how to rebuild the catalog, see "Rebuilding a Catalog for a Restore" in Using Backup to

Restore Your Data.

5. Expand the tree structure of the media so that the name of each Exchange database that you are restoring

appears.

6. Record the names of the storage groups and each mailbox store or public folder store that you want to restore.

- 60 -

Storage group and mailbox store names in Backup

7. Open Exchange System Manager. Click Start, point to Programs, point to Microsoft Exchange, and then click

System Manager.

8. In Exchange System Manager, navigate to the server that contains the database that you want to restore.

9. In the console tree and details pane, note the names of the storage group and databases. Compare these with the

storage group and database names on your backup media. The names in Exchange System Manager must match

those on the backup media or the restore process will fail.

- 61 -

Storage group and mailbox store names in Exchange System Manager

How to Rename a Storage Group or DatabaseThis topic explains how to rename a storage group or database.

Procedure

To rename a storage group or database1. In Exchange System Manager, right-click the storage group or database that you want to rename.

2. Click Rename.

- 62 -

Renaming a database

3. Type the name of the database or storage group that you are restoring. Make sure that the name you type

exactly matches the name on the backup media, and then press ENTER.

How to Create a Storage GroupThis topic explains how to create a storage group.

Procedure

To create a storage group1. In Exchange System Manager, right-click the server where you want to create the storage group.

2. Click New.

3. Click Storage Group.

- 63 -

Creating a new storage group in Exchange System Manager

4. On the General tab of the Properties dialog box, type the name exactly as it appears on your backup

media.

5. Click OK.

How to Create a Mailbox or Public Folder StoreThis topic explains how to create a mailbox or public folder store.

Procedure

To create a mailbox or public folder store

1. In Exchange System Manager right-click the storage group where you want to create the database.

   Note

 The structure that you see in the user interface (UI) should mirror the original structure on

your backup media.     

2. Point to New.

3. Click the type of database that you are restoring.

- 64 -

Creating a new mailbox store in Exchange System Manager

4. In the Name field, type the name of the mailbox or public folder store exactly as it appears on your

backup media.

5. Click OK.

6. When prompted to mount the store, click No.

How to Start the Microsoft Exchange Information Store Service (MSExchangeIS)This topic explains how to start the Microsoft Exchange Information Store service.

Procedure

To start the Microsoft Exchange Information Store service (MSExchangeIS)

1. Start the Services snap-in: Click Start, click Run, and then type services.msc.

2. Locate the Microsoft Exchange Information Store service (MSExchangeIS) and make sure that the Status

column displays Started.

- 65 -

Locating the Microsoft Exchange Information Store service (MSExchangeIS)

3. If you have to start the service, right-click Microsoft Exchange Information Store, and then click Start.

How to Select the Backup Files to Restore from Your Backup MediaThis topic explains how to select the backup files to restore from your backup media.

Procedure

To select the backup files to restore from your backup media

1. Start Backup in Advanced Mode.

For detailed information, see the following procedures:

• How to Start the Backup Utility

- 66 -

• How to Switch Backup to Advanced Mode

2. Click the Restore and Manage Media tab.

3. In the console tree, click the backup media that you want to restore. If the correct media does not display in the

console tree, you might have to rebuild the catalog. For more information about how to rebuild the catalog, see

"Rebuilding a Catalog for a Restore" in Using Backup to Restore Your Data.

4. Click the check boxes next to the storage groups or databases that you want to restore.

Selecting the storage groups or databases that you want to restore

For example, if you want to restore a whole storage group, select the check box next to the storage group that you

want to restore. If you want to restore just one database in a storage group, select only the check box next to the

database you want to restore.

How to Restore Selected FilesThis topic explains how to use Backup to restore selected files.

Procedure

To restore selected files1. Start Backup in Advanced Mode.

For detailed instructions, see the following procedures:

• How to Start the Backup Utility

• How to Switch Backup to Advanced Mode

- 67 -

2. On the Restore and Manage Media tab, in the Restore files to list, select the location to where you want

the files restored. By default, the location specified is Original location.

3. Click Start Restore.

4. In the Restore To box, specify the Exchange server that you want the databases restored to.

The Restoring Database Store dialog box

5. In the Temporary location for log and patch files box, specify a directory to store log files during the

restore process.

6. To perform the restore, you must have sufficient space in the directory to store the files. The disk space

requirement is about 10 MB more than the size of the transaction log files that are being restored.

  

Important

 The directory that you specify in the Temporary location for log and patch files box must not

contain the original database or log files or the restore might fail.     

  

Note

 

It is recommended that you create an empty temporary folder for this procedure. Because

transaction logs are written per storage group, and not per database, using a temporary folder

ensures that transaction log replay is isolated and will not interfere with undamaged

databases that are still running in a storage group during recovery.

    

7. Select the Last Restore Set check box only if this is the last backup set that you have to restore before

you remount your databases.

8. If you are restoring a backup that is part of a series of normal, differential, or incremental backups,

leave this check box cleared until you restore the final incremental or differential backup in the series.

The restore process does not initiate hard recovery to play back the log files to the database that is

being restored until this box is selected.

9. If you do not select this check box when you restore the last backup set, you can use Eseutil to

- 68 -

manually replay the transaction logs. For a step-by-step explanation of this process, see, "Replay the

Transaction Log Files Using Eseutil /CC (Optional)" in Recovering an Exchange Database. For more

information about hard recovery and transaction log replay, see Microsoft Knowledge Base article

232938, "The 'Last Backup Set' Check Box and Hard Recovery in Exchange."

10. Only select the Mount Database After Restore check box if this is the last backup set that you plan to

restore, and you are sure that you are ready to mount the databases. It is recommended that you do not

select this check box.

11. Click OK when you are ready to start the restore process.

12. If Backup prompts you for the location of the backup file to use in the restore, select the correct backup

name, and then click OK.

How to Run Eseutil /ccThis topic explains how to run Eseutil /cc.

Procedure

To run Eseutil /cc1. After the last backup has been restored and you want to initiate a hard recovery, open a Command

Prompt window: Click Start, click Run, type cmd, and then click OK.

2. Find the folder where the Restore.env file is located.

3. Type eseutil /cc. Do not use any other parameters.

4. When the transaction logs finish replaying successfully, the message, "Operation completed

successfully" appears.

Eseutil performs the same function as the Last Restore Set check box. Use all other Eseutil /cc switches

with extreme caution.

- 69 -

How to Mount an Exchange StoreThis topic explains how to mount an Exchange store.

Procedure

To mount an Exchange Store (database)

1. Open Exchange System Manager. Click Start, point to Programs, point to Microsoft Exchange, and then

click System Manager.

2. In Exchange System Manager, navigate to the database that you want to mount, right-click the database,

and then click Mount Store.

- 70 -

Resolving Exchange Database Restore ProblemsIf the restore process fails, troubleshoot the problem as soon as possible. Sometimes, performing the restore

process again corrects the problem. Other times, you might have to repair one or more Exchange databases.

For information about how to repair Exchange databases, see "Repairing Exchange Databases."

For general information about how to search and troubleshoot restore errors, see "Checking the Success of a

Completed Restore Job."

If you experience problems with the databases that you tried to restore, check the application log for errors,

and then search the Microsoft Knowledge Base for specific solutions to those errors.

Troubleshooting Failed Restore ProcessesIf the restore process is not completed successfully, search for errors in the Backup status window, the

Backup restore log, and the logs in Event Viewer. These errors might help you determine the cause of the

failure.

Because Exchange relies heavily on your Windows Server 2003 operating system, look for both Exchange-

specific errors in the event logs and errors for non-Exchange components that Exchange relies on. Also

consider hardware errors. For example, a bad page file on a hard disk drive can prevent Exchange from

moving forward writing to the database.

After you have identified errors in the event log that you suspect might be the cause of the failed restore,

search the Microsoft Knowledge Base for those specific errors.

  

Note

- 71 -

 If one or more Exchange database or log files are damaged or missing, the application log might

include the following error: Error -1216 (JET_errAttachedDatabaseMismatch)     

  

Note

 

For information about how to troubleshoot database restore issues that include the 1216 error, see

Microsoft Knowledge Base article 296843, "XADM: Error -1216 Recovering an Exchange   2000

Database."     

If you cannot resolve the problems that are preventing you from restoring your Exchange databases, contact

Microsoft Help and Support.

Restoring Exchange Databases to Another ServerIf you experience problems when you restore Exchange databases to the original server, or to the server to

which you have restored the original server's configuration, you can restore Exchange databases to a

different Exchange server. However, restore Exchange databases to a different server only as a last resort.

The Exchange server to which you restore Exchange databases must meet specific criteria. For example,

Exchange service packs and hotfixes that you install on the server must match those of the server whose

Exchange databases you backed up. For more information about how to restore Exchange databases to a

different server, see Exchange   2000 Server Database Recovery .

How Exchange Online Backups Work in Exchange Server 2003Microsoft® Exchange Server databases can be backed up while users are online, even as new data is written

to them. This capability exists because of Exchange's transaction logging mechanism (as discussed in

Appendix B, "Exchange Transaction Logging").

As you begin an online backup, the backup program streams the database file to the backup medium.

Changes to the database continue, even to parts of the database that have already been backed up. These

missed changes will later be reconstructed from transaction log files.After the database file has been backed up, Exchange copies at least one transaction log (and usually several of them) to the backup set. These are the transaction logs generated from the time the backup starts until just after it finishes.

  

Note

 

Prior to Exchange2000 Service Pack2, a patch file (database_name.pat) was created during backup

and was saved with the backup set. The patch file was needed to reconstruct a small subset of

possible database changes that could not be preserved in the transaction logs. In newer versions,

Exchange no longer saves the patch data to a separate file, but inserts it at the end of the database

file. For more information about how patch data is used when restoring an online backup, see

Transaction Log File Replay: Soft Recovery and Hard Recovery in Exchange Server 2003.

    

When you restore an online backup, you always replay at least one transaction log into it. If you examine

the header of a restored database before transaction logs are played into it, you see that it reads "Dirty

- 72 -

Shutdown." Restoring a database from online backup and then starting it is similar to starting a database

after a system crash.

Replaying logs after an unexpected database stop is called soft recovery. Replaying logs after restoring an

online backup is called hard recovery. The most important difference between the two kinds of recovery is

the application of the extra patch data during hard recovery.

Because Exchange replays transaction logs during recovery of every online backup, it is possible to add

more transaction logs to be replayed than were originally on the backup tape. If E0000007.log is on the

backup tape, and you have log E0000008.log and others going forward, you can continue log file replay

after restoring the online backup as long as there are available logs in an unbroken series. Even if your

backup is several days old, you can bring it completely up-to-date as long as you have all the transaction

logs generated since the backup was made.Suppose that you made an online backup of the database on Monday. On Wednesday, the database files were destroyed by a hard disk failure, requiring you to restore Monday's backup. If the transaction log files for the last two days still exist, it is possible to restore Monday's backup and recover all data from Tuesday and Wednesday by retrieving the data from the transaction log files.

  

Note

 

It is an Exchange best practice to keep transaction log files on a dedicated disk separate from the

database files. Not only does this improve database performance, but it also provides fault

tolerance in case the database disk is destroyed.    

There are four kinds of online backups of an Exchange database: normal, copy, incremental, and differential. You may be familiar with these terms; however, the meaning that Exchange assigns to each of them differs from conventional usage: • Normal   The backup program backs up the database files (.edb and .stm), patch data, and at least one log

file. After backup is complete, the backup program deletes all log files prior to the checkpoint at the time

that backup began; this prevents log files from accumulating until they use up all available drive space.

Note that in current versions, Exchange no longer keeps patch information in a separate file, but appends

a patch header page to the end of the database file when the backup process is complete.• Copy   The same as a normal backup, except that the backup program does not delete old log files, and

does not update the database header to indicate that a backup has taken place. • Incremental   The backup program only backs up log files, not database files. Log files since the last

normal backup are copied to the backup medium and are then purged from disk. To restore an incremental

backup, you must also restore an earlier normal or copy backup because the incremental backup does not

contain the database files. Transaction logs from the incremental backup can be replayed after the logs

from the full backup are replayed, assuming that there is an unbroken sequence of logs between the two

backups.• Differential   The same as an incremental backup, except that the backup program does not delete old log

files from disk.In terms of the files actually placed on the backup medium, there is no difference between a normal and

copy backup, and no difference between an incremental and differential backup.

- 73 -

Restoring an Online BackupExchange 5.5 has only one storage group. It holds only two databases, a mailbox database and a public

folder database. Starting the Information Store mounts both databases and stopping the Information Store

disconnects both of them. Beginning with Exchange 2000, however, a server can hold up to 20 Exchange

store databases spread over four storage groups. Each database is capable of being independently mounted

and dismounted. This flexibility has important ramifications for restoring online backups.

Recall that all the databases in a storage group share the same set of log files, and that restoring an online

backup requires replaying some log files. With Exchange 2003, you can now restore one database in a

storage group while others are running. This capability means that there are several scenarios in which

restoration of log files could cause hard recovery failure or interfere with the operation of other databases in

the storage group. Further, it is possible that multiple simultaneous restore operations could occur at once.

To prevent various interaction problems, log files from online backups are now restored to a temporary

folder, along with a Restore.env file that controls the hard recovery process. Restore.env is not in plain text

format, but its contents can be viewed with the command Eseutil /cm.

  

Note

 

Exchange5.5 administrators may be familiar with the Restore in Progress registry key, which

serves much the same purpose for Exchange 5.5 that Restore.env serves for newer versions of

Exchange. There is no Restore in Progress registry setting for Exchange 2000 and later versions.     

If you are restoring multiple online backups (for example, a single full backup and several incremental

backups), you do not want hard recovery to begin before all backups have been restored. You have only one

opportunity to replay log files into a restored database; therefore, hard recovery must be postponed until all

necessary log files are in place.

If you are using Backup to restore an online backup, you indicate that you are ready to begin hard recovery

by selecting the Last Backup Set check box before restoring your final backup set. (Other backup

applications may implement this differently.) If you do not select the Last Backup Set check box when

restoring the last backup, you can still complete hard recovery manually with the Eseutil /cc command. You

should run this command from the folder where Restore.env exists.

After hard recovery finishes processing log files in the temp folder, other transaction logs in the storage

group's normal transaction log folder can be replayed as long as they continue in an unbroken sequence with

the logs in the temp folder.

Restoring a single Exchange online backup set is a straightforward operation. You need only pick a target

server, pick a temporary location on the server for the restored log files, and set hard recovery to run

automatically after restore is complete. However, if you are restoring multiple backup sets, you should

understand how log file replay works, and how to verify that you have actually restored all needed files.

Transaction Log File Replay: Soft Recovery and Hard Recovery in Exchange Server 2003 describes the log

file replay and recovery process in more detail, and Cross-Matching Exchange Databases and Log Files in

- 74 -

Exchange Server 2003 explains how to check a set of log files to make sure they belong together and are

complete.

How Recovery Storage Groups Work in Exchange Server 2003Before you begin using recovery storage groups, you should have a general understanding of how they work

and what their limitations are.

When You Can Use a Recovery Storage GroupRecovery storage groups were designed to aid in database recovery under the following conditions: • The logical information about the storage group and its mailboxes remains intact and unchanged in

Microsoft® Active Directory® directory service.

• In addition, you need to recover a single mailbox, a single database, or a group of databases in a single storage group. Recovery scenarios include: • Recovering deleted items that a user mistakenly purged from their mailbox.

• Recovering or repairing an alternate copy of a database while another copy remains in production

(typically, with the goal of merging data between the two databases using the Mailbox Merge Wizard

(ExMerge) tool.

• Recovering a database on a server other than the original server for that database. If needed, you can

then merge the recovered data back to the original server (although performance would be slower than

if the recovery storage group and the original database were on the same server).Use the following guidelines for working with recovery storage groups: • The database you are recovering must be on a server that is a member of the same administrative group as

the server running the recovery storage group (if the database is from a different administrative group, the

restore operation will not succeed).

• If you want to recover more than one database at a time, you can add multiple databases to the recovery

storage group as long as they are all from the same original storage group (once you have added the first

database, you can only add databases from that database's storage group). Otherwise, you must use more

than one recovery storage group (on more than one server).

• The database you are recovering is from a server running a version of Exchange that is between Microsoft

Exchange Server 2000 Service Pack (SP) 3 and the version of Exchange running on the recovery storage

group server.

All databases restored to the recovery storage group will be upgraded to the database version currently

running on the recovery storage group server. This means that you cannot copy databases back to their

original servers without first upgrading the original servers to the same version of Exchange (major

version and service pack revision). Nonetheless, you can use ExMerge to move data between servers,

regardless of version mismatches.

In addition, databases from versions of Exchange later than the version on the recovery storage group

server cannot be restored to the recovery storage group.

Top of page

When You Should Not Use a Recovery Storage GroupRecovery storage groups are not appropriate under the following conditions:

- 75 -

• You need to recover public folder content. Only mailbox recovery operations are supported. Public folder

recovery procedures remain the same for Exchange Server 2003 as they are for Exchange 2000.

• You need to restore entire servers.

• You need to restore databases from multiple storage groups.

• You are in an emergency situation that requires changing or rebuilding your Active Directory topology.In addition, you cannot use a recovery storage group if the Exchange configuration data stored in Active Directory has changed since the database was last backed up. The functionality of a recovery storage group depends on specific mailbox and mailbox database attributes in Active Directory. (Later sections of this section describe these attributes in greater detail). Because of this limitation, you cannot use recovery storage groups in the following circumstances: • You need to recover mailboxes that have been deleted or purged from the system, or moved to other

databases or servers.

Re-creating a deleted mailbox is not useful in this situation because Exchange does not recognize the re-

created mailbox as the same mailbox. When you create a mailbox for a user, it has a unique identifier. If

you delete and then re-create a mailbox, the mailbox will have a new identifier that is different from the

previous identifier. For more information about these identifiers, see How the Recovery Database Links

Back to the Original Database.

  

Note

 

You can use recovery storage groups in a limited fashion when you need to recover deleted or

purged mailboxes. For more information about this situation, see Recovering Deleted Items or

Purged Mailboxes Using a Recovery Storage Group in Exchange Server 2003.    

• The database holding the mailboxes that you are trying to recover was moved to a different storage group

after the last backup or has since been deleted.

Re-creating a deleted database will not resolve this situation for reasons similar to those that apply to a re-

created mailbox. Each database also has a unique identifier, and in Exchange, a re-created database is a

new database with no relation to the previous database.

How to Create the Recovery Storage GroupThis topic explains how to create the recovery storage group to aid in database recovery. For more

information, see How to Set Up a Recovery Storage Group.

Procedure

To create a recovery storage group1. In Exchange System Manager, right-click the server on which you intend to place the recovery storage

group, point to New, and click Recovery Storage Group.

2. Name the recovery storage group and set the transaction log location and the system path location (see

the following figure). Remember that if the server does not already have a storage group with a name

identical to the name of the storage group of the database to be restored, you must give that name to the

- 76 -

recovery storage group.

How to Add Databases to Be RestoredThis topic explains how to add the databases to be restored to aid in database recovery. For more

information, see How to Set Up a Recovery Storage Group.

Procedure

To add a database to a recovery storage group

1. In Exchange System Manager, find the server on which you created the recovery storage group, right-

click the recovery storage group and then click Add Database to Recover.

Exchange automatically determines which databases can be added to the recovery storage group and

presents you with a list from which to choose.

- 77 -

2. In the Select database to recoverdialog box, click the database that you want to recover and then click

OK (see the following figure).

  

Note

 

If the recovery storage group already contains a database, Exchange limits the list of databases

to those in the same storage group as the database that has already been added to the recovery

storage group.    

Select database to recover dialog box

3. Name the database, and define the paths for the database and streaming database files (see the following

two figures). Remember that if you intend to copy these files to the original storage group to replace the

original database, the names must match those used for the original database.

- 78 -

General tab for a new recovery storage group database

Database tab for a new recovery storage group database

- 79 -

How to Restore Online Backup Sets to a Recovery Storage GroupYou can restore databases to a recovery storage group from online backup sets or by manually copying

database files into the appropriate file paths.

Before You BeginBefore you begin restoring data, make sure that you configure your system appropriately. For detailed

information, see Setting up a Recovery Storage Group.

Top of page

Procedure

To restore online backup sets to a recovery storage group

1. In Exchange System Manager, disconnect from any databases currently mounted in the recovery storage

group.

2. At a command prompt, run the command Eseutil /mh [database filename].edb to examine each database

header. The header should contain a line reading "State: Clean Shutdown", verifying that each database

has disconnected successfully. Remember to check both the .edb database file and its matching .stm

streaming database file.

  

Note

 For more information about the two types of database files, see Managing Mailbox Stores and

Public Folder Stores in the Exchange Server 2003 Administration Guide. .     

3. In Windows File Manager, remove transaction log files (*.log) and checkpoint files (*.chk) from the

recovery storage group directory to prevent them from interfering with recovery.

4. Using Exchange System Manager, verify that the This database can be overwritten by a restore check

box is selected for each newly recovered database.

5. In Backup (or a different backup program), choose a full backup set to restore. Determine if you need to

run hard recovery automatically after the restore is complete. After all backup sets have been restored,

hard recovery must be run to replay transaction logs and put the restored database in a mountable state.

Use the following guidelines to determine whether you should run hard recovery manually or

automatically:

• If this is the only backup set that you need to restore, and you do not need to add extra log files to the

recovery storage group, set hard recovery to run automatically after the restore is complete. In

Backup, you can do this by selecting the Last Restore Setcheck box, as shown in the following figure.

• If you have additional backup sets to restore, wait until you are ready to restore the last set to use the

Last Restore Set option (as described later in this procedure).

• If you will be manually copying transaction log files to the recovery storage group in addition to

- 80 -

restoring log files from online backup, you will need to run hard recovery manually, as described in

Transaction Log File Replay: Soft Recovery and Hard Recovery in Exchange Server 2003. Manually

running hard recovery will allow you to verify that all log files match and are in sequence before

recovery starts.

Last Restore Set check box in the Restoring Database Store dialog box of Backup

6. Restore the full backup set to the recovery storage group server.

7. If additional incremental or differential transaction log backups are available, restore them. As you are

restoring the final backup, you can set hard recovery to run automatically, unless you determined in Step

5 above that you need to run hard recovery manually.

  

Note

 For more information about Microsoft® Exchange Server 2003 incremental and differential

backups, see How Exchange Online Backups Work in Exchange Server 2003.     

8. If additional log files are available, move them to the transaction log directory. Verify that the sequence

and signatures of these log files match those from the backup set, and then run hard recovery manually.

For more information, see How to Run Hard Recovery Manually.

If you are unfamiliar with how to do this task, see Cross-Matching Exchange Databases and Log Files in

Exchange Server 2003.

   Important

 If you are using additional log files beyond those included in the backup sets, you should run

hard recovery manually.

- 81 -

How to Run Hard Recovery ManuallyThis procedure describes how to run hard recovery manually. This procedure applies to the topic How to

Restore Databases from Online Backup Sets.

Procedure

To run hard recovery manually1. At a command prompt, change your default directory to the folder in which the Restore.env file exists.

This will be a subfolder of the temporary location that you defined when restoring the backup.

If hard recovery has already been run successfully, Exchange will have deleted Restore.env

automatically.

If you are using additional log files beyond those included in the backup sets, it is a best practice to run

hard recovery manually. Running hard recovery manually gives you a chance to verify the sequence and

signatures of all the log files before recovery starts. If you have already copied all additional log files

into place before restoring your backup sets, you can run hard recovery from within the backup

application, but it will be difficult to verify before recovery runs that all needed log files are actually

present.

2. Make sure that all log files, including any extra log files that were not part of the backup set, are in place

(as described in the previous procedure).

3. From the folder identified in Step 1, run the command Eseutil /cc to begin hard recovery.

How to Verify Hard Recovery and Mount the Recovered DatabasesThis procedure describes how to verify hard recovery and mount the recovered databases.

Procedure

To verify hard recovery and mount the recovered databases

1. Wait for hard recovery to complete. You can examine the Application Log for events indicating successful

completion of hard recovery. You can also inspect the temporary folder in which Restore.env is located. After

recovery completes successfully, Exchange automatically deletes all files in this folder.

2. Using a command prompt, verify that hard recovery was successful by using the command Eseutil /mh

[database filename].edb to examine each database header. The header should contain a line reading "State:

Clean Shutdown." If the state is "Dirty Shutdown," hard recovery probably did not run automatically or

recovery failed. You can correct the problem that caused the failure and then attempt hard recovery again

using the procedure in How to Run Hard Recovery Manually.

3. After hard recovery has completed successfully, mount the database.

4. If appropriate, mount other databases in the recovery storage group.

- 82 -

The following figure shows a recovered database with several mailboxes in Exchange System Manager.

Recovered mailboxes in Exchange System Manager

How to Restore Databases from Offline or File Copy BackupsBefore you begin restoring data, make sure that your system is configured appropriately. To review, make sure that: • A recovery storage group exists. Because you are not using an online backup, the name of the recovery

storage group does not matter.

• The database that you want to restore has been added to the recovery storage group. The file names of the recovery storage group database match the file names of the original database. By default, the recovery storage group database is not mounted. Leave it in this state.

  

Note

 

After changing permissions, adding or deleting recovery storage group databases, or changing

recovery storage group attributes, it may take up to 15 minutes for previously cached values to

be refreshed. Until the cache has been refreshed, restoring to or extracting data from the

recovery storage group may fail.

    

- 83 -

Procedure

To restore databases from offline or file copy backups

1. Verify that all database files to be restored are in Clean Shutdown state. For detailed information, see

How to Verify That All Database Files to Be Restored Are in Clean Shutdown State.

2. Restore file copies of databases to a recovery storage group. For detailed information, see How to

Restore File Copies of Databases to a Recovery Storage Group.

How to Verify that all Database Files to Be Restored Are in Clean Shutdown StateThis procedure describes how to verify that all database files to be restored are in Clean Shutdown state.

- 84 -

Procedure

To verify that all database files to be restored are in Clean Shutdown state

1. Using a command prompt, run the command Eseutil /mh [database filename].edbto examine each

database header. Remember that each .edb database file must be accompanied by its matching .stm

streaming database file.

2. If necessary, run soft recovery of each database. If the database files are in Clean Shutdown state, it is

not necessary, but it is possible to run soft recovery and replay additional transaction log files into the

database. If the database files are not in Clean Shutdown state, you must run soft recovery of each

database or repair each database after the copies have been moved into place.

• If transaction log files are available, use Exchange Server Database Utilities (Eseutil.exe) to replay the

necessary transaction log file into the database.

It is best to perform transaction log replay in an empty staging folder before moving a database to the

recovery storage group. This ensures that there is no interference with existing log or checkpoint files

in the recovery storage group.

  

Note

 

For more information about replaying transaction log files in this way, see Transaction Log

File Replay: Soft Recovery and Hard Recovery in Exchange Server 2003. For more

information about determining which log files are required, see Cross-Matching Exchange

Databases and Log Files in Exchange Server 2003.

    

• If required log files are not available, you must use the repair functionEseutil /p to restore the database

to consistency, and then use the Information Store Integrity Checker (Isinteg.exe) tool to fix bad

references in the database caused by forcing the database to consistency without applying all

transactions

How to Restore File Copies of Databases to a Recovery Storage GroupThis procedure describes how to restore file copies of databases to a recovery storage group.

Procedure

To restore file copies of databases to a recovery storage group

1. In Windows File Manager, copy .edb and .stm database files into the locations defined for them in the

recovery storage group directory.

- 85 -

If the file names defined in Exchange System Manager for the database and streaming database files are

different than the filenames of the actual files, you can either rename the files or delete the recovery storage

group database in Exchange System Manager, and start over with the correct names. If you intend to replay

log files into the databases at this point, you should choose the latter method. However, it is a best practice to

replay log files "out of place" as described in the previous section. This practice is important if you are

restoring multiple databases in a single recovery storage group.

2. In Exchange System Manager, disconnect from any databases currently mounted in the recovery storage

group.

3. In Windows File Manager, remove transaction log files (*.log) and checkpoint files (*.chk) from the recovery

storage group directory to prevent them from interfering with recovery.

4. Using Exchange System Manager, verify that the This database can be overwritten by a restore check box is

selected for each newly recovered database.

5. If you need to run soft recovery manually, use the following steps:

1. In Windows File Manager, copy necessary transaction logs to the same location as the database files.

2. Identify the log file with the highest sequence number, and then truncate the last five characters of its

file name. For example, if the log file with the highest sequence number is E0001234.log, rename it

E00.log.

3. At a command prompt, change your default directory to the folder in which the database files have been

restored. All transaction log files should be in this folder as well. Run the command Eseutil /r Enn /i /d

to complete soft recovery. Replace Enn with the file name that you used for the log file in the step

above. In this example, the file name is E00. After soft recovery finishes, verify that the database files

are in Clean Shutdown state by running Eseutil /mh [database filename].edb.

6. Using Exchange System Manager, mount the database.

7. If appropriate, mount other databases in the recovery storage group.

The following figure shows a recovered database with several mailboxes in Exchange System Manager.

- 86 -

Recovered mailboxes in Exchange System Manager

Exchange migration 5.5to 2000, 5.5 to 2003and 2000 to 2003.C H A P T E R   2

Installing New Exchange Server 2003 ComputersThis chapter provides information about deploying new installations of Microsoft® Exchange Server 2003 in your organization. Specifically, this chapter will: Provide you with the requirements necessary to install Exchange 2003. Provide you with information about running Exchange Server 2003 Deployment Tools. Provide you with information about front-end and back-end architecture, including how to configure

a front-end server. Show you how to run ForestPrep. Show you how to run DomainPrep. Show you how to install Exchange 2003 on new servers, including how to run Exchange 2003 Setup

in attended and unattended modes.

Procedures in Chapter 2After ensuring that your organization meets the necessary prerequisites, the procedures in this chapter guide you through the deployment process. This process includes installing the first Exchange 2003 computer into your organization.Table 2.1 lists the specific procedures that are detailed in this chapter, as well as the required permissions.

- 87 -

Table 2.1   Chapter 2 procedures and corresponding permissionsProcedure Required permissions or rolesEnable Microsoft Windows® 2000 Server or Microsoft Windows Server™ 2003 services

See Windows 2000 or Windows Server 2003 Help

Run ForestPrep on a domain controller (updates the Microsoft Active Directory® directory service schema)

Enterprise Administrator Schema Administrator Domain Administrator Local Machine Administrator

Run DomainPrep Domain Administrator Local Machine Administrator

Install Exchange 2003 on the first server in a domain Exchange Full Administrator role applied at the organization level

Local Machine AdministratorInstall Exchange 2003 on additional servers in the domain Exchange Full Administrator role

applied at the administrative group level Exchange 5.5 Site Administrator (if

installing into an Exchange 5.5 site) Local Machine Administrator

Install the first instance of a connector Exchange Full Administrator applied at the organization level

For more information about managing and delegating permissions, and user and group authorities, see the book Exchange Server 2003 Administration Guide (http://www.microsoft.com/exchange/library).

Exchange 2003 Security ConsiderationsBefore installing Exchange Server 2003 in your organization, it is important that you are familiar with your organization's security requirements. Familiarizing yourself with these requirements helps ensure that your Exchange 2003 deployment is as secure as possible. For more information about planning Exchange 2003 security, see the book Planning an Exchange Server 2003 Messaging System (http://www.microsoft.com/exchange/library).

Exchange Server Deployment ToolsExchange Server Deployment Tools are tools and documentation that lead you through the entire installation or upgrade process. To ensure that all of the required tools and services are installed and running properly, it is recommended that you run Exchange 2003 Setup through the Exchange Server Deployment Tools.

Note   You must download the latest version of the Exchange Server Deployment Tools before you run them. To receive the latest version of the tools, see Exchange Server 2003 Tools and Updates (http://www.microsoft.com/exchange/2003/updates).

To start the Exchange Server 2003 Deployment Tools1. Insert the Exchange Server 2003 CD into your CD-ROM drive.2. On the Welcome to Exchange Server 2003 Setup page, click Exchange Deployment Tools.3. If the Welcome to Exchange Server 2003 Setup page does not appear after you insert your CD, double-

click Setup.exe, and then click Exchange Deployment Tools to begin.4. Follow the step-by-step instructions in the Exchange Server Deployment Tools documentation.After you start the tools and specify that you want to follow the process for New Exchange 2003 Installation, you are provided with a checklist detailing the following installation steps: Verify that your organization meets the specified requirements. Install and enable the required Windows services. Run the DCDiag tool.

- 88 -

Run the NetDiag tool. Run ForestPrep. Run DomainPrep. Run Exchange Setup.With the exception of running the DCDiag and NetDiag tools, each of these installation steps is detailed later in this chapter. For more information about the DCDiag and NetDiag tools, refer to the Exchange Server Deployment Tools. It is recommended that you run the DCDiag and NetDiag tools on every server on which you plan to install Exchange 2003.When you use Exchange Server Deployment Tools, you can run specific tools and utilities to verify that your organization is ready for the Exchange 2003 installation. If you do not want to run Exchange Server Deployment Tools, follow the remaining procedures in this chapter to install Exchange 2003.

System-Wide Requirements for Exchange 2003Before you install Exchange Server 2003, ensure that your network and servers meet the following system-wide requirements: Domain controllers are running Windows 2000 Server Service Pack 3 (SP3) or Windows

Server 2003. Global catalog servers are running Windows 2000 SP3 or Windows Server 2003. It is recommended

that you have a global catalog server in every domain where you plan to install Exchange 2003. Domain Name System (DNS) and Windows Internet Name Service (WINS) are configured correctly

in your Windows site. Servers are running Windows 2000 SP3 or Windows Server 2003 Active Directory.For more information about Windows 2000 Server, Windows Server 2003, Active Directory, and Domain Name System (DNS), see the following resources: Windows 2000 Help Windows Server 2003 Help Best Practice: Active Directory Design for Exchange 2000

(http://go.microsoft.com/fwlink/?LinkId=17837) Planning an Exchange Server 2003 Messaging System

(http://www.microsoft.com/exchange/library)

Server-Specific Requirements for Exchange 2003Before you install Exchange Server 2003, ensure that your servers meet the requirements that are described in this section. If your servers do not meet all the requirements, Exchange 2003 Setup will stop the installation.

- 89 -

Hardware RequirementsThe following are the minimum and recommended hardware requirements for Exchange 2003 servers: Intel Pentium or compatible 133 megahertz (MHz) or faster processor 256 megabytes (MB) of RAM recommended minimum, 128 MB supported minimum 500 MB of available disk space on the drive on which you install Exchange 200 MB of available disk space on the system drive CD-ROM drive SVGA or higher-resolution monitor

For more information about hardware requirements, for front-end and back-end servers, see the book Using Microsoft Exchange 2000 Front-End Servers (http://go.microsoft.com/fwlink/?linkid=14575&clcid=0x409).

File Format RequirementsTo install Exchange 2003, disk partitions must be formatted for NTFS file system and not for file allocation table (FAT). This requirement applies to the following partitions: System partition Partition that stores Exchange binaries Partitions containing transaction log files Partitions containing database files Partitions containing other Exchange files

Operating System RequirementsExchange Server 2003 is supported on the following operating systems: Windows 2000 SP3 or later

Note   Windows 2000 SP3 or later is available for download at http://go.microsoft.com/fwlink/?linkid=18353. Windows 2000 SP3 or later is also a prerequisite for running the Exchange 2003 Active Directory Connector.

Windows Server 2003

Installing and Enabling Windows 2000 or Windows Server 2003 ServicesExchange 2003 Setup requires that the following components and services be installed and enabled on the server: .NET Framework ASP.NET Internet Information Services (IIS) World Wide Web Publishing Service Simple Mail Transfer Protocol (SMTP) service Network News Transfer Protocol (NNTP) service

If you are installing Exchange 2003 on a server running Windows 2000, Exchange Setup installs and enables the Microsoft .NET Framework and ASP.NET automatically. You must install the World Wide Web Publishing Service, the SMTP service, and the NNTP service manually before running Exchange Server 2003 Installation Wizard.If you are installing Exchange 2003 in a native Windows Server 2003 forest or domain, none of these services is enabled by default. You must enable the services manually before running Exchange Server 2003 Installation Wizard.

Important   When you install Exchange on a new server, only the required services are enabled. For example, Post Office Protocol version 3 (POP3), Internet Message Access Protocol version 4 (IMAP4), and NNTP services are disabled by default on all of your Exchange 2003 servers. You should enable only services that are essential for performing Exchange 2003 tasks.

- 90 -

To enable services in Windows 20001. Click Start, point to Settings, and then click Control Panel.2. Double-click Add/Remove Programs.3. Click Add/Remove Windows Components.4. Click Internet Information Services (IIS), and then click Details.5. Select the NNTP Service, SMTP Service, and World Wide Web Service check boxes.6. Click OK.

Note   Ensure that the Internet Information Services (IIS) check box is selected.

To enable services in Windows Server 20031. Click Start, point to Control Panel, and then click Add or Remove Programs.2. In Add or Remove Programs, click Add/Remove Windows Components.3. In Windows Component Wizard, on the Windows Components page, highlight Application Server, and

then click Details.4. In Application Server, select the ASP.NET check box (Figure 2.1).

Figure 2.1   The Application Server dialog box5. Highlight Internet Information Services (IIS), and then click Details.

- 91 -

6. In Internet Information Services (IIS), select the NNTP Service, SMTP Service, and World Wide Web Service check boxes, and then click OK (Figure 2.2).

Figure 2.2   The Internet Information Services (IIS) dialog box7. In Application Server, ensure that the Internet Information Services (IIS) check box is selected, and then

click OK to install the components.Note   Do not select the E-mail Services check box.

8. Click Next, and when the Windows Components Wizard completes, click Finish.9. Perform the following steps to enable ASP.NET:

a. Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.

b. In the console tree, expand the local computer, and then click Web Service Extensions.c. In the details pane, click ASP.NET, and then click Allow.

Running Exchange 2003 ForestPrepExchange 2003 ForestPrep extends the Active Directory schema to include Exchange-specific classes and attributes. ForestPrep also creates the container object for the Exchange organization in Active Directory. The schema extensions supplied with Exchange 2003 are a superset of those supplied with Exchange 2000. Even if you have run Exchange 2000 ForestPrep, you must run Exchange 2003 ForestPrep again. For information about the schema changes between Exchange 2000 and Exchange 2003, see "Appendix: Exchange 2003 Schema Changes" in the book What's New in Exchange Server 2003 (http://www.microsoft.com/exchange/library).In the domain where the schema master resides, run ForestPrep. (By default, the schema master runs on the first Windows domain controller installed in a forest.) Exchange Setup verifies that you are running ForestPrep in the correct domain. If you are not in the correct domain, Setup informs you which domain contains the schema master. For information about how to determine which of your domain controllers is the schema master, see Windows 2000 or Windows Server 2003 Help.The account you use to run ForestPrep must be a member of the Enterprise Administrator and the Schema Administrator groups. While you are running ForestPrep, you designate an account or group that has Exchange Full Administrator permissions to the organization object. This account or group has the authority to install and manage Exchange 2003 throughout the forest. This account or group also has the authority to delegate additional Exchange Full Administrator permissions after the first server is installed.

Important   When you delegates Exchange roles to a security group, it is recommend that you use Global or Universal security groups and not Domain Local security groups. Although Domain Local security groups can work, they are limited in scope to their own domain. In many scenarios, Exchange Setup needs to authenticate to other domains during the installation. Exchange Setup may fail in this case because of a lack of permissions to your external domains.Note   To decrease replication time, it is recommended that you run Exchange 2003 ForestPrep on a domain controller in your root domain.

- 92 -

To run Exchange 2003 ForestPrep1. Insert the Exchange CD into your CD-ROM drive.2. On the Start menu, click Run and then type E:\setup\i386\setup /ForestPrep, where E is your CD-ROM

drive.3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.4. On the License Agreement page, read the agreement. If you accept the terms, click I agree, and then

click Next.5. On the Product Identification page, type your 25-digit product key, and then click Next.

- 93 -

6. On the Component Selection page, ensure that Action is set to ForestPrep. If not, click the drop-down arrow, and then click ForestPrep. Click Next (Figure 2.3).

Figure 2.3   The ForestPrep option on the Component Selection pageImportant   If ForestPrep does not appear under Action, you may have misspelled the "ForestPrep" command in Step 2. If this is the case, go back to Step 2 and retype the command.

7. On the Microsoft Exchange Server Administrator Account page, in the Account box, type the name of the account or group that is responsible for installing Exchange (Figure 2.4).

Note   The account that you specify also has permission to use Exchange Administration Delegation Wizard to create other Exchange administrator accounts. For more information about Exchange Administration Delegation Wizard, see the book Exchange Server 2003 Administration Guide (http://www.microsoft.com/exchange/library).

Figure 2.4   The Microsoft Exchange Server Administrator Account page8. Click Next to start ForestPrep. After ForestPrep starts, you cannot stop the process.

- 94 -

Note   Depending on your network topology and the speed of your Windows 2000 or Windows Server 2003 domain controller, ForestPrep may take a considerable amount of time to complete.

9. On the Completing the Microsoft Exchange Wizard page, click Finish.

Running Exchange 2003 DomainPrepAfter you run ForestPrep and allow time for replication, you must run Exchange 2003 DomainPrep. DomainPrep creates the groups and permissions necessary for Exchange servers to read and modify user attributes. The Exchange 2003 version of DomainPrep performs the following actions in the domain: Creates Exchange Domain Servers and Exchange Enterprise Servers groups. Nests the global Exchange Domain Servers into the Exchange Enterprise Servers local group. Creates the Exchange System Objects container, which is used for mail-enabled public folders. Sets permissions for the Exchange Enterprise Servers group at the root of the domain, so that

Recipient Update Service has the appropriate access to process recipient objects. Modifies the AdminSdHolder template where Windows sets permissions for members of the local

Domain Administrator group. Adds the local Exchange Domain Servers group to the Pre-Windows 2000 Compatible Access

group. Performs Setup pre-installation checks.The account you use to run DomainPrep must be a member of the Domain Administrators group in the local domain and a local machine administrator. You must run DomainPrep in the following domains: The root domain. All domains that will contain Exchange 2003 servers. All domains that will contain Exchange Server 2003 mailbox-enabled objects (such as users and

groups), even if no Exchange servers will be installed in these domains. All domains that will contain Exchange 2003 users and groups that you will use to manage your

Exchange 2003 organization.Note   Running DomainPrep does not require any Exchange permissions. Only Domain Administrator permissions are required in the local domain.

To run Exchange 2003 DomainPrep1. Insert the Exchange CD into your CD-ROM drive. You can run DomainPrep on any computer in the

domain.2. From a command prompt, type E:\setup\i386\setup /DomainPrep, where E is your CD-ROM drive.3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then

click Next. 5. On the Product Identification page, type your 25-digit product key, and then click Next.

- 95 -

6. On the Component Selection page, ensure that Action is set to DomainPrep. If not, click the drop-down arrow, and then click DomainPrep. Click Next (Figure 2.5).

Figure 2.5   The DomainPrep option on the Component Selection pageImportant   If DomainPrep does not appear in the Action list, you may have misspelled the "DomainPrep" command in Step 2. If this is the case, go back to Step 2 and retype the command.

7. On the Completing the Microsoft Exchange Wizard page, click Finish.

Running Exchange 2003 SetupAfter planning and preparing your Exchange organization in accordance with the requirements and procedures listed in this chapter, you are ready to run Exchange 2003 Setup. To install the first Exchange 2003 server in the forest, you must use an account that has Exchange Full Administrator permissions at the organization level and is a local administrator on the computer. Specifically, you can use the account you designated while running ForestPrep or an account from the group that you designated. For more information about Exchange 2003 permissions, see "Procedures in Chapter 2" earlier in this chapter.

To run Exchange 2003 Setup1. Log on to the server on which you want to install Exchange. Insert the Exchange Server 2003 CD into

your CD-ROM drive.2. On the Start menu, click Run and then type E:\setup\i386\setup /ForestPrep, where E is your CD-ROM

drive.3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then

click Next.5. On the Product Identification page, type your 25-digit product key, and then click Next.6. On the Component Selection page, in the Action column, use the drop-down arrows to specify the

appropriate action for each component, and then click Next (Figure 2.6).

- 96 -

Figure 2.6   The Component Selection page

- 97 -

7. On the Installation Type page, click Create a new Exchange Organization, and then click Next (Figure 2.7).

Figure 2.7   The Installation Type page8. On the Organization Name page, in the Organization Name box, type your new Exchange organization

name, and then click Next (Figure 2.8).Note   The name must contain at least 1 character, but be fewer than 64 characters. You can use the following characters in your new Exchange 2003 organization name:•   A through Z•   a through z•   0 through 9•   Space•   Hyphen or dash

Figure 2.8   The Organization Name page

- 98 -

9. On the License Agreement page, read the agreement. If you agree to the terms, click I agree that I have read and will be bound by the license agreements for this product, and then click Next.

10. On the Component Selection page, in the Action column, use the drop-down arrows to specify the appropriate action for each component, and then click Next.

- 99 -

11. On the Installation Summary page, confirm that your Exchange installation choices are correct, and then click Next (Figure 2.9).

Figure 2.9   The Installation Summary page12. On the Completing the Microsoft Exchange Wizard page, click Finish.To verify that your Exchange installation was successful, see Appendix A, "Post-Installation Steps."

Unattended Setup and InstallationDeploying multiple Exchange 2003 servers in a large organization with intensive messaging needs can be a time consuming and resource-intensive effort. Your organization may need several hundred Exchange 2003 servers, and though many of these servers will be configured identically, you may not have the resources to accomplish the deployment in a given time frame. To remedy this problem, after you install your first Exchange 2003 server, you can install the subsequent Exchange servers in unattended mode, so that you can automate your server installations. An unattended setup of an Exchange 2003 server proceeds and completes without any prompts or dialog boxes. Furthermore, an unattended setup creates an answer file that stores information about a sample configuration. The file can then be used to set up Exchange 2003 on multiple servers. An answer file contains the deployment parameters and sample configurations so that you can specify what type of installation you want to perform. These configurations are normally set when you perform a manual Exchange 2003 installation on one of your servers. You can run unattended setup only on servers that meet the requirements listed in "System-Wide Requirements for Exchange 2003" and "Server-Specific Requirements for Exchange 2003" earlier in this chapter. Do not run an unattended setup if your servers do not meet these requirements.For more information about unattended setup, see Microsoft Knowledge Base article 312363, "HOW TO: Install Exchange 2000 Server in Unattended Mode in Exchange 2000 Server" (http://support.microsoft.com/?kbid=312363).

When Unattended Setup Can Be RunYou can run unattended setup for the following procedures: Installing the second to nth Exchange 2003 server in your organization Installing Exchange 2003 System Management Tools Running DomainPrep

When Unattended Setup Cannot Be RunYou cannot run unattended setup for the following procedures:

- 100 -

Installing the first Exchange Server 2003 server in your organization Installing Exchange Server 2003 in a Windows cluster Installing Exchange Server 2003 in a mixed-mode environment (for example, Exchange 5.5 and

Exchange 2003) Performing any maintenance tasks (for example, adding or removing programs, re-installing

Exchange, or upgrading from Exchange 2000)

Running Unattended SetupThe following procedure shows you how to deploy your new Exchange 2003 servers in unattended setup mode.

Note   If Autologon is enabled on the server where the unattend answer file is created, the password of the user creating the answer file is stored in plain text in the answer file. Disable Autologon before using the /createunattend switch. For information about how to enable and disable Autologon, see Microsoft Knowledge Base article 234562, "HOW TO: Enable Automatic Logon in Windows 2000 Professional" (http://support.microsoft.com/?kbid=234562).

To create an answer file for running unattended setup1. On a server that meets the prerequisites for an Exchange Server 2003 installation, insert the Exchange

CD into your CD-ROM drive.2. From a command prompt, type E:\setup\i386\setup /createunattend D:\myanswerfile.ini, where E is your

CD-ROM drive, D is your system drive, and myanswerfile.ini represents the answer file you want to use for your subsequent installations.

Important   The Exchange 2003 Setup.exe command-line parameters are not validated at the command line. Any misspelling of the setup.exe /createunattend switch results in the launch of a manual setup. You cannot verify if you are running a manual setup or a setup in unattended mode until you click Next on the Summary page. At this point, in a manual setup, Exchange 2003 installation begins and cannot be cancelled. Therefore, ensure that command-line switches are spelled correctly before attempting to create and use an answer file for an unattended installation of Exchange 2003.

3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.4. On the License Agreement page, read the agreement. If you agree to the terms, click I agree, and then

click Next.5. On the Product Identification page, type your 25-digit product key, and then click Next.6. On the Component Selection page, in the Action column, use the drop-down arrows to specify the

appropriate action for each component, and then click Next.Note   You can create an answer file for installing an Exchange 2003 server, for installing Exchange 2003 System Management Tools only, and for running DomainPrep.

7. On the Installation Summary page, confirm that your Exchange installation choices are correct, and then click Next.

8. On the Completing the Microsoft Exchange Wizard page, click Finish.To use an answer file to run unattended setup

1. On a server to which you want to install Exchange 2003 in unattended mode, insert the Exchange CD into your CD-ROM drive.

2. From a command prompt, type E:\setup\i386\setup /unattendfile D:\myanswerfile.ini, where E is your CD-ROM drive, D is your system drive, and myanswerfile.ini represents the answer file you created in the preceding section.

Exchange 2003 is then installed on your server automatically without any user interaction. To verify that your Exchange installation is successful, see Appendix A, "Post-Installation Steps."

Switching from Mixed Mode to Native ModeBy default, when you complete your installation of Exchange 2003 into your organization, Exchange 2003 is running in mixed mode. If your Exchange 2003 servers have to coexist with Exchange 5.5 in the future, your organization must run in mixed mode. An Exchange mixed-mode organization uses Site Replication

- 101 -

Service to ensure future interoperability and communication between Exchange 2003 servers and Exchange 5.5. Running in mixed mode limits the functionality of Exchange 2003. Therefore, it is recommended that you switch from mixed mode to native mode. This section discusses the advantages of a native-mode Exchange organization and provides the steps to switch from mixed mode to native mode.You are ready to change your Exchange 2003 organization to native mode if: Your organization will never require interoperability between your Exchange 2003 servers and

Exchange 5.5 servers in the same organization.Note   After you switch your Exchange 2003 organization from mixed mode to native mode, you cannot switch the organization back to mixed mode. Make sure that your Exchange 2003 organization will not have to interoperate with Exchange 5.5 in the future before you switch from mixed mode to native mode.

Advantages of Running Exchange in Native ModeBecause many Exchange 2003 features are available only when you run your Exchange 2003 organization in native mode, it is recommended that you switch from mixed mode to native mode. Running Exchange 2003 in native mode has the following advantages: You can create query-based distribution groups. A query-based distribution group provides the same

functionality as a standard distribution group. However, instead of specifying static user memberships, with a query-based distribution group you can use an LDAP query to build membership in the distribution group dynamically. For more information about query-based distribution groups, see "Managing Recipients and Recipient Policies" in the book Exchange Server 2003 Administration Guide (http://www.microsoft.com/exchange/library).

Your routing bridgehead server pairs use 8BITMIME data transfers instead of converting to 7-bit. This difference equates to a considerable bandwidth saving over routing group connectors.

Routing groups can consist of servers from multiple administrative groups. You can move Exchange 2003 servers between routing groups. You can move mailboxes between administrative groups. Simple Mail Transfer Protocol (SMTP) is the default routing protocol.

Switching to Native ModeUse the following procedure to switch your Exchange organization from mixed mode to native mode.

Important   After you switch your Exchange 2003 organization from mixed mode to native mode, you cannot switch the organization back to mixed mode. Before you perform the following procedure, ensure that your Exchange 2003 organization will not have to interoperate with Exchange 5.5 in the future.

To switch to native mode1. Start Exchange System Manager: Click Start, point to All Programs, point to Microsoft Exchange, and

then click System Manager.2. In the console tree, right-click the organization that you want to switch to native mode, and then click

Properties.3. In <Organization Name> Properties, under Change operation mode, click Change Mode.4. In the warning dialog box, click Yes if you are sure that you want to permanently switch to native mode.

Click Apply to accept your new Exchange mode.To take full advantage of Exchange native mode, you must restart the Microsoft Exchange Information Store service on all of the Exchange servers in your organization. You do not need to restart all of the Microsoft Exchange Information Store services simultaneously, but you must restart the service on each server for the server to take advantage of all Exchange native mode features. Restart the service on your servers after the change to native mode has been replicated to your local Windows domain controller.

To restart the Microsoft Exchange Information Store service1. On the Start menu, click Run, type services.msc, and then click OK.2. In the Services (Local) pane, find the Microsoft Exchange Information Store service.

- 102 -

3. Right-click the service and click Restart.

Chapter 3: Upgrading from Exchange 2000 Server   103

C H A P T E R   3

Upgrading from Exchange 2000 ServerThis chapter provides instructions for upgrading your organization from Microsoft® Exchange 2000 Server to Exchange Server 2003. Specifically, this chapter will: Provide you with the requirements necessary to upgrade from

Exchange 2000. Provide you with information about running Exchange Server 2003

Deployment Tools. Provide you with information about improvements in Exchange 2003

Setup. Show you how to run ForestPrep. Show you how to run DomainPrep. Show you how to run Exchange Setup to upgrade your organization. Provide you with information about removing Exchange 2000 tuning

parameters.

Procedures in Chapter 3After ensuring that your organization meets the necessary prerequisites, the procedures in this chapter guide you through the deployment process. This process includes upgrading your Microsoft Active Directory® directory service forest to the Exchange 2003 schema, and then upgrading your Exchange 2000 servers to Exchange Server 2003.Table 3.1 lists the specific procedures that are detailed in this chapter, as well as the required permissions.Table 3.1   Chapter 3 procedures and corresponding permissionsProcedure Required permissions or rolesEnable Windows® 2000 Server or Windows Server™ 2003 services

See Windows 2000 or Windows Server 2003 Help

Run ForestPrep on a domain controller (updates the Active Directory schema)

Enterprise Administrator Schema Administrator Domain Administrator Local Machine Administrator

Run DomainPrep Domain Administrator Local Machine Administrator

Remove Mobile Information Server Exchange 2000 Event Source

Microsoft Mobility Administrator

Chapter 3: Upgrading from Exchange 2000 Server   104

Procedure Required permissions or roles Local Machine Administrator

Upgrade to Exchange 2003 on an Exchange 2000 server in a domain

Exchange Full Administrator role applied at the organization level

Local Machine AdministratorInstall Exchange 2003 on additional servers in the domain

Exchange Full Administrator role applied at the administrative group level

Local Machine Administrator

For more information about managing and delegating permissions, and user and group authorities, see the book Exchange Server 2003 Administration Guide (http://www.microsoft.com/exchange/library).

Exchange 2003 Security ConsiderationsBefore installing Exchange Server 2003 in your organization, it is important that you are familiar with your organization's security requirements. Familiarizing yourself with these requirements helps ensure that your Exchange 2003 deployment is as secure as possible. For more information about planning Exchange 2003 security, see the book Planning an Exchange Server 2003 Messaging System (http://www.microsoft.com/exchange/library).

Exchange Server Deployment ToolsExchange Server Deployment Tools are tools and documentation that lead you through the entire upgrade process. To ensure that all of the required tools and services are installed and running properly, it is recommended that you run Exchange 2003 Setup through the Exchange Server Deployment Tools.

Note   You must download the latest version of the Exchange Server Deployment Tools before you run them. To receive the latest version of the tools, see Exchange Server 2003 Tools and Updates (http://www.microsoft.com/exchange/2003/updates).

To start the Microsoft Exchange Server 2003 Deployment Tools1. Insert the Exchange Server 2003 CD into your CD-ROM drive.2. On the Welcome to Exchange Server 2003 Setup page, click Exchange

Deployment Tools.3. If the Welcome to Exchange Server 2003 Setup page does not appear after

you insert your CD, double-click Setup.exe, and then click Exchange Deployment Tools to begin.

Chapter 3: Upgrading from Exchange 2000 Server   105

4. Follow the step-by-step instructions in the Exchange Server Deployment Tools documentation.

After you start the tools and specify that you want to Upgrade from Exchange 2000 Native Mode, you are provided with a checklist detailing the following installation steps: Verify that your organization meets the specified requirements. Run the DCDiag tool. Run the NetDiag tool. Run ForestPrep. Run DomainPrep. Run Exchange Setup.With the exception of running the DCDiag and NetDiag tools, each of these installation steps is detailed later in this chapter. For more information about the DCDiag and NetDiag tools, refer to the Exchange Server Deployment Tools. It is recommended that you run the DCDiag and NetDiag tools on every server on which you plan to install Exchange 2003.Using Exchange Server Deployment Tools, you can run specific tools and utilities to verify that your organization is ready to install Exchange 2003. If you do not want to run Exchange Server Deployment Tools, follow the remaining procedures in this chapter to install Exchange 2003.

Chapter 3: Upgrading from Exchange 2000 Server   106

System-Wide Requirements for Exchange 2003Before you upgrade to Exchange Server 2003, ensure that your network and servers meet the following system-wide requirements: Domain controllers are running Windows 2000 Service Pack 3 (SP3) or

Windows Server 2003. Global catalog servers are running Windows 2000 SP3 or later, or

Windows Server 2003. It is recommended that you have a global catalog server in every domain where you plan to install Exchange 2003.

Servers are running Windows 2000 Server SP3 or Windows Server 2003 Active Directory.

You backed up your Exchange 2000 databases.For more information about Windows Server 2003, Active Directory, and Domain Name System (DNS), see the following resources: Windows Server 2003 Help Best Practice: Active Directory Design for Exchange 2000

(http://go.microsoft.com/fwlink/?LinkId=17837) Planning an Exchange Server 2003 Messaging System

(http://www.microsoft.com/exchange/library)

Server-Specific Requirements for Exchange 2003Before you upgrade to Exchange Server 2003, ensure that your Exchange 2003 servers meet the requirements that are described in this section.

Hardware RequirementsThe following are the minimum hardware requirements for Exchange 2003 servers: Intel Pentium or compatible 133 megahertz (MHz) or faster processor 256 megabytes (MB) of RAM recommended minimum, 128 MB

supported minimum 500 MB of available disk space on the drive on which you install

Exchange 200 MB of available disk space on the system drive CD-ROM drive SVGA or higher-resolution monitor

Operating System RequirementsExchange Server 2003 is supported on the following operating systems: Windows 2000 SP3 or later

Chapter 3: Upgrading from Exchange 2000 Server   107

Note   Windows 2000 SP3 or later is available for download at http://go.microsoft.com/fwlink/?LinkId=18353. Windows 2000 SP3 or later is also a prerequisite for running the Exchange 2003 Active Directory Connector.

Windows Server 2003

Exchange 2000 Server RequirementsBefore you upgrade your Exchange 2000 servers to Exchange 2003, your servers must be running Exchange 2000 SP3 or later.Exchange 2000 SP3 is available for download at http://go.microsoft.com/fwlink/?LinkId=17058.

Windows 2000 ComponentsWhen upgrading to Exchange 2003, the current state of the Post Office Protocol version 3 (POP3), Internet Message Access Protocol version 4 (IMAP4), and Network News Transfer Protocol (NNTP) services is preserved. Furthermore, if you are upgrading to Exchange 2003 on a server running Windows 2000, Exchange Setup installs and enables the Microsoft .NET Framework and ASP.NET components automatically, which are prerequisites for Exchange 2003.

Important   Unless it is necessary that you run a particular service, you should disable it. For example, if you do not use POP3, IMAP4, or NNTP, you should disable these services on all of your Exchange 2003 servers after you install Exchange 2003.

For more information about installing these components, see Windows 2000 Help.

Upgrading Front-End and Back-End Servers Exchange 2003 supports the deployment of Exchange in a manner that distributes server tasks among front-end and back-end servers. Specifically, a front-end server accepts requests from POP3, IMAP4, and RPC/HTTP clients, and proxies them to the appropriate back-end server for processing.If your Exchange 2000 organization takes advantage of front-end and back-end architecture, you must upgrade your front-end servers before you upgrade your back-end servers. For more information about front-end and back-end architecture, see Chapter 8, "Configuring Exchange Server 2003 for Client Access."For information about front-end and back-end scenarios, configurations, and installation, see the following books:

Chapter 3: Upgrading from Exchange 2000 Server   108

Planning an Exchange Server 2003 Messaging System(http://www.microsoft.com/exchange/library)

Using Microsoft Exchange 2000 Front-End Servers(http://go.microsoft.com/fwlink/?linkid=14575&clcid=0x409). Although this book relates to Exchange 2000, the information applies to Exchange 2003 as well.

Pre-Upgrade ProceduresBefore you begin upgrading your Exchange 2000 organization to Exchange 2003, it is important that you prepare your organization for the upgrade process. This section provides recommended and required pre-upgrade procedures.

Upgrading the Operating SystemsIf you plan to upgrade your Exchange 2000 servers running Windows 2000 SP3 (or later) to Windows Server 2003, you must first upgrade those servers to Exchange 2003. This upgrade sequence is required because Exchange 2000 is not supported on Windows Server 2003.

Chapter 3: Upgrading from Exchange 2000 Server   109

Removing Unsupported ComponentsThe following components are not supported in Exchange Server 2003: Microsoft Mobile Information Server Instant Messaging service Exchange Chat Service Exchange 2000 Conferencing Server Key Management Service cc:Mail connector MS Mail connectorTo successfully upgrade an Exchange 2000 server to Exchange 2003, you must first use Exchange Setup to remove these components. For more information about removing these unsupported components, see Exchange 2000 Help and Mobile Information Server Help.

Note   If you want to retain these components, do not upgrade the Exchange 2000 servers that are running them. Instead, install Exchange 2003 on other servers in your organization.

Upgrading International Versions of ExchangeWhen upgrading from Exchange 2000 to Exchange 2003, you must upgrade to the same language version of Exchange 2003. For example, you cannot use Exchange Setup to upgrade a German version of Exchange 2000 to a French version of Exchange 2003.

Important   You can use Exchange Setup to upgrade an English version of Exchange 2000 to the Chinese Simplified, Chinese Traditional, or Korean versions of Exchange 2003. The Novell GroupWise connector, however, is not supported on any of these language versions. Therefore, if this connector is installed on your English version of Exchange 2000, you must remove it before you can upgrade to Exchange 2003.

Running Exchange 2003 ForestPrepEven if you previously ran Exchange 2000 ForestPrep, you must still run Exchange 2003 ForestPrep.Exchange 2003 ForestPrep extends the Active Directory schema to include Exchange-specific classes and attributes. ForestPrep also creates the container object for the Exchange organization in Active Directory. The schema extensions supplied with Exchange 2003 are a superset of those supplied with Exchange 2000. For information about the schema changes between Exchange 2000 and Exchange 2003, see "Appendix: Exchange 2003 Schema

Chapter 3: Upgrading from Exchange 2000 Server   110

Changes" in the book What's New in Exchange Server 2003 (http://www.microsoft.com/exchange/library).In the domain where the schema master resides, run Exchange 2003 ForestPrep in your Active Directory forest. (By default, the schema master runs on the first Windows domain controller installed in a forest.) Exchange Setup verifies that you are running ForestPrep in the correct domain. If you are not in the correct domain, Setup informs you which domain contains the schema master. For information about how to determine which of your domain controllers is the schema master, see Windows 2000 or Windows Server 2003 Help.

Note   If you used the schema manager to index Exchange 2000 schema attributes, you must verify and reapply any manual changes you made to the schema after Exchange 2003 ForestPrep updates the schema.

The account you use to run ForestPrep must be a member of the Enterprise Administrator and the Schema Administrator groups. While you are running ForestPrep, you designate an account or group that has Exchange Full Administrator permissions to the organization object. This account or group has the authority to install and manage Exchange 2003 throughout the forest. This account or group also has the authority to delegate additional Exchange Full Administrator permissions after the first server is installed.

Important   When you delegate Exchange roles to a security group, it is recommend that you use Global or Universal security groups and not Domain Local security groups. Although Domain Local security groups can work, they are limited in scope to their own domain. In many scenarios, Exchange Setup needs to authenticate to other domains during the installation. Exchange Setup may fail in this case because of a lack of permissions to your external domains. The account or group you select does not override your previous account or previous delegations; it adds to them.Note   To decrease replication time, it is recommended that you run Exchange 2003 ForestPrep on a domain controller in your root domain.

To run Exchange 2003 ForestPrep1. Insert the Exchange CD into your CD-ROM drive.2. On the Start menu, click Run, and then type E:\setup\i386\setup /ForestPrep,

where E is your CD-ROM drive.3. On the Welcome to the Microsoft Exchange Installation Wizard page, click

Next.4. On the License Agreement page, read the agreement. If you accept the terms,

click I agree, and then click Next.5. On the Product Identification page, type your 25-digit product key, and then

click Next.

Chapter 3: Upgrading from Exchange 2000 Server   111

6. On the Component Selection page, ensure that Action is set to ForestPrep. If not, click the drop-down arrow, and then click ForestPrep. Click Next (Figure 3.1).

Figure 3.1   The ForestPrep option on the Component Selection pageImportant   If ForestPrep does not appear under Action, you may have misspelled the "ForestPrep" command in Step 2. If this is the case, go back to Step 2 and retype the command.

Chapter 3: Upgrading from Exchange 2000 Server   112

7. On the Microsoft Exchange Server Administrator Account page, in the Account box, type the name of the account or group that is responsible for installing Exchange (Figure 3.2).

Note   The account that you specify will also have permission to use Exchange Administration Delegation Wizard to create other Exchange administrator accounts. For more information about Exchange Administration Delegation Wizard, see the book Exchange Server 2003 Administration Guide (http://www.microsoft.com/exchange/library).

Figure 3.2   The Microsoft Exchange Server Administrator Account page8. Click Next to start ForestPrep. After ForestPrep starts, you cannot cancel the

process.Note   Depending on your network topology and the speed of your Windows 2000 or Windows 2003 domain controller, ForestPrep may take a considerable amount of time to complete.

9. On the Completing the Microsoft Exchange Wizard page, click Finish.

Chapter 3: Upgrading from Exchange 2000 Server   113

Running Exchange 2003 DomainPrepAfter you run ForestPrep and allow time for replication, you must run Exchange 2003 DomainPrep. DomainPrep creates the groups and permissions necessary for Exchange servers to read and modify user attributes. Even if you previously ran Exchange 2000 DomainPrep, you must run Exchange 2003 DomainPrep. The Exchange 2003 version of DomainPrep performs the following actions in the domain: Creates Exchange Domain Servers and Exchange Enterprise Servers

groups. Nests the global Exchange Domain Servers into the Exchange Enterprise

Servers local group. Creates the Exchange System Objects container, which is used for mail-

enabled public folders. Sets permissions for the Exchange Enterprise Servers group at the root of

the domain, so that Recipient Update Service has the appropriate access to process recipient objects.

Modifies the AdminSdHolder template where Windows sets permissions for members of the local Domain Administrator group.

Adds the local Exchange Domain Servers group to the Pre-Windows 2000 Compatible Access group.

Performs Setup pre-installation checks.The account you use to run DomainPrep must be a member of the Domain Administrators group in the local domain and a local machine administrator. You must run DomainPrep in the following domains: The root domain. All domains that will contain Exchange 2003 servers. All domains that will contain Exchange Server 2003 mailbox-enabled

objects (such as users and groups), even if no Exchange servers will be installed in these domains.

All domains that will contain Exchange 2003 users and groups that you will use to manage your Exchange 2003 organization.Note   Running DomainPrep does not require any Exchange permissions. Only Domain Administrator permissions are required in the local domain.

Chapter 3: Upgrading from Exchange 2000 Server   114

To run DomainPrep1. Insert the Exchange CD into your CD-ROM drive. You can run DomainPrep

on any computer in the domain.2. From a command prompt, type E:\setup\i386\setup /DomainPrep, where E is

your CD-ROM drive.3. On the Welcome to the Microsoft Exchange Installation Wizard page, click

Next.4. On the License Agreement page, read the agreement. If you agree to the

terms, click I agree, and then click Next. 5. On the Product Identification page, type your 25-digit product key, and then

click Next.6. On the Component Selection page, ensure that Action is set to DomainPrep.

If not, click the drop-down arrow, and then click DomainPrep. Click Next (Figure 3.3).

Figure 3.3   The DomainPrep option on the Component Selection pageImportant   If DomainPrep does not appear in the Action list, you may have misspelled the "DomainPrep" command in Step 2 above. If this is the case, go back to Step 2 and retype the command.

7. On the Completing the Microsoft Exchange Wizard page, click Finish.

Chapter 3: Upgrading from Exchange 2000 Server   115

Running Exchange 2003 SetupTo upgrade the first Exchange 2000 server in the forest, you must use an account that has Exchange Full Administrator permissions at the organization level and is a local administrator on the computer. Specifically, you can use the account you designated while you were running ForestPrep. For more information about Exchange 2003 permissions, see "Procedures in Chapter 3" earlier in this chapter. Before you begin your upgrade, you should back up your Exchange 2000 servers and databases, Active Directory, and ensure that the databases can be mounted on backup servers. For more information about how to back up your Exchange 2000 servers, see the book Disaster Recovery for Microsoft Exchange 2000 Server (http://go.microsoft.com/fwlink/?linkid=1714&clcid=0x409). For more information about how to back up Active Directory, see Best Practice: Active Directory Design for Exchange 2000 (http://go.microsoft.com/fwlink/?LinkId=17837).

Note   You can mount an Exchange 2000 SP3 database on an Exchange 2003 server. You cannot, however, mount an Exchange 2003 database on an Exchange 2000 SP3 server.

Close all Exchange 2000 Microsoft Management Console (MMC) applications, such as Exchange System Manager and Active Directory Users and Computers. If you are using Terminal Services or Windows Remote Desktop to perform the upgrade, ensure that all Exchange MMC applications are closed on both the console and on other Terminal Services logons.

To run Exchange 2003 Setup1. Log on to the server on which you want to install Exchange. Insert the

Exchange Server 2003 CD into your CD-ROM drive.2. On the Microsoft Exchange Server page, click Setup, and then click

Exchange Server Setup. 3. On the Welcome to the Microsoft Exchange Installation Wizard page, click

Next.4. On the License Agreement page, read the agreement. If you agree to the

terms, click I agree, and then click Next.5. On the Product Identification page, type your 25-digit product key, and then

click Next.

Chapter 3: Upgrading from Exchange 2000 Server   116

6. On the Component Selection page, in the Action column, use the drop-down arrows to specify the appropriate action for each component, and then click Next (Figure 3.4).

Figure 3.4   The Component Selection page

Chapter 3: Upgrading from Exchange 2000 Server   117

7. On the Installation Summary page, confirm that your Exchange installation choices are correct, and then click Next (Figure 3.5).

Figure 3.5   The Installation Summary page8. On the Completing the Microsoft Exchange Wizard page, click Finish.9. After your upgrade, you should back up your Exchange 2000 servers, and

databases, and Active Directory again.To verify that your Exchange installation was successful, see Appendix A, "Post-Installation Steps."

Removing Exchange 2000 Tuning ParametersMany Exchange 2000 tuning parameters that were recommended in previous Exchange documentation (for example, the parameters listed in the article Microsoft Exchange 2000 Internals: Quick Tuning Guide) are no longer applicable in Exchange 2003. In fact, some of these parameters may cause problems. If you previously tuned your Exchange 2000 servers with the settings listed in this section, you must remove them manually for Exchange 2003.Use Registry Editor to remove the settings. To start Registry Editor, click Start, click Run, type regedit, and then click OK.

Warning   Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the

Chapter 3: Upgrading from Exchange 2000 Server   118

registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.

Initial Memory PercentageDelete the following registry parameter because it no longer works with Exchange 2003:

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Parameter: Initial Memory Percentage (REG_DWORD)

Log BuffersIf you tuned the msExchESEParamLogBuffers parameter manually to 9000 (an Exchange 2000 SP2 recommendation) or 500 (an Exchange 2000 SP3 recommendation), delete the manual tuning. Exchange 2003 uses a default value of 500. Previously, Exchange 2000 used a default value of 84.

Max Open TablesIf you tuned the msExchESEParamMaxOpenTables parameter manually, you should return the value to its default setting of <Not Set>. Exchange 2003 calculates the correct value for you automatically.

Extensible Storage System HeapsThe optimum number of heaps is now calculated automatically with Exchange 2003. Therefore, you should delete the following registry parameter:

Location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ESE98\Global\OS\Memory

Parameter: MPHeap parallelism (REG_SZ)

Outlook Web Access Content ExpirationFor Microsoft Outlook® Web Access, you should not disable content expiry for the \Exchweb virtual directory. The default expiration setting of 1 day should be used in all scenarios.

DSAccess MaxMemoryConfig KeyIf you previously tuned the DSAccess performance by adding a MaxMemoryConfig key, you can now remove your manual tuning. Therefore, you should remove the following registry parameter:

Chapter 3: Upgrading from Exchange 2000 Server   119

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess\Instance0

Parameter: MaxMemoryConfig (REG_DWORD)

DSAccess Memory Cache TuningIf you previously tuned the user cache in DSAccess, you can now remove your manual tuning. Exchange 2000 had a default user cache of 25 MB, whereas Exchange 2003 defaults to 140 MB. Therefore, you should remove the following registry parameter:

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess\Instance0

Parameter: MaxMemoryUser (REG_DWORD)

Chapter 3: Upgrading from Exchange 2000 Server   120

Cluster Performance TuningIf previously implemented, the following registry parameters should be deleted when Exchange 2003 is installed:

Location HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMTPSVC\Queuing

Parameter: MaxPercentPoolThreads (REG_DWORD)Location: HKEY_LOCAL_MACHINE\SYSTEM\

CurrentControlSet\Services\SMTPSVC\Queuing

Parameter: AdditionalPoolThreadsPerProc (REG_DWORD)

C H A P T E R   4

Migrating from Exchange Server 5.5 This chapter provides instructions for migrating your organization from Microsoft® Exchange Server 5.5 to Exchange Server 2003. Furthermore, because it is recommended that you run your new Exchange 2003 organization in native mode, this chapter discusses the advantages of native mode, and provides instructions for switching from mixed mode to native mode.Specifically, this chapter will: Provide you with the information necessary to migrate your Exchange 5.5

mailboxes and public folders to Exchange Server 2003. Show you how to use the Microsoft Active Directory® directory service tools. Provide you with the requirements necessary to install Exchange 2003. Show you how to run ForestPrep. Show you how to run DomainPrep. Show you how to run Exchange Setup. Provide you with information about how to move mailboxes and public folders. Provide you with information about how to switch your Exchange 2003

organization from mixed mode to native mode.

Procedures in Chapter 4After ensuring that your organization meets the necessary prerequisites, the procedures in this chapter guide you through the deployment process. Table 4.1 lists the specific procedures that are detailed in this chapter, as well as the permissions that are required to perform them.

Table 4.1   Chapter 4 procedures and corresponding permissionsProcedure Required permissions or rolesEnable Microsoft Windows® 2000 Server or Microsoft Windows Server™ 2003 services

See Windows 2000 or Windows Server 2003 Help

Run ForestPrep on a domain controller (updates the Active Directory schema)

Enterprise Administrator Schema Administrator Domain Administrator Local Machine Administrator

Run DomainPrep Domain Administrator Local Machine Administrator

Install Active Directory Connector (ADC)

Enterprise Administrator Schema Administrator Domain Administrator Local Machine Administrator

Install Exchange 2003 on the first server in a domain

Exchange Full Administrator role applied at the organization level

Exchange 5.5 Administrator under the organization, site, and configuration nodes (if installing into an Exchange 5.5 site)

Local Machine AdministratorInstall Exchange 2003 on additional servers in the domain

Exchange Full Administrator role applied at the administrative group level

Exchange 5.5 Site Administrator (if installing into an Exchange 5.5 site)

Exchange 5.5 Service Account password

Local Machine AdministratorInstall Exchange 2003 on a server that is running Site Replication Service (SRS)

Exchange Full Administrator role applied at the organization level

Local Machine Administrator Exchange 5.5 Service Account

passwordRun Active Directory Account Cleanup Wizard

Enterprise Administrator

For more information about managing and delegating permissions and user and group authorities, see the book Exchange Server 2003 Administration Guide (http://www.microsoft.com/exchange/library).

Exchange 2003 Security ConsiderationsBefore installing Exchange Server 2003 in your organization, it is important that you are familiar with your organization's security requirements. Familiarizing yourself with these requirements helps ensure that your Exchange 2003 deployment is as secure as possible.

For more information about planning Exchange 2003 security, see the book Planning an Exchange Server 2003 Messaging System (http://www.microsoft.com/exchange/library).

Exchange Server Deployment ToolsThe Exchange Server Deployment Tools are tools and documentation that help with your migration and validate that your organization is prepared for the Exchange 2003 installation. To ensure that all of the required tools and services are installed and running properly, you are required to run Exchange 2003 Setup through the Exchange Server Deployment Tools.

Note   You must download the latest version of the Exchange Server Deployment Tools before you run them. To receive the latest version of the tools, see Exchange Server 2003 Tools and Updates (http://www.microsoft.com/exchange/2003/updates).

To start the Microsoft Exchange Server 2003 Deployment Tools1. Insert the Exchange Server 2003 CD into your CD-ROM drive.2. On the Welcome to Exchange Server 2003 Setup page, click Exchange Deployment

Tools.3. If the Welcome to Exchange Server 2003 Setup page does not appear after you insert

your CD, double-click Setup.exe, and then click Exchange Deployment Tools to begin.

4. Follow the step-by-step instructions in the Exchange Server Deployment Tools documentation.

After you start the tools and specify that you want to follow the process for Coexistence with Exchange 5.5, you are provided with a checklist detailing the installation steps. This checklist is separated into three phases:Phase 1

Verify that your organization meets the specified requirements. Run the DCDiag tool. Run the NetDiag tool.

Phase 2 Run ForestPrep. Run DomainPrep. Run Active Directory Connector Setup. Run Active Directory Connector tools.

Phase 3 Run Exchange Setup.

Important   You should not run Exchange Setup until you have completed running the Exchange Server Deployment Tools. Before you can install your first Exchange 2003 server, Exchange Setup verifies that the tools are completed and your organization is in a healthy state.

With the exception of running the DCDiag and NetDiag tools, each of these installation steps is detailed later in this chapter (it is recommended that you run the DCDiag and NetDiag tools on every server on which you plan to install Exchange 2003). Moreover, the remaining sections in this chapter provide information about the concepts and considerations involved in migrating from Exchange 5.5 to Exchange 2003.

Active Directory and Exchange 5.5 ConsiderationsBefore installing Exchange 2003, you should familiarize yourself with certain Active Directory and Exchange 5.5 directory considerations. Specifically, this section will provide you with information about migrating your Windows user accounts and synchronizing your Exchange 5.5 directory with Active Directory.

Exchange Directory Service and Windows NT User AccountsIn Microsoft Windows NT® Server version 4.0 and Exchange 5.5, when you create a user and assign that user a mailbox, you associate a Windows NT user account with a mailbox object in the Exchange directory. A Windows security identifier (SID) is a unique number that makes this association. Every computer and user account on a network running Windows NT has a SID.

Active Directory User Objects and Directory SynchronizationUnlike earlier versions of Exchange and Windows NT, Active Directory contains a single object that has default user attributes and Exchange-specific attributes. When you populate Active Directory with user objects in an organization that includes an earlier version of Exchange, the user objects in Active Directory do not include Exchange-specific attributes. When you install Exchange 2003, Exchange extends user objects in Active Directory to include Exchange-specific attributes.Exchange 5.5 has its own directory service, which, by default, cannot communicate with Active Directory and Exchange 2003. Therefore, Exchange 2003 Active Directory

Connector (ADC) is used to allow communication and synchronization between the Exchange 5.5 directory and Active Directory.ADC populates and synchronizes Active Directory with mailbox, custom recipient, distribution list, and public folder information from the Exchange 5.5 directory. Similarly, ADC also populates and synchronizes the Exchange 5.5 directory with user, contact, and group information from Active Directory. For more information about using ADC, see "Active Directory Connector" later in this chapter.

Populating Active DirectoryBefore synchronization can occur, you must populate Active Directory with user information from your existing directory service. Active Directory is populated when your Windows NT 4.0 user account information and Exchange-specific object information from your Exchange 5.5 directory service reside in Active Directory. Your deployment plan may require a combination of the methods described in the following section.

Populating User Information from Windows NTTo populate Active Directory with Windows NT user account information from an existing Windows NT 4.0 deployment, use one or both of the following methods: Upgrade existing Windows NT 4.0 user accounts to Active Directory user

accounts. Use Active Directory Migration Tool to create cloned user accounts that preserve

security information. Note   These methods provide a phased approach to populating Active Directory for Exchange Server 2003. Although the following sections discuss these methods briefly, a complete discussion about these methods is outside the scope of this document. How you formulate your deployment strategy depends on your domain structure, deployment timeline, Windows server operating system upgrade plan, and business needs. Be sure to construct a thorough deployment plan before you implement any of the following methods. For conceptual and procedural information about upgrading user accounts, Active Directory Migration Tool, Windows NT 4.0, Windows 2000, and Windows Server 2003, see Windows Help and the Microsoft Windows Web site (http://www.microsoft.com/windows).

Upgrading Existing User AccountsOne method of populating Active Directory is to upgrade the Windows NT primary domain controller in the domain that contains your user accounts to a Windows 2000 or Windows Server 2003 domain controller. When you upgrade a Windows NT user account, you preserve all account information, including the SID.

Using Active Directory Migration ToolAnother method of populating Active Directory is to use Active Directory Migration Tool to clone the accounts in Active Directory. A cloned account is an account in a Windows 2000 or Windows Server 2003 domain that has been copied from a Windows NT 4.0 source account to a new (cloned) user object in Active Directory. Although the new user object has a different SID than the source account, the SID of the source account is copied to the new user object's SIDHistory attribute. Populating the SIDHistory attribute with the source account SID allows the new

user account to access all network resources available to the source account, providing that trusts exist between resource domains and the cloned account domain.When you run Active Directory Migration Tool, you specify a source Windows NT account (or domain) and a target container in Active Directory in which Active Directory Migration Tool creates cloned accounts.

Active Directory ConnectorAfter you populate Active Directory with Windows NT 4.0 user and group accounts, the next step in your migration is to connect your Exchange 5.5 directory to Active Directory. Specifically, you must use either Active Directory Migration Tool or the user domain upgrade method to add Exchange 5.5 mailbox attributes to the Active Directory users and groups that you copied to Active Directory. Synchronizing Active Directory with the Exchange 5.5 directory during the migration process is necessary because Exchange 2003 uses Active Directory as its directory service. Active Directory Connector (ADC) is a synchronization component that updates object changes between the Exchange 5.5 directory and Active Directory. ADC synchronizes current mailbox and distribution list information from the Exchange 5.5 directory to Active Directory user accounts and groups, thereby eliminating the need for re-entering this data in Active Directory. If ADC finds a recipient object in the Exchange directory that does not have a matching SID in Active Directory, ADC creates a user object in Active Directory and stores the existing SID in the msexchmsteraccountSID attribute of the new object. By default, ADC searches for the Windows NT user account SID before searching for a new object's SID history. However, ADC will not find a matching SID in Active Directory if: ADC replicates before correctly upgrading your existing Windows NT 4.0 user

accounts. If your migrated users have problems logging on to their mailboxes after you use Active Directory Migration Tool and Active Directory Connector, you can use the Exchange 2003 Active Directory Account Cleanup Wizard to merge the duplicate objects for mailbox logon purposes.

To run Active Directory Account Cleanup Wizard Click Start, point to All Programs, point to Microsoft Exchange, point to

Deployment, and then click Active Directory Account Cleanup Wizard. Follow the instructions in the wizard to merge your duplicate user objects.Note   While your Exchange 2003 organization coexists with Exchange 5.5, you must use ADC to maintain directory synchronization.

Installing Active Directory ConnectorTo install the Exchange 2003 version of ADC, you must have at least one server in each Exchange site running Exchange 5.5 SP3. The account you use to install ADC must be a member of the Enterprise Administrator, Schema Administrator, and Domain Administrator groups. The account must also be a Local Machine Administrator on the local machine.

To install Active Directory Connector1. Insert the Exchange CD into your CD-ROM drive. You can install ADC on any

computer in the Windows domain.2. On the Start menu, click Run, and then type E:\adc\i386\setup, where E is your CD-

ROM drive.

3. On the Welcome to the Active Directory Connector Installation Wizard page, click Next.

4. On the Component Selection page, select the Microsoft Active Directory Connector Service and the Microsoft Active Directory Connector Management components, and then click Next.

5. On the Install Location page, verify the folder location, and then click Next.6. On the Service Account page, in the Account box, browse to the user or group that

the ADC service will run as, and then click Next.Important   The service account or group you chose must have Local Administrator and built-in Domain Administrator permissions. The account or group that you designate as the ADC service account will have full control of the Exchange organization. Therefore, you should ensure that it is a secure account or group.

7. On the Microsoft Active Directory Connector Setup page, click Finish.

Using Active Directory Connector ToolsADC Tools (shown in Figure 4.1) lead you through the process of confirming that your Exchange 5.5 directory and mailboxes are ready for migration. ADC Tools are a collection of wizards and utilities that help you set up and configure your connection agreements. The tools also ensure that replication between your Windows NT 4.0 organization and Windows 2000 or Windows Server 2003 is functioning properly.ADC Tools are configured to check your organization's configuration and connection agreements and provide a recommendation based on your configuration. It is strongly recommended that you accept the recommendation in Active Directory Connector Tool.

Figure 4.1   The Active Directory Connector Services Tools page

To run ADC Tools1. On your ADC server, click Start, point to All Programs, point to Microsoft Exchange,

and then click Active Directory Connector.2. In the console tree, click ADC Tools.3. Follow the steps indicated in the ADC Tools details pane.Specifically, the ADC Tools lead you through the processes of scanning your directory, running Resource Mailbox Wizard, running Connection Agreement Wizard, and verifying synchronization.

Resource Mailbox WizardThe Resource Mailbox Wizard identifies Active Directory and Windows NT 4.0 accounts that match more than one Exchange 5.5 mailbox. In Windows NT 4.0 and Exchange 5.5, you could have a user account that corresponded to more than one mailbox. Using Active Directory and Exchange 2003, a user account can no longer have more than one mailbox. You can use the Resource Mailbox Wizard to match the appropriate primary mailbox to the Active Directory account and assign other mailboxes with the NTDSNoMatch value, which designates the mailboxes as resource mailboxes. You can either make these changes online using the Resource Mailbox Wizard or export to a comma-separated value (.csv) file that you can update and import into the Exchange 5.5 directory.

Connection Agreement WizardThe Connection Agreement Wizard recommends public folder connection agreements and recipient connection agreements based on your Exchange 5.5 directory and Active Directory configuration. You can then review the recommended connection agreements, and select those that you want the wizard to create. There are three kinds of connection agreements:Recipient connection agreements

Recipient connection agreements replicate recipient objects and the data they contain between the Exchange directory and Active Directory.

Public folder connection agreementsPublic folder connection agreements replicate public folder directory objects between the Exchange 5.5 directory and Active Directory.

Configuration connection agreementsDuring your initial Exchange 2003 installation, Exchange 2003 Setup creates a configuration connection agreement between Active Directory and your Exchange 5.5 site. Configuration connection agreements replicate Exchange-specific configuration information between the Exchange 5.5 directory and Active Directory. These agreements allow Exchange 2003 to coexist with Exchange 5.5.

Figure 4.2   The Active Directory Connector Services page

System-Wide Requirements for Exchange 2003Before you migrate to Exchange Server 2003, ensure that your network and servers meet the following system-wide requirements: You have Windows 2000 Server Service Pack 3 (SP3) Active Directory or

Windows Server 2003 Active Directory. Each Exchange 2003 server has access to a Windows global catalog server that is

no more than one Active Directory site away. You have Domain Name System (DNS) and Windows Internet Name Service

(WINS) configured correctly. You have established NetBIOS, RPC, and TCP/IP connectivity between your

Exchange 5.5 organization and your Windows domain controllers. You backed up your Exchange 5.5 databases, and your servers running

Windows 2000 or Windows Server 2003. You have at least one server in each Exchange site running Exchange 5.5 SP3 to

allow synchronization between the Exchange 5.5 directory and Active Directory.For more information about Windows 2000 Server, Windows Server 2003, Active Directory, and DNS, see the following resources: Windows 2000 Help Windows Server 2003 Help Best Practice: Active Directory Design for Exchange 2000

(http://go.microsoft.com/fwlink/?LinkId=17837) Planning an Exchange Server 2003 Messaging System

(http://www.microsoft.com/exchange/library)

Running Exchange 2003 ForestPrepExchange 2003 ForestPrep extends the Active Directory schema to include Exchange-specific classes and attributes. ForestPrep also creates the container object for the Exchange organization in Active Directory. The schema extensions supplied with Exchange 2003 are a superset of those supplied with Exchange 2000. For information about the schema changes between Exchange 2000 and Exchange 2003, see "Appendix: Exchange 2003 Schema Changes" in the book What's New in Exchange Server 2003 (http://www.microsoft.com/exchange/library).In the domain where the schema master resides, run ForestPrep once in the Active Directory forest. (By default, the schema master runs on the first Windows domain controller installed in a forest.) Exchange Setup verifies that you are running ForestPrep in the correct domain. If you are not in the correct domain, Setup informs you which domain contains the schema master. For information about how to determine which of your domain controllers is the schema master, see Windows 2000 or Windows Server 2003 Help.The account you use to run ForestPrep must be a member of the Enterprise Administrator and the Schema Administrator groups. While you are running ForestPrep, you designate an account or group that has Exchange Full Administrator permissions to the organization object. This account or group has the authority to install and manage Exchange 2003 throughout the forest. This account or group also has the authority to delegate additional Exchange Full Administrator permissions after the first server is installed.

Important   When you delegate Exchange roles to a security group, it is recommend that you use Global or Universal security groups and not Domain Local security groups. Although Domain Local security groups can work, they are limited in scope to their own

domain. In many scenarios, Exchange Setup needs to authenticate to other domains during the installation. Exchange Setup may fail in this case because of a lack of permissions to your external domains.Note   To decrease replication time, it is recommended that you run Exchange 2003 ForestPrep on a domain controller in your root domain.

You can run Exchange 2003 ForestPrep from either the Exchange Server Deployment Tools or from the Exchange 2003 CD. For information about how to run Exchange ForestPrep from the Exchange Server Deployment Tools, see "Exchange Server Deployment Tools" earlier in this chapter.

To run Exchange 2003 ForestPrep1. Insert the Exchange CD into your CD-ROM drive.2. On the Start menu, click Run, and then type E:\setup\i386\setup /ForestPrep, where E

is your CD-ROM drive.3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.4. On the License Agreement page, read the agreement. If you accept the terms, click I

agree, and then click Next.5. On the Product Identification page, type your 25-digit product key, and then click

Next.

6. On the Component Selection page, ensure that Action is set to ForestPrep. If not, click the drop-down arrow, and then click ForestPrep. Click Next (Figure 4.3).

Figure 4.3   The ForestPrep option on the Component Selection pageImportant   If ForestPrep does not appear under Action, you may have misspelled the "ForestPrep" command in Step 2. If this is the case, go back to Step 2 and retype the command.

7. On the Microsoft Exchange Server Administrator Account page, in the Account box, type the name of the account or group that is responsible for installing Exchange (Figure 4.4).

Note   The account that you specify will also have permission to use Exchange Administration Delegation Wizard to create other Exchange administrator accounts. For more information about Exchange Administration Delegation Wizard, see the book Exchange Server 2003 Administration Guide (http://www.microsoft.com/exchange/library).

Figure 4.4   The Microsoft Exchange Server Administrator Account page8. Click Next to start ForestPrep. After ForestPrep starts, you cannot cancel the process.

Note   Depending on your network topology and the speed of your Windows 2000 or Windows 2003 domain controller, ForestPrep may take a considerable amount of time to complete.

9. On the Completing the Microsoft Exchange Wizard page, click Finish.

Running Exchange 2003 DomainPrepAfter you run ForestPrep and allow time for replication, you must run Exchange 2003 DomainPrep. DomainPrep creates the groups and permissions necessary for Exchange servers to read and modify user attributes. The Exchange 2003 version of DomainPrep performs the following actions in the domain: Creates Exchange Domain Servers and Exchange Enterprise Servers groups. Nests the global Exchange Domain Servers into the Exchange Enterprise Servers

local group. Creates the Exchange System Objects container, which is used for mail-enabled

public folders. Sets permissions for the Exchange Enterprise Servers group at the root of the

domain, so that Recipient Update Service has the appropriate access to process recipient objects.

Modifies the AdminSdHolder template where Windows sets permissions for members of the local Domain Administrator group.

Adds the local Exchange Domain Servers group to the Pre-Windows 2000 Compatible Access group.

Performs Setup pre-installation checks.The account you use to run DomainPrep must be a member of the Domain Administrators group in the local domain and a local machine administrator. You must run DomainPrep in the following domains: The root domain. All domains that will contain Exchange 2003 servers. All domains that will contain Exchange Server 2003 mailbox-enabled objects

(such as users and groups), even if no Exchange servers will be installed in these domains.

All domains that will contain Exchange 2003 users and groups that you will use to manage your Exchange 2003 organization.Note   Running DomainPrep does not require any Exchange permissions. Only Domain Administrator permissions are required in the local domain.

You can run Exchange 2003 DomainPrep from either the Exchange Server Deployment Tools or from the Exchange 2003 CD. For information about how to run Exchange DomainPrep from the Exchange Server Deployment Tools, see "Exchange Server Deployment Tools" earlier in this chapter.

To run Exchange 2003 DomainPrep1. Insert the Exchange CD into your CD-ROM drive. You can run DomainPrep on any

computer in the domain.2. From a command prompt, type E:\setup\i386\setup /DomainPrep, where E is your

CD-ROM drive.3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.4. On the License Agreement page, read the agreement. If you agree to the terms, click I

agree, and then click Next. 5. On the Product Identification page, type your 25-digit product key, and then click

Next.6. On the Component Selection page, ensure that Action is set to DomainPrep. If not,

click the drop-down arrow, and then click DomainPrep. Click Next (Figure 4.5).

Figure 4.5   The DomainPrep option on the Component Selection pageImportant   If DomainPrep does not appear in the Action list, you may have misspelled the "DomainPrep" command in Step 2. If this is the case, go back to Step 2 and retype the command.

7. On the Completing the Microsoft Exchange Wizard page, click Finish.

Server-Specific Requirements for Exchange 2003Before you install Exchange 2003, ensure that your servers meet the requirements that are described in this section. If your servers do not meet all of the requirements, Exchange Setup will stop the installation.

Hardware RequirementsThe following are the minimum hardware requirements for Exchange 2003 servers: Intel Pentium or compatible 133 megahertz (MHz) or faster processor 256 megabytes (MB) of RAM recommended minimum, 128 MB supported

minimum 500 MB of available disk space on the drive on which you install Exchange 200 MB of available disk space on the system drive CD-ROM drive SVGA or higher-resolution monitor

For more information about hardware requirements, for front-end and back-end servers, see the book Using Microsoft Exchange 2000 Front-End Servers (http://go.microsoft.com/fwlink/?linkid=14575&clcid=0x409).

File Format RequirementsTo install Exchange 2003, disk partitions must be formatted for NTFS file system and not for file allocation table (FAT). This requirement applies to the following partitions: System partition Partition that stores Exchange binaries Partitions containing transaction log files Partitions containing database files Partitions containing other Exchange files

Operating System RequirementsExchange Server 2003 is supported on the following operating systems: Windows 2000 SP3 or later

Note   Windows 2000 SP3 or later is available for download at http://go.microsoft.com/fwlink/?LinkId=18353. Windows 2000 SP3 or later is also a prerequisite for running Exchange 2003 ADC.

Windows Server 2003

Installing and Enabling Windows 2000 or Windows Server 2003 ServicesExchange 2003 Setup requires that the following components and services be installed and enabled on the server: .NET Framework ASP.NET Internet Information Services (IIS) World Wide Web Publishing Service Simple Mail Transfer Protocol (SMTP) service Network News Transfer Protocol (NNTP) service

If you are installing Exchange 2003 on a server running Windows 2000, Exchange Setup installs and enables the Microsoft .NET Framework and ASP.NET automatically. You must install the World Wide Web Publishing Service, SMTP service, and NNTP service before running Exchange Server 2003 Installation Wizard.

Important   When you install Exchange on a new server, only the required services are enabled. For example, Post Office Protocol version 3 (POP3), Internet Message Access Protocol version 4 (IMAP4), and NNTP services are disabled by default on all of your Exchange 2003 servers. You should enable only services that are essential for performing Exchange 2003 tasks.

To install services in Windows 20001. Click Start, point to Settings, and then click Control Panel.2. Double-click Add/Remove Programs.3. Click Add/Remove Windows Components.4. Click Internet Information Services (IIS), and then click Details.5. Select the NNTP Service, SMTP Service, and World Wide Web Service check boxes.6. Click OK.7. Click Next, and when the Windows Components Wizard completes, click Finish.

Note   Ensure that the Internet Information Services (IIS) check box is selected.

To install services in Windows Server 20031. Click Start, point to Control Panel, and then click Add or Remove Programs.2. In Add or Remove Programs, click Add/Remove Windows Components.3. In Windows Component Wizard, on the Windows Components page, highlight

Application Server, and then click Details.4. In Application Server, select the ASP.NET check box (Figure 4.6).

Figure 4.6   The Application Server dialog box5. Highlight Internet Information Services (IIS), and then click Details.

6. In Internet Information Services (IIS), select the NNTP Service, SMTP Service, and World Wide Web Service check boxes, and then click OK (Figure 4.7).

Figure 4.7   The Internet Information Services (IIS) dialog box7. In Application Server, ensure that the Internet Information Services (IIS) check box is

selected, and then click OK to install the components.Note   Do not select the E-mail Services check box.

8. Click Next, and when the Windows Components Wizard completes, click Finish.9. Perform the following steps to enable ASP.NET:

a. Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.

b. In the console tree, expand the local computer, and then click Web Service Extensions.

c. In the details pane, click ASP.NET, and then click Allow.

Running Exchange 2003 SetupAfter planning and preparing your Exchange organization in accordance with the requirements and procedures listed in this chapter, you are ready to run Exchange 2003 Setup. When running Setup, it is recommended that you join your existing Exchange 5.5 organization. By joining your Exchange 5.5 organization, you can move your mailboxes and public folders more easily.

To run Exchange 2003 Setup1. Log on to the server on which you want to install Exchange. Insert the Exchange

Server 2003 CD into your CD-ROM drive.2. On the Start menu, click Run and type E:\setup\i386\setup.exe, where E is your CD-

ROM drive.3. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.4. On the License Agreement page, read the agreement. If you agree to the terms, click I

agree, and then click Next.5. On the Product Identification page, type your 25-digit product key, and then click

Next.

6. On the Component Selection page, in the Action column, use the drop-down arrows to specify the appropriate action for each component, and then click Next (Figure 4.8).

Figure 4.8   The Component Selection pageNote   It is recommended that you install the Microsoft Exchange 5.5 Administrator program on your Exchange 2003 server. Click and select Install on the Component Selection page.

7. On the Installation Type page, click Join or upgrade an existing 5.5 Exchange Organization, and then click Next (Figure 4.9).

Figure 4.9   The Installation Type pageImportant   If you select Create a new Exchange Organization, you must use the Exchange 2003 Migration Wizard to move your mailboxes from your old Exchange 5.5 organization to your newly created Exchange 2003 organization. For information about using the Exchange 2003 Migration Wizard, see Chapter 5 "Inter-Organizational Migration".

8. On the Select a Server in an Exchange 5.5 Organization page, in the Exchange Server 5.5 Name box, type the name of an Exchange 5.5 SP3 server in the site you want to join, and then click Next.

Note   Before setup starts, Exchange Setup performs specific checks on your organization, including service pack versions, Windows 2000 version checks, and interoperability with Exchange 5.5. Therefore, all Exchange 5.5 servers in your administrative groups must be up and running before you start Exchange Setup. Exchange Setup also contacts the Exchange 5.5 server and performs checks against Active Directory. If Exchange Setup detects that you have not completed running the ADC Tools, Setup will stop. If you have not completed the ADC Tools, see "Using Active Directory Connector Tools" earlier in this chapter.

9. On the License Agreement page, read the agreement. If you agree to the terms, click I agree that I have read and will be bound by the license agreements for this product, and then click Next.

10. On the Service Account page, type the password for your Exchange 5.5 service account.

11. On the Installation Summary page, confirm that your Exchange installation choices are correct, and then click Next (Figure 4.10).

Figure 4.10   The Installation Summary page12. On the Completing the Microsoft Exchange Wizard page, click Finish.To verify that your Exchange installation was successful, see Appendix A, "Post-Installation Steps."

Moving Exchange 5.5 Mailbox and Public Folder ContentsAfter you have populated Active Directory with Windows NT 4.0 objects, connected the Exchange 5.5 directory to Active Directory, and installed your first Exchange 2003 server into the Exchange 5.5 site, your next migration task is to move your Exchange 5.5 mailbox and public folder contents into the Exchange 2003 organization.This section provides information about using Exchange Task Wizard to move your mailbox contents and using Microsoft Exchange Public Folder Migration Tool (pfMigrate) to move your public folder contents.

Using Exchange Move Mailbox in Task WizardExchange Task Wizard provides an improved method for moving mailboxes. You can now select as many mailboxes as you want, and then using the task scheduler, schedule a move to occur at a specified time. You can also use the task scheduler to cancel any unfinished moves at a specified time. For example, you can schedule a large move to start at midnight on Friday and terminate automatically at 6:00 A.M. on Monday, thereby ensuring that your server's resources are not being used during regular business hours. Using the wizard's improved multithreaded capabilities, you can move as many as four mailboxes simultaneously.

To run Exchange 2003 Task Wizard1. On your Exchange 2003 computer, click Start, point to All Programs, point to

Microsoft Exchange, and then click System Manager.2. In the console tree, expand Servers, expand the server from which you want to move

mailboxes, expand the Storage Group from which you want to move mailboxes, expand the Mailbox Store you want, and then click Mailboxes.

3. In the details pane, right-click the user or users you want, and then click Exchange Tasks.

4. In Exchange Task Wizard, on the Available Tasks page, click Move Mailbox, and then click Next.

5. On the Move Mailbox page, to specify the new destination for the mailbox, in the Server list, select a server, and then in the Mailbox Store list, select a mailbox store. Click Next.

6. Under If corrupted messages are found, click the option you want, and then click Next.

Note   If you click Skip corrupted items and create a failure report, these items are lost permanently when the mailbox is moved. To avoid data loss, back up the source database before moving mailboxes.

7. On the Task Schedule page, in the Begin processing tasks at list, select the date and time for the move. If you want to cancel any unfinished moves at a specified time, in the Cancel tasks that are still running after list, select the date and time. Click Next to start the process.

8. On the Completing the Exchange Task Wizard page, verify that the information is correct, and then click Finish.

Using Microsoft Exchange Public Folder Migration ToolThe Microsoft Exchange Public Folder Migration Tool (pfMigrate) is a new tool that enables you to migrate both system folders and public folders to the new server. You can use pfMigrate to create system folder and public folder replicas on the new server and,

after the folders have replicated, remove replicas from the source server. Unlike Exchange 5.5, you do not need to set a home server for a public folder in Exchange Server 2003. Any replica acts as the primary replica of the data it contains, and any public folder server can be removed from the replica list.To determine how many system folders or public folders need to be replicated, use pfMigrate to generate a report before you actually run the tool. To determine whether the folders replicated successfully, you can generate the same report after you run the tool. The pfMigrate tool is run from the Exchange Server Deployment Tools. For information about how to start Exchange Server Deployment Tools, see "Exchange Server Deployment Tools" earlier in this chapter.

To run pfMigrate1. In Exchange Server Deployment Tools, on the Welcome to the Exchange Server

Deployment Tools page, click Deploy the first Exchange 2003 server.2. On the Deploy the First Exchange 2003 Server page, in the Follow this process

column, click Coexistence with Exchange 5.5.3. On the Coexistence with Exchange 5.5 page, click Phase 3.4. On the Phase 3. Installing Exchange Server 2003 on the Initial Server page, click

Next.5. On the Install Exchange 2003 on Additional Servers page, click Next.6. On the Post-Installation Steps page, under Moving System Folders and Public

Folders, click move system folders and public folders, and then follow the steps listed to complete your public folder migration.Note   After you run pfMigrate, only the hierarchy of the system folders and public folders is migrated immediately. You must wait for replication for the contents of the system folders and public folders to be migrated. Depending on the size and number of system and public folders, as well as your network speed, replication could take a considerable amount of time.

Switching from Mixed Mode to Native ModeBecause Exchange 2003 is structured to take advantage of Active Directory functionality, there are some limitations when Exchange 2003 coexists in the same organization with Exchange 5.5. When Exchange 2003 servers coexist with Exchange 5.5, your organization must run in mixed mode. Running in mixed mode limits the functionality of Exchange 2003. Therefore, after migrating from Exchange 5.5 to Exchange 2003, it is recommended that you switch from mixed mode to native mode. This section discusses the advantages of a native-mode Exchange organization and provides the steps to switch from mixed mode to native mode.You are ready to change your Exchange 2003 organization to native mode if: Your organization will never require interoperability between your

Exchange 2003 servers and Exchange 5.5 servers in the same organization. Your Exchange 5.5 servers exist in an organization that is separate from your

Exchange 2003 servers.Note   After you switch your Exchange 2003 organization from mixed mode to native mode, you cannot switch the organization back to mixed mode. Make sure that your Exchange 2003 organization will not have to interoperate with Exchange 5.5 in the future before you switch from mixed mode to native mode.

First, you should determine in which mode your Exchange organization is currently running.

To determine the operating mode of your Exchange organization1. In Exchange System Manager, right-click the Exchange organization for which you

want to determine the operating mode, and then click Properties.2. On the General tab, under Operation mode, the operating mode of your organization

is displayed.

Exchange 2003 Considerations for Mixed and Native Mode As mentioned earlier, after you migrate from Exchange 5.5 to Exchange 2003, by default, your organization runs in mixed mode. Running Exchange 2003 in mixed mode has the following disadvantages: Exchange 5.5 sites are mapped directly to administrative groups. Administrative groups are mapped directly to Exchange 5.5 sites. Routing group membership consists only of servers that are installed in the

administrative groups. You cannot move Exchange 2003 servers between routing groups.Because many Exchange 2003 features are available only when you run your Exchange 2003 organization in native mode, it is recommended that you switch from mixed mode to native mode. Running Exchange 2003 in native mode has the following advantages: You can create query-based distribution groups. A query-based distribution group

provides the same functionality as a standard distribution group. However, instead of specifying static user memberships, with a query-based distribution group you can use an LDAP query to build membership in the distribution group dynamically. For more information about query-based distribution groups, see "Managing Recipients and Recipient Policies" in the book Exchange Server 2003 Administration Guide (http://www.microsoft.com/exchange/library).

Your routing bridgehead server pairs use 8BITMIME data transfers instead of converting down to 7-bit. This equates to a considerable bandwidth saving over routing group connectors.

The Exchange store in Exchange 2003 ignores and removes zombie access control entries (ACEs) from the previous Exchange 5.5 servers in your organization automatically. These zombie access control entries are security identifiers from previous Exchange 5.5 servers that have been removed from your organization.

Routing groups can consist of servers from multiple administrative groups. You can move Exchange 2003 servers between routing groups. You can move mailboxes between administrative groups. Simple Mail Transfer Protocol (SMTP) is the default routing protocol.

Removing the Last Exchange 5.5 ServerBefore you can switch from mixed mode to native mode, you must remove all Exchange 5.5 servers in your site. This section guides you through the process of removing the last Exchange 5.5 server from you organization. For more information about removing your Exchange 5.5 servers, refer to the Exchange 5.5 SP3 documentation.

Note   Ensure that the account to which you are logged on has Exchange Full Administrator permissions, as well as Exchange 5.5 service account Administrator permissions to the site.

To remove the last Exchange 5.5 server1. In Exchange System Manager, in the console tree, expand Administrative Groups,

expand the administrative group you want, expand Folders, and then click Public Folders.

2. Right-click Public Folders, and then click View System Folders.3. Under System Folders, click to expand Offline Address Book. The offline address

book should be in the following format: EX:/O=ORG/OU=Site.4. Right-click the offline address book, click Properties, and then click the Replication

tab. Verify that Replicate content to these Public Stores has an Exchange 2003 computer listed. If a replica does not exist on an Exchange 2003 computer, click the Add button to add a replica to an Exchange 2003 computer.

5. Repeat Steps 3 and 4 for Schedule+ Free Busy Folder and Organization Forms.Note   If Exchange 5.5 public folders are present on the computer running Exchange 5.5, you can use the pfMigrate tool that is available with the Exchange Deployment Tools to move your public folders to an Exchange 2003 server. For more information, see "Exchange Server Deployment Tools" and "Using Microsoft Exchange Public Folder Migration Tool" earlier in this chapter.

6. Move any connectors (for example site connectors or directory replication connectors) on this computer to an SRS server in your site.

7. Wait for public folder, Schedule+ Free Busy, and Organization Forms information to replicate before you begin the next steps.

8. From an Exchange 2003 or Exchange Server 5.5 computer, start the Exchange Server 5.5 Administrator program. When you receive the prompt for a server to connect to, type the name of the Exchange 2003 SRS server for that administrative group.

Note   You cannot delete an Exchange 5.5 computer if you are connected to it with the Exchange Administrator program. Make sure you are not connected to any Exchange 5.5 servers that you want to remove.

9. Under Configuration, click to expand the Servers node. Click the Exchange Server 5.5 computer that you want to remove from the administrative group, and then press Delete.

10. From the Active Directory Connector Tool MMC snap-in, right-click the Config_CA_SRS_Server_Name object, and then click Replicate Now. The Exchange Administrator program also removes the Exchange Server 5.5 computer from the SRS database. The Config_CA object "reads" this delete, and then replicates it to Active Directory.

Removing Site Replication ServiceSite Replication Service (SRS) is a component that exchanges configuration information between Active Directory and the directory in Exchange 5.5. In Exchange 5.5, SRS is necessary because Exchange 5.5 configuration information can only be exchanged between Exchange 5.5 servers and Exchange 5.5 directories—not with Active Directory. SRS mimics an Exchange 5.5 directory so that other Exchange 5.5 servers can replicate information to it. Using the configuration connection agreement created by Exchange Setup, Active Directory Connector replicates the configuration information in SRS into Active Directory. SRS runs only in a mixed-mode Exchange administrative group. SRS also performs additional functions, such as detecting and reacting to directory replication topology changes. You cannot switch from mixed mode to native mode until you have removed all instances of SRS.SRS is enabled automatically in two situations: On the first Exchange 2003 server you install in an Exchange 5.5 organization. When you upgrade to Exchange 2000 from an Exchange 5.5 server that is the

directory replication bridgehead server for an organization.To remove Exchange SRS

1. From the Active Directory Connector Tool MMC snap-in, navigate to your recipient connection agreements. To remove any recipient connection agreements that exist in your Exchange organization, right-click the connection agreement, and then click Delete.

2. Either from another Exchange 5.5 server, or directly from the Exchange 2003 server that is running SRS, open the Exchange 5.5 Administrator program. This is typically the first Exchange 2003 server installed in an Exchange 5.5 site. Click File, click Connect to Server, and then type the name of the Exchange 2003 server running SRS.

3. In the Exchange 5.5 Administrator program, expand the local site name (displayed in bold), expand Configuration, click Directory Replication Connectors, and then delete any directory replication connectors that exist.

Important   Do not delete the ADNAutoDRC connector listed under Directory Replication Connectors.

4. Allow time for the changes that you made in Exchange Administrator to replicate to the configuration connection agreements (Config CAs) to Active Directory.

5. In Exchange System Manager, ensure that no Exchange 5.5 computers are displayed in any administrative groups.

6. In Exchange System Manager, expand Tools, and click Site Replication Services. From the details pane right-click each SRS, and then click Delete. When you do so, the SRS and corresponding Config CA for that SRS are deleted.

7. After all instances of SRS are deleted, remove the Active Directory Connector (ADC) service.

After you complete these steps, you can convert the Exchange organization to native mode.

Switching to Native ModeUse the following procedure to switch your Exchange organization from mixed mode to native mode.

Important   After you switch your Exchange 2003 organization from mixed mode to native mode, you cannot switch the organization back to mixed mode. Before you perform the following procedure, ensure that your Exchange 2003 organization will not have to interoperate with Exchange 5.5 in the future.

To switch to native mode1. Start Exchange System Manager: Click Start, point to All Programs, point to

Microsoft Exchange, and then click System Manager.2. In the console tree, right-click the organization that you want to switch to native

mode, and then click Properties.3. In <Organization Name> Properties, under Change operation mode, click Change

Mode.4. In the warning dialog box, click Yes if you are sure that you want to permanently

switch to native mode. Click Apply to accept your new Exchange mode.To take full advantage of Exchange native mode, you must restart the Microsoft Exchange Information Store service on all of the Exchange servers in your organization. You do not need to restart all of the Microsoft Exchange Information Store services simultaneously, but you must restart the service on each server for the server to take advantage of all Exchange native mode features. Restart the service on your servers after the change to native mode has been replicated to your local Windows domain controller. To determine whether the changes have been replicated to your local domain controller, refer to the procedure "To determine the operating mode of your Exchange organization" in the section "Switching from Mixed Mode to Native Mode" earlier in this chapter.

To restart the Microsoft Exchange Information Store service1. On the Start menu, click Run, type services.msc, and then click OK.2. In the Services (Local) pane, find the Microsoft Exchange Information Store service.3. Right-click the service and click Restart.Note   In the <Organization Name> Properties dialog box, the Change Mode button is unavailable if any Exchange 5.5 servers are present or SRS exists in the organization.

C H A P T E R   6

Upgrading from Mixed Exchange 2000 and Exchange 5.5 OrganizationsThis chapter provides instructions for upgrading from a mixed Microsoft® Exchange 2000 Server and Exchange Server 5.5 organization to an Exchange Server 2003 organization. Furthermore, because it is recommended that you run your new Exchange 2003 organization in native mode, this chapter discusses the advantages of native mode and provides instructions for switching from mixed mode to native mode. Specifically, this chapter will:

Provide you with the information necessary to upgrade your Exchange 2000 and Exchange 5.5 organization to Exchange 2003.

Provide you with information about running Exchange Server 2003 Deployment Tools.

Show you how to use the Active Directory Tool. Show you how to run ForestPrep. Show you how to run DomainPrep. Show you how to upgrade your Exchange 2000 servers to Exchange 2003. Provide you with the information necessary to install a new Exchange 2003

server.Note   You can install a new Exchange 2003 server before upgrading your existing Exchange 2000 servers. It is not necessary that you perform the upgrade first.

Provide you with the information necessary to migrate your Exchange 5.5 mailboxes and public folders to Exchange 2003.

Provide you with information about how to switch your Exchange organization from mixed mode to native mode.

Provide you with information about removing Exchange 2000 tuning parameters.

Procedures in Chapter 6After helping you ensure that your organization meets the necessary prerequisites, the procedures in this chapter guide you through the deployment process. Table 6.1 lists the specific procedures that are detailed in this chapter, as well as the permissions that are required so that you can perform them.

Table 6.1   Chapter 6 procedures and corresponding permissionsProcedure Required permissions or rolesEnable Microsoft Windows® 2000 Server or Microsoft Windows Server™ 2003 services

See Windows 2000 or Windows Server 2003 Help

Run ForestPrep on a domain controller (updates the Active Directory schema)

Enterprise Administrator Schema Administrator Domain Administrator Local Machine Administrator

Run DomainPrep Domain Administrator Local Machine Administrator

Install Active Directory Connector (ADC)

Enterprise Administrator Schema Administrator Domain Administrator Local Machine Administrator

Install Exchange 2003 on the first server in a domain

Exchange Full Administrator role applied at the organization level

Exchange 5.5 Administrator under the organization, site, and configuration nodes (if installing into an Exchange 5.5 site)

Procedure Required permissions or roles Local Machine Administrator

Install Exchange 2003 on additional servers in the domain

Exchange Full Administrator role applied at the administrative group level

Exchange 5.5 Site Administrator (if installing into an Exchange 5.5 site)

Local Machine AdministratorInstall Exchange 2003 on a server that is running Site Replication Service (SRS)

Exchange Full Administrator role applied at the organization level

Local Machine Administrator Exchange 5.5 Service Account password

Upgrade to Exchange 2003 on an Exchange 2000 server in a domain

Exchange Full Administrator role applied at the organization level

Local Machine Administrator

For more information about managing and delegating permissions and user and group authorities, see the book Exchange Server 2003 Administration Guide (http://www.microsoft.com/exchange/library).

Exchange 2003 Security ConsiderationsBefore installing Exchange Server 2003 in your organization, it is important that you are familiar with your organization's security requirements. Familiarizing yourself with these requirements helps ensure that your Exchange 2003 deployment is as secure as possible. For more information about planning Exchange 2003 security considerations, see the book Planning an Exchange Server 2003 Messaging System (http://www.microsoft.com/exchange/library).

Exchange Server Deployment ToolsThe Exchange Server Deployment Tools are tools and documentation that help with the upgrade and migration of your Exchange 2000 and Exchange 5.5 organization. To ensure that all of the required tools and services are installed and running properly, you are required to run Exchange 2003 Setup through the Exchange Server Deployment Tools.

Note   You must download the latest version of the Exchange Server Deployment Tools before you run them. To receive the latest version of the tools, see Exchange Server 2003 Tools and Updates (http://www.microsoft.com/exchange/2003/updates).

To start the Microsoft Exchange Server 2003 Deployment Tools1. Insert the Exchange Server 2003 CD into your CD-ROM drive.2. On the Welcome to Exchange Server 2003 Setup page, click Exchange Deployment

Tools.3. If the Welcome to Exchange Server 2003 Setup page does not appear after you insert

your CD, double-click Setup.exe, and then click Exchange Deployment Tools to begin.

4. Follow the step-by-step instructions in the Exchange Server Deployment Tools documentation.

After you start the tools and specify that you want to follow the process for Coexistence with Mixed Mode Exchange 2000 and Exchange 5.5, you are provided with the following options:Upgrade Active Directory Connector servers

This option includes a checklist for upgrading your ADC servers. This checklist includes the following steps: Run ForestPrep. Run DomainPrep. Run ADC Setup. Run ADC Tools. Update ADC version on all servers before you upgrade your Exchange 2000

servers.Install or Upgrade the First Exchange Server

This option includes a checklist for installing or upgrading to Exchange 2003. This checklist includes the following steps: Verify that your organization meets the specified requirements. Remove unsupported components. Run the DCDiag tool. Run the NetDiag tool. Run Exchange Setup.

With the exception of running the DCDiag and NetDiag tools, each of these installation steps is detailed later in this chapter (it is recommended that you run the DCDiag and NetDiag tools on every server on which you plan to install Exchange 2003). Moreover, the remaining sections in this chapter provide information about the concepts and considerations involved in migrating from Exchange 5.5 to Exchange 2003.

System-Wide Requirements for Exchange 2003Before you install Exchange Server 2003, ensure that your network and servers meet the following system-wide requirements: You have Windows 2000 Server Service Pack 3 (SP3) or Windows Server 2003

Active Directory. Each Exchange 2003 server has access to a Windows global catalog server that is

no more than one Active Directory site away. You have Domain Name System (DNS) and Windows Internet Name Service

(WINS) configured correctly in your Windows site. You backed up your Exchange 5.5 databases, and backed up your servers running

Windows 2000 or Windows Server 2003.For more information about Windows 2000 Server, Windows Server 2003, Active Directory, and DNS, see the following resources: Windows 2000 Help Windows Server 2003 Help Best Practice: Active Directory Design for Exchange 2000

(http://go.microsoft.com/fwlink/?LinkId=17837) Planning an Exchange Server 2003 Messaging System

(http://www.microsoft.com/exchange/library)

Running Exchange 2003 ForestPrepEven if you previously ran Exchange 2000 ForestPrep, you must still run Exchange 2003 ForestPrep. Exchange 2003 ForestPrep extends the Active Directory schema to include Exchange-specific classes and attributes. ForestPrep also creates the container object for the Exchange organization in Active Directory. The schema extensions supplied with Exchange 2003 are a superset of those supplied with Exchange 2000. For information about the schema changes between Exchange 2000 and Exchange 2003, see "Appendix: Exchange 2003 Schema Changes" in the book What's New in Exchange Server 2003 (http://www.microsoft.com/exchange/library).

In the domain where the schema master resides, run ForestPrep once in the Active Directory forest. (By default, the schema master runs on the first Windows domain controller installed in a forest.) Exchange Setup verifies that you are running ForestPrep in the correct domain. If you are not in the correct domain, Setup informs you which domain contains the schema master. For information about how to determine which of your domain controllers is the schema master, see Windows 2000 or Windows Server 2003 Help.The account you use to run ForestPrep must be a member of the Enterprise Administrator and the Schema Administrator groups. While you are running ForestPrep, you designate an account or group that has Exchange Full Administrator permissions to the organization object. This account or group has the authority to install and manage Exchange 2003 throughout the forest. This account or group also has the authority to delegate additional Exchange Full Administrator permissions after the first server is installed.

Important   When you delegate Exchange roles to a security group, it is recommend that you use Global or Universal security groups and not Domain Local security groups. Although Domain Local security groups can work, they are limited in scope to their own domain. In many scenarios, Exchange Setup needs to authenticate to other domains during the installation. Exchange Setup may fail in this case because of a lack of permissions to your external domains. The account or group your select does not override your previous account or previous delegations, it adds to them.Note   To decrease replication time, it is recommended that you run Exchange 2003 ForestPrep on a domain controller in your root domain.

You can run Exchange 2003 ForestPrep from either the Exchange Server Deployment Tools or from the Exchange 2003 CD. For information about how to run Exchange ForestPrep from the Exchange Server Deployment Tools, see "Exchange Server Deployment Tools" earlier in this chapter.

To run Exchange 2003 ForestPrep5. Insert the Exchange CD into your CD-ROM drive.6. On the Start menu, click Run and type E:\setup\i386\setup/ForestPrep, where E is

your CD-ROM drive.7. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.8. On the License Agreement page, read the agreement. If you accept the terms, click I

agree, and then click Next.9. On the Product Identification page, type your 25-digit product key, and then click

Next.

10. On the Component Selection page, ensure that Action is set to ForestPrep. If not, click the drop-down arrow, and then click ForestPrep. Click Next (Figure 6.1).

Figure 6.1   The ForestPrep option on the Component Selection pageImportant   If ForestPrep does not appear under Action, you may have misspelled the "ForestPrep" command in Step 2. If this is the case, go back to Step 2 and retype the command.

11. On the Microsoft Exchange Server Administrator Account page, in the Account box, type the name of the account or group that is responsible for installing Exchange (Figure 6.2).

Note   The account that you specify will also have permission to use Exchange Administration Delegation Wizard to create other Exchange administrator accounts. For more information about Exchange Administration Delegation Wizard, see the book Exchange Server 2003 Administration Guide (http://www.microsoft.com/exchange/library).

Figure 6.2   The Microsoft Exchange Server Administrator Account page12. Click Next to start ForestPrep. After ForestPrep starts, you cannot cancel the process.

Note   Depending on your network topology and the speed of your Windows 2000 or Windows 2003 domain controller, ForestPrep may take a considerable amount of time to complete.

13. On the Completing the Microsoft Exchange Wizard page, click Finish.

Running Exchange 2003 DomainPrepAfter you run ForestPrep and allow time for replication, you must run Exchange 2003 DomainPrep. DomainPrep creates the groups and permissions necessary for Exchange servers to read and modify user attributes. Even if you previously ran Exchange 2000 DomainPrep, you must run Exchange 2003 DomainPrep. The Exchange 2003 version of DomainPrep performs the following actions in the domain: Creates Exchange Domain Servers and Exchange Enterprise Servers groups. Nests the global Exchange Domain Servers into the Exchange Enterprise Servers

local group. Creates the Exchange System Objects container, which is used for mail-enabled

public folders. Sets permissions for the Exchange Enterprise Servers group at the root of the

domain so that Recipient Update Service has the appropriate access to process recipient objects.

Modifies the AdminSdHolder template where Windows sets permissions for members of the local Domain Administrator group.

Adds the local Exchange Domain Servers group to the Pre-Windows 2000 Compatible Access group.

Performs Setup pre-installation checks.The account you use to run DomainPrep must be a member of the Domain Administrators group in the local domain and a local machine administrator. You must run DomainPrep in the following domains: The root domain. All domains that will contain Exchange 2003 servers. All domains that will contain Exchange Server 2003 mailbox-enabled objects

(such as users and groups), even if no Exchange servers will be installed in these domains.

All domains that will contain Exchange 2003 users and groups that you will use to manage your Exchange 2003 organization.Note   Running DomainPrep does not require any Exchange permissions. Only Domain Administrator permissions are required in the local domain.

You can run Exchange 2003 DomainPrep from either the Exchange Server Deployment Tools or from the Exchange 2003 CD. For information about how to run Exchange DomainPrep from the Exchange Server Deployment Tools, see "Exchange Server Deployment Tools" earlier in this chapter.

To run Exchange DomainPrep14. Insert the Exchange CD into your CD-ROM drive. You can run DomainPrep on any

computer in the domain.15. From a command prompt, type E:\setup\i386\setup/DomainPrep, where E is your CD-

ROM drive.16. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.17. On the License Agreement page, read the agreement. If you agree to the terms, click I

agree, and then click Next. 18. On the Product Identification page, type your 25-digit product key, and then click

Next.19. On the Component Selection page, ensure that Action is set to DomainPrep. If not,

click the drop-down arrow, and then click DomainPrep. Click Next (Figure 6.3).

Figure 6.3   The DomainPrep option on the Component Selection pageImportant   If DomainPrep does not appear in the Action list, you may have misspelled the "DomainPrep" command in Step 2. If this is the case, go back to Step 2 and retype the command.

20. On the Completing the Microsoft Exchange Wizard page, click Finish.

Server-Specific Requirements for Exchange 2003Before you upgrade to Exchange 2003 or install a new Exchange 2003 server, make sure that your servers meet the requirements that are described in this section.

Hardware RequirementsThe following are the recommended hardware requirements for Exchange 2003 servers: Intel Pentium or compatible 133 megahertz (MHz) or faster processor 256 megabytes (MB) of RAM recommended minimum, 128 MB supported

minimum 500 MB of available disk space on the drive on which you install Exchange 200 MB of available disk space on the system drive CD-ROM drive SVGA or higher-resolution monitor

For more information about hardware requirements for front-end and back-end servers, see the book Using Microsoft Exchange 2000 Front-End Servers (http://go.microsoft.com/fwlink/?linkid=14575&clcid=0x409).

File Format RequirementsTo install Exchange 2003, disk partitions must be formatted for NTFS file system and not for file allocation table (FAT). This requirement applies to the following partitions: System partition Partition that stores Exchange binaries Partitions containing transaction log files Partitions containing database files Partitions containing other Exchange files

Operating System RequirementsExchange Server 2003 is supported on the following operating systems: Windows 2000 SP3 or later

Note   Windows 2000 SP3 or later is available for download at http://go.microsoft.com/fwlink/?LinkId=18353. Windows 2000 SP3 or later is also a prerequisite for running the Exchange 2003 Active Directory Connector.

Windows Server 2003

Exchange 2000 Server RequirementsBefore you upgrade your Exchange 2000 servers to Exchange 2003, your servers must be running Exchange 2000 SP3 or later.Exchange 2000 SP3 is available for download at http://go.microsoft.com/fwlink/?LinkId=17058.

Windows 2000 ComponentsWhen you are upgrading to Exchange 2003, the current state of the Post Office Protocol version 3 (POP3), Internet Message Access Protocol version 4 (IMAP4), and Network News Transfer Protocol (NNTP) services is preserved. Furthermore, if you are upgrading to Exchange 2003 on a server running Windows 2000, Exchange Setup automatically installs and enables the Microsoft .NET Framework and ASP.NET components, which are prerequisites for Exchange 2003.

Important   Unless it is necessary that you run a particular service, you should disable it. For example, if you do not use POP3, IMAP4, or NNTP, you should disable these services on all of your Exchange 2003 servers.

For more information about installing these components, see Windows 2000 Help.

Upgrading Exchange 2000 Active Directory ConnectorBefore you can upgrade your server running Exchange 2000 Active Directory Connector (ADC) to Exchange 2003, you must first upgrade the Exchange 2000 version of ADC to Exchange 2003.

To upgrade Exchange 2000 Active Directory Connector21. On your server running Exchange 2000 ADC, click Start, click Run, and then type E:\

setup\adc\i386\setup.exe, where E is your CD-ROM drive.22. On the Welcome to the Active Directory Connector Installation Wizard page, click

Next.23. On the Previous Installation Detected page, click Reinstall to upgrade your

Exchange 2000 ADC to the Exchange 2003 ADC.

Figure 6.4   The Previous Installation Detected page24. On the Completing the Active Directory Connector Installation Wizard page, click

Finish.

Upgrading Front-End and Back-End Servers Exchange 2003 supports the deployment of Exchange in a manner that distributes server tasks among front-end and back-end servers. Specifically, a front-end server accepts requests from POP3, IMAP4, and RPC/HTTP clients, and proxies them to the appropriate back-end server for processing.If your mixed-mode Exchange 2000 and Exchange 5.5 organization takes advantage of front-end and back-end architecture, you must upgrade your Exchange 2000 front-end servers before you upgrade your back-end servers to Exchange 2003. For more information about front-end and back-end architecture, see Chapter 8, "Configuring Exchange Server 2003 for Client Access."For information about front-end and back-end scenarios, configurations, and installation, see the following books: Planning an Exchange Server 2003 Messaging System

(http://www.microsoft.com/exchange/library) Using Microsoft Exchange 2000 Front-End Servers

(http://go.microsoft.com/fwlink/?linkid=14575&clcid=0x409). Although this book relates to Exchange 2000, the information applies to Exchange 2003 as well.

Pre-Upgrade Procedures for Exchange 2000Before you begin upgrading your Exchange 2000 organization to Exchange 2003, it is important that you prepare your organization for the upgrade process. This section provides recommended and required pre-upgrade procedures.

Upgrading the Operating SystemsIf you plan to upgrade your Exchange 2000 servers that are running Windows 2000 SP3 (or later) to Windows Server 2003, you must first upgrade those servers to

Exchange 2003. This upgrade sequence is required because Exchange 2000 is not supported on Windows Server 2003.

Removing Unsupported ComponentsThe following components are not supported in Exchange 2003: Microsoft Mobile Information Server Instant Messaging service Exchange 2000 Conferencing Server Key Management Service

cc:Mail connector MS Mail connectorTo upgrade an Exchange 2000 server to Exchange 2003 successfully, you must first use Exchange Setup to remove these components. For more information about removing these unsupported components, see Exchange 2000 Help and Mobile Information Server Help.

Note   If you want to retain these components, do not upgrade the Exchange 2000 servers that are running them. Instead, install Exchange 2003 on other servers in your organization.

Upgrading International Versions of ExchangeWhen you upgrade from Exchange 2000 to Exchange 2003, you must upgrade to the same language version of Exchange 2003, with the exception of the Chinese Traditional, Chinese Simplified, or Korean languages. For example, you cannot use Exchange Setup to upgrade a German version of Exchange 2000 to a French version of Exchange 2003.

Important   You can use Exchange Setup to upgrade an English version of Exchange 2000 to the Chinese Simplified, Chinese Traditional, or Korean versions of Exchange 2003. The Novell GroupWise connector, however, is not supported on any of these language versions. Therefore, if this connector is installed on your English version of Exchange 2000, you must remove it before you can upgrade to Exchange 2003.

Upgrading your Exchange 2000 Servers to Exchange 2003After performing the pre-upgrade procedures, you can run Exchange 2003 Setup to upgrade your Exchange 2000 servers to Exchange 2003. You can run Exchange 2003 Setup from either the Exchange Server Deployment Tools or from the Exchange 2003 CD.For information about how to run Exchange Setup from the Exchange Server Deployment Tools, see "Exchange Server Deployment Tools" earlier in this chapter.For information about how to run Exchange Setup from the Exchange CD, see "Running Exchange 2003 Setup" in Chapter 3.

Installing a New Exchange 2003 ServerThis section provides you with the necessary requirements and procedures to install a new Exchange 2003 server.

Note   You can install a new Exchange 2003 server before upgrading your existing Exchange 2000 servers. It is not necessary that you perform the upgrade first.

Installing and Enabling Windows 2000 or Windows Server 2003 ServicesExchange 2003 Setup requires that the following components and services be installed and enabled on the server: .NET Framework ASP.NET Internet Information Services (IIS) World Wide Web Publishing Service Simple Mail Transfer Protocol (SMTP) service Network News Transfer Protocol (NNTP) service

If you are installing Exchange 2003 on a server running Windows 2000, Exchange Setup installs and enables the .NET Framework and ASP.NET automatically. You must install the World Wide Web Publishing Service, the SMTP service, and the NNTP service manually before running Exchange Server 2003 Installation Wizard.If you are installing Exchange 2003 in a native Windows Server 2003 forest or domain, none of these services is enabled by default. You must enable the services manually before running Exchange Server 2003 Installation Wizard.

Important   When you install Exchange on a new server, only the required services are enabled. For example, POP3, IMAP4, and NNTP services are disabled by default on all of your Exchange 2003 servers. You should enable only services that are essential for performing Exchange 2003 tasks.

To enable services in Windows 200025. Click Start, point to Settings, and then click Control Panel.26. Double-click Add/Remove Programs.27. Click Add/Remove Windows Components.28. Click Internet Information Services (IIS) and then click Details.29. Select the NNTP Service, SMTP Service, and World Wide Web Service check boxes.30. Click OK.

Note   Ensure that the Internet Information Services (IIS) check box is selected.

To enable services in Windows Server 200331. Click Start, point to Control Panel, and then click Add or Remove Programs.32. In Add or Remove Programs, click Add/Remove Windows Components.33. In Windows Component Wizard, on the Windows Components page, highlight

Application Server, and then click Details.34. In Application Server, select the ASP.NET check box (Figure 6.5).

Figure 6.5   The Application Server dialog box35. Highlight Internet Information Services (IIS), and then click Details.

36. In Internet Information Services (IIS), select the NNTP Service, SMTP Service, and World Wide Web Service check boxes, and then click OK (Figure 6.6).

Figure 6.6   The Internet Information Services (IIS) dialog box37. In Application Server, ensure that the Internet Information Services (IIS) check box is

selected, and then click OK to install the components.Note   Do not select the E-mail Services check box.

38. Click Next, and when the Windows Components Wizard completes, click Finish.39. Perform the following steps to enable ASP.NET:

d. Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.

e. In the console tree, expand the local computer, and then click Web Service Extensions.

f. In the details pane, click ASP.NET, and then click Allow.

Running Exchange 2003 SetupTo install your first Exchange 2003 server in the forest, you must use an account that has Exchange Full Administrator permissions at the organization level and is a local administrator on the computer. For more information about Exchange 2003 permissions, see "Procedures in Chapter 6" earlier in this chapter. You can run Exchange 2003 Setup from either the Exchange Server Deployment Tools or from the Exchange 2003 CD.

For information about how to run Exchange Setup from the Exchange Server Deployment Tools, see "Exchange Server Deployment Tools" earlier in this chapter.

To run Exchange 2003 Setup40. Log on to the server on which you want to install Exchange. Insert the Exchange

Server 2003 CD into your CD-ROM drive.41. On the Start menu, click Run and type E:\setup\i386\setup.exe, where E is your CD-

ROM drive.42. On the Welcome to the Microsoft Exchange Installation Wizard page, click Next.43. On the License Agreement page, read the agreement. If you agree to the terms, click I

agree, and then click Next.44. On the Product Identification page, type your 25-digit product key, and then click

Next.45. On the Component Selection page, in the Action column, use the drop-down arrows

to specify the appropriate action for each component, and then click Next (Figure 6.7).

Figure 6.7   The Component Selection page46. On the License Agreement page, read the agreement. If you agree to the terms, click I

agree that I have read and will be bound by the license agreements for this product, and then click Next.

47. On the Installation Summary page, confirm that your Exchange installation choices are correct, and then click Next (Figure 6.8).

Figure 6.8   The Installation Summary page48. On the Completing the Microsoft Exchange Wizard page, click Finish.To verify that your Exchange installation was successful, see Appendix A, "Post-Installation Steps."

Moving Exchange 5.5 Mailbox and Public Folder ContentsAfter upgrading the Exchange 2000 servers in your organization and installing a new Exchange 2003 server, your next task is to move your Exchange 5.5 mailbox and public folder contents to your new Exchange 2003 server. This section provides information about using Exchange Task Wizard to move your mailbox contents and using Microsoft Exchange Public Folder Migration Tool (pfMigrate) to move your public folder contents.

Using Exchange Move Mailbox in Task WizardExchange Task Wizard provides an improved method for moving mailboxes. You can now select as many mailboxes as you want, and then using the task scheduler, schedule a move to occur at a specified time. You can also use the task scheduler to cancel any unfinished moves at a specified time. For example, you can schedule a large move to start at midnight on Friday and terminate automatically at 6:00 A.M. on Monday, thereby ensuring that your server's resources are not being used during regular business hours. Using the wizard's improved multithreaded capabilities, you can move as many as four mailboxes simultaneously.

To run Exchange 2003 Task Wizard49. On your Exchange 2003 computer, click Start, point to All Programs, point to

Microsoft Exchange, and then click System Manager.50. In the console tree, expand Servers, expand the server from which you want to move

mailboxes, expand the Storage Group from which you want to move mailboxes, expand the Mailbox Store you want, and then click Mailboxes.

51. In the details pane, right-click the user or users you want, and then click Exchange Tasks.

52. In Exchange Task Wizard, on the Available Tasks page, click Move Mailbox, and then click Next.

53. On the Move Mailbox page, to specify the new destination for the mailbox, in the Server list, select a server, and then, in the Mailbox Store list, select a mailbox store. Click Next.

54. Under If corrupted messages are found, click the option you want, and then click Next.

Note   If you click Skip corrupted items and create a failure report, these items are lost permanently when the mailbox is moved. To avoid data loss, back up the source database before moving mailboxes.

55. On the Task Schedule page, in the Begin processing tasks at list, select the date and time for the move. If you want to cancel any unfinished moves at a specified time, in the Cancel tasks that are still running after list, select the date and time. Click Next to start the process.

56. On the Completing the Exchange Task Wizard page, verify that the information is correct, and then click Finish.

Using Microsoft Exchange Public Folder Migration ToolThe Microsoft Exchange Public Folder Migration Tool (pfMigrate) is a new tool that enables you to migrate both system folders and public folders to the new server. You can use pfMigrate to create system folder and public folder replicas on the new server and, after the folders have replicated, remove replicas from the source server. Unlike Exchange 5.5, you do not need to set a home server for a public folder in Exchange Server 2003. Any replica acts as the primary replica of the data it contains, and any public folder server can be removed from the replica list.To determine how many system folders or public folders need to be replicated, use pfMigrate to generate a report before you actually run the tool. To determine whether the folders replicated successfully, you can generate the same report after you run the tool. The pfMigrate tool is run from the Exchange Server Deployment Tools. For information about how to start Exchange Server Deployment Tools, see "Exchange Server Deployment Tools" earlier in this chapter.

To run pfMigrate57. In Exchange Server Deployment Tools, on the Welcome to the Exchange Server

Deployment Tools page, click Deploy the first Exchange 2003 server.58. On the Deploy the First Exchange 2003 Server page, in the Follow this process

column, click Coexistence with Exchange 5.5.59. On the Coexistence with Exchange 5.5 page, click Phase 3.60. On the Phase 3. Installing Exchange Server 2003 on the Initial Server page, click

Next.61. On the Install Exchange 2003 on Additional Servers page, click Next.62. On the Post-Installation Steps page, under Moving System Folders and Public

Folders, click move system folders and public folders, and then follow the steps listed to complete your public folder migration.Note   After you run pfMigrate, only the hierarchy of the system folders and public folders is migrated immediately. You must wait for replication for the contents of the system

folders and public folders to be migrated. Depending on the size and number of system and public folders, as well as your network speed, replication could take a considerable amount of time.

Switching from Mixed Mode to Native ModeBecause Exchange 2000 and Exchange 2003 are structured to take advantage of Active Directory functionality, there are some limitations when Exchange 2003 coexists in the same organization with Exchange 5.5. When Exchange 2000 or Exchange 2003 servers coexist with Exchange 5.5, your organization must run in mixed mode.

Running in mixed mode limits the functionality of Exchange 2003. Therefore, after migrating from Exchange 5.5 to Exchange 2003, it is recommended that you switch from mixed mode to native mode. This section discusses the advantages of a native-mode Exchange organization and provides the steps that are necessary to switch from mixed mode to native mode.You are ready to change your Exchange 2003 organization to native mode if: Your organization will never require interoperability between your

Exchange 2003 servers and Exchange 5.5 servers in the same organization. Your Exchange 5.5 servers exist in an organization that is separate from your

Exchange 2003 servers.Note   After you switch your Exchange 2003 organization from mixed mode to native mode, you cannot switch the organization back to mixed mode. Make sure that your Exchange 2003 organization will not have to interoperate with Exchange 5.5 in the future before you switch from mixed mode to native mode.

First, however, you should determine in which mode your Exchange organization is currently running.

To determine the operating mode of your Exchange organization63. In Exchange System Manager, right-click the Exchange organization for which you

want to determine the operating mode, and then click Properties.64. On the General tab, under Operation mode, the operating mode of your organization

is displayed.

Exchange 2003 Considerations for Mixed and Native Mode As mentioned earlier, after you migrate from Exchange 5.5 to Exchange 2003, by default, your organization runs in mixed mode. Running Exchange 2003 in mixed mode has the following disadvantages: Exchange 5.5 sites are mapped directly to administrative groups. Administrative groups are mapped directly to Exchange 5.5 sites. Routing group membership consists only of servers that are installed in the

administrative groups. You cannot move Exchange 2003 servers between routing groups.

Because many Exchange 2003 features are available only when you run your Exchange 2003 organization in native mode, it is recommended that you switch from mixed mode to native mode. Running Exchange 2003 in native mode has the following advantages: You can create query-based distribution groups. A query-based distribution group

provides the same functionality as a standard distribution group. However, instead of specifying static user memberships, with a query-based distribution group you can use an LDAP query to build membership in the distribution group dynamically. For more information about query-based distribution groups, see "Managing Recipients and Recipient Policies" in the book Exchange Server 2003 Administration Guide. (http://www.microsoft.com/exchange/library).

Your routing bridgehead server pairs use 8BITMIME data transfers instead of converting down to 7-bit. This equates to a considerable bandwidth saving over routing group connectors.

The Exchange store in Exchange 2003 ignores and removes zombie access control entries (ACEs) from the previous Exchange 5.5 servers in your organization automatically. These zombie access control entries are security identifiers from previous Exchange 5.5 servers that have been removed from your organization.

Routing groups can consist of servers from multiple administrative groups. You can move Exchange 2003 servers between routing groups. You can move mailboxes between administrative groups. Simple Mail Transfer Protocol (SMTP) is the default routing protocol.

Removing the Last Exchange 5.5 ServerBefore you can switch from mixed mode to native mode, you must remove all Exchange 5.5 servers in your site. This section guides you through the process of removing the last Exchange 5.5 server from you organization. For more information about removing your Exchange 5.5 servers, refer to the Exchange 5.5 SP3 documentation.

Note   Ensure that the account to which you are logged on has Exchange Full Administrator permissions, as well as Exchange 5.5 service account Administrator permissions to the site.

To remove the last Exchange 5.5 server65. In Exchange System Manager, in the console tree, expand Administrative Groups,

expand the administrative group you want, expand Folders, and then click Public Folders.

66. Right-click Public Folders, and then click View System Folders.67. Under System Folders, click to expand Offline Address Book. The offline address

book should be in the following format: EX:/O=ORG/OU=Site.68. Right-click the offline address book, click Properties, and then click the Replication

tab. Verify that Replicate content to these Public Stores has an Exchange 2003 computer listed. If a replica does not exist on an Exchange 2003 computer, click the Add button to add a replica to an Exchange 2003 computer.

69. Repeat Steps 3 and 4 for Schedule+ Free Busy Folder and Organization Forms.Note   If Exchange 5.5 public folders are present on the computer running Exchange 5.5, you can use the pfMigrate tool that is available with the Exchange Deployment Tools to move your public folders to an Exchange 2003 server. For more

information, see "Exchange Server Deployment Tools" and "Using Microsoft Exchange Public Folder Migration Tool" earlier in this chapter.Important   After adding the replicas to the Exchange 2003 servers, you will need to wait for the content of the folders to replicate. After the content has replicated, repeat the steps to remove the replicas from the Exchange 5.5 servers.

70. Move any Directory Replication connectors from the Exchange 5.5 servers on this computer to an SRS server in your site.

71. Wait for public folder, Schedule+ Free Busy, and Organization Forms information to replicate before you begin the next steps.

72. From an Exchange 2003 or Exchange Server 5.5 Administrator only computer, start the Exchange Server 5.5 Administrator program. When you receive the prompt for a server to connect to, type the name of the Exchange 2003 SRS server for that administrative group.

Note   You cannot delete an Exchange 5.5 computer if you are connected to it with the Exchange Administrator program. Make sure you are not connected to any Exchange 5.5 servers that you want to remove.

73. Under Configuration, click to expand the Servers node. Click the Exchange Server 5.5 computer that you want to remove from the administrative group, and then press Delete.

74. From the Active Directory Connector Tool MMC snap-in, right-click the Config_CA_SRS_Server_Name object, and then click Replicate Now. The Exchange Administrator program also removes the Exchange Server 5.5 computer from the SRS database. The Config_CA object "reads" this delete, and then replicates it to Active Directory.

Removing Site Replication ServiceSite Replication Service (SRS) is a component that exchanges configuration information between Active Directory and the directory in Exchange 5.5. In Exchange 5.5, SRS is necessary because Exchange 5.5 configuration information can only be exchanged between Exchange 5.5 servers and Exchange 5.5 directories—not with Active Directory. SRS mimics an Exchange 5.5 directory so that other Exchange 5.5 servers can replicate information to it. Using the configuration connection agreement created by Exchange Setup, Active Directory Connector replicates the configuration information in SRS into Active Directory. SRS runs only in a mixed-mode Exchange administrative group. SRS also performs additional functions, such as detecting and reacting to directory replication topology changes. You cannot switch from mixed mode to native mode until you have removed all instances of SRS.SRS is enabled automatically in two situations: On the first Exchange 2000 or Exchange 2003 computer that you install in an

Exchange site that is running only Exchange 5.5 servers. When you in-place upgrade to Exchange 2000 from an Exchange 5.5 server that is

the directory replication bridgehead server for a site.To remove Exchange SRS

75. From the Active Directory Connector Tool MMC snap-in, navigate to your recipient connection agreements. To remove any recipient connection agreements that exist in

your Exchange organization, right-click the connection agreement, and then click Delete.

76. Either from another Exchange 5.5 server, or directly from the Exchange 2003 server that is running SRS, open the Exchange 5.5 Administrator program. This is typically the first Exchange 2000 or Exchange 2003 server that is installed in an Exchange 5.5 site. Click File, click Connect to Server, and then type the name of the Exchange 2003 server running SRS.

77. In the Exchange 5.5 Administrator program, expand the local site name (displayed in bold), expand Configuration, click Directory Replication Connectors, and then delete any directory replication connectors that exist.

Important   Do not delete the ADNAutoDRC connector listed under Directory Replication Connectors.

78. Allow time for the changes that you made in Exchange Administrator to replicate to the configuration connection agreements (Config CAs) to Active Directory.

79. In Exchange System Manager, ensure that no Exchange 5.5 computers are displayed in any administrative groups.

80. In Exchange System Manager, expand Tools, and click Site Replication Services. From the details pane right-click each SRS, and then click Delete. When you do so, the SRS and corresponding Config CA for that SRS are deleted.

81. After all instances of SRS are deleted, remove the Active Directory Connector (ADC) service.

After you complete these steps, you can convert the Exchange organization to native mode.

Switching to Native ModeUse the following procedure to switch your Exchange organization from mixed mode to native mode.

Important   After you switch your Exchange 2003 organization from mixed mode to native mode, you cannot switch the organization back to mixed mode. Before you perform the following procedure, make sure that your Exchange 2003 organization will not have to interoperate with Exchange 5.5 in the future.

To switch to native mode82. Start Exchange System Manager: Click Start, point to All Programs, point to

Microsoft Exchange, and then click System Manager.83. In the console tree, right-click the organization that you want to switch to native

mode, and then click Properties.84. In <Organization Name> Properties, under Change operation mode, click Change

Mode.85. In the warning dialog box, click Yes if you are sure that you want to permanently

switch to native mode. Click Apply to accept your new Exchange mode.To take full advantage of Exchange native mode, you must restart the Microsoft Exchange Information Store service on all of the Exchange servers in your organization. You do not need to restart all of the Microsoft Exchange Information Store services simultaneously, but you must restart the service on each server for the server to take advantage of all Exchange native mode features. Restart the service on your servers after the change to native mode has been replicated to your local Windows domain controller. To determine whether the changes have been replicated to your local domain controller,

refer to the procedure "To determine the operating mode of your Exchange organization" in the section "Switching from Mixed Mode to Native Mode."

To restart the Microsoft Exchange Information Store service86. On the Start menu, click Run, type services.msc, and then click OK.87. In the Services (Local) pane, find the Microsoft Exchange Information Store service.88. Right-click the service and click Restart.

Note   In the <Organization Name> Properties dialog box, the Change Mode button is unavailable if any Exchange 5.5 servers are present or SRS exists in the organization.

Removing Exchange 2000 Tuning ParametersMany Exchange 2000 tuning parameters that were recommended in previous Exchange documentation (for example, the parameters listed in the article Microsoft Exchange 2000 Internals: Quick Tuning Guide) are no longer applicable in Exchange 2003. In fact, some of these parameters may cause problems. If you previously tuned your Exchange 2000 servers with the settings listed in this section, you must remove them manually for Exchange 2003.Use Registry Editor to remove the settings. To start Registry Editor, click Start, click Run, type regedit, and then click OK.

Warning   Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.

Initial Memory PercentageDelete the following registry parameter, because it no longer works with Exchange 2003:

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

Parameter: Initial Memory Percentage (REG_DWORD)

Log BuffersIf you tuned the msExchESEParamLogBuffers parameter to 9000 (an Exchange 2000 SP2 recommendation) or 500 (an Exchange 2000 SP3 recommendation) manually, delete the manual tuning. Exchange 2003 uses a default of value of 500. Previously, Exchange 2000 used a default value of 84.

Max Open TablesIf you tuned the msExchESEParamMaxOpenTables parameter manually, you should return the value to its default (not present). Exchange 2003 calculates the correct value for you automatically. On an eight-processor server, a value of 27600 is used.

Extensible Storage System HeapsThe optimum number of heaps is now calculated automatically with Exchange 2003. Therefore, you should delete the following registry parameter:

Location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ESE98\Global\OS\Memory

Parameter: MPHeap parallelism (REG_SZ)

Outlook Web Access Content ExpirationFor Microsoft Outlook® Web Access, you should not disable content expiry for the \Exchweb virtual directory. The default expiration setting of 1 day should be used in all scenarios.

DSAccess MaxMemoryConfig KeyIf you previously tuned the DSAccess performance by adding a MaxMemoryConfig key, you can now remove your manual tuning. Therefore, you should remove the following registry parameter:

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess\Instance0

Parameter: MaxMemoryConfig (REG_DWORD)

DSAccess Memory Cache TuningIf you previously tuned the user cache in DSAccess, you can now remove your manual tuning. Exchange 2000 had a default user cache of 25 MB, whereas Exchange 2003 defaults to 140 MB. Therefore, you should remove the following registry parameter:

Location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess\Instance0

Parameter: MaxMemoryUser (REG_DWORD)

Cluster Performance TuningIf previously implemented, the following registry parameters should be deleted when Exchange 2003 is installed:

Location HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMTPSVC\Queuing

Parameter: MaxPercentPoolThreads (REG_DWORD)Location: HKEY_LOCAL_MACHINE\SYSTEM\

CurrentControlSet\Services\SMTPSVC\Queuing

Parameter: AdditionalPoolThreadsPerProc (REG_DWORD)

Exchange connectors, troubleshooting details.

Exchange Server 2003 Enterprise Edition still provides a X.400 connector. With Exchange

Server 5.5 this was the default protocol and connectivity standard. With the release of Exchange 2000 Server Microsoft implemented SMTP as the default protocol for connectivity. Due to backward compatibility there is still a X.400 based MTA stack available. But it is only a stack and not a protocol implementation. The following article is a drill-down through the basics of X.400 and how to configure the X.400 connector. Afterwards we will then talk about in what cases we still need it.

X.400 BasicsThe X.400 recommendations were established in the 1980s. It is a complex standard and was developed under the umbrella of Consultative Committee of International Telephone and Telegraph (CCITT) which now is better known as Telecommunications Standardization Sector of the International Telecommunication Union (ITU-T). Every four years ITU-T publishes updated X.400 recommendations. The first official X.400 recommendation was published in 1984 and is referred to as the Red Book because of the color of its cover. The 1984 X.400 recommendation had several weaknesses in the area of message handling. In 1988 X.400 introduced message body parts and envelope properties. The 1988 X.400 standard is referred to as the Blue Book.

Port Number Description 1 TCP Port Service Multiplexer (TCPMUX)5 Remote Job Entry (RJE)7 ECHO18 Message Send Protocol (MSP)20 FTP -- Data21 FTP -- Control22 SSH Remote Login Protocol23 Telnet25 Simple Mail Transfer Protocol (SMTP)29 MSG ICP37 Time42 Host Name Server (Nameserv)43 WhoIs49 Login Host Protocol (Login)53 Domain Name System (DNS)69 Trivial File Transfer Protocol (TFTP)70 Gopher Services79 Finger80 HTTP103 X.400 Standard108 SNA Gateway Access Server109 POP2

110 POP3115 Simple File Transfer Protocol (SFTP)118 SQL Services119 Newsgroup (NNTP)137 NetBIOS Name Service139 NetBIOS Datagram Service143 Interim Mail Access Protocol (IMAP)150 NetBIOS Session Service156 SQL Server161 SNMP179 Border Gateway Protocol (BGP)190 Gateway Access Control Protocol (GACP)194 Internet Relay Chat (IRC)197 Directory Location Service (DLS)389 Lightweight Directory Access Protocol (LDAP)396 Novell Netware over IP443 HTTPS444 Simple Network Paging Protocol (SNPP)445 Microsoft-DS458 Apple QuickTime546 DHCP Client547 DHCP Server563 SNEWS569 MSN1080 Socks

Examining the Link State TableThe link state table is a small, in-memory database that is not stored on disk. To examine the entries that the routing engine uses to make routing decisions, you can use the Exchange Server 2003 WinRoute tool (Winroute.exe), which is available for download from the Downloads for Exchange Server 2003 Web site (http://go.microsoft.com/fwlink/?LinkId=25097).

Note   The WinRoute tool also shipped with Exchange 2000 Server, but it is best to download and use the Exchange Server 2003 version of this tool on all Exchange 2000 and Exchange Server 2003 servers in your organization.

The WinRoute tool connects to the link state port, TCP port 691, on the selected Exchange server and extracts the link state table. The information in this table is a series of GUIDs and American Standard Code for Information Interchange (ASCII) text that represent routing groups, routing group members, and connectors in the routing groups.

The link state table also includes information about the configuration of each connector. The information fields in the link state table are separated by parentheses in the following manner:

Configuring an SMTP Connector

Date Launched: Jun 30, 2004 Last Updated: Jul 20, 2004

Section: Tutorials :: Exchange 2003Author: Marc Grote

 Printable   Version Rating: 4.3/5 - 129 Votes

 1 2 3 4 5

   

You can configure an SMTP Connector to connect your Exchange Organization with the Internet or with another organization using SMTP as a transport protocol. This article explains in detail how to configure an SMTP Connector in Exchange 2003.

This article is based on Windows 2003 Enterprise Edition (Build 3790) and Microsoft

Exchange Server 2003 (Build 6944.4).

IntroductionThere are many ways in Exchange 2003 to configure your organization for receiving and

sending e-mails. The default Virtual SMTP Server created in every Exchange

Organization is good enough to connect the entire organization to the Internet. The virtual

Server handles these connections. Generally, all that you require for mail to flow is the

connectivity to the Internet and an MX record that points back to the server that is

running Exchange 2000 or Exchange 2003 in your organization.

The question is: Why do we need a SMTP Connector?

The answer:

You are connecting to a Microsoft Exchange Server 5.5 computer in another routing group (site), and want to use SMTP.

You want to configure either server-side or client-side ETRN/TURN. You want either to send or not to send ETRN/TURN. You want to request ETRN/TURN when sending messages. You want to request ETRN/TURN from different servers. You want to configure outbound security, and to do it once and affect many

outbound servers. You want to permit high, normal, or low message priorities for a domain.

You want to permit system or non-system messages. You want to schedule the SMTP connector. You want to use different delivery times for oversized messages. You want to queue mail for remote triggered delivery. You want to send HELO instead of EHLO. You want to specify a specific address space. You want to set delivery restrictions.

An SMTP connector requires an SMTP virtual server. Settings on the SMTP connector

override are comparable to settings on the virtual server. When you restrict the size of

messages on the virtual server, any connector automatically inherits that limit.

Let’s beginThe first step is to open the Exchange System Manager (ESM) and navigate to the

Connectors Container in the First Administrative Group in this example. When you can’t

see the Administrative Groups you have to go into the properties of the Exchange

Organization object and enable the view of “Administrative Groups” and “Routing

Groups”.

Important: Unless you activate the view of Routing- and Administrative Groups in ESM

you can’t create a Routing Group Connector. This is also true when your Administrative

Group has only one Routing Group.

In the Context Menu of the Connector Container click New – “SMTP Connector”.

Figure 1: Creating a SMTP Connector

Now we have to give a Name to the new Connection. I recommend naming the

connector after the two endpoints which this connector connects.

Next we have to select “Use DNS to route to each address space on this connector”. DNS

is the recommended configuration for Exchange.

It is also possible to “Forward all mail through this connector to the following smart

hosts”. When you prefer this type you must type the host name into the field or the IP

address of the Smart Host in Brackets (this prevents Exchange from trying to resolve the

IP Address with DNS).

Figure 2: General settings

Select a Bridgehead Server for the virtual SMTP Server Instance. Every SMTP

Connector must be associated with a virtual SMTP Server instance.

Figure 3: Select a Bridgehead Serve

The next step is to configure a Address Space for the SMTP Connector. There a several

Address Space types available. We select “SMTP” and specify the Address

“contoso.com”. In the future this connector will accept e-mails for *@contoso.com. You

can use wildcards like *.com and many others.

The Connector scope makes it possible for you to restrict the scope of the selected

Routing Group or the entire Organization.

To optimize and customize the Exchange Routing process you can assign logical costs to

every address space.

Figure 4: Select a Address Space

In the Delivery Restrictions field you can specify from which Recipients you accept and

reject messages. You can specify “Black-" and "White-Lists". 

Figure 5: Configure Delivery Restrictions

In the Delivery Options Field you can specify when messages are sent through this

connector.

A nice feature is to specify a different delivery time for oversize messages.

Figure 6: Configure Delivery Options

In the Content Restrictions field you can select the allowed priorities for e-mails sent

through this connector. You can specify a message Priority in Outlook.

It is possible to choose which allowed types of message are delivered through this

connector. This makes it possible to create two connectors. One connector for only Non-

system messages and one connector for System messages for a better control of message

delivery.

At last you can restrict the maximum message size for this connector.

Figure 7: Configure Content Restrictions

In the Advanced Tab you can configure the SMTP Connector for the extended SMTP

commands (HELO/EHLO). The Default is EHLO. Older e-mail Systems don’t

understand the EHLO syntax and use HELO instead of EHLO.

Figure 8: Configure Advanced Options

ConclusionWith the help of an SMTP Connector you have complete control over the message flow

in your Enterprise. The SMTP Connector is a flexible and powerful component in an

Exchange Organization.

     

Understanding Routing GroupsA routing group is a logical collection of servers used to control mail flow and public folder referrals. In a routing group, all servers communicate and transfer messages directly to one another.

In a routing group, all servers communicate and transfer messages directly to one another, as follows:89. A user in your Exchange organization uses a mail client to send mail to another user.90. Using SMTP, the sender's client submits this mail to the SMTP virtual server on the

Exchange server on which the client's mailbox resides.91. The Exchange server looks up the recipient of the mail message to determine which

server the recipient's mailbox resides on.92. One of two things occurs:

If the recipient's mailbox is on the same Exchange server, Exchange delivers the message to the recipient's mailbox.

If the recipient's mailbox is on another Exchange server, the first Exchange server sends the message to the recipient's home mailbox server, and it is the recipient's home mailbox server that delivers the message to the recipient's mailbox.

Although all servers communicate with each other directly in a routing group, this is not the case when a server in one routing group must communicate with a server in another routing group. To allow servers to communicate with servers in other routing groups, you must create a routing group connector. Although you can use an X.400 connector or an SMTP connector to connect routing groups, the routing group connector is specifically designed for this purpose and is the preferred method of connecting routing groups.By default, all servers in a routing group can send mail over the routing group connector. Servers that can send mail over a routing group connector are bridgehead servers. These bridgehead servers are each a combination of an SMTP virtual server and an Exchange server responsible for delivering all messages through a connector.When creating a routing group connector, you have the option of keeping all the servers as bridgehead servers for that connector or of specifying that only a selected set of servers act as bridgehead servers for that connector. Table 5.1 compares the advantages of each approach.Table 5.1   Number of bridgehead servers in a routing groupNumber of bridgehead servers

Advantages

All servers in a routing group

Provides more efficient message flow because all the servers in the routing group can directly deliver messages to other routing groups.

Takes advantage of those configurations where all the servers in a routing group have the same network connectivity to the servers in other routing groups.

Only a select few servers in a routing group

Makes troubleshooting message flow easier because there are limited points of contact between routing groups.

Distributes messaging if you anticipate heavy message flow between routing groups.

Makes mail flow more reliable and efficient in those configurations where some servers have better network connectivity than others.

Figure 5.1 illustrates the basic components of routing discussed thus far. Figure 5.1 shows message flow between servers in a routing group and between routing groups. It also illustrates a topology that uses only a single bridgehead server in each routing group.

Figure 5.1   Communication in and between routing groups

When a topology is as simple as that shown in Figure 5.1, you do not have to consider how to best route messages between routing groups. As topologies become more complex, with large numbers of routing groups spread over varying geographical distances, message routing among groups becomes critical. You configure routing among routing groups by assigning costs to the routing group connectors that are used by these groups. When a user on a server in one routing group sends mail to a user on a server in another routing group, Exchange uses these costs (part of the link state information maintained by Exchange) to determine the most efficient route. Exchange always uses the route with the lowest cost unless a connector or server in that route is unavailable. So that every routing group knows what the various costs are for each connector and the status of those connectors, each routing group has a routing group master that updates and coordinates this information with all the other servers in a routing group.

Understanding Link State InformationExchange 2003, like Exchange 2000, uses link state information to determine the most effective route for delivering messages. The link state table contains information about the routing topology and whether each connector in the topology is available or unavailable. Additionally, the link state table contains costs associated with each available connector. Exchange uses this information to determine the route with the lowest cost. If a connector along the lowest cost route is unavailable, Exchange determines the best alternative route, based on cost and connector availability.To understand how link state information and connector costs work, consider the routing topology shown in Figure 5.2, in which four routing groups exist: Seattle, Brussels, London, and Tokyo. The connectors exist between each routing group and are assigned costs based on the network speed and available bandwidth.

Figure 5.2   Routing topology and costs

If all connections between the routing groups are available, a server in the Seattle routing group always sends a message to the Brussels routing group by sending the message first through the London routing group. This route has a cost of 20, the lowest cost route available. But, if the bridgehead server in London is unavailable, messages originating in Seattle and destined for Brussels travel over the higher cost route, the one that goes through the Tokyo routing group.

Understanding Routing Group MastersWhen you create a routing group, the first server in that routing group is assigned the role of routing group master. The routing group master keeps track of the link state information and propagates it to the other servers in the routing group, and other servers communicate back any changes in link state. For example, if a member server tries to

contact another server over a connector, and this link is unavailable, the member server immediately notifies the routing group master. Likewise, when a non-master receives new link state information, it immediately transfers the link state information to the master, so that other servers can receive the information about the routing change.In a routing group, the routing group master and the other Exchange servers communicate link state information over TCP/IP port 691 using SMTP. However, communication of link state information between routing groups is different. If the routing group master is not a bridgehead server for the routing group, the routing group master sends the link state information to the group's bridgehead server over TCP/IP port 691. The bridgehead server then forwards this information (over TCP/IP port 25 using SMTP) to the bridgehead servers of other routing groups.If you do not want the first server installed in the routing group to be the routing group master (the default setting), you can change the routing group master to another server using the following procedure.

To change which server is the routing group master In Exchange System Manager, expand the routing group, click Members, right-

click the server, and then select Set as Master.Important   There is no automatic failover for routing group masters. If a routing group master fails, you must manually configure a new routing group master in Exchange System Manager. If a routing group master fails, the other servers in the routing group use the last known link state information until a routing group master becomes available or another routing group master is designated.

Using Routing Groups in Native and Mixed ModesIn Exchange 2003 and Exchange 2000, the administrative and routing functions are split into different units: Administrative groups define the logical administrative boundary for Exchange

servers. Routing groups define the physical routes that messages travel over the network.

If your Exchange organization is in native mode, where all servers are running Exchange 2000 or later, this split between administrative groups and routing groups helps you to create routing groups that span administrative groups, and move servers between routing groups that exist in different administrative groups. This functionality also helps you to separate routing and administrative functions. For example, you can administer servers in two central administrative groups, placing servers from each administrative group in different routing groups, based on your network topology.However, the functionality of routing groups in mixed mode, where some servers are running Exchange 2003 or Exchange 2000 while others are running Exchange 5.5, is different from native mode. In mixed mode, you: Cannot have a routing group that spans multiple administrative groups. Cannot move servers between routing groups that exist in different administrative

groups.

This is because the routing topology in Exchange 5.5 is defined by sites—logical combinations of servers connected by a high-bandwidth reliable network. Sites provide the functionality of both the administrative group and routing group in Exchange 2003 and Exchange 2000. This difference in routing topology limits routing groups in mixed mode.

Note   For more information about native and mixed mode Exchange organizations, see Chapter 2, "Managing an Exchange Organization."

Exchange Server Edge Services OverviewPublished: February 24, 2004Microsoft plans to extend and enhance Microsoft Exchange

Server messaging environments with an updated release of a

newly developed Simple Mail Transfer Protocol (SMTP)

implementation that acts as a perimeter or edge guard.

Exchange Server Edge services will enable you to better

protect your e-mail system from spam and viruses as well as

improve the efficiency of handling and routing Internet e-

mail traffic.

Add More RolesBy building on the roles that Exchange Server 2003 can provide and on the

improvements offered by Microsoft Exchange Server Intelligent Message Filter,

Exchange Server Edge services will represent a major milestone in next-generation e-

mail protection, security, and hygiene.Exchange Server 2003 enables you to design e-mail systems that are often composed of multiple servers performing different roles in order to make the e-mail infrastructure effective, such as:• Mailbox servers for storing personal information manager (PIM) data and information

services such as scheduling, unified messaging, and mailbox agents. This could also be

summarized into Microsoft Outlook data.• Front-end servers to enable roaming of Outlook data to browser-based computer and

mobile devices.• Bridgehead servers for e-mail routing internal to an organization. This would cross site

boundaries in the case of Exchange Server.• Routing to offer SMTP Internet–based e-mail routing.Exchange Server Edge services expands the number of roles that Exchange Server can play by adding three major logical or physical e-mail-related functions for critical e-mail protection, security, and hygiene. These include:1. SMTP gateway. Get a more secure and reliable SMTP implementation that requires a

direct connection to the Internet and relays e-mail to and from the Internet. Exchange

Server Edge services is the e-mail gatekeeper for the messaging customers.

2. E-mail message hygiene. Exchange Server Edge services provides the basic

Related Links• Bill Gates Outlines

Technology Vision to Help Stop Spam

• Security and Protection for Exchange Server 2003

• Exchange Server Intelligent Message Filter

infrastructure to support a variety of antispam or junk e-mail and antivirus

technologies, from basic sender or recipient filtering, to an infrastructure for non-

Microsoft independent software vendors (ISVs) to build and run antispam and

antivirus services, to the new Intelligent Message Filter.

3. Routing. Apply basic routing server rules (relay, address rewrite, masquerading,

format conversion, and so on) and provide the basic rules engine to enable you to

build custom rules.

Note: The highlighted functions mentioned earlier do not necessarily constitute computer

boundaries. Exchange Server Edge services functions could live on the same server or on

different servers.

Exchange Server 2003 Message Routing TopologyFigure 5.1 illustrates an Exchange Server 2003 organization routing topology with multiple internal routing groups connected through routing group connectors and a connector that connects the Exchange organization to an external messaging system. In this topology, routing group A represents a central routing hub. All messages to remote routing groups (routing groups B and C) and the non-Exchange messaging system are routed through routing group A. Multiple bridgehead servers are deployed in routing group A to provide redundant message transfer paths.

Figure 5.1   An Exchange Server 2003 message routing topology

The message routing topology shown in Figure 5.1 includes the following key components: Routing groups   These are logical collections of servers, used to control mail

flow and public folder referrals. Routing groups share one or more physical connections. In a routing group, all Exchange servers communicate and transfer messages directly to one another, using Simple Mail Transfer Protocol (SMTP) virtual servers. In a native mode organization, routing groups can include servers from different administrative groups. However, in a mixed mode organization, routing groups cannot span multiple administrative groups, due to backward compatibility with Exchange Server 5.5. This is because the routing topology in Exchange 5.5 is defined by sites, and sites provide the functionality of both the administrative group and the routing group.

Tip   SMTP works well over any type of TCP/IP connection. Therefore, a routing group does not necessarily define regions on a computer network with high network bandwidth. Routing groups can span slow network connections, if the connection is permanent and reliable. For example, if all servers in Figure 5.1 can communicate directly through TCP/IP, you might consolidate all Exchange servers into one routing group, thus eliminating four of the five bridgehead servers and all routing group connectors. This significantly streamlines the routing group topology. In Figure 5.1, the bridgehead server running a connector to the non-Exchange messaging system must remain connected to the external messaging system. Note, however, that all servers in a routing group periodically poll the routing group master. Gaining control over server-to-server communication might require you to implement multiple routing groups, which might be especially important if communication over wide area network (WAN) connections generates costs. For more information about the design and configuration of routing group topologies, see Exchange Server 2003 Transport and Routing Guide (http://go.microsoft.com/fwlink/?LinkId=26041).

Routing group connectors   A routing group connector enables message transfer between two routing groups. The following Exchange connectors can be used to establish message transfer paths between routing groups: Routing group connectors   A routing group connector provides a one-way

connection path in which messages are routed from servers in one routing group to servers in another routing group. Routing group connectors use Simple Mail Transfer Protocol (SMTP) to communicate with servers in connected routing groups. Routing group connectors provide the best connection between routing groups.

Note   The Routing Group Connector (note the capitalization) is a specific type of connector that can only be used to connect routing groups with each other. Other connectors that can connect routing groups are the SMTP connector and X.400 connector. However, these connectors can also be used to connect an Exchange organization to an external messaging system through SMTP or X.400. To avoid confusion, this guide uses "Routing Group Connector" to refer to the specific connector that can only be used between routing groups and "routing group connector" to refer to all types of connectors that can be used to connect routing groups.

SMTP connector   An SMTP connector can be used to connect routing groups, but this is not recommended. SMTP connectors are designed for external message delivery. SMTP connectors define specific paths for e-mail messages that are destined for the Internet or an external destination, such as a non-Exchange messaging system.

X.400 connectors   Although you can use X.400 connectors to connect routing groups, X.400 connectors are designed to connect servers running Exchange with other X.400 systems or to servers running Exchange Server 5.5 outside an Exchange organization. A server running Exchange Server 2003 can then send messages over this connector using the X.400 protocol.

Note   X.400 connectors are available only in Exchange Server 2003 Enterprise Edition.

Connectors to non-Exchange messaging systems   These connectors support message transfer and directory synchronization between Exchange and non-Exchange messaging systems. When appropriate connectors are implemented, the user experience is similar on both messaging systems and the transfer of messages and other information between the Exchange and non-Exchange messaging system is transparent to the user. However, some message properties might be lost during message conversion from an Exchange format to a non-Exchange format, or vice versa.

Mailbox servers   A mailbox server is an Exchange server configured to host mailboxes. Users can access their mailboxes through a variety of clients, such as Microsoft Office Outlook®, Microsoft Office Outlook Web Access, Microsoft Office Outlook Mobile Access, Post Office Protocol version 3 (POP3)-based clients, and Internet Message Access Protocol version 4rev1 (IMAP4)-based clients. In the Exchange Server 2003 routing topology, mailbox servers are typical sources and destinations of e-mail messages.

Bridgehead servers   A bridgehead server is a connection point that performs message transfer from one routing group to another routing group, or to an external messaging system. In large organizations, bridgehead servers are often separated from mailbox servers to avoid performance bottlenecks. Mailbox servers create bottlenecks

due to increased processing requirements during peak messaging hours. Bridgehead servers are identified as local or remote bridgehead servers, as follows: Local bridgehead servers   This server hosts a connector and uses it to transfer

messages. When you create a connector, you designate at least one Exchange server as a bridgehead server. You can also designate multiple bridgehead servers for load balancing, performance, and redundancy. For example, the default option for routing group connectors is Any local server can send mail over this connector. In this case, all Exchange servers in the local routing group can use the connector to transfer messages.

Remote bridgehead servers   The remote bridgehead server, specified in a connector configuration, is the server (in the connected routing group or non-Exchange messaging system) that receives all messages transferred over a connector. Routing Group Connector can have multiple remote bridgehead servers (that is, remote virtual SMTP servers). SMTP connector and X.400 connector, however, can have only one remote bridgehead server per connector instance. Remote bridgeheads are also named target bridgeheads.

Differences (improvements) between exchange versions.

Improvements in Exchange 2003

Date Launched: Nov 11, 2003 Last Updated: Nov 11, 2003

Section: Tutorials :: Exchange 2003Author: Jakub Synoradzki

 Printable   Version Rating: 3.8/5 - 72 Votes

 1 2 3 4 5

   

Not everyone has managed to migrate to Exchange 2000 yet, while others choose to ignore it completely, and continue using Exchange 5.5. Meanwhile, Microsoft has introduced a new upgrade – the 2003. This is related to the appearance of a new MS Windows 2003 version, the operating system to provide a really good tandem with Exchange 2003. As we will see further on, when using Exchange 2003 without combining it with Windows 2003, it loses most of its functionality.

1. Installation and upgradeWindows 2000 Server and Windows 2003 Server are the only systems to support

coexistence with Exchange 2003. To enable installation, Windows 2000 needs to be

installed with, at a minimum, Service Pack 3. As with the previous version of Exchange

(2000), the 2003 version integrates its directories within the Active Directory. If the

Windows 2000 environment is of concern, all global catalog domain controllers and

servers are required to have Service Pack 3 as a minimum. All domain types are

supported – the native Windows 2000 and 2003 and mixed Windows 2000/ 2003.

Upgrading to Exchange 2003 can only be done from Exchange 2000. If you have an older

version, i.e. the 5.5, you should upgrade Exchange 2000 to Exchange 2003 first, and then

move the mailboxes from the old server to the new one. You can also use the ´Exchange

Server Deployment Tools´, which comprise the Active Directory Connector – a well-

known Exchange 2000 tool for moving mailboxes from Exchange 5.5 to Exchange 2003

Server. Use also pfmigrate (Public Folder Migration Tool) to move the existing folders.

2. Something new....Exchange 2003 runs on Windows 2000. At a first glance, 2003 seems to be simply a

polished version of Exchange 2000. Once installed, its ´System manager´ looks almost

identical, similar expansion procedures are applied to the Active Directory scheme

(forestprep, domainprep) before the installation, even the tools to move mailboxes from

Exchange 5.5 retain their original names,  (Active Directory Connector). However

appearances are misleading. The list of genuine, new, features is rather long. We may

now have a look at them.

2.1 Query Based Distribution GroupExchange Server distribution lists have been known since the earliest versions of

Exchange, but they have always had a common feature – static membership. A list had to

be created in advance, followed by the addition of the list of users to be able to finally

send something to the list itself. Why not have these procedures in reverse? Start with the

submission of a message and leave the ´initiative´ to the server. The ´dynamic´

distribution lists within Exchange 2003 function similarly. A query-based distribution

group uses the Lightweight Directory Access Protocol (LDAP) query filter rules to

dynamically build membership in the distribution group. This occurs upon sending a

query instead of specifying static user membership. Here, the Administrator’s task is

limited only to defining the membership rules – for example, the users belonging to the

same department. Exchange itself categorizes the list of recipients basing on the LDAP

query to the Active Directory and the recipient’s attribute. In this example the

´Department´ attribute. Query Based Distribution Group is also an excellent means of

hiding the membership of a query-based distribution group in the Global Address List

because it is dynamically generated each time mail is sent. It is worth remembering that

not all attributes are replicated to the Global Catalog for each object – a badly created

dynamic list will fail to function properly. Therefore, it is good practice to verify the

query-handling feature by clicking the Preview tab, after the lists have been created, to

have the distribution group returned.

An experienced administrator might notice a certain risk associated with the dynamic

distribution lists, namely high CPU utilization and an increased working set, because

each message to the query-based distribution group causes a corresponding LDAP query

to be run against the Microsoft Active Directory service to determine its membership.

There is a transport component, the categorizer, which is responsible for membership

building. The categorizer sends the LDAP query request to the global catalog server to

generate a recipient list that contains all the users.  It is worth mentioning that the

categorizer requires as much as 2KB of RAM for every user while building the list.

Microsoft recommends placing a dedicated server without email boxes to generate

dynamic distribution lists.

Query Based Distribution Groups can be used for Microsoft Exchange 2000 Server or

Exchange 2003 and Exchange 2000 SP3 users.

2.2 Out Of Office AssistantWe have all experienced situations, where once a message is sent to a distribution list,

several ´Out Of Office´ notifications are received after a certain period of time. This is

particularly aggravated during the holiday season, generating unusual traffic and

consuming email server resources. Exchange 2003 can help with this by blocking ´Out of

Office´ messages from distribution lists. If a recipient is not specified on the To: or Cc:

line, the ´Out of Office´ message is not sent.

2.3 Server ConfigurationWith the advent of Windows 2000, a very useful feature was added, namely the

´systemstate´ dump that is similar to Exchange 2003’s ´exchdump´. This tool allows the

user to dump (either wholly or partly) the Exchange configuration. ´Exchdump´ is

provided with the following controls:

ALL – full server configuration. REMOTE – an option to engage a remote dump. By default, the configuration is

dumped from a local machine. HTTP – to dump, for example, the OWA Server configuration. SMTP – to dump the SMTP Server. RG – Routing Groups. USER – provides information on user properties. It is recommended to give the

user name as ´User Principle Name´. RP – Recipient Policies.

FH – Folder Hierarchy.

2.4 Recovery Storage GroupThe Recovery Storage Group's purpose is simple: It lets you restore a database and its

mailboxes without using a separate recovery server. This ability is invaluable when you

need to restore just one mailbox. When you use an Exchange-aware backup program, the

Recovery Storage Group lets you mount a mailbox database from a backup onto any

other Exchange server in the same administrative group as the server on which the

original database resided. You can then copy data from the Recovery Storage Group's

databases (however, you can't create new mailboxes). Problems with the recovery of a

crashed mailbox have been known since the earliest Exchange versions. To ensure a

successful restoration of just one mailbox, users had to use the backup to restore the

whole Exchange database and export the mailbox afterwards. The biggest problem was

associated with the database restoration because of the need to use another server.

Instead, the Recovery Storage Group lets you mount a mailbox database from a backup

onto any other Exchange server in the same administrative group as the server on which

the original database resided. You can access a mailbox in the Recovery Storage Group

using the ´exmerge´ tool that is available for downloading at Microsoft’s

http://www.microsoft.com/exchange/2003/updates During the whole restoration, the

operation is completely transparent to the users and the email server operates regularly.

2.5 Volume Shadow CopyA new service named ´volume shadow copy´ has been implemented in Windows 2003.

Exchange 2003 can profit from this, creating the ´Shadow Copy Backup´, allowing open

and in-use files to be backed up. Roughly speaking, it enables backups of the whole

volume with the Exchange databases without rebooting the machine. Afterwards, the

´shadow copy´ is used instead of the running disc. This is to avoid damaging databases

while backing up online. Unfortunately, ´ntbackup.exes´ ability to reap these benefits has

been compromised – third-party applications are now required.

2.6 Outlook Web AccessAlso known since 5.5, here within 2003 it has been completely modified. Its enhanced

OWA – Premium version has in fact almost the same functionality as a standard

Exchange client, beginning from email encryption and ending with spell check

capabilities.

Upon logging in to Outlook Web Access, a client has two versions from which to choose

– the Basic and Premium ones. The Basic, as its name indicates, is limited to a few

functions only. It is mainly designed for users who access the server via low capacity

connections. Any HTML 3.2 - compliant web browser is supported, whilst Microsoft’s

recommended one is Internet Explorer 5.01 or higher and Netscape Navigator 4.7 or later.

OWA provides message encoding: for the Middle Europe it is the ISO 8859-2.

Premium is a more robust Outlook-like environment and it supports:

New color schemes, Preview pane, Shortcut menu, Quick flagging, Public folder management, Spelling Checker (Polish version is not supported), Personal tasks (creation, preview, deletion), Calendar Folder, Support for common rules, User validation through “Global Address Book”, Item window sizing, Email encryption/signing.

As for security logon options, the user can choose between the “Private computer” or

“Public or shared computer”. This choice is related to the inactivity time before the user

is automatically disconnected from the Exchange server:  Private computer offers a

longer period of time, 24 hours, before this automatic disconnect, Public computer offers

15 minutes respectively.  These values may be modified via the system register.

Cookie authentication enablement is new in Exchange 2003. Once the session is

terminated, the cookie is deleted from the machine. Snappier performance is also a plus.

The current version supports data compression in its two options:

High – both dynamic and static pages are compressed, Low – only static pages are compressed,

Also, data compression option can be disabled. In order to enable data compression, both

OWA and email boxes must reside on Exchange 2003. The email content is also

refreshed less frequently (with Exchange 2000, refreshment is done after each operation -

mail deletion, movement etc): the view is refreshed automatically only after 20 percent of

the messages are moved or deleted from a page, not after each deletion. Assuming, that

the inbound box has 20 messages, the view will be refreshed only after four (20%)

messages are deleted (copied, moved)

As it has been mentioned earlier, Outlook Web Access supports S/MIME feature to

provide authentication and message integrity. As you know, two certificates (keys) are

required here – a private certificate and a public one. The public certificate is stored

within Active Directory accessible form OWA. For better performance, the whole

communication process is over the Exchange server – Active Directory path. Hence, the

OWA client does not “sense” any additional network traffic. In case the public certificate

(for message encryption) is not found in Active Directory, Contacts will be browsed in

the user’s email box. The private certificate that is used to encrypt messages must either

be installed on the machine connecting OWA, or located on a “smart card”.

2.7 Outlook Mobile AccessOMA, as its name indicates, is a sister product to OWA, designed and optimized

especially for devices type Pocket PC, and -PAQ etc. When coupled with Outlook

Mobile Access via a Web browser, the client has to submit the username, the password

and the domain name. Once successfully verified, he or she can receive/send messages

and create contacts and tasks.

2.8 Cluster servicesExchange 2003 Server can now be installed on 8-node clusters. Also, handling of

´failover´ tasks is enhanced through the change in the service dependability. The

Exchange services (http, smtp, pop3) are dependant on ´System Attendant´, and not on

Exchange Store. Whenever a failure occurs, the services (pop3, smtp etc) can

simultaneously start from the Exchange store (mailbox store, public folder store). In

Exchange 2003, ´Volume mount points´ are now supported on the shared disk,  which

contains directories on a volume for an application to ´mount´ a different volume, that is,

to set it up for use at the location a user specifies – but also, only in the presence of

Windows 2003 (Enterprise Edition and Datacenter Edition versions). Mounting is helpful

in ´bypassing´ 26 drive letter limitation systems.

The above-mentioned number of nodes within a cluster is also dependent on the given

operating system.

Windows 2000 Advanced Server – 2 nodes, Windows 2000 Datacentre Server – 4 nodes, Windows 2003 Server Enterprise Edition – 8 nodes, Windows 2003 Server Datacenter Edition – 8 nodes.

Again, it should be noticed, that Exchange 2003 coexists well with Windows 2003

Server.

Furthermore, Kerberos has replaced NTLM to authenticate users in virtual Exchange

servers.

2.9 System Manager – queueThe Exchange System Manager Queue Viewer is another feature Microsoft added based

on specific Exchange administrator feedback. Every Exchange 2000 administrator has

directly experienced the torture of being forced to click until a view of the queue appears.

Each queue was separately located - for X.400 within the protocol setup, similarly for

SMTP. With Exchange 2003 queues are centralized on a per-server basis. You can

disable all outbound mail, set up your own view refresh rate, preview hidden queues (for

example, a queue of messages to be sent at a fixed time).

2.10 MS Outlook 2003It would be hard to not mention the new Exchange client, namely MS Outlook. Here,

some essential changes have also been introduced. Firstly, the user authentication

protocol has been replaced – Outlook 2003 uses Kerberos. Windows Server 2003

provides support for implementing the remote procedure call (RPC) protocol over HTTP,

known as "RPC over HTTP". The main advantage of this solution is that it provides

security for the client–server communication via the Internet. No more expensive ´Virtual

Private Network´ is required, because all the traffic travels on port 443 – SSL. In order to

exploit the RPC over HTTP feature, all Exchange Servers must be installed on Windows

2003. All domain controllers and ´global catalog´ servers (installed with Windows 2003),

must be appropriately set up to communicate with Outlook and Exchange. It is important

to note a certain requirement that is placed on the machines to connect Exchange server

using RPC over HTTP –Windows XP with Service Pack 1 PLUS patch – Q331320.

Outlook 11 performs slowly or stops responding when connected to Exchange Server

2003 through HTTP (http://support.microsoft.com/?kbid=331320).

No more pestering by users, especially those using low capacity connections - client

performance is improved by reducing the number of change notifications when a client is

working in the cached Exchange mode. In addition, the server detects and only sends the

native format of messages to the client. Clients using a cached Exchange mode also

receive the number and size of messages to be downloaded. Even in the case of a

complete breakdown in communication with the server, Outlook will still be available.

This service is active by default. If you have users who have large Exchange mailboxes

and have OST files already configured for Outlook, please note that you may need to take

special steps to help avoid errors when those users upgrade to Outlook 2003 with Cached

Exchange Mode enabled.

3. ....some old features become obsoleteCertain old features have been eliminated with the new server version. These are:

Key Management Service - This service in tandem with the certificate Windows 2000 server provided a PKI for Exchange. The current Exchange version is able to operate in conjunction with any PKI solution that supports X.509v3 compatible certificates– including Windows 2003.

Drive M. The only drive to exist in one Exchange version – 2000. It was a source of problems since not everyone was aware of the backup exclusion list, antivirus scanning problems etc. Everything mentioned above might damage the Exchange databases. (See also – Remove the IFS mapping for drive M in Exchange 2000 Server (http://support.microsoft.com/?kbid=305145).

Real Time Collaboration – a support for any kind of communicators, chats etc. It has been removed because of a new Microsoft product to support such services (code Name Greenwich)

A connector for Lotus cc:Mail and for MS MailTo summarize, the new Exchange Server seems to be a good product, particularly when

combined with Windows 2003. After certain experiences with Exchange 2000, Microsoft

has improved troublesome functions of its predecessor. The server’s performance has

now been enhanced, easier mailbox backup is provided, and Outlook Web Access seems

to be almost a completely new product. Exchange 2003’s feature set might be enough to

make some organizations consider the migration.

Exchange 2000 featuresThere is always an air of excitement with any upgrade; however, to get the most from

your move Exchange 2000 take the time to evaluate the new components.  My first piece

of advice is to choose the Enterprise version, and avoid the basic Exchange 2000 which

has a miserly 16GB limit on the mail store.← Integration with Active Directory.  Think of a mail box as a property of the

user. ← Move Mailboxes is now available through Active Directory Users and

Computers.  (Right click user). ← Multiple Storage Groups - provide for easier management and faster recovery. 

e.g. put the boss in their own Storage Group. ← Administrative Groups - useful for delegation. ← Create Front End servers for authentication and Backend server to store the

mailboxes ← Trial OWA.  Outlook Web Access is much improved and supports public

folders and right mouse clicking.

← Create Routing Groups to transfer mail between your sites.  (They replace Site Connectors in Exchange 5.5)

← Master the SMTP connector to send and receive internet email. ← Inspect the property sheets of the SMTP virtual server. ← Configure a System Policies folder and create policies to set limits on users'

mailboxes. ← Exchange 2000 relies on IIS for the SMTP service. ← Be aware that Exchange creates a special virtual 'M:' drive which is used by its

Installable File System. ← Configure Index Server so that Outlook 200x clients can take advantage of

speedy Advanced searches. ← Instant Messenger (Personally I am not sure if Instant Messenger is useful or

will be a pain!) ← Conference Server - Note this a simple Add-on and NOT a big separate

Exchange version.

Exchange tools in detail.

IntroductionThe Add Root Certificate tool enables you to add your own root certificate to your Pocket PC device. For security, organizations often want to use secure sockets layer (SSL) when syncing or accessing a server. Several Pocket PC 2002 applications use root certificates and SSL, including:

Pocket Internet Explorer for Secure Sockets Layer (SSL) connections Exchange 2003 Server ActiveSync for server-based synchronization Third-party applicationsNote   This tool is for Pocket PC 2002 devices only. Pocket PC 2003 devices do not require a tool to install certificates.

There are two ways to use internal, SSL websites without getting warnings about untrusted certificates:

Obtain a certificate from one of the four certificate authorities that are represented by the root certificates that are included on the device.

Add your own root certificate onto the device.Pocket PC 2002 devices come with root certificates from four standard certificate authorities pre-installed: VeriSign, CyberTrust, Thawte, and Entrust. Servers that have certificates from these authorities will work without any additional configuration. Some organizations, however, may prefer to use their own root certificate, rather than paying for one from a certificate authority. You can use the Add Root Certificate tool to install your custom root certificate on the device.

Installing and Using the CleanSweep ToolView products that this article applies to. This article was previously published under Q174045

SUMMARYThis article discusses how to obtain, install and use the CleanSweep tool. This tool enables you to delete permissions, forms, views, rules, or reply rule templates from a

Microsoft Exchange Server mailbox. When you delete the rules and permissions associated with a folder, all rules and permissions for the folder are deleted. This utility is useful for cases where it has been determined that Out of Office (OOF) messages or other rules are not functioning properly.

MORE INFORMATIONThe CleanSweep tool may be obtained from the Microsoft BackOffice Resource Kit, Part Two compact disk.

NOTE: The CleanSweep tool does not work with the Microsoft Exchange Windows 95 client, version 4.0. It is recommended that you use this extension with the following clients: Microsoft Exchange Windows 95 client, version 5.0 Microsoft Exchange Windows NT client, versions 4.0 and 5.0 Microsoft Outlook Windows 95 client, versions 8.00, 8.01, 8.02, and 8.03 Microsoft Outlook Windows NT client, versions 8.00, 8.01, 8.02, and 8.03

IMPORTANT: In Outlook 98 and 2000, CleanSweep is unable to properly remove the following folder attributes:

← Permissions ← Rule Reply Templates (The OOF rule is deleted, but the OOF rule is still set to

show the user OOF)

Microsoft is researching this problem and will post more information in this article when the information becomes available.

How to Install the CleanSweep ToolWARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk. To install the extension, complete the following steps.

NOTE: The registry entries for Windows 2000 are case-sensitive.

1. From the following subdirectory of the Microsoft BackOffice Resource Kit, Part Two CD-ROM

Exchange\operating system\platform\Admin\Cleanswp

Copy the Clnswp32.dll file to your system directory, which is \System32 on Windows NT.

2. Using Registry Editor (RegEdit.exe for Windows 95, or RegEdt32.exe for Windows NT), add the CLNSWP value to the following Registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Client\Extensions

3. Enter the following text as a String (REG_SZ) value:

4.0;drive:\path\CLNSWP32.DLL;2

where drive and path indicate the location in which you copied the file.

For example, if the file were located in the C:\WINNT\SYSTEM32 directory, you would enter the following text:

4.0;C:\WINNT\SYSTEM32\CLNSWP32.DLL;2

4. Quit Registry Editor. 5. Restart the Microsoft Exchange or Microsoft Outlook client.

NOTE: Verify that the Ctl3d32.dll file exists in the System or System32 directory. CleanSweep depends on this file for correct operation.

If Ctl3d32.dll does not exist, extract it from the original media from which you installed the Microsoft Exchange or Microsoft Outlook client.

For Microsoft Exchange 4.0, follow these steps to extract the file:

1. From a Command prompt, navigate to the appropriate directory on the original installation media. If you are using Windows 95, go to the \ENG\WIN95 directory. If you are using Window NT or Windows 2000, go to the \ENG\WINNT\I386 directory.

2. Type the following extract command to extract the file:

extract /a exchng4.cab ctl3d32.dll /L C:\Windows\System

-or-

extract /a exchng4.cab ctl3d32.dll /L C:\Winnt\System32

For Microsoft Outlook 97, you can find the Ctl3d32.dll file in the \platform\OS directory on the CD-ROM.

How to Use the CleanSweep ToolWhen the CleanSweep tool is installed, the Clean Sweep option is added to the Tools menu of the Microsoft Exchange or Microsoft Outlook client. To use the CleanSweep extension, follow these steps:

1. You may want to save any existing rules prior to running the Clean Sweep tool (although this is not necessary).For additional information about how to save existing rules, click the article number below to view the article in the Microsoft Knowledge Base:

152852 XADM: Steps to Move User and Inbox Assistant Rules

2. Click to select the folder (such as Inbox) that contains the items you want to delete.

NOTE: If you do not select a folder, the Clean Sweep menu item will be disabled (grayed out).

3. From the Tools menu, click Clean Sweep. 4. Select the items to delete. Click OK.

Sample ScenariosThe following are two scenarios in which you might need to run the CleanSweep tool.

NOTE: These steps will remove the multiple OOF replies, but will not delete the Inbox Assistant rules, so you may want to back up your Out Of Office message text before you run CleanSweep.

Scenario AThe Out of Office Assistant responds with two OOF messages instead of one message. To correct this behavior, follow these steps:

1. Click the Inbox folder. 2. Click Clean Sweep from the Tools menu. 3. Click Rule Reply Templates. 4. Click Details and select all boxes that contain the following text:

no subject

5. Click OK, and then click OK again.. 6. In the OOF Assistant, delete and recreate the OOF rule.

Scenario BThe Out of Office Assistant responds to incoming mail even when it has been disabled. To correct this behavior:

1. Start the CleanSweep tool. 2. Click Rules and then click Rule Reply Templates. 3. Click Details and then click to select only the boxes titled. 4. Click OK twice. 5. In the OOF Assistant, delete and recreate the OOF rule.

NOTE: This will correct the OOF if it is corrupt and not firing, or if it is firing even when disabled. However, as a side effect you will lose all Inbox Assistant rules as well.

XCLN: How to Use the Mdbvu32 Utility to Remove Inbox RulesView products that this article applies to. This article was previously published under Q320022

SUMMARYThis article describes how to use the Mdbvu32 utility to remove Inbox rules that that you may not be able to remove by other means, including the CleanSweep utility.

NOTE: The Mdbvu32 utility is located on the Microsoft Exchange Server CD. You run the Mdbvu32 utility on the computer that is running Microsoft Outlook.

MORE INFORMATIONTo use the Mdbvu32 utility to remove Inbox rules, follow these steps:

1. Start the Mdbvu32.exe utility on the client computer. This utility is located on your Exchange Server CD in the CD-ROM_Drive\Server\Support\Utils\I386 folder.

2. Click OK, select your profile in the Choose Profile dialog box, and then click OK. 3. In the MDB Viewer Test Application dialog box, click OpenMessageStore on the

MDB menu. 4. Make sure that your mailbox is selected, and then click Open. 5. Click Open Root Folder on the MDB menu. 6. In the MAPI_Folder-Root dialog box, double-click Top of Information Store in

the Child Folders list. 7. In the MAPI_Folder-Top of Information Store dialog box, double-click Inbox in

the Child Folders list.

8. Examine the contents of the Associated Messages in Fld list where all your rules are listed. Click the rule that you want to delete (to examine rule's properties, double-click it).

9. In the Operations available (Select operation, then push Call Function button) text box, click the down arrow to open the list of available functions.

10. Click lpFld ->DeleteMessages() (ON SELECTED MSGS), and then click Call Function.

11. In the MAPI_FOLDER - Inbox ->DeleteMessages() dialog box, click OK to delete the rule that you selected.

12. Click Close three times. 13. In the MDB Viewer Test Application dialog box, click Store Logoff on the MDB

menu, and then click OK twice. 14. In the MDB Viewer Test Application dialog box, click Exit on the Session menu.

REFERENCESFor additional information about the CleanSweep tool, click the article number below to view the article in the Microsoft Knowledge Base:

174045 Installing and Using the CleanSweep Tool

For additional information about the Mdbvu32 tool, click the article number below to view the article in the Microsoft Knowledge Base:

250338 XADM: Mdbvu32 Enhancements for Viewing/Managing Rules Messages