By late 2004, our corporate database at the Colorado Department of Labor and Employment had finally outgrown the Windows 2000 and Microsoft SQL Server 2000 cluster that hosted it. It was time to upgrade our hardware and OS and install a new cluster—running Windows Server 2003, Enterprise Edition and SQL Server 2000, Enterprise Edition. We also wanted to migrate our standalone Exchange Server 5.5 mail server to a separate Exchange Server 2003 cluster. Two systems, two technologies, and my job is to make it work. For the cluster hardware, we've chosen HP's Packaged Cluster Solution, which includes two ProLiant DL380 G3 servers with dual 3.4GHz processors and 3GB of RAM and a SCSI Smart Array 5i Plus shared storage array with redundant controllers.
Installing the SQL Server Cluster
I cut my teeth on Windows clustering on a Windows 2000 Advanced Server system that ran Microsoft Cluster Service (MSCS) and supported a two-node active/passive SQL Server 2000 cluster. I'm pleased to discover that clustering in Windows 2003 Enterprise is much easier to configure and use than in Win2K Advanced. Cluster services are installed by default, so to set up a cluster you need only configure it on the cluster nodes by using a wizard.
Because I plan to run SQL Server on the Windows 2003 cluster, after I configure the cluster I have to install Microsoft Distributed Transaction Coordinator (MS DTC) on each cluster node. SQL Server 2000 uses MS DTC to process distributed queries and two-phase commit transactions and provide replication functionality. (For more information about installing MS DTC, see the Web-exclusive sidebar "Installing MS DTC on a Windows Server 2003 Cluster," http://www.windowsitpro.com, InstantDoc ID 46690.)
Next, I install SQL Server 2000 on the cluster from the cluster's active node (the node controlling the SQL Server machine). When I install SQL Server 2000 on the Windows 2003 server, I get a warning message stating that SQL Server 2000 Service Pack 3 (SP3) is required. I ignore the message and continue with the installation. (I'll apply the service pack after SQL Server is installed.) SQL Server recognizes that I'm installing it on a clustered server and prompts me for the server's virtual name and associated IP address.
Now I have to apply SQL Server 2000 SP3; you need SP3 or SP3a to run SQL Server 2000 under Windows 2003. When I apply SP3 to the cluster's active node, SQL Server again recognizes that it's installed on a clustered server and upgrades the virtual server accordingly. After the service pack is applied, I'm prompted to reboot the server and any remaining nodes to complete the installation.
Setting Up the Exchange Cluster
I assumed—alas, incorrectly—that installing Exchange in a clustered environment would be similar to installing SQL Server on a cluster. Exchange 2003 includes significant ease-of-use improvements that facilitate installing it on a cluster. Nevertheless, properly configuring an Exchange cluster takes significantly more work than setting up Windows 2003 and SQL Server clustering. My situation is more complex because I'm installing the Exchange 2003 server in our existing Exchange 5.5 organization.
When you add an Exchange 2003 server to an Exchange 5.5 organization, the first server added cannot be a virtual server. This is because Site Replication Service (SRS) is required on the first Exchange 2000 Server or later server that you add to a mixed-mode organization, and SRS won't run in a cluster. (For more information about this limitation, see the Exchange Server 2003 Deployment Guide.) I had to install a standalone Exchange 2003 server before adding the cluster. The server doesn't have to host any mailboxes and can be a front-end server. The good news is that unlike Exchange 2000, an Exchange 2003 front-end server can run Exchange 2003, Standard Edition although the back-end server uses Exchange 2003, Enterprise Edition. The front-end server remains in place after the cluster is up and running.
Before I install Exchange, I run Netdiag and Dcdiag on the cluster nodes. The Dcdiag test produces some errors. One problem is a false-positive because our AD is Windows 2000 and the Exchange server is Windows 2003. I got the error NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS doesn't have Replicating Directory Changes. I find information about the error in the Microsoft article "'Replicating Directory Changes All' error message when you run the Dcdiag.exe utility" at http://support.microsoft.com/?kbid=829306, which states that we can safely ignore the error in our situation.
The other errors aren't as easily resolved, so I contact Microsoft technical support for help. We discover that our domain controllers (DCs) aren't direct members of the Domain Controllers organizational unit (OU) but are members of a child OU under the Domain Controllers OU. Moving all DCs back to the built-in Domain Controllers OU solves this problem.
I encounter another error, which Web Figure 1 at http://www.windowsitpro.com, InstantDoc ID 46622 shows. This error occurred because we'd configured the Exchange 5.5 distribution list (DL) for security on Create Top Level Folders. I solve the problem by starting Exchange 5.5 Administrator; navigating to Site, Configuration, Information Site Configuration; clicking the Top Level Folder Creation tab; and deleting any Distribution Groups (DGs) from both panes.
After resolving the errors, I install the front-end (nonclustered) Exchange 2003 server. To install Exchange 2003, the user you log on as must be a member of the Schema Admins and Enterprise Admins groups.
I'm ready to tackle setting up the Exchange cluster. The Exchange 2003 deployment tools, which are on the Exchange 2003 CD-ROM, take a lot of guesswork out of installing Exchange by ensuring that Active Directory (AD) is correctly configured for Exchange. Exchange 2003 uses a different permissions model from Exchange 2000. In Exchange 2003, the Windows Cluster Service account no longer requires that the Exchange Full Administrator role be applied to it. The default permissions of the Windows Cluster Service account in the forest are sufficient. The Cluster Administrator account in Exchange 2003, as in Exchange 2000, still requires the Exchange Full Administrator role applied at organization level if the Exchange Virtual Server (EVS) is the first EVS. If the EVS isn't the first, the account must have the Exchange Full Administrator role applied at the administrative group level.
I install Exchange on each cluster node, using Cluster Administrator to create the Exchange services on the virtual server. First, I create the group to host the EVS. Next, I create IP Address, Network Name, and disk resources, as described in the Exchange Server 2003 Deployment Guide. Then I create the System Attendant service resource and bring it online. The System Attendant creates several resources on the virtual server; for more information about these services, see the main article. (In Exchange 2003, the IMAP3 and POP3 protocol services are no longer created by default upon creation of an EVS that's running Windows 2003.)
Our clustered Exchange server is ready to go. I do a quick test by forcing a failover between both nodes. Before I start moving mailboxes, I apply Exchange 2003 SP1. Applying the service pack on the front-end server is straightforward; applying it on the cluster is more complicated. For more information about the procedure I followed, see the Web-exclusive sidebar "Applying Exchange 2003 SP1 on a Cluster," http://www.windowsitpro.com, InstantDoc ID 46691.
Mission Accomplished
Clustering has come a long way in Windows 2003. Installing SQL Server in a cluster is much easier than before. Exchange 2003's deployment tools smooth the process considerably, but it still takes careful planning and lots of reading and patience to install Exchange 2003 in a cluster. Having some kind of Microsoft support on hand is also advisable. Windows 2003 clustering with SQL Server 2000 and Exchange 2003 has greatly improved the reliability of our database and mail servers. The extra work involved in setting up a cluster was worth it.
