1

I'm looking at the database availability groups in regards to creating a constant replication of the mailbox database.

Here are three options I'm thinking of (and sorry if I'm wrong with my assumptions on this).

  1. Completely new server, doesn't need to be high-end. Normal server to only house the Mailbox server role of Exchange 2010 and create the constant replication.
  2. I have a secondary DC that does absolutely nothing but the tasks of the DC. Install the Exchange 2010 Mailbox role on that system and create the constant replication.
  3. Add another drive to the Exchange 2010 server, and add a Mailbox database to that drive and start the replication here.

What do you guys think the best method/practice for this would be?

I should note: my thought is just a new server for the replicated database. I don't really like the same server idea. possibly even have this server at a different location - remote store etc. to hold the replication. I'm not 100% sure how it works yet however.

Ben Pilbrow
  • 12,041
  • 5
  • 36
  • 57
Jeff
  • 1,089
  • 5
  • 26
  • 46
  • Option 3 is not actually an option with Exchange 2010. You might be thinking of Local Continuous Replication (LCR) which was an option with Exchange 2007 but not 2010. – Paul Cunningham Apr 19 '11 at 00:28

2 Answers2

2

Running on a DC can work, but it's kind of fragile.

http://support.microsoft.com/kb/940845 <-- MS KB article defining some of the problems.

For one, you'll need to tweak some things to make sure the Exchange service start after a reboot.

Completely separate storage on the same server is also a valid replication config, though as you note not as robust as having a discrete server for it. Recovering from that same-server storage will require staging up a new Exchange server and mounting from the replicated databases. It'll work, but there is some effort involved.

sysadmin1138
  • 133,124
  • 18
  • 176
  • 300
  • right. i would like to stay away from fragile if possible. i try to make things stable - and as effortless as possible in the end. what do you mean by tweak some things to make sure the exchange services start after reboot ? are you talking about the replicated database or the primary exchange server (hub transport , client access ) roles? – Jeff Apr 18 '11 at 21:25
  • @Jeff If running on a DC, chances are good that DC is also a global catalog. The Exchange services require the GC service to be up before it starts, and the only way to guarantee that is to make the Exchange services depend on the GC service by hand. – sysadmin1138 Apr 18 '11 at 21:36
  • it is a gc. i see what you are saying. i wonder if a automatic - delayed start would work? – Jeff Apr 18 '11 at 21:42
  • Delayed start *might* work, but I wouldn't depend on it. It's not too difficult to manually make a service dependant on another, but I just always err on the side of caution when Microsoft say *This is a supported but not recommended configuration*. You never know when a Microsoft support wonk will just give up citing Exchange being on a DC as the root cause of some problem you're having. – Ben Pilbrow Apr 18 '11 at 21:46
  • The do just what Ben says. On one memorable call they kept saying it must be running Exchange in an ESX cluster causing my problem, when it was clearly a misconfigured transit rule once they actually looked at the problem. – sysadmin1138 Apr 18 '11 at 21:49
  • i see. appreciate both your help. – Jeff Apr 18 '11 at 21:53
2

Option 1 definitely sounds the best. Microsoft don't recommend you install Exchange on a Domain Controller, and adding extra disks to an existing server isn't going to protect you if for example the motherboard fails in that machine.

For your second server, the best thing you could do is buy the same server and configuration as your existing server. Sometimes failover servers are treated as second class citizens and as such are specced lower than the primary server. The problem with this is that when the time comes to fail over, the same management that told you not to spend as much money on the failover server will be hounding you because it is not very quick.

One requirement is that the disk layout MUST be identical on your two Mailbox servers. If you have a 500GB Exchange volume on E: and a 140GB transaction log volume on F:, this must be the same across both servers in your DAG.

Something else that springs to mind is if this server is only going to be a Mailbox server, have you factored in high availability for the other roles such as CAS and Hub Transport? It's all good and well having a DAG, but if you've only got one CAS/Hub server and that fails, you may as well not have a DAG, since Outlook goes via a CAS server to the Mailbox, not directly to it as in older versions of Exchange.

Ben Pilbrow
  • 12,041
  • 5
  • 36
  • 57
  • i think you meant option 1 in your answer. to be honest - i just learned about the DAG , and was curious what others thought about a 'best practice' setup for it. but from your post im guessing that i could set this new server up as basically a mirror of the primary server, so in the case of fail over - all the roles on the secondary would just kick in and downtime would be minimized? i understand what you mean about secondary servers being considered as second class citizens. – Jeff Apr 18 '11 at 21:31
  • Heh, I may have been having a senior moment :P You can *sort of* have all roles on 2 servers, but highly available Mailbox servers and CAS servers can't be on the same box, so you need a hardware load balancer to make the CAS server highly available with only 2 Exchange servers. – Ben Pilbrow Apr 18 '11 at 21:35
  • ok i see what you are saying. originally i was thinking that the failover system would be similiar to a secondary dc. dcpromo and a few other commands and you are up and running. im not familiar with hardware load balancers. ill have to do some research on them. thanks for the advice though – Jeff Apr 18 '11 at 21:41
  • i had to go with this for the answer. i think it gave me a better idea of what i want to do. – Jeff Apr 18 '11 at 22:13