1.4 Deploying Exchange 2003

---

The basic system requirements to begin an Exchange 2003 deployment are straightforward. The server needs to run Windows 2000 SP3 or Windows 2003, and you can only upgrade an existing Exchange server if it runs Exchange 2000 SP3 or later. After you've done all the hard work to ensure that you're running the right version of Windows and Exchange, the actual upgrade to Exchange 2003 is easy, and you should be able to apply it on all but the largest servers in a couple of hours. Be sure to take a backup before and after the upgrade, just in case you need to roll back.

Because Exchange depends on the Active Directory to hold information about the organization, servers, connectors, and users, you need to prepare the AD infrastructure before you can upgrade to Exchange 2003. Because of the requirement for secure LDAP access to support services, such as the Recipient Update Service (RUS), Active Directory Connector (ADC), and Site Replication Services (SRS), domain controllers (DCs) and Global Catalog servers (GCs) must run Windows 2000 SP3 before Exchange 2003 servers will bind to their AD service. If you have not yet upgraded these servers to SP3, you should make plans to do so before deploying Exchange 2003. The Exchange 2003 setup procedure actually checks to see whether the DCs and GCs run the right software versions, so this is not something you can avoid. The alternate approach is to install Windows 2003 on the DCs and GCs. However, most administrators are loathe to deploy a new operating system until they have fully tested the software and understand how to deploy it within their production environment. Fortunately, Exchange 2003 is happy to run on a Windows 2000 (SP3 or later) or Windows 2003 server.

Microsoft supports neither Exchange 2000 nor Exchange 5.5 on Windows 2003, so if your company plans to deploy Windows 2003 soon, you should consider a plan to move to Exchange 2003 first, since a concurrent upgrade of operating system and email servers creates a level of unacceptable complexity for most administrators. Note that you cannot upgrade a server from Exchange 5.5 to Exchange 2003 without going through Exchange 2000 first, so a phased approach is required to move to a new infrastructure. For example, if you run Exchange 2000 now, you can follow this upgrade schedule:

• Upgrade to Windows 2000 SP3.

• Upgrade Exchange 2000 to Exchange 2003.

• Upgrade Windows 2000 to Windows 2003.

Of course, you could take a server through all these steps in a single day, but I only recommend this approach in a laboratory environment and it is not something that you would do in production. Instead, it is likely that you will need a week or so between each major upgrade step to allow the overall environment to settle down, replication operations to complete, and be ready to execute the next step. Note too the general rule that you cannot restore databases from an Exchange server to a server running an earlier release. This means that you have to be sure that you include disaster recovery considerations in your deployment plans.

If you have used Exchange 5.5 for awhile and are considering an upgrade of your server hardware, you can adopt a "moving train" approach to the deployment. This means that you introduce new servers^[3] into your infrastructure by installing Windows 2003 and then Exchange 2003. When you are happy that the servers are functioning correctly and you have all the necessary pieces to integrate the servers into daily operations, you can then start to move mailboxes over to the new Exchange servers. Usually, the new hardware can replace several older servers, so you gradually consolidate your environment as you move mailboxes. If you are still running Windows NT 4.0, you should also be able to consolidate domain controllers and other infrastructure servers by replacing them with Windows 2003 equivalents. Eventually, you will have moved all the mailboxes, and you can then decommission the last Exchange 5.5 server and turn your organization from mixed (Exchange 5.5/Exchange 2003) to native mode (only Exchange 2003). The moving train approach is recommended by Microsoft because it is far easier to move mailboxes around, especially with the new functionality in Exchange 2003, than to perform multiple software upgrades on servers.

Some differences exist between the installation procedure requirements for Exchange 2000 and Exchange 2003. The .NET framework and ASP .NET components must be present on all Exchange 2003 servers. The Exchange 2003 installation procedure installs these components automatically when you install Exchange 2003 on a Windows 2000 server, but you have to install the ASP .NET components manually before you install Exchange 2003 on Windows 2003. The reason for the difference is that under Microsoft's Trustworthy Computing initiative, the general approach for Windows 2003 is never to install a system component unless you know that it is necessary. For the same reason, you have to install the IIS, NNTP, SMTP, and WWW services on Windows 2003 before proceeding with Exchange 2003. With respect to IIS 6.0, the Exchange 2003 installation procedure makes sure that IIS switches into Worker Process Isolation Mode and enables the various Exchange ISAPI interfaces (such as Outlook Mobile Access and Outlook Web Access).

