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.