Skip navigation

Build an Exchange 2003 Cluster: Install Exchange on the Cluster

How to run Exchange on a Windows 2003 cluster

In the Windows IT Pro article "Build an Exchange 2003 Cluster—Part 1: Plan and Prepare," July 2005,, InstantDoc ID 46621, I explain the tasks you must perform before you actually install Exchange Server 2003 Service Pack 1 (SP1) on a Windows Server 2003 SP1 cluster. Assuming you've made these preparations, you're ready to install Exchange 2003 on a cluster server. Although installing Exchange on a cluster is straightforward, it involves a few more steps than installing Exchange on a standalone server. To recap, the cluster we built in Part 1 is a two-node, active/passive cluster. Let's get started with the installation.

Before You Install
Before building your new Exchange 2003 cluster, check that you've met all the requirements for deploying Exchange 2003. Read the guidelines at, and make sure that you've completed all the steps described in the Windows IT Pro article I mentioned earlier.

In that article, I discussed building the cluster by using Windows 2003 SP1 and Exchange 2003 SP1. Since that article's publication, Microsoft released Exchange 2003 SP2. To run Exchange 2003 SP2, you should apply a Windows 2003 SP1 hotfix to each cluster node before you configure Exchange. The hotfix resolves a problem with Windows 2003 SP1 that can cause network-connectivity problems between Windows 2003 SP1 servers and other servers or clients. You can find information about the problem and download locations for the hotfix at After you apply the hotfix, you need to reboot the cluster node. Be aware that the connectivity problem can also affect servers running Windows 2003 release to manufacturing (RTM) version with security update MS015-019.

Creating an Exchange Virtual Server
By now you've configured the cluster group with the cluster name and IP address resource and a Microsoft Distributed Transaction Coordinator (MS DTC) resource. You've also configured an Exchange resource group that contains disk resources, a cluster network name, and an IP address resource for your Exchange Virtual Server (EVS). Your next task is to install Exchange 2003 on the cluster nodes, by following the procedure I outline below.

Document the installation. Document every step of the installation. The documentation shows other administrators how you built the server and can also be useful for disaster recovery purposes (i.e., if you have to rebuild the cluster). The easiest way to create documentation is to open a new WordPad or Microsoft Word document, then for every step of the installation take a screen shot of the active window by pressing Alt+Print Screen, which copies an image of the window into the Clipboard. From WordPad, select Edit, Paste Special, and choose Device Independent Bitmap. Choosing to paste the image as a device-independent bitmap (instead of doing a standard paste) reduces the document's size. Store the documentation log somewhere safe (and off the cluster).

Install Exchange 2003 on the first cluster node. Log on to Node 1 by using an account that has Exchange Full Administrator permissions. Run the Exchange 2003 setup program (located in the \setup\i386 folder of the Exchange 2003 CD-ROM). You'll get the error message Exchange Server 2003 has a known compatibility issue with this version of Windows. Ignore this message for now; later we'll apply Exchange 2003 SP2 to correct the problem. At the Welcome screen, click Next.

Click I Agree to accept the End User License Agreement (EULA). Under the Action menu, select Typical. At the next screen, accept the terms of a Per Seat Licensing Agreement. The installation begins; a completion message is displayed when the installation is done.

Install Exchange 2003 on the second cluster node. Install Exchange 2003 on the second node (Node 2), repeating the steps you followed for Node 1. You can't update the binaries to Exchange 2003 SP2 yet; you must create the EVS before you can apply SP2.

Create the EVS. After you've installed the Exchange binaries on the cluster nodes, you can create an EVS. You must create the EVS on the active node (the node that currently owns the EVS) because the setup program places Exchange databases, transaction logs, and other components on the shared storage so that each node can access them.

To create the EVS, log on to the active node by using an account that has Exchange Full Administrator privileges. Open Cluster Administrator; click File, New, Resource; and select Microsoft Exchange System Attendant. Create this resource in the Exchange cluster group (not the same as the cluster group), which in our example is DARA-EVS1-GRP, as Figure 1 shows. Click Next.

You're prompted to specify nodes as possible owners for this resource. Both cluster nodes should be listed as owners by default. Click Next to continue. Next, you're prompted to supply dependencies for the Exchange System Attendant resource. Select all the resources (IP address, network name, and disk resources) in the left pane and click Add to add them as required resources for the Exchange System Attendant resource. Click Next.

