Customizing Your Exchange 2000 Server Installation

In Exchange Server 5.5 and earlier versions, the Exchange Performance Optimizer lets you tune and customize Exchange. Exchange 2000 Server doesn't include an equivalent tool to tailor the finer points of an installation. However, you can use tools such as ADSI Edit and regedt32 to customize an Exchange 2000 installation. Let's see what these tools can do to help you in your installation tasks. (I don't cover performance tuning in this article.)

Improve Exchange Performance
You can optimize Exchange performance by distributing the various components across different drives instead of placing all the components on one drive. For example, transaction logs and Exchange databases (.edb and .stm files) should be on separate drives. Separating the databases and logs from the other components also makes file-based virus scanning easier because you can exclude the database and transaction log drives from scans.

Exchange 2000's Setup program isn't as flexible as Exchange 5.5's Performance Optimizer. The Performance Optimizer lets you move from one drive to another the directories that Exchange components use, whereas the Setup program lets you choose the directory only for the Exchange binaries (i.e., the Exchange program files, DLLs, and executables such as the Information Store—IS—and the System Attendant service). However, you can use ADSI Edit and modify the registry to move components after the installation is complete.

ADSI Edit and regedt32 are powerful utilities that you must use with care. Incorrect use can seriously damage your Windows and Exchange installation. Perform a full backup before making any changes to your server. You must install ADSI Edit separately after you install Windows 2000 because ADSI Edit is one of the Win2K Support Tools, all of which are available on the Win2K CD-ROM. The support tools' Setup program is in the \support\tools directory. For more information about ADSI Edit, see Tony Redmond, "Introducing the ADSI Edit Utility," July 2000, InstantDoc ID 8901. To perform the changes I describe, you need Microsoft Exchange Administrator permissions.

Moving Exchange Components
Let's look at the steps you need to take to move Exchange components in a single-server Exchange 2000 installation. You can also use these steps to move Exchange components in a clustered Exchange 2000 installation. The following examples assume that the system is a new Exchange 2000 installation in which all the components are installed on the D drive. Table 1, page 2, lists each Exchange component with its current directory path and the proposed new location.

Be sure to use folder names that are consistent and meaningful. You should be able to determine a folder's contents by the folder name (e.g., S:\exchsrvr\mtadata holds the Message Transfer Agent—MTA—database). The directories in Table 1 follow the usual Exchange naming convention; only the drive letter differs.

Ideally, you should perform the steps I describe as soon as possible after you install a new Exchange 2000 server. All the changes I mention require you to stop the Exchange services and therefore interrupt user access. If you want to customize an active production server, be sure to schedule and announce the necessary downtime well in advance.

When you relocate components, copy files, don't move them. Copying the files reduces the risk of inadvertently losing or damaging a file and lets you compare file sizes after you move the component. Use a utility such as Robocopy (from the Microsoft Windows 2000 Resource Kit) to copy files and folders. Using Robocopy with the /sec switch retains permissions during the copy process. To move components, follow these steps.

Move the MTA. The Exchange 2000 MTA provides backward compatibility with the Exchange 5.5 MTA. Exchange 2000 routes all mail to Exchange 5.5 servers and X.400 connectors over the MTA. Moving the MTA will improve performance if your server hosts an X.400 connector or is in a mixed-mode site. The MTA work directory holds temporary files for messages while the messages are being processed.

Before moving the MTA work directory, use Exchange System Manager (ESM) to verify that no messages are queued on your server. However, if messages are in the queue, Exchange will process them when you restart the MTA. In ESM, you'll find the MTA queue under Protocols, X.400, Queues. Follow these steps to move the MTA work directory:

1. Stop the Microsoft Exchange MTA Stacks service.
2. Run the exchsrvr\bin\mtacheck utility to verify that no corrupt messages are in the MTA database and work directory. When the run is successful, the message Database Clean—No errors detected will display.
3. Create a new folder for the MTA (e.g., S:\exchsrvr\mtadata). Start the Registry Editor (regedt32) and navigate to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMTA\Parameters\MTA database path subkey. Change the MTA database path to S:\exchsrvr\mtadata. In the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMTA\Parameters\MTA Run Directory subkey, change MTA Run Directory to S:\exchsrvr\mtadata
4. Use Robocopy with the /sec switch to copy all the files from the current MTA folder (i.e., D:\exchsrvr\mtadata) to the new MTA folder (i.e., S:\exchsrvr\mtadata).
5. Verify that permissions on the new MTA folder match those on the old MTA folder.
6. Run the exchsrvr\bin\mtacheck utility again to validate the MTA database and work directory.
7. Start the Microsoft Exchange MTA Stacks service.

The Microsoft article "XCON: How to Change the Location of the MTA Database and Run Directory" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q259896) provides more information about this procedure.

