In part two of this two-part series on clustering Exchange, SearchWin2000.com site expert Schott Schnoll talks...
about installing and configuring Exchange 2000 software to increase system reliability and performance. Part one discussed planning for an Exchange cluster, and getting your cluster ready for installation. For more information on Exchange clustering, tune in to our recent expert webcast. Click here to listen.
Once your initial planning is done, there are a few prerequisites for building an Exchange 2000 cluster, as well as some potential pitfalls you should know about. First, make sure you only use hardware found on Microsoft's Hardware Compatibility List. Use the Cluster category to select a cluster-certified system. But that's only the first step, because the software is equally important. You build an Exchange 2000 cluster using only the Enterprise Edition of Exchange 2000 running on Windows 2000 Advanced Server or Windows 2000 Datacenter Server. And as of this writing, you definitely want Service Pack 3 for both Windows and Exchange. (Editor's note: In the future, you'll likely need the highest-level service pack available.)
Next, prepare the hardware by applying the latest firmware and BIOS updates for all update-able components, and make sure you're also using the latest software drivers. In addition, I always like to disable unused hardware components, such as unused serial and parallel ports.
Now install Windows 2000 and the required IIS components, and then apply Service Pack 3. Visit Windows Update and http://www.microsoft.com/security to make sure you have all necessary updates and security patches. You'll also need to install the Windows 2000 Administration Tools, which can be done by executing adminpak.msi in the Run dialog on the Start menu.
To prepare the nodes for the Cluster Service, you'll want to disable all unnecessary services and configure the networks appropriately. Unnecessary services include Application Management, Computer Browser, Distributed File System, Distributed Link Tracking Client, Distributed Link Tracking Server, License Logging Service, the Print Spooler and the Task Scheduler. To configure the network, you'll want to disable NetBIOS on the private network interface, and if you are using network cards that support Media Sense, disable that, too. I also like to rename the connections to Public and Private to distinguish them easily in the Network Connections UI.
Next, create an account in your domain for use by the Cluster Service. The Cluster Service must run under a domain account, and you must use the same account on all nodes in the cluster. This account will also need Exchange Full Admin rights, which can be granted to it using the Delegation Wizard in Exchange Systems Manager.
The last step in preparing the nodes for the cluster service is to prepare the disks. At a minimum, you'll need to create a partition on the shared disks for the cluster quorum. Because the quorum is responsible for several critical operations in the cluster, it is arguably the most important component there. It stores the most current configuration data in quorum recovery logs and registry checkpoints; it maintains resource checkpoints; and it provides persistent physical storage. The recovery logs that the quorum maintains are also important because they enable any node to form and maintain the cluster. But more important, they guarantee that a single cluster is formed. Generally, I recommend a quorum partition of 500 MB.
At this point, you're ready to install the Cluster Service on each node. This is done through the Add or Remove Programs applet in Control Panel by selecting Add/Remove Windows Components. During installation, you'll need to acknowledge and agree to Microsoft's support policy regarding certified hardware and clustering. Basically, you are agreeing that you understand that Microsoft only supports clusters when they are built using hardware listed on the Cluster HCL.
Once the Cluster Service is installed, you need to install the Microsoft Distributed Transaction Coordinator (DTC) on the cluster. You have to do it even though there is very little available documentation from Microsoft about it. To install it, simply run comclust.exe on each node. This will automatically install and configure the DTC resource and COM+ database for your cluster.
At this point, you're ready to install Exchange 2000 Enterprise Edition on each node. You'll want to do this one node at a time, and make sure that the program files are installed in the same location on each system. Basically, you will install Exchange on one node, reboot that node, then install Exchange on the next node and reboot that node. Once each node has rebooted, apply Exchange 2000 Service Pack 3 to each node. This is done in the same manner -- or example, you install SP3 on one node, reboot that node, then install SP3 on the next node and reboot that.
If you are already running Exchange 2000 clusters but you have not yet installed Service Pack 3, you'll want to be aware of a permissions issue you'll encounter with SP3. After installing Exchange 2000 SP3 on a clustered server, the upgrade process may reset permissions you have modified to their original default values. For example, if you have removed the Everyone group from the permissions on the Organization object, the upgrade may reapply the original out-of-the-box permissions, so Everyone may be back. Permissions are only reset in this fashion on clustered Exchange servers, and no explicitly added permissions will be removed. So keep track of any manual permission modifications you have made so that you can reapply them after installing SP3. For more information on this issue, see Microsoft Knowledge Base Article 320007.
Now create one or more Resource Groups that will contain your Exchange Virtual Servers. When creating the Resource Group, do not make both nodes the preferred owner. If both nodes are designated as preferred owners and one node fails, the resource group will failover and failback repeatedly, effectively taking all resources offline.
After you have created the resource group, create the resources that are required for an Exchange Virtual Server. You'll need, at a minimum, a physical disk resource, an IP address resource and a network name resource. Once these three things have been created, the last resource you need to create is the System Attendant resource. During the System Attendant resource installation, you will get a prompt for the path to the data files, which must be stored on the external disk. At the completion of the System Attendant Resource creation, the additional Exchange 2000 resources (the Information Store, MTA, Routing Service, Protocol Virtual Servers and Microsoft Search) will be automatically created for you.
When you create the first EVS, you're using an Active/Passive model. If your cluster will run in Active/Active, then you will need to create an additional resource group, and create an additional EVS within it. Once all of your resource groups and resources have been created, you can bring the resources online.
I hope that after reading this article you have a pretty good idea as to what is involved in building a reliable Exchange 2000 cluster.
Microsoft has some great documentation on clustering Exchange 2000, including its deployment white paper, which you can download here.
Click here to read the first part of this article.