Now you'll choose an administrative group for your EVS. Select a group and click Next, then select a routing group for your EVS and click Next. At the next prompt, select a data directory folder in the shared storage to contain Exchange databases, transaction logs, the SMTP folders, the full-text–indexing database, and the message-tracking log files. The default location for this folder is the \exchsrvr folder on a physical disk resource in the Exchange resource group that you created in Part 1. A limitation of the Exchange setup program is that it places all the components (such as the databases) in the same folder at installation time. You need to move them manually after the installation. To help me identify which Exchange components the setup program has placed at installation time, I usually name the folder by using the convention \exchsrvr_staging-EVSname. (In this cluster build, I called it \exchsrvr_staging_DARA-EVS1 to indicate that this folder was created at installation time for that EVS.) Later I'll explain how you can move these components to other drivers or folders.

The setup program displays a summary screen that lists all the settings, as Figure 2 shows. Click Finish to accept the installation summary. The Exchange setup program automatically creates resources for Exchange components such as the Information Store and protocol resources for IMAP and POP. Upon completion, the setup program displays a message stating that the Exchange System Attendant cluster resource was created successfully.

At this point, you can see in Cluster Administrator that all Exchange resources are offline. Bring each resource online by right-clicking the Exchange resource and selecting Bring Online. The list of resources displayed in Cluster Administrator should look similar to the screen that Figure 3 shows.

To verify that the EVS is online, open Exchange System Manager (ESM) and check your administrative group. DARA-EVS1 appears as a clustered server running Exchange 2003 RTM version 6944.4.

I recommend you now perform a failover test to Node 2 to verify that the EVS can run on both nodes. To perform a failover by using Cluster Administrator, right-click the Exchange resource group associated with the EVS (here, DARA-EVS1) and select Move Group. Doing so triggers a failover of your newly created EVS from Node 1 to Node 2.

Installing Exchange 2003 SP2
After you've successfully created an EVS that uses Exchange 2003 RTM, I advise you to upgrade the cluster to Exchange 2003 SP2. Before you upgrade your cluster to Exchange 2003, be sure to upgrade any front-end servers to Exchange 2003 SP2. You must apply service packs to front-end servers before you can upgrade back-end servers. For Exchange 2003, Microsoft introduced a new procedure for upgrading Exchange service packs. To learn more about this procedure, see "Exchange 2003 Clusters: Rolling Upgrades," July 2005, InstantDoc ID 46335.

