Skip to main content

Geographically Dispersed CCR Cluster

I recently had the opportunity to install a geographically dispersed CCR Exchange 2007 cluster.

Server 2008’s cluster features can now handle clusters on separate subnet’s making the fact that the only data centres available were operating on Layer 3 wasn’t a problem. I didn’t need to stretch a VLAN across physical sites.

Configuring the networking for the cluster went slightly against the grain for me. Essentially the Private networking element has gone for these types of clusters, because all traffic, heartbeat and all has to go over the public network. That said, it was a simple process. I configured the networking using four NIC’s, three were teamed and another was on its own but it was set not to register in DNS. I didn’t want client traffic coming over the single NIC.

When you set up the cluster you simply enter two IP addresses that the cluster can use, and on failover, one, the one that’s not on the subnet the active node is in, will stay offline, sounds nice doesn’t it, but wait.

Even though you don’t have to stretch a VLAN anymore for this type of cluster. Exchange 2007 still requires cluster nodes to be in the same Active Directory site. This means that if you are planning for the disaster of losing a site, then you’ll need two DC’s in each site in the same AD site so that each node will always have a DC in the event that you loose one of the physical sites. You can’t use DC siteCoverage for this, as I discovered.

With the cluster set up I set up a combined HUB CAS in each physical site. Exchange will load balance mail flow to each HUB Transport Server by itself, but what about CAS connectivity. Autodiscovery service will handle Outlook Web Services, such as OAB & Out of Office etc, but what about Outlook Web Access. On the same subnet you’d use NLB to provide users with a single resilient point of entry to OWA. That’s no good on separate subnets unless you have a hardware load balancer, which I didn’t. So the OWA failover process became a manual process using CName’s in DNS. Not the nicest of solutions.

Another issue… You can’t put a Public Folder Database on a CCR unless it’s the on CCR in the Exchange Organisation. So Public Folders were to be sat on the HUB/CAS servers with content replication between each server. But in the event of a loss of one of those PF servers, it’s a manual failover process to get PF access back. You need to change the Default Public Folder Database for each Mailbox Database in the CCR. But that’s the same for any Public Folder failure.

So now we have two parts of the failover that requires manual failover, not nice, was starting to not like separating my Cluster over different subnets.

Issue number 3… When cluster failover occurs, the cluster IP changes. Meaning that unless all your clients are sat on the same AD site this change of DNS record will take time to replicate to them. By default the TTL of cluster DNS names is 20 Minutes. Meaning that in the worst scenario, your clients could be waiting 15 minutes for AD replication plus 20 Minutes for the DNS record to expire on their machines. 35 Minutes is a long time. Not really acceptable either. You can alleviate this issue by reducing the TTL of the record. I reduced mine to 3 Minutes. Another change you can make is by enabling change notification on the AD site links between the Cluster’s AD site and the AD site/sites where the clients sit. This brings the failover time down to 3 Minutes. Another change we made was in group policy… We created a GPO that configured Outlook not to complain about connectivity issues for 4 Minutes after disconnection from the Exchange Server.

This configuration meant that during a failover the majority of clients would not notice a problem unless they were sending emails and noticing that they were sitting in their outbox.

So with the exception of OWA and Public Folders, the system was quite acceptable. Just after covering off all of the above problems, space became available in our main data centre. We could now stretch a VLAN between these sites. So I reconfigured the networking and put each node in the same subnet. And guess what, most of the problems above went away. With the exception of Public Folder failover, but I can’t get these people to use the SharePoint servers available in the organisation, so I’m afraid that they’ll just have to live with that  :-).

Comments

Unknown said…
I completely resolved my question when I read this post, thanks to the author for the very detailed description. I wrote my review on the cvwritingserviceuk, you can go in and read. Thank you very much for your attention in your time.
10 June 2021 at 14:39
Post a Comment

Popular posts from this blog

Convert Linked Mailboxes to User Mailboxes in Bulk

My organisation has gone through a massive migration project to unify Active Directories and Exchange organisations. As a result of these migrations a lot of mailbox migrations have resulted in a lot of mailboxes ending up as linked mailboxes even though their not. The official TechNet article on this explains how to disconnect the mailbox and re-attach it to the user account correctly as a user mailbox. http://technet.microsoft.com/en-us/library/bb201749(EXCHG.80).aspx Another way to make this appear to be corrected is to manually change the “Recipient Type” AD property on the affected mailboxes. This though, is unsupported. Using the official method from Microsoft results in the loss of any specific mailbox information such as SMTP, x400 & x500 addresses, mailbox sizes and any other individual mailbox settings. Only e-mail addresses and mailbox sizes were important to me (I must admit, I forgot about mailbox sizes at first). I came up with the script below that would properly con
28 comments
Read more

Upgrading Exchange 2007 Clusters to SP2 – Workaround

I posted last month about a problem delegating installs of Exchange 2007 SP2. Delegated Admins will receive an error message stating the following… You must be a member of the 'Exchange Organization Administrators' or 'Enterprise Administrators' group to continue. Have been looking into the issue and have had a case open with Microsoft. Turns out that you only get this issue on a fully patched server. If you try upgrading or installing as a delegated admin on a fresh install of either server 2008 or 2003 you don’t see the problem either with Exchange SP1 or SP2. I haven’t had time to identify exactly what patch causes this yet, if I’ll bother at all. If you have patched your server though, MS came up with this workaround. Disable update checking for the BPA by heading into the registry and HKCU\Software\Microsoft\Exchange\ExBPA and either creating or modifying a DWORD named “VersionCheckAlways” and set it to ‘0’ Copy the installation files to a local drive and replace S
16 comments
Read more

Creating a Windows PE 3 Bootable USB device

I’ve used Windows PE for a long time. And I’ve grown to love it. It’s an extremely useful tool, not just for OS installation, but for diagnostics. Since there’s a version of WinPe for x64 & x86 (& itanium) I like to keep both x64 & x86 on my USB stick. Essentially copying the each version to the root of the USB stick as needed. Meaning at any one time I have three copies of WinPE on my USB stick. Other applications I copy directly to my USB stick, so that I don’t have to remount the image every time i need another application added. Shortly after Windows 7 was released came a new version of WinPE, WinPE 3.0 on the Windows Automated Installation Kit. Preparing the USB stick. You’ll need to prepare the USB stick. To do this open a command prompt using Run As Administrator and use the following commands. diskpart list disk select disk 7 clean create partition primary select partition 1 active format quick fs=fat32 assi
12 comments
Read more