In front-end/back-end configurations, where you have Exchange frontend servers that proxy incoming communications to back-end mailbox servers, you have to upgrade all the front-end servers within an administrative group to Exchange 2003 before you upgrade the back-end servers. You have to complete the upgrade to both front-and back-end servers before you can use the new Outlook Web Access client interface. Forms authentication works if only the front-end servers run Exchange 2003, but session timeouts are more reliable when all of the servers run Exchange 2003.

Exchange 2003 removes support for the Exchange 2000 Instant Messaging (IM), Key Management Server (KMS), Chat, and Conferencing components. The Windows 2003 Certificate Server takes over the role of KMS in terms of generating new certificates to users, maintaining revocation lists, and so on. You can continue to keep these servers in place and run them alongside new Exchange 2003 servers until you are ready to phase them out. Contact Microsoft for the most up-to-date recommendations on replacement strategies, because there are development activities in these areas that you may benefit from.

1.4.1 Upgrade time

The first step to deploying Exchange 2003 is to run the ForestPrep and DomainPrep procedures, both part of Exchange's setup utility. This is necessary even if you have an existing Exchange organization, and, just like the first time you ran these procedures, you have to run ForestPrep once for the forest and then run DomainPrep for every domain that hosts servers or mail-enabled objects, including the root domain-even if it seems to be empty of any mail-enabled objects. ForestPrep extends the AD schema with an additional set of object definitions over those required by Exchange 2000.

The actual installation of Exchange 2003 is not onerous and normally completes within an hour. Certainly, assuming that a server runs the necessary version of Windows and that you have prepared the infrastructure, perhaps by installing Windows 2003 on DCs and GCs, it should not take more than a couple of hours to complete the installation. Once the server restarts, the Store performs a schema upgrade and rebuilds any store indexes used by Exchange's full-text indexing feature, so CPU demand is heavier until these tasks complete. The upgrade procedure allows you to defer the full text rebuild to a more suitable time, if you want.

The nature of clusters is that they are more complex than standard servers, so you have more work to do. After applying an upgrade in the normal manner, open the Cluster Administrator utility, select the Exchange System Attendant resource for each Exchange virtual server in the cluster, and take the "Upgrade Exchange Virtual Server" option. In addition, because Exchange 2003 replaces EXRES.DLL (the resource DLL to control Exchange resources), you have to reboot the server. In most cases, you do not have to reboot a standard server after you upgrade to Exchange 2003.

Do remember to take a full backup before beginning to upgrade a server and then take another backup after the installation completes. The full backup beforehand should include the system state and system and application files as well as the Exchange databases. Afterward, let Exchange start up and mount the databases so that the Store stamps the databases with the new version number. This completes the upgrade process and you can then take a full online backup to ensure that you can recover the server if a subsequent problem occurs.

Note that apart from the first server in the organization, you no longer need permission over the full organization to be able to install an Exchange server. Instead, Exchange 2003 requires that you only need Exchange Full Administrator permission for the target administrative group to be able to add a new server, install a service pack or hot fix, or remove a server. A small but important change is that the Exchange 2003 installation procedure no longer assumes that it has the permissions necessary to add a server to the local Exchange Domain Servers global security group (Figure 1.2). Instead, you have to arrange for someone (such as an enterprise Windows administrator) to add the account after you install Exchange.

Figure 1.2: Membership of the Exchange Domain Servers group.

Unlike the situation with Exchange 2000 installations and service pack updates, the Exchange 2003 installation procedure does not attempt to reset default permissions on the organizational object at each server install. This fixes an irritating bug that allowed users to create top-level public folders after administrators had limited access to this feature. Another small but important change is that the installation procedure can proceed without the need to communicate with the forest's schema master (FSMO role). Instead of insisting on connecting to the schema master to validate that the schema extensions for Exchange exist, the installation procedure now checks that the organization exists in the configuration naming context of the AD. The logic here is that the presence of the organization indicates that ForestPrep has updated the schema.