Event ID 9298 will appear in the Application event log if the start-up was successful. Send a test email message with a delivery-receipt request to a mailbox on an Exchange 5.5 server in your site to verify that the MTA is working correctly. If the message arrives successfully, rename the old MTA folder D:\exchsrvr\old mtadata.

Move the SMTP work directories. By default, Exchange 2000 Setup places the set of directories that the SMTP virtual servers use on the same drive as the Exchange binaries. To head off any chance that logs will fill the disk and cause Exchange to halt, you should put the Exchange binaries on a dedicated partition and put the directories that the MTA and SMTP virtual servers use on a separate partition.

Moving the SMTP directories is more complicated than moving the MTA components because the configuration information for the SMTP service resides in Active Directory (AD). Each SMTP virtual server has a separate configuration under the SMTP container. Using ADSI Edit, follow the steps below to change the configuration for the default SMTP virtual server. Repeat the procedure to change the path for the other directories.

1. Stop the Microsoft Exchange System Attendant service and the SMTP service (part of Microsoft IIS). Stopping the System Attendant stops all the other Exchange services (e.g., IS, MTA).
2. Create a new folder (e.g., S:\exchsrvr\mailroot\vs 1) to use for the temporary files that the SMTP virtual server creates.
3. Use Robocopy with the /sec switch to copy the old SMTP folder (i.e., D:\exchsrvr\mailroot\vs 1) to the new folder (i.e., S:\exchsrvr\mailroot\vs 1). Ensure that all subdirectories under the \mailroot directory are recreated on the S drive.
4. Right-click the folder, select Properties, then select the Security tab and verify that the permissions on the old and new folders are consistent.
5. Open ADSI Edit and connect to the configuration container of a domain controller (DC) in the Exchange server's Win2K site.
6. Navigate to Configuration, Services, Microsoft Exchange, your Exchange organization name, Administrative Groups, your administrative group, Servers, your Exchange server, Protocols, SMTP, CN=1. Right-click CN=1 and select Properties. Note that CN=1 refers to the default SMTP server. If you have multiple SMTP servers, they will display as CN=2, CN=3, and so forth.
7. In the Select a property to view drop-down list on the Attributes tab, select msExchSmtpBadMailDirectory, as Figure 1 shows. This directory holds messages that the SMTP service considers undeliverable. Click Clear. In the Edit Attribute box, enter the new folder path, S:\exchsrvr\mailroot\vsi 1\badmail. Click Set.
8. Repeat Step 7 to change the path for msExchSmtpQueueDirectory, which holds messages queued for processing, and msExchSmtpPickupDirectory, which holds messages for the SMTP service to pick up and process.
9. Click OK to save your changes, then wait for replication to occur.
10. Start the Microsoft Exchange System Attendant service and the SMTP service. Event ID 334 will appear in the Application event log if the SMTP service starts successfully. Start the other Exchange services.

Send a test email message to a mailbox on another Exchange 2000 server or to an Internet email address. If the process is working correctly, rename the old SMTP folder to D:\exchsrver\old mailroot\vs 1.

Move the Exchange databases. Use ESM to move Store databases from one drive to another. The individual databases appear under each storage group (SG). Right-click the Mailbox Store or Public Folder Store you want to move and click Properties. The existing paths for the .edb and .stm files appear on the Database tab, as Figure 2 shows. Make sure that the new partition has enough space to hold the new copy of the database before attempting to move the database, then follow these steps:

1. Create a folder on the new partition and match its permissions with the folder that currently holds the database.
2. Click Browse next to the Exchange database box, select the new location for the database, then click Apply. This action dismounts the database, copies it to the new location, remounts the database, and updates AD with the new configuration information.
3. Perform a full backup immediately.