To install Exchange 2003 SP2, log on to Node 1 (it should be passive now because you've just performed a failover to Node 2) and apply Exchange 2003 SP2 by running update.exe (located in the \setup\i386 folder of the Exchange 2003 SP2 CD-ROM). At the Licensing Agreement screen, select I Agree to accept the License Agreement and click Next. Under the Action column, select Update, as Figure 4 shows. Select the default action (which is to update all components, such as ESM). Be aware that when the update procedure is done, you might be prompted to reboot. I was prompted to reboot because I performed the installation over a Remote Desktop connection.

To complete the upgrade, you need to take the EVS offline while leaving online the network name, IP address, and storage resources associated with the EVS. To do so, right-click the System Attendant resource, then select Take Offline. Doing this takes offline Exchange resources such as Store and Protocol resources for IMAP and POP because they're all dependent on the Exchange System Attendant (i.e., EVS) being online.

Next you need to move the Exchange resource group from Node 2 to Node 1 by performing a failover (right-click the Exchange resource group and select Move Group). Be aware that you can't perform this process from a Cluster Administrator session running on Node 2 because the files required for the upgrade procedure aren't yet installed on Node 2. The requirement to run an additional upgrade procedure for Exchange service packs from Cluster Administrator is new in Exchange 2003. It was first introduced as part of the cluster upgrade procedure from Exchange 2000 Server to Exchange 2003. The procedure is also required to upgrade a cluster from Exchange 2003 RTM to Exchange 2003 SP1.

The Exchange program files are now upgraded to Exchange 2003 SP2 on Node 1. To finish the upgrade, log on to Node 1. Right-click the System Attendant resource for the EVS and select Upgrade Exchange Virtual Server. When the upgrade is done, you should see the message The Exchange Virtual Server has been upgraded successfully.

Node 2 is running the Exchange 2003 RTM version. Install Exchange 2003 SP2 on Node 2 by running update.exe. At the Licensing Agreement screen, select I Agree to accept the License Agreement and click Next. Select Update from the Action column. When the SP2 upgrade is finished on Node 2, reboot if prompted to do so, and when Node 2 has finished restarting, verify that SP2 has been installed correctly by moving the Exchange resource group from Node 1 to Node 2 as you did earlier. As a final test, I recommend you reboot each node in turn, starting with Node 1. The EVS should fail over from Node 1 to Node 2. When Node 1 has returned online and rejoined the cluster, reboot Node 2 to test the failover from Node 2 to Node 1. These tests will verify that the Exchange cluster is configured correctly. After each failover finishes, check the Application log for errors.

Post-Installation Tasks and Best Practices
Give yourself a pat on the back: You now have a working Exchange cluster! But before you place mailboxes on the EVS, you need to perform some key tasks.

Redistribute Exchange components across disk resources. The Exchange cluster Setup program places the Exchange components in the \data directory folder. (I placed all the components in H:\exchsrvr_staging_DARA-EVS1 folder when the sample EVS was created.) The following folders contain the Exchange cluster components for our sample installation:

  • E:\exchsrvr_staging_DARA-EVS1\mdbdata contains Exchange .edb files, streaming database (.stm) files, the checkpoint file, and the transaction logs.
  • E:\exchsrvr_staging_DARA-EVS1\mtadata contains the Message Transfer Agent (MTA) folder.
  • E:\exchsrvr_staging_DARA-EVS1\mailroot contains the folder structures that the SMTP Virtual Server uses.
  • E:\exchsrvr_staging_DARA-EVS1\exchangeserver_servername contains the full-text–indexing database associated with the EVS.
  • E:\exchsrvr_staging_DARA-EVS1\servername.log contains the message-tracking log files.

Place transaction logs and Exchange databases on separate drives. Placing these entities on separate drives is a long-established Microsoft best practice, which I strongly advise you to adhere to. Doing so will help your Exchange server perform better. (The Information Store process writes each transaction to the database and transaction logs; splitting them across different physical drives distributes the load on the storage.) More important, though, placing the transaction logs on a drive physically separate from the database lets you recover data from a backup if you lose the drive that holds your databases. For more information about placing databases and transaction logs on separate drives, follow the instructions in the Microsoft article "How to move Exchange databases and logs in Exchange Server 2003" ( Also see "Customizing Your Exchange 2000 Server Installation," June 2002, InstantDoc ID 24774.

Move SMTP folders. To move SMTP folders, follow the instructions in the Microsoft article "How to change the Exchange 2003 SMTP Mailroot folder location" (

Move the indexing files. To move the full-text–indexing property store and property store logs, follow the instructions at and in the Microsoft article "XADM: Recommendations for Using Content Indexing Utilities (Pstoreutl or Catutil) in a Cluster Environment" ( You use two utilities to move the indexing files: pstoreutl.exe, which moves the property store to another drive location, and catutil.exe, which moves the catalog (index) to another drive location.

Back up the cluster. After you've moved the necessary components, perform a full backup of your cluster by using NTBackup. Back up the drives in your local storage and the system state and also perform a full Exchange database backup.

Install third-party products. Install third-party layered products such as file-based antivirus software, Exchange-aware antivirus software, and monitoring software. Take care to exclude folders that contain Exchange databases and transaction logs from a file-based virus scanner because such scanners can corrupt Exchange databases. (For more information, see the Microsoft article "Overview of Exchange Server 2003 and antivirus software" at

Perform tests. Create a test mailbox on your cluster and create a Microsoft Outlook profile that has Cached Exchange Mode enabled. Perform some failover tests and record the time it took for the EVS to go offline and online between cluster nodes. You'll find this information useful for planning future maintenance. As you add mailboxes to the cluster, failover times might increase because more connections will be open to the EVS. On production clusters that have several hundred active client connections, I've seen failovers take 2 to 10 minutes. Failover times depend on many different factors, such as the hardware specification of cluster nodes, performance of the Exchange storage subsystem, and number of active connections.

Run Exchange Server Best Practices Analyzer (ExBPA). Run ExBPA against your newly installed cluster to verify your installation. ExBPA is cluster aware and will analyze the configuration of the cluster and EVS and generate a report like the one that Web Figure 1 at, InstantDoc ID 47909 shows. For more information about ExBPA, see the Web-exclusive article "ExBPA, Round 2," March 2005,, InstantDoc ID 45823. You can download ExBPA at

You've Got an Exchange Cluster!
Following the procedures that I describe in this article and "Build an Exchange 2003 Cluster—Part 1: Plan and Prepare" will help you successfully deploy an Exchange cluster. After your Exchange cluster is up and running, you'll want to keep it functioning smoothly. To help you manage your new cluster, see the articles "8 Ways to Improve Your Exchange Cluster, Part 1," April 2004, InstantDoc ID 41630 and "8 Ways to Improve Your Exchange Cluster, Part 2," May 2004, InstantDoc ID 41943.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.