Exchange CCR Cluster resources

neil4933 used Ask the Experts™

I have just created a CCR cluster on Windows 2003 Server.

If I go to Cluster Administrator, I notice there are two Cluster Groups:

ExchangeCCR: Exchange IS, System Attendant, First Storage Group, IP Address etc

Cluster Group: Cluster IP Address, Cluster Name, Majority Node Set

Could someone explain the difference between the two? Also, when I set the Cluster up, I had to enter an IP address and name for the Cluster, which was different to the CMS/address name. Should this have been the case? If so. what does it represent?

Finally, does anyone know a way to find out which physical node a CCR server is on by viewing the Exchange Console? Say for instance I had multiple CCR clusters set up globally, and I wanted to check which node the one in Japan was on, how could I see that? So far, the only way seems to be log onto the CMS and open the Cluster Administrator
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®


Yes, I've seen that but it doesn't answer my questions?
The two cluster groups represent the Windows cluster (Cluster Group), and the Exchange virtual server (ExchangeCCR).  The Windows cluster is sort of a "virtual" Windows server, with it's own IP address, that provides the foundation for cluster-aware applications like Exchange, SQL Server, etc.

On top of the Cluster Group, you have your Exchange application which is formed by the ExchangeCCR cluster group.  The resources inside the ExchangeCCR cluster group are what compose the Exchange virtual server.

You can think of it this way.  You have 2 cluster objects.  One is a virtual Windows server, the other is a virtual Exchange server.  The virtual Exchange server is "running" on the virtual Windows server.

Each one of these cluster groups requires its own IP address.  The IP address of Cluster Group is the address of the Windows virtual server, and that is what Cluster Administrator connects to for managing the Exchange cluster.  You can actually use Remote Desktop to connect to the Cluster Group address!  The IP address of the ExchangeCCR cluster group is the address of your Exchange server -- it's what other mail servers and your clients connect to using SMTP, POP, IMAP, MAPI, HTTP/S, etc.

You cannot see which physical node you are running on from Exchange System Manager.  From it's point of view, all it knows is that it's running on your virtual Windows server.  You need to use Cluster Administrator to see which physical node your cluster groups are running on.


Thanks Grobbs, well explained...

Just one further question - if I was to fail over the Exchange resources from one node to another, should I also fail over the Windows Cluster group resources? I notice that if I use the Exchange Management Console to fail over, it doesn't move the Windows Cluster Group. So just wanted to check if failing over was recommended to be a two step process (move Exchange resources using Exchange Management Console and then move Windows resources using Cluster Admin)?

Alternatively, we could just reboot the active node and this would move *everything* over to the passive?
Yes, it's a two-step process to fail over the cluster, just as you said:  Exchange Mgmt Console to move Exchange resources, and Cluster Aministrator to move Cluster Group.  It is recommended that you move the Cluster Group resources as well when you want to fail over to the other node, although I don't believe that's strictly necessary.  Everything will keep working with one group on one server and the other group on the other server.  But then both servers are really active, and you'll have to eventually fail over part of the cluster when you do maintenance (install patches, etc.).  You may as well just keep both groups on the same server, so that you KNOW you can safely work on the passive node.

This used to be a single step with Exchange 2003, where the Exchange resources could also be moved using Cluster Administrator, but not with Exchange 2007.

It is possible to fail over your entire cluster by rebooting, but that's not recommended.  Rebooting relies on the passive node to notice that the active node is down, which involves a small time delay, and it is seen as a failure.  It's cleaner to move the resources before rebooting.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial