We want to build a multinode Exchange Server 2003 cluster in which not all nodes are identical. We want two two-processor nodes (one to serve as the SMTP bridgehead and one to act as a public folder and resource mailbox server) and two four-processor nodes (one to be an active mailbox server and one to serve as a passive mailbox server). Can you see anything wrong with this design?

Microsoft recommends that your cluster be built with identical nodes, but doing so isn't mandatory. What is mandatory is that you use machines that appear in the Windows Server Catalog Cluster Solutions site (formerly the Cluster Hardware Compatibility List—HCL), which you can find by going to http://www.microsoft.com/windows/catalog/server/, clicking the Hardware tab, and choosing Cluster Solutions from the list at the left. Be sure to check the catalog before you set up your cluster. (Be aware that the number of processors isn't part of the HCL certification—for example, the list doesn't look at whether an approved server that can hold four processors actually has all four or only two installed—so don't expect to see that information.)

Having said that, I advise you to reconsider putting your SMTP bridgehead on a cluster node. Why? There are several good reasons:

  • Exchange Intelligent Message Filter (IMF) can't run on a cluster, so you won't be able to use this helpful (and free) tool on your bridgehead server.
  • For what you pay for one cluster node, you can probably buy two or three (or maybe more) smaller single-processor servers, giving you a higher degree of redundancy, as well as reducing the complexity of the cluster. If your goal is to boost your SMTP bridgehead availability, I suggest using several single-processor servers and using the Windows Network Load Balancing Service (NLBS) to distribute incoming traffic across those machines.
  • There's a fair chance that you'll want to perform different types of periodic maintenance (e.g., upgrading components) on SMTP and mailbox servers. If you set up a cluster as you propose, you'll have to take everything offline instead of being able to perform maintenance on one component while keeping the other component running.