During installations, you can select the domain controller to communicate with by using the SETUP/ ChooseDC switch, which is useful when you know the most appropriate domain controller to use (ideally one that you know is fully up-to-date in terms of replication). It is also useful when you want to install many servers in a short period, since you can now spread the load across domain controllers or direct the installation procedure to use a powerful server reserved for the purpose. The final change is that the installation procedure no longer prompts you to enter the name of an organization until you install the first server in an organization. Instead, Exchange creates a placeholder GUID for the organization in the configuration container and you then populate the organization's visible name when you install the first server. These small but important changes make it much easier to deploy Exchange, especially inside large organizations.

1.4.2 Deployment tools

As Microsoft has had three years' hard experience of Exchange 2000 in production, it is not surprising that it has created a deployment kit to help you assess whether you need to take steps to prepare your infrastructure before you start. The tools and deployment guide are included in the \Support\ ExDeploy folder in the server CD.

You can launch a wizard-like interface to the tools by invoking the compiled help file at \Support\ExDeploy\Exdeploy.chm. As you can see in Figure 1.3, ExDeploy offers tests that allow you to verify whether you are ready to deploy Exchange 2003 in specific circumstances, including upgrades and new server installations. Behind the scenes, ExDeploy calls the various executables as required and generates log files that you can find in the \Logs folder. Do not copy the ExDeploy files to a remote file share and execute ExDeploy from there, since you may see unpredictable results. Always execute ExDeploy from a local disk.

Figure 1.3: ExDeploy.

It is interesting to see that Microsoft provides many tools to assist administrators to migrate from Exchange 5.5 and reduce the number of support calls that Microsoft receives during migrations. This reflects the reality of a situation where installations have been slow to move because of the perceived difficulty of migration, so these tools exist to help people past the barrier. Among the more interesting items in the ExDeploy tool set are:

• OrgPrepCheck: Validates that the organizational requirements for Exchange 2003 exist before you install the first server. You run this tool after the ForestPrep and DomainPrep options in the installation procedure to ensure that Windows (AD and FRS) has correctly replicated security policies and groups to all necessary servers within the organization. OrgPrepCheck is actually a "tool group," because it calls several other tools to do its work, including OrgCheck, PolCheck, PubFoldCheck, and OrgNameCheck. The last tool checks for illegal characters in the organization name. Exchange organization, administrative group, routing group, and server names must comply with the character restrictions documented in RFC 821, which is a tighter restriction than that applied to Exchange 5.5. For example, you can no longer include brackets in any Exchange names.

• DCdiag: Tests the connectivity between an Exchange server and DCs.

• NetDiag: Tests the basic network configuration for a potential Exchange server. Separate versions exist for Windows 2000 and Windows 2003. See Microsoft Knowledge Base article 321708.

• SetupPrep: Checks that the infrastructure components that Exchange depends on (such as DNS) are available and functioning.

• ADCUserCheck: Scans an Exchange 5.5 directory store to create a recommended list of AD connection agreements to synchronize the Exchange 5.5 directory with the AD. This tool is used only to prepare an Exchange 5.5 server to migrate to Exchange 2000.

• DSScopeScan: Audits an Exchange 5.5 server and documents what it finds. Reports servers, stores, connectors, mailboxes, public folders, and so on-the essential data that you need to know to be able to scope the migration.

These are basic tools and may not include the same depth of functionality for functions sich as directory management, which you can buy from ISVs such as NetIQ (www.netiq.com), Aelita (www.aelita.com), and BindView (www.bindview.com), but they exist for the specific purpose to help you to move smoothly to Exchange 2003. You could manually extract the same data that the tools analyze to figure things out for yourself, but it is much easier when you have automatic processing to provide a baseline. Anything that avoids work is welcome!

^[3] To ensure support and achieve best reliability, the hardware for any new servers should be included in Microsoft's Hardware Compatibility List (HCL).

---