The Microsoft article "XADM: How to Move Exchange Databases and Logs in Exchange 2000 Server" (http://support.microsoft.com/default.aspx?scid=kb;en-us;q257184) fully documents this procedure.

Move the transaction logs. Best practice mandates that you place the Exchange databases and transaction logs on separate drives for the best performance. For more information about transaction logs, read Mark Ott, "Tips for Using Transaction Log Files," October 1998, InstantDoc ID 4862.

Each SG has a set of transaction logs. Use ESM to select the SG whose logs you want to move. Right-click the SG and click Properties. The Properties dialog box's General tab, which Figure 3 shows, identifies the system path for the checkpoint file. To move the transaction logs, follow these steps:

1. Use Browse to select the new location for the transaction log set. Before ESM lets you move the logs, it displays a warning that the procedure dismounts all databases in the SG, so be sure to schedule downtime for the move. Click OK to proceed. When the logs are successfully moved, you'll see the message The paths have been successfully changed and all the previously mounted stores are back online.
2. On servers with multiple SGs, assign names to folders to reflect the SG (e.g, F:\exchsrvr\sgroup2\db for the folder holding the databases in SG 2, L:\exchsrvr\sgroup2\logs for the folder holding the transaction logs).

Move the message-tracking logs. The Exchange 2000 Setup program places the message-tracking log files on the same partition as the Exchange binaries. For performance reasons, don't put the tracking logs on the same drive as the SMTP folders. If you want to keep tracking logs longer than the 7-day default period, open ESM and go to the General tab of the server's Properties dialog box. If the message-tracking settings aren't accessible, a message-tracking policy has been configured and applied to this server. To check which policies have been applied to your server, go to the Policies tab of the server's Properties dialog box. You can view and update policies under the Policies container for the Administrative Group. To move the message-tracking logs, perform the following steps:

1. Take all Exchange services offline by stopping the Microsoft Exchange System Attendant service.
2. Note the permissions of the current tracking-log directory. Right-click the current tracking-log folder, select Properties, select the Security tab, then verify that the permissions on the old and new folders are consistent.
3. Create a new directory for the transaction logs (e.g., T:\exchsrvr) with permissions that match the current tracking-log directory.
4. Copy the current tracking-log directory (e.g, D:\Exchsrvr\yourservername.log) to T:\exchsrvr (e.g., T:\exchsrvr\yourservername.log).
5. Open ADSI Edit and navigate to Configuration, Services, Microsoft Exchange, your Exchange organization, Administrative Groups, your administrative group, Servers, your Exchange server.
6. Right-click your Exchange server and click Properties. In the Select a property to view drop-down box, choose msExchDataPath, as Figure 4 shows.
7. Click Clear, then enter T:\exchsrvr as the path in the Edit Attribute box. Click Set, then click Apply.
8. Open the registry editor and update the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSA\Parameters\Log Directory subkey to match the new tracking-log folder (e.g., T:\exchsrvr\yourservername.log). Also update the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares registry subkey to make the tracking-log file share match the new tracking-log folder (e.g., T:\exchsrvr\yourservername.log).
9. Allow some time (about 15 minutes) for the ADSI Edit changes to take effect. Restart the Exchange server; this reboot is required to create the share. Verify that the share is created correctly after the reboot by typing

net view \\<your server name>

at a command prompt.

10. In ESM, go to Tools, Message Tracking Center to open the Message Tracking Center, then track a message on the server. For instructions about using the Message Tracking Center, see Tony Redmond's Windows & .NET Magazine article "Exchange 2000's Message Tracking Center," http://www.winnetmag.com, Instant Doc ID 16006. If you can successfully track a message, rename the old tracking-log folder to D:\exchsrver\old_servername.

Move the Site Replication Service database. The Site Replication Service (SRS) replicates configuration information between the Exchange 5.5 Directory and AD in mixed-mode Exchange sites. The SRS is automatically installed when the first Exchange 2000 server joins an Exchange 5.5 site. Each Exchange site can have only one SRS server. To move the SRS database (srs.edb) and transaction logs to another partition, use the following procedure. As you do with all other Exchange databases, place the SRS database and transaction logs on separate drives.

1. Stop the Microsoft Exchange Site Replication Service.
2. Create a new folder for the SRS database (e.g., G:\exchsrvr\srsdata).
3. Use Robocopy with the /sec switch to copy D:\exchsrvr\srsdata\srs.edb to G:\Exchsrvr\srsdata.
4. Create a new folder for the SRS transaction logs (e.g., H:\Exchsrvr\srsdata).
5. Open regedt32. In the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSRS\Parameters\DSA Database File subkey, change the DSA Database File key to G:\exchsrvr\srsdata\srs.edb. In the HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\Services\MSExchangeSRS\Parameters\Database log files path, change Database log files path to H:\exchsrvr\srsdata. Close regedt32.
6. Restart the Microsoft Exchange Site Replication Service. To verify that the SRS has started successfully, check that event ID 1000 appears in the Application event log.
7. Rename the old SRS folder to D:\exchsrvr\old_srsdata.

Clean up. After you customize the installation, the system will contain duplicate directories and inactive files. As a precaution, perform a full backup before deleting any folders. Using Table 1 as a checklist, delete or rename the directories that no longer contain active files. Update your server-build documentation to reflect the changes.

Do-It-Yourself Customization
Despite the lack of a dedicated utility to move Exchange 2000 files and directories, you can customize your installation by using ADSI Edit and modifying the registry. Take care to copy files properly and perform all steps with due regard for system availability and user access. And always perform a full backup.