This is becoming a pretty common question in my Exchange classes. Which should I use? Why one over the other?
My current recommendation is to use CCR whenever possible vs. SCC. Why? I am glad you asked that question.
High Availability, see my definition here, is all about risk mitigation. What we should be doing is identifying risks to our important/critical applications and finding ways to eliminate or at least mitigate the risks where economically feasible.
One of the major risks that I see with Exchange Server 2007, as well as previous versions of Exchange, is losing my production database because of a disk failure or my database becoming corrupted. In the case of a disk failure, I would normally restore my database, but that takes time, and very few people want to run a dial tone database while they recover. So, two Exchange Server 2007 technologies provide some protection against a lost database drive or a corrupted database. One is Local Continuous Replication (LCR). LCR, however, is a single server technology and does not provide the risk mitigation against an entire server loss that a cluster can provide. The second technology is to use Cluster Continuous Replication (CCR). CCR provides the one extra piece that a Single Copy Cluster (SCC) does not: it provides for loss of the database disk or corruption of the database.
Since CCR does not do a block by block copy like a SAN replication utility might, the likelihood of corruption passing from the production database to the passive copy is extremely low. Remember, the passive copy is receiving transactions and having them applied to the database much like the production database. Corruption is not copied in such an environment.
Of course, we can’t forget that by using CCR, we also can eliminate the need for a SAN, which is a huge cost savings.
So, add the increased risk mitigation and elimination of the SAN requirement for high availability and you can see that CCR is a vast improvement over SCC.
I want to end the work day on a positive note. Yes, there are a couple of things about Exchange Server 2007 that tick me off, but overall, I love the product.
I just wanted to take a couple of minutes to mention some of my favorite features.
Databases – The change to a single database is a big plus in my mind. Also, I love that we can now have up to 50 Storage Groups and up to 50 Databases when using Enterprise Edition. With the larger number of databases, we can now have smaller and faster databases. We can also have an extremely large number of spindles to provide even more disk I/O. Of course, being able to have a single transaction log disk per database also is a nice change which will lead to better performance as well as easier database recovery.
OWA – Wow, lots of great changes here (except for the issue of Public Folder support which will be added back with SP1). I love that it is so much easier to select recipients without having to do a search. The vast number of new options is also a big plus.
Mobile – Being able to allow users to wipe their own lost/stolen mobile devices is nice as well as being able to allow users to setup their own devices. The updated Exchange Active Sync is fantastic.
OOF – Out of office messages are now much more granular. It is possible to configure them in a number of ways so that we can control the OOFs differently based on whether it is an internal sender vs. an external sender and even to the point of controlling OOFs to partners where we have SMTP connections setup directly with them.
Transport Rules – I can’t say enough about all of the fantastic things we can now do using transport rules. I could go on for hours about the many new options we have as administrators including simple things like being able to add disclaimers to all outbound email.
UM – Unified messaging with the Outlook Voice Access capabilites are fantastic. I am having a blast playing with this new functionality.
If you have looked into Exchange Server 2007, I highly recommend downloading an evaluation version, taking a class, and seeing just how it can improve messaging in your company. The changes I have listed above are just the tip of the ice berg. There are many more new features that I am sure your company can use today.
I have been thinking about this a great deal lately. I, as I said in my previous blog post, I am pretty concerned at the way a CCR implementation is supposed to be moved using the Exchange Management Shell (EMS).
Scott Schnoll, somebody I respect greatly, posted on the Exchange Team blog that it is recommended to always use EMS to move the clustered mailbox server from one node to another. He says that you can use the Cluster Administrator tool, but that using Cluster Administrator is not recommended 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.
What does this mean? Well, I have to say it since nobody else will. It means that:
- Messages may be lost because they were not properly replicated before the move of the clustered mailbox server.
- The database may not be mountable.
- Replication might be broken.
You know what that sounds like to me when you say a database can’t be mounted? It sounds to me like it might be corrupted. At the minimum, it might not be complete because of lost messages that didn’t get replicated. In either case, this is bad (how is that for a technical term?) and should be something that is discussed in your organization.
With this in mind, all I can say to you is that you should never use the cluster administrator to move a CCR clustered mailbox server because it could cause ugly things to happen.
Scott Schnoll posted on the Microsoft Exchange Team Blog the other day regarding the proper tools to use when managing an Exchange Server 2007 Cluster.
Yes, there is some confusion. If you research the topic on Microsoft’s website, documentation clearly says to use the Move-ClusteredMailboxServer cmdlet. Most of us in the industry just took that and ran with it. But, there is a problem here. Every other single application that runs on Windows Server 2003 server clustering can be fully managed using the Cluster Administrator tool or the cluster.exe command line. Exchange Server 2007 is a bit different when dealing with Clustered Continuous Replication (CCR).
Using the Cluster Administrator MMC, it is easy to properly delegate permissions so that operators and other non-administrators can perform basic tasks when managing clustered applications. The Exchange Server 2007 Management Shell (EMS), does not provide that ease of delegation. I can honestly say that I sure don’t want to be giving Exchange Administrator permissions to non-Exchange administrators. That is opening up a can of worms and it would be impossible to get them all back in again.
Please take a few minutes and read Scott’s blog. It is extremely helpful, but at the same time, it really underlines a serious management problem. He states, “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.” I see a potential problem here for many organizations. There really isn’t a good way to delegate permissions to an operations type of team to allow them to do Exchange Server 2007 clustered mailbox moves without giving them too many other permissions in the Exchange environment.
Right now, I have to say that I am a bit peeved. OK, maybe that is too strong, but I am extremely concerned about how this should be best handled.
In order to keep the number of servers down in a high availability environment, administrators have been looking at using Network Load Balancing (NLB) for CAS and then co-locating the HT role on each node of the NLB cluster to also provide high availability for the HT role.
This configuration can work, and it really is not too difficult to configure. It is extremely important to note that using NLB to load balance the default SMTP receive connectors (using port 25) is not supported and is completely unnecessary since they are load balanced for all intra-Exchange communications like HT to HT communications. However, using NLB to provide redundancy and load balancing for connections to HTs that are hosting Client SMTP receive connectors (using port 587) is fully supported and may be desireable if you have a large number of external SMTP/POP and SMTP/IMAP clients that need to connect to this receive connector.
The steps that you need are to:
Setup two servers running Windows Server 2003 with two NICs in each server
Install Exchange Server2007 Hub Transport and Client Access Service (CAS) on each server
Configure one NIC for the Network Load Balance cluster and setup the other NIC in a separate network so it can be managed through that IP address
Configure NLB with Unicast and even load balancing
Setup the port rules:
Port 25 to 25 for both TCP and UDP and select the radio button to disable this port range (this will exclude port 25 from being listed to using the virtual IP address of the NLB cluster, but still allow the individual server IPs to still listen to port 25)
Port 465 to 465 for both TCP and UDP and selected the radio button to disable this port range
Port 80 to 80 for both TCP and UDP and set affinity to none (I recommend “none” so you can easily test and verify that it works)
Port 587 to 587 for both TCP and UDP, affinity none (this is for the client SMTP receive connector)
Port 443 to 443 for both TCP and UDP, affinity none
Port 110 to 110 for both TCP and UDP, affinity none
Port 993 to 993 for both TCP and UDP, affinity none
Port 143 to 143 for both TCP and UDP, affinity none
Port 995 to 995 for both TCP and UDP, affinity none
With affinity set to none, you can more readily test the CAS (after updating the web pages to show which server is actually responding) and verify that the load is being shared. You can also test to make sure the NLB cluster does not respond to SMTP on port 25, which it shouldn’t if you set it right, and verify that each server does respond to SMTP as an individual server name.
You can configure protocol logging for the other protocols and telnet to the ports using the NLB IP address to see if they are loading balancing like they should. You can also use the NLB IP for the testing by sending and receiving messages and checking the message tracking logs to see that the traffic was being balanced. It all worked.
NOTE: You may want to change affinity to either single (especially if it is being used internally) or Class C (especially if it is accessible from the Internet) once your testing is done.
Good luck, and have lots of fun!