Exchange Tools vs. Cluster Tools: What's the Deal?
Published Oct 22 2007 01:53 PM 3,909 Views

Note: Since authoring this blog, Microsoft Customer Support Services has identified a scenario in which moving a CMS using the cluster tools can leave databases in a dismounted or offline state. During regular operation, the Microsoft Exchange Replication service maintains a "mount allowed" value for each server within the CCR cluster via a private property of the clustered Information Store resource. When the Exchange tools are used to move resources between nodes, the Microsoft Exchange Replication service performs health checks to determine if the mount allowed value can be set to true. When moving resources with the cluster management tools, the Microsoft Exchange Replication service might not immediately become aware that a resource move has occurred. This can result in some or all of the databases hosted by the CMS in an offline or failed state. This can happen randomly, or not at all. Using the Exchange tools to move a CMS allows for notifications to be sent directly to the Microsoft Exchange Replication service, thereby preventing this issue from occurring. If you should happen to encounter this situation, we recommend you use the Exchange tools to move your CMS between nodes, and not the cluster management tools.
There is some confusion and misperceptions about the correct tools to use to manage a clustered mailbox server (CMS) in a single copy cluster (SCC) or cluster continuous replication (CCR) environment. Specifically, folks are asking the following questions:
  1. Do I use the Windows Server failover cluster management tools (namely, Cluster Administrator and Cluster.exe) to manage a CMS, or do you use the Exchange tools (namely, the Exchange Management Console and the Exchange Management Shell)?
  2. Will anything bad happen if I use the wrong tool to perform a task on my CMS?
To clear up this confusion, I thought a blog post might be helpful. The answer to the second question is generally, no, because the answer to the first question is generally, there is no wrong tool. Instead, use of the tools really falls into two categories:
  1. You have to use tool X because there's no choice. This category refers to the tasks that must be performed with the cluster tools.
  2. You should use tool X instead of tool Y because it's better. This category refers to tasks performed by Exchange tools that do extra things that are good for you that the cluster tools don't do.
Let's look at what we say in the documentation which speaks to the second category, where we recommend using Exchange tools instead of Cluster tools, and the reasons why we recommend them. In the content related to CCR, we say the following:

Cluster Administrator and Cluster.exe should not be used because:  
  • These methods do not validate the health or state of the passive copy. Thus, their use can result in an extended outage while the node performs the operations necessary to make the database mountable.
  • These methods may also leave a database offline indefinitely because the replication is in a broken condition.
In the content related to SCC, we say the following:
Cluster Administrator and Cluster.exe provide mechanisms for moving resource groups between nodes in a cluster. When performing a handoff of a clustered mailbox server in a single copy cluster, we recommend that you use the Move-ClusteredMailboxServer cmdlet or the new Manage Clustered Mailbox Server Wizard in Exchange 2007 Service Pack 1 instead of the cluster management tools, because it enables the administrator to specify a reason for the handoff.
To be super clear, Microsoft fully supports the use of Cluster Administrator and Cluster.exe to manage clustered mailbox servers in Exchange 2007 RTM and SP1. But there are certain tasks for which we strongly recommend using the Exchange tools instead of the Cluster tools. But then there's the first category. There are other scenarios in which the Exchange tools are not available, or cannot be used because continuous replication is not healthy, or because Exchange has not yet been installed on all nodes in the cluster. In those cases, because the Exchange tools cannot be used, you have no choice but to use the Cluster tools. Going back to the documentation once again, there are several places where we provide instructions that include the use of Cluster Administrator or Cluster.exe because you have to use those tools, such as: These are just some examples; there are others. One of the reasons we recommend using Exchange tools to manage clustered mailbox servers is that, while Exchange is cluster-aware, the cluster tools are not Exchange-aware. In a CCR environment, the Exchange tasks perform additional checks that the Cluster tools do not and cannot perform, such as checking the health and status of continuous replication. There is intelligence in the Exchange tasks that blocks the move if the task determines that, based on the current state of replication, a handoff would results in one or more databases not mounting. Once those additional checks are done, the Exchange tasks use the Cluster API to do cluster-related operations such as stopping a CMS, starting a CMS, or moving a CMS. In other words, the Exchange tasks do everything that the Cluster tools would do (using the same Cluster API), as well as some additional checks that the cluster tools can't and don't do. For example, besides checking the state of replication, in both a CCR environment and in an SCC, the Exchange tasks also allow you to specify an administrative reason for a move or a stop, and it records that reason in the event log for audit and tracking purposes. The cluster tools also cause a move or a stop operation to be logged in the event log, but they do not allow you to specify a reason for the action. I think some of the confusion around which tool to use is the result of having different tool guidance for different tasks that are associated with a single CMS, or with a specific environment (CCR or SCC). It just so happens that the guidance is the right tool for the right task and the right tool varies depending on what task you're performing. I also think some of the confusion may stem from the fact that, in previous versions of Exchange (for example, Exchange 2003), there weren't any Exchange interfaces that were specific to clustered mailbox servers (what we used to call Exchange Virtual Servers (EVS)). In fact, it was just the opposite. When you installed Exchange 2003 in a cluster, it was not Setup that created the EVS, but instead it was the administrator manually creating a group with IP address, Network Name, and Physical Disk resources, and then creating a System Attendant resource, which in turn hydrated and created an EVS. This made the Setup experience for an EVS very different from the Setup experience for standalone Mailbox servers. This was a problem we squarely addressed in Exchange 2007. One of the many goals we had for Exchange 2007 was to provide a rich Exchange-based management experience for all Exchange servers, including clustered mailbox servers. We wanted to get folks out of non-Exchange tools as much as possible, and allow them to use Exchange tools (the Exchange Management Console and the Exchange Management Shell) to manage Exchange objects (such as a clustered mailbox server). Previous versions of Exchange didn't provide any interface to manage Exchange Virtual Servers; instead, administrators had to use Cluster tools, even when it came to creating the EVS in the first place. We did create a rich and robust management experience with the Exchange tools, but there are still a few tasks that remain outside of Exchange tools and in Cluster tools. But we do recommend that you use the Exchange tools when performing certain tasks, such as:
  • Moving a CMS between nodes. Move-ClusteredMailboxServer in RTM and SP1, and the new Manage Clustered Mailbox Server Wizard in SP1, remain the preferred tool for regular handoffs (scheduled outages). In the case of CCR, extra health checks are done, in the case of SCC, checks for an existing CMS are done, and in both CCR and SCC, you can log an administrative reason for the move. In cases where the tasks are not available, or by design won't work because replication is not healthy, you can use Cluster Administrator or Cluster.exe to move a CMS between nodes.
  • Stopping a CMS. Stop-ClusteredMailboxServer in RTM and SP1, and the new Manage Clustered Mailbox Server Wizard in SP1, remain the preferred tool for stopping a CMS (taking it offline). In the case of SCC and CCR, these tools perform a faster offlining of the CMS, and they enable you to log an administrative reason for the stop.
  • Starting a CMS. Start-ClusteredMailboxServer in RTM and SP1, and the new Manage Clustered Mailbox Server Wizard in SP1, remain the preferred tool for starting a CMS (bringing it online), because it has extra Exchange logic in it that does things like look for the presence of a CMS that is already online on the same node.
At the beginning of this post, I said that nothing bad will happen if you use the wrong tool because there is no wrong tool. But let's say you've ignored our recommendations to use the Exchange tools for some tasks, and instead you decide to use the Cluster tools. Will anything bad happen in this case? Again, generally, no. I say generally, because it depends on your definition of "bad." Here's what I mean by this. Using Cluster Administrator or Cluster.exe to take a CMS offline, to bring a CMS online, or to move a CMS between nodes will not cause any harm to the cluster, to the clusters configuration, to the CMS, to the CMS' configuration, to any databases hosted on the CMS, or, to any other aspect of the cluster. So none of that bad stuff will happen. But remember, if some of the Exchange checks that are performed only by the Exchange tools and not by the Cluster tools are skipped, then bad things might result from the action. For example, in a CCR environment, Move-ClusteredMailboxServer checks to see if replication is healthy before performing the move. If replication is broken or too far behind, the Exchange task will block the move, and no change will happen in the cluster. Everything will remain online, with no interruption in service. By contrast, the cluster group move function knows nothing about the state of replication, and will happily perform the handoff of the CMS, even if replication is broken or too far behind. After the handoff, any storage group for which continuous replication is not healthy will have an offline database, and will incur an interruption in service until the copy can be brought up to date, or until some other administrative action is taken that corrects the Failed copy status for the storage group(s). So that kind of bad stuff could happen. And that is why we recommend using Exchange tools for certain tasks; they provide a level of protection for you that the Cluster tools do not. I hope this clears things up for everyone! - Scott Schnoll
10 Comments
Version history
Last update:
‎Jul 01 2019 03:31 PM
Updated by: