Exchange 2010 High Availability and Disaster Recovery Video

Made this video for Simpler-Webb regarding Exchange 2010 Database Availability Groups and the differences between Exchange 2007 HA/DR planning and Exchange 2010 HA/DR planning - it's a little goofy and embarrassing, but have at it!

Exchange 2010 Standard to support High Availability DAGs

From the Unified Communications blog, there is this post on 2010 licensing.


From there:
"On the server side, Exchange Server Standard will now support high availability, so all customers can take full advantage of the new database availability group capabilities. Exchange Server Enterprise enables configurations with up to 100 databases per server."

Still looking for some documentation on the maximum number of databases in a DAG that Standard edition will support, but my presumption is 5 (Similar to the 2007 Standard limitation on DB's)

Update: Scott Schnoll has confirmed this is accurate. Exchange 2010 Standard can have up to 5 DAG databases!

This is HUGE news for small customers wanting HA (the difference between $550 per Exchange Standard and $3200 for Enterprise) - for a 3 server DAG, that's $8k in licensing savings on Exchange ALONE.

Awesome news for small businesses wanting HA and DR for Exchange!

Exchange 2010 - Database Availability Groups - Part 2

In Part 1 of my DAG coverage, I gave some generic design considerations, and the how to configure a 2 server DAG. In part 2, I will cover adding an additional DAG copy of a database.

Before you begin, you need to rapidly deploy your OS and pre-requisites, and then you can deploy an additional DAG copy, with a few mouse clicks!

First, add your new server to the DAG group:
then, add the server we are adding to the DAG:

Then, add a database copy in the database management section of Organization Management:



And after some time seeding:

Now, let's test that UK server! First, I used OWA to send myself a recent email.

Then activate the EU server:

Choosing a lossless activation:

Now, this being a different AD site, I saw this:


Which was very concerning at first, but after some time (I have my VM's scaled down quite a bit) it synced up:


Confirming via the OWA CAS on EXCH2010EU, my latest email was intact:

That's it. We seeded, and failed to the UK site. Now we can seed back to the main server:

I performed another lossless activation, and it worked perfect:


And before I end part two, let's try and BREAK it � here I am hitting the hard power button on the activated DB server for geodb1.


After re-attaching RDP to the next server, and refreshing the view:


The local server mounted, and the UK site is healthy still. OK, let's plug in the power cord I "tripped" over and see how things go.
Few seconds after boot up:

At which point we can choose to move it back, or let Exchange manage it autonomously.

Exchange 2010 - Database Availability Groups - Part 1

This is part one of a two part series on Database Availability Groups, which is the Exchange 2010 High Availability and Disaster Recovery technology.

DAGs are similar to Exchange 2007's SCR and CCR technologies, but mixed together, along with a few key benefits like:

Incremental Deployments - You can start with a single server environment and add hardware later to phase in a DR plan or additional high availability. However, you would need to deploy Exchange 2010 on Windows 2008 R2 Enterprise as DAG's require the Failover Clustering role. In a lab, I wouldn't mind an in place Standard to Enterprise in place upgrade, but your opinion may differ on such an upgrade on a server containing production data.

Automated Cluster Management - In Exchange 2007, CCR Cluster management needed to be pre-configured on server nodes, and there was additional complexity and confusion on what tasks you performed in Cluster Administrator, and which in Exchange Management Console or Shell. In Exchange 2010, this is ALL performed from native Exchange tools, and most can be done from a GUI.

Combined HA and DR plan - In Exchange 2007 CCR was the High Availability solution, while SCR was the Disaster Recovery solution. In order to effectively get both, deploying both was required. There was a combined solution known as "Stretched CCR" where a node would be in a different physical site, but this was fairly complicated and had high bandwidth requirements.

Lower Bandwidth requirements - In Exchange 2007, SCR used SMB (Server Message Block) for transaction log shipping. SMB is well known as being a "fat" network protocol. In Exchange 2010, Exchange Administrators can choose a single TCP port (configurable) for direct TCP connectivity for log shipping.

Less Powershell - If you checked out the Exchange 2007 SCR article I recently published, you see there is a LOT of PowerShell, which is why I wrote the article - there are a lot of steps and places for confusion, mistyping, and mistakes. And in the event of a diaster, that can be pretty harrowing. The Exchange 2010 DAG process, while of course is able to be managed from PowerShell, is not a requirement. Most of the screenshots I will post you will see are done in the GUI.

There is a LOT to be learned about scaling and planning DAG's, and I am leaving this to Microsoft for now. Below are some valuable links on DAGs, DAG planning, and planning disks for your member servers in a DAG.

Planning for High Availability and Site Resilience - the requirements here is pretty much required reading if you are considering implementing Database Availability Groups in your environment.
Mailbox Server Storage Design Recommendations - at the time of this posting, this was marked as "in tech review" - about 1/2 way down you can tell the article is talking about Exchange 2007 more than 2010. There also is still not an Exchange 2010 storage calculator, this will hopefully come soon.
Deploying High Availability and Site Resilience - much of this How to is based on information here.

First off, my environment - Exchange 2010 is ONLY 64 bit, so of course, that is the architecture in play here.

Server	OS	LAN Network	Replication Network
EXCH2010	Windows 2008 R2 Enterprise	192.168.201.62	10.1.1.62
EXCH2010DR	Windows 2008 R2 Enterprise	192.168.201.63	10.1.1.63

Currently, there is one database on EXCH2010 named geodb1 - it contains a single user mailbox. As you can see, I configured this database with non-default paths. While using the default path is fine, if and when you need to specify a path in PowerShell ever, it's easier if its not 50 characters of path to type.



Whatever server is the witness needs to be a member of the Exchange Servers domain group, or you will receive an error message. If you are using a domain controller as your FSW, you need to read this article by Devin Ganger. the DC's computer account to be a member of the Exchange Trusted Subsystem group, and your Exchange Trusted Subsystem group must be a member of your domain's BUILTIN\Administrators group. Thanks to Tom Pacyk for this information! If you receive the warning "Insufficient permissions to access file shares on witness server" please review Tom's article.



Once we create the DAG, we can now add servers to the DAG.


Adding both servers is as simple as right clicking the DAG and choosing "Manage Database Availability Group membership." This process may take a while depending on hardware, as during this step is when Failover Clustering is installed and configured on both servers.


This process also created the DAG networks for me, and now my DAG screen looks like this:



I do not want replication enabled on the 192.168.201.x network, I want it explicitly on the 10.1.1.x network, so I disabled replication for DAGNetwork01, and also told the DAG to ignore the network using Powershell:

Set-DatabaseAvailablityGroupNetwork -Identity GEODAG\DAGNetwork01 -IgnoreNetwork:$true -ReplicationEnabled:$false

Now we can add a database to our DAG!

Then right click the database you want a copy of and choose "Add Mailbox Database copy" and choose the server you want to add a copy on.





This will complete, And then you can see the database re-synchronizing, and then come Healthy:




Here, I decided to reboot the EXCH2010, and refreshed the EMC console on EXCH2010DR:



We can see that EXCH2010 failed, and EXCH2010DR now has my data. I logged into OWA and confirmed.

When EXCH2010 came back up, I waited and refreshed again:



Healthy! Very neat.

At this point, we can manage where the data is with the right click context menu on DB copies:



Choosing which, we have several options:



In an "available" scenario Lossless is the best choice.



We can see the status flip and copy queue stack in the other's favor.

In part two of this, I will add a third Exchange server at a DR location to add some DR planning and also show how this affects DAG network planning. In addition, I will hopefully dig in to more failure scenarios and how to address them. Keep in mind, like I said - this is a pretty basic DAG implementation, and no real planning of physical architecture lying underneath it.

Continue Part Two

Exchange 2007 HT and CAS in NLB - Unicast versus Multicast

I have implemented about 4 NLB clusters for HT, CAS, or both now, and every time the rule of thumb has been, use what works.

From the MS Exchange page on IPv6 (also applies to IPv4) we know that:

• Unicast address A packet is delivered to one interface.
  
• Multicast address A packet is delivered to multiple interfaces.
  

More searching turned up this very helpful article describing the differences:

http://vittoriop77.blogspot.com/2006/03/nlb-unicast-vs-multicast.html

So, in one implementation, the customer had a Proventia M60 firewall, and unicast ended up working and performing more reliably. In another using an Juniper SSG firewall, unicast performed poorly and multicast ended up being the fix.

I searched the Exchange implementation guide and CHM thoroughly and didn't find any particular guidance, so I think at this point trial and error is the best bet. Learn what works in your config and go with it.