If ever there was a time for Microsoft to use the expression "evolution, not revolution" to describe a major product revision, that time is now. Exchange Server 2003 Enterprise Edition includes extended clustering support, multiple storage groups (SGs), and database sizes in excess of 16GB, but planning for and implementing the new version won't be dramatically different from the steps you take with Exchange 2000 Server. As always, though, the devil is in the details, and some of the basic tenets of deployment are changing in Exchange 2003. If you're considering the new messaging server, take a moment to learn about the server's environmental requirements, changes to Exchange's installation procedure, and several important installation options.
Planning the Environment
Planning Exchange 2003's entry into your environment involves a bit more consideration than earlier versions require. For example, you need to think about which Windows versions you're using or planning to use. Windows Server 2003 and Windows 2000 Server Service Pack 3 (SP3) or later support Exchange 2003, but Windows 2003 doesn't support Exchange 2000 or Exchange Server 5.5. You can, however, run Exchange 2000 or even Exchange 5.5 on a Win2K member server in a domain with a Windows 2003 domain controller (DC). Note, however, that an Exchange 2000 SP2 server running in this type of environment requires the Exchange 2000 post-SP2 hotfix rollup package.
Exchange 2003 requires at least one Windows 2003 or Win2K SP3 or later DC in the same domain as the Exchange 2003 server. This requirement is necessary for several reasons, not least of which is that these DCs offer secure Lightweight Directory Access Protocol (LDAP) connectivity to many Exchange 2003 components, such as the Active Directory Connector (ADC), the Site Replication Service (SRS), the Recipient Update Service (RUS), and DSAccess. The Microsoft article "XADM: You Cannot Install Exchange 2000 on a Computer That Is Running Windows Server 2003" (http://support.microsoft.com/?kbid=321648) describes the supported configurations.
After you decide which OS to use on your servers, other considerations are necessary. NTFS partitions are a requirement for most file systems on the Exchange 2003 server, including the SYSTEM volume, the volume that hosts Exchange 2003 binaries or other application files, the database and transaction-log volumes, and any other volumes that will contain Exchange 2003 files. Secure LDAP access requires a server certificate on the DCs and Global Catalog (GC) servers that Exchange 2003 uses. (Windows 2003 offers an advantage over Win2K when it comes to GC servers. A Windows 2003 DC advertises its ability to act as a GC only when it's fully synchronized within the Active Directory—AD—environment, thus minimizing latency problems. And you don't need to reboot Windows 2003 GC servers when you enable the Name Service Provider Interface—NSPI—for use by Messaging API—MAPI—clients. See the sidebar "Exchange 2003 and IIS 6.0" for information about another advantage of running Exchange 2003 on Windows 2003.) Also note that if you want to use Exchange 2003's /3GB boot switch for Exchange servers with more than 1GB of memory, you'll need to use Windows 2003, Enterprise Edition or Win2K Advanced Server.
Changes to Installation
Before you begin installing Exchange 2003, be aware of changes to the installation procedure. Some of these changes depend on the OS on which you plan to run Exchange 2003.
When you install Exchange 2003 on Win2K, the installation procedure automatically installs the Windows .NET Framework and ASP.NET components, and Win2K installs the World Wide Web service and SMTP service by default. Windows 2003 installs fewer services by default (as part of the Microsoft Trustworthy Computing initiative), so you'll need to install these components manually when you install Exchange 2003 on Windows 2003. On either OS, you must manually install the Network News Transfer Protocol (NNTP) service. You'll need System Administrator permissions to install all these components.
New or upgraded Exchange 2000 installations require that the account running the Setup program have Full Exchange Administrator privileges at the organization level. Only the first Exchange 2003 installation that you perform in a domain requires this level of permissions; subsequent installations require Full Exchange Administrator privileges only at the administrative-group level. Installations of service packs or the removal of the server from an administrative group also require Full Exchange Administrator privileges only at the administrative-group level (unless the server hosts the SRS, in which case Full Exchange Administrator privileges at the organization level are necessary to remove the server). Table 1 summarizes the required permissions for various installation scenarios. Of course, you (or your organization's Windows administration team) will need to add the Machine account for the system on which you're installing Exchange 2003 to the Exchange Domain Servers group for all installations.
Exchange 2000 requires that all installations have access to the Schema Flexible Single-Master Operation (FSMO) role holder, aka Operations Master, during installation so that the installation process can confirm that schema modifications are successful (even though the installation couldn't proceed otherwise). Although this requirement is by no means a major roadblock to deployment, it does occasionally cause an installation to fail when the network is experiencing problems or the Operations Master is unavailable during the installation. Exchange 2003 no longer has this superfluous requirement. Rather, the installation process confirms that the appropriate seeding of the organization has taken place in the Configuration Naming Context—something that can happen only after the schema modifications are installed successfully.
Exchange 2003 Setup's new /ChooseDC option lets you specify a DC to use during the installation process. This option is useful when you want to install many Exchange 2003 servers quickly. If each installation were to arbitrarily choose a DC, you'd run the risk of replication latency causing some of the installations to use out-of-date information from the Configuration Naming Context. The /ChooseDC switch eliminates this risk.
Each time you install an Exchange 2000 server, the installation routine processes the access rights on the Exchange container object in AD and resets them to their default value. Although this precautionary measure is certainly useful, it's somewhat problematic if you've modified the default permissions. For example, suppose you removed the default permissions that let all users create top-level public folders. Reinstalling an Exchange 2000 server anywhere in the organization would result in the installation routine rewriting the default permissions to AD. In Exchange 2003, the installation routines stamps the default permissions on the Exchange container object only during the first Exchange 2003 installation (regardless of whether that installation is new or an upgrade to an existing Exchange 2000 system). Subsequent installations of Exchange 2003 don't restamp any permissions.
For conventional operations, Exchange 2003 and Exchange 2000 depend on the Exchange Domain Servers and Exchange Enterprise Servers security groups, which the Domainprep utility creates. For example, a server that's a member of one of these groups has permission to perform privileged AD lookups and to access mailboxes. During the Exchange 2003 installation process, the Setup program checks for the existence and correct configuration of these groups. If Setup finds any inconsistencies, it's terminated and the installation fails.
Exchange 2000 gives the Administrator account permission to open other users' mailboxes. Exchange 2003 Setup locks this permission, preventing this type of access.
Preparing for Deployment
You can begin the Exchange 2003 installation and Setup program in a greenfield environment in two ways. You can use a command line to execute the setup.exe program (with the /forestprep and /domainprep switches for the first installation in the organization), then run Setup from the command line or by double-clicking the executable in Windows Explorer. Alternatively, you can use Microsoft Exchange Server Deployment Tools (exdeploy.exe), a GUI-based wizard of sorts that prompts you to carry out various discrete tasks.
The Deployment Tools program isn't a true wizard but rather a set of tutorial-type Help pages that guides you through the required installation steps. To launch exdeploy.exe from Windows Explorer, double-click exdeploy.chm in the \support\exdeploy directory on the Exchange 2003 installation CD-ROM. Be sure to run the file locally, not from a remotely mounted copy of the CD-ROM. Remotely executing exdeploy.chm results in erratic behavior such as Deployment Tools occasionally being unable to find files. Also locally mount the installation kit—working with setup.exe on a remote file share can cause Deployment Tools to fail to recognize the file.
When you first launch Deployment Tools, the program presents several options, as Figure 1 shows. In a greenfield installation, follow the New Exchange 2003 Installation process. The program then presents the various steps for this type of installation, as Figure 2 shows. For the first Exchange 2003 server in your organization, the program suggests that you run Domain Controller Diagnostics (Dcdiag), Network Connectivity Tester (Netdiag), Forestprep, and Domainprep before you run Setup.
Running Dcdiag and Netdiag
You can find dcdiag.exe in the \support\exdeploy directory on the Exchange 2003 installation CD-ROM. Dcdiag provides a basic test of network connectivity and DNS resolution to DCs in your Windows 2003 or Win2K infrastructure. Typically, you run the utility by itself from the command line. To do so, use the following syntax:
dcdiag /s:<DC name> /f:<log file name>
Specify the /s option only when you run dcdiag.exe from a member server; executing the tool from a DC lets dcdiag.exe automatically determine the domain configuration. Basic connectivity tests don't require any administrative privileges, but you need the Enterprise Admin privilege to execute the complete range of tests.
Netdiag, which is in the same directory as Dcdiag, tests basic network connectivity from the perspective of the system on which you execute the program. This test essentially assumes that you'll install Exchange 2003 on the local system, the point of the test being to ensure that Exchange 2003 will have access to the DC services that it requires. The utility performs several tests, from basic connectivity tests on the network adapter to confirming that the local server can establish Kerberos and LDAP channels to a DC.
The means by which you invoke netdiag.exe depends on whether you install Exchange 2003 on Windows 2003 or Win2K. To run Netdiag on Windows 2003, run the command
netdiag-wsh.exe
To execute Netdiag on Win2K, run
netdiag-w2k.exe
In a mixed-mode environment that contains Exchange 5.5 servers, Exchange 2003's DSScopeScan tool automatically executes Netdiag. Netdiag's log file—exdeploy-netdiag.log—is in Deployment Tools' Logs directory (typically on the C drive). You can find supplemental information about netdiag.exe in the Microsoft article "HOW TO: Use the Network Diagnostics Tool (Netdiag.exe) in Windows 2000" (http://support.microsoft.com/kbid=321708).
Running Forestprep
You must run Forestprep (either by running setup.exe with the /forestprep switch or by carrying out Step 5 in the Deployment Tools New Exchange 2003 Installation procedure) before you install the first Exchange 2003 server in your organization, even if you've run Forestprep before (e.g., during an Exchange 2000 installation). Forestprep prepares the AD environment for Exchange 2003. You can execute Forestprep only once; if you try to run Forestprep again, the installation code will recognize that you've already run Forestprep and will terminate its execution.
Exchange 2003 provides 142 AD object and attribute definitions in addition to those that Exchange 2000 supplies. Therefore, you must run Forestprep even if your first Exchange 2003 installation is an upgrade to an Exchange 2000 server. If you're curious about these new schema extensions and want to inspect them, they take the form of LDAP Data Interchange Format (LDIF) commands within 10 files (schema0.ldf through schema9.ldf) on the Exchange 2003 installation CD-ROM's \setup\i386\exchange directory.
As well as modifying the Windows 2003 or Win2K schema, Forestprep performs another important task: It creates the Exchange container object within the AD Configuration Naming Context. The Exchange container object is the AD branch that holds information about the configuration of all Exchange servers within the organization. Exchange 2000's version of Forestprep requires you to enter the name of the Exchange organization during creation of this object, then writes that name to AD at the first level within the Exchange container object. Therefore, you must decide on your organization's name even before you install the first Exchange 2000 server. Exchange 2003 resolves this minor irritation. Instead of requesting an Exchange organization name, Forestprep writes a placeholder globally unique identifier (GUID) to the Exchange container. This GUID is consistent across all installations and has the value \{335A1087-5131-4D45-BE3E-3C6C7F76F5EC\}.
You don't need to execute Forestprep on the Schema Master, but you must execute Forestprep on a server in the domain that holds the Operations Master. (Typically, the Operations Master is the first DC installed in the Windows forest, but you might have moved the Operations Master role to another server.) If you attempt to run the Forestprep utility on a server in a different domain, Setup will stop and display a message specifying the correct server. The executing server uses an LDAP bind to perform the necessary LDIF operations against the Operations Master.
The account from which you run Forestprep must be a member of the Enterprise Administrators group, the Schema Administrators group, the Domain Administrators group, and the Administrator group on the local machine. Forestprep also asks you to designate an existing Windows account from which to run the Exchange Administration Delegation Wizard, which you use to assign specific Exchange administration roles to other Windows administrative accounts. You can then use these other accounts to install and manage subsequent Exchange 2003 installations.
Expect to see relatively light CPU usage on the server from which you run Forestprep, but expect to see heavy CPU usage on the Schema Master, which acts as the target for Forestprep's LDIF operations. (Most LDAP operations on a Windows server consume a lot of CPU resources.) You can expect to see 100 percent CPU usage on a one-processor Schema Master for the duration of the LDAP operations. Because the LDAP threads in lsass.exe (the AD process that consumes the CPU resources) aren't multiprocessor aware, a two-processor system will max out at 50 percent usage for the duration of the LDAP operations, a four-processor system will max out at 25 percent usage, and so forth. Performing the schema extensions on my test Schema Master, a one-processor 500MHz Pentium III system with 256MB of memory, took about 19 minutes.
Running Domainprep
Before the first Exchange 2003 installation, you must run Domainprep in each domain that will hold an Exchange 2003 or Exchange 2000 server or mail-enabled objects (i.e., Exchange mailboxes or Contacts with associated Exchange addresses), regardless of whether you've run Domainprep during an earlier Exchange 2000 installation. Domainprep creates the Exchange Domain Servers global security group and the Exchange Enterprise Servers local security group in each domain. Each subsequent Exchange 2003 server that you install joins these groups; membership lets the Exchange servers read and modify user and configuration information.
Domainprep also creates a Public Folder Proxy container in each domain in which you execute it. This object is basically an AD entry that holds email addresses associated with public folders so that users can send email to those folders. Exchange 2003 and Exchange 2000 also expect to see a Public Folder Proxy container in the forest's root domain, so you must execute Domainprep from that domain whether or not it contains any other Exchange servers or objects.
Domainprep's permission requirements aren't as severe as Forestprep's requirements. The account from which you execute Domainprep must be a member of the Domain Administrators group and the Administrator group on the local machine.
A Smooth Transition
Familiarity with Exchange 5.5 deployment concepts did little to help you understand the necessary Exchange 2000 planning activities because Exchange 2000 brought a sea of change in terms of underlying concepts and AD technologies. The transition from Exchange 2000 to Exchange 2003, however, is markedly different. Preparing for and installing Exchange 2003 involves the same concepts and—for the most part—tasks as Exchange 2000: correctly deploying Windows DCs and GC servers, verifying connectivity, running Forestprep to install schema extensions, and running Domainprep here, there, and everywhere. Exchange 2003 is designed to simplify deployment, and the changes in the installation process accomplish the job.
