Now that Exchange Server 2010 is RTM and Server 2008 R2 is RTM, I thought it would be nice to create a multi-part article on how to use create a Database Availability Group (DAG) on two Exchange Server 2010 RTM nodes utilizing Server 2008 R2 as their Operating System. This article is to guide you through the entire process from preparing Server 2008 R2 for Exchange 2010 RTM, installing Exchange 2010 RTM, creating databases, creating a DAG, adding our nodes to the DAG, and then replicating our databases between both servers.
Part 1
Lab Setup
Guest Virtual Machines
One Server 2008 R2 Enterprise (Standard can be used) RTM x64 Domain Controller.
Two Server 2008 R2 Enterprise (Enterprise Required) RTM x64 (x64 required) Member Servers where Exchange 2010 RTM will be installed with the Mailbox, Client Access Server, and Hub Transport Server roles.
One Server 2008 Enterprise (Standard can be used) RTM x64 server that will be our File Share Witness (FSW) Server. This box will not serve any other purpose in this lab other than FSW.
Assumptions
- You have a domain that contains at least one Server 2003 SP2 Domain Controller (DC).
- You have configured the IP settings accordingly for all servers to be on the same subnet which includes the public NICs for both Failover Cluster nodes. I have provided the IP scheme of my lab below, but this will vary depending on your needs and VMware configuration.
Computer Names
DAG Node 1 – SHUD-EXC01
DAG Node 2 – SHUD-EXC02
Domain Controller – SHUD-DC01
FSW Server – SHUD-OCSFE01
Configuration of Exchange 2010 DAG Nodes
Processor: 4
Memory: 1024MB
Network Type – MAPI NIC (MAPI Network)
Network Type – Replication NIC (Replication Network)
Virtual Disk Type – System Volume (C:\): 50GB Dynamic
Storage Note: In a real-world environment, depending on the needs of the business and environment, it is best practice to install your database and logs on separate disks/spindles; both of which are separate from the spindles that the C:\ partition utilize. We will be installing Exchange 2010 RTM databases/logs on the same disks/spindles for simplicity sakes for this lab. While Exchange 2010 databases move a lot of the IO for databases to sequential IO, there’s still quite a bit of Random IO occurring and is still recommended to place the database and logs on separate spindles.
Network Note: A single NIC DAG is supported. It is still recommended to have at least one dedicated replication network. If using only a single NIC, it is recommended for this network to be redundant as well as gigabit.
Configuration of Domain Controller
Processor: 4
Memory: 512MB
Network Type – External NIC
Virtual Disk Type – System Volume (C:\): 50GB Dynamic
IP Addressing Scheme (Corporate Subnet otherwise known as a MAPI Network to Exchange 2010 DAGs)
IP Address – 192.168.1.x
Subnet Mask – 255.255.255.0
Default Gateway – 192.168.1.1
DNS Server – 192.168.1.150 (IP Address of the Domain Controller/DNS Server)
IP Addressing Scheme (Heartbeat Subnet otherwise known as a Replication Network to Exchange 2010 DAGs)
IP Address – 10.10.10.x
Default Gateway – 10.10.10.x
Subnet Mask – 255.255.255.0
LAB Architecture
Some notes about this architecture:
- Exchange 2010 DAGs remove the limitation of requiring Mailbox Only Role Servers as existed with Exchange 2007 Clustered Servers
- Exchange 2010 is no longer Cluster Aware and only utilizes very few pieces of the Failover Cluster Services such as Cluster Heartbeat and Cluster Networks. More on this in an upcoming part.
- UM is supported on these two DAG nodes but is recommended to be installed on separate servers
- For HTTP publishing, ISA can be utilized. For RPC Client Access Server publishing (which ISA cannot due as it publishes HTTP traffic only) with CAS Servers on the DAG nodes, you must use a hardware load balancer due to a Windows limitation preventing you from using Windows NLB and Clustering Services on the same Windows box. Alternatively, you can deploy two dedicated CAS Servers and utilize Windows NLB to load balance your RPC Client Access Server traffic.
- Two node DAG requires a witness that is not on a server within the DAG. Unlike Exchange 2007, Exchange 2010 automatically takes care of FSW creation; though you do have to specify the location of the FSW. It is recommended to specify the FSW to be created on a Hub Transport Server. Alternatively, you can put the witness on a non-Exchange Server after some prerequisites have been completed. I will be deploying the FSW on a member server (which happens to be my OCS Server in my lab) and will display the prerequisite process for achieving this.
Preparation of Exchange 2010 RTM DAG Nodes
Network Interface Card (NIC) Configuration
First thing we will want to do is configure the IP Configuration of both the MAPI NIC and the Replication NIC.
We will want to rename our MAPI NIC connection to MAPI and our Replication NIC connection to Replication. To do so, go to Start > Right-Click Network > Properties.
Once in the Control Panel, Choose Change Adapter Settings.
Now you will be presented with the Network Connections window. This is where you can modify the network properties for each NIC in your server. For your Internal Corporate Connection which is also your MAPI Network, rename your Local Area Connection to Internal. Likewise, for your Private Heartbeat Connection which is also your Replication Network, rename your Local Area Connection to Replication. After you have done this, it will look something similar to the following:
Network Interface Card (NIC) Configuration
First thing we will want to do is configure the IP Configuration of both the MAPI and Replication NIC.
Part of the assumptions earlier in this article as that you have a properly configured TCP/IP Network where all nodes are properly connected to the TCP/IP Network. Because of this, I will skip the Public TCP/IP Configuration and proceed to configuring the Private Heartbeat NIC.
Important: When configuring the MAPI NIC, you can leave IPv6 enabled if you are using Server 2008 R2. There is an issue with Server 2008 (still exists in SP2) that prevents IPv6 from listening on port 6004 that prevents Outlook Anywhere from working. You can read more about that here. Again, Server 2008 R2 does not have this issue. So if you happen to be installing Exchange 2010 on Server 2008, disable IPv6 as discussed below. If using Server 2008 R2, feel free to leave IPv6 enabled.
Note: You can, if you’d like, disable File and Printer Sharing for Microsoft Networks. In Exchange 2007 SP1, Microsoft provided the ability to allow for continuous replication to occur over the private network. Because Exchange 2007 utilizes SMB for log shipping, it is required to have the File and Printer Sharing enabled. Exchange 2010 no longer utilizes SMB and now utilizes TCP. More on this later in an upcoming Part.
In addition to disabling IPv6 from the NIC Properties, I would follow these instructions here to fully disable IPv6 on your Exchange 2010 system as disabling it on the NIC itself doesn’t fully disable IPv6. While the article is based on Exchange 2007, it’s a Windows based modification and will apply to a system running Exchange 2010 as well.
Double-Click or Right-Click > Properties on the Replication NIC to begin configuration.
Uncheck the following:
- Internet Protocol Version 6 (TCP /IPv6) – Disable IPv6 in the registry as well as noted above.
Select Internet-Protocol Version 4 (TCP /IPv4) and press the Properties button. For NodeA, the only TCP/IP configuration we will need, is the IP Address and Subnet Mask. NodeA’s IP configuration will be 10.10.10.152/24 while NodeB’s IP configuration will be 10.10.10.153/24.
Go into the Advanced NIC configuration settings by clicking the Advanced button. From there, you will navigate to DNS tab and de-select “Register this connection’s addresses in DNS.”
Select the WINS tab and de-select “Enable LMHOSTS lookup” and configure the NetBIOS setting to “Disable NetBIOS over TCP/IP.”
Once you are done configuring the Advanced settings, press OK three times and you will be back at the Network Connections screen. From here, choose Advanced and select Advanced Settings…
You will be presented with the Binding Order for your current NICs. Ensure that the MAPI NIC is on top by selecting MAPI and pressing the green up arrow key on the right-hand side of the dialog.
Exchange 2010 Operating System Prerequisites
Server 2008 SP2 and Server 2008 R2 prerequisites are quite different. Because our servers are going to be deployed on Server 2008 R2, we will follow the guidance for deploying on Server 2008 R2. You can see the prerequisite requirements here.
We will be doing our prerequsite installations via PowerShell. You can open PowerShell by going to Start > Run > PowerShell.
You will first have to import the module for ServerManager. Afterwards, depending on the roles that are installed, different prerequisites are required. Because we are going to be installing HUB/CAS/MBX, the command we would run is the following:
Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy,Failover-Clustering -Restart
Note: The installation documentation does not have you include Failover-Clustering in the above command. I add it anyways since we’ll be using it for the DAG. I you don’t add it in the above command, you can just add it below when you enable the NetTcpPortSharing. If you don’t add it below, when you add the first node to the DAG, Failover Clustering will be installed anyways. I like to install it beforehand though.
Finally, we’ll want to modify the NetTcpPortSharing service to start automatically.
Summary
Well folks, that is all for Part 1 of this article. For Part 2, I will go through the installation process of one our DAG nodes that will contain the Client Access Server, Hub Transport Server, as well as Mailbox Server roles.
I am actually thankful to the holder of this web site who has shared this fantastic post at at this place.
Enterprise edition of either flavor of Windows is required, since DAGs use cluster components which are only available when running enterprise… The Exchange license itself can be standard, however.
Nice guide :)
A quick question. Do any of the servers running the nodes need to be enterprise edition?
A technet article says;
If you're installing the Mailbox server role and you intend the server to be a member of a database availability group (DAG), you must be running the Enterprise Edition of Windows Server 2008 or Windows Server 2008 R2. The Standard Edition doesn't support the features needed for DAGs. You can't upgrade Windows when Exchange is installed on the server.
Does this mean;
"Enterprise Edition of Windows Server 2008" or "Any version of Windows Server 2008 R2"
or
"Enterprise Edition of Windows Server 2008" or "Enterprise Edition of Windows Server 2008 R2.
I think it's a bit ambiguious.
Niroshan,
What was the resolution to this issue? Somehow it is happening to my setup.
There is a error as (The Cluster Network Name is not online)
I am Using Server 2008 R2 Hyper V
Event Ids
1205
1069
1240
Thanks
Jonathan
Hi team, in the lab architecture i could see that some active databse on NODE1 and some on NODE2, what is the possibilty of keeping all active database on NODE1 and paassive db's on NODE2 , Does it make any sense on increasing i/o rates in NODE1, please calrify it ?
You can distribute the load however you see fit – if you have significantly faster storage on node1 you could keep all DBs active there and rely on node2 only for a failover event, but given similar performance characteristics it is nice to spread the load evenly between the two to get the highest performance…
Hi Elan
Does the FWS have to be a Ent version of Windows Server running Failover Cluster Service?
Regards,
-ferry-
No, it's just a file share so there's no real requirements other than it being a Windows Box. If you're putting the FSW on a non-Exchange box, make sure you add the Exchange Trusted Subsystem group into the Local Administrators group of that Windows Server to ensure that Exchange can remotely manage the FSW.
First of all thanks for the article Elan really nice.
I am going to install the FSW on a server outside of a 2 noded DAG like you did but what happens when the FSW server goes down?
Is it easy to recover?
How much HD space is required for the FSW?
Does the FSW take a lot of the server's resources?
Nothing really happens if the FSW goes down if you still have majority. Majority is 50% + 1. So if you have 2 DAG Nodes and 1 FSW, if your FSW goes down, you still have 2 nodes up so you still have majority. Just bring back up the server that has the FSW and all is well. The FSW doesn't take up much space at all. It's nothing you have to plan for. It's probably only a few MB in size (I'd have to check our server). The FSW takes up no real resources at all, nothing you would have to account for.
If for some reason, your FSW server dies, just set the Set-DatabaseAvailabilityGroup cmd to create a new FSW on a different server.
I think I get it now. The FSW is mainly used to get a majority i thought the replication was also a part of the FSW's job. (Explains the resource question) But the replication NIC takes care of that. So when it goes down you still have 2 nodes replicating which can both have mounted databases in use. But when the FSW is down you can't get a 2/3 majority and that could cause split brain if something happens to the replication NiC.
Thanks for your time you've helped a lot.
Hi~~
Do you know how to disable Client Throttling in EXCHANGE 2010?
Thank you
Dear All..
I have Managed to Install Exchange 2010 on my Exchange 2007 Organisation, I am unable to move the mailboxes to the 2010. it says you don’t have permission. also i have created a test user on 2010- mails from 2007 to 2010 is flowing but i am unable to send mails from 2010 to 2007..
Shijas
The Issue is resolved
Dag is working perfectly
Nice Article
There is a error as (The Cluster Network Name is not online)
I am Using Server 2008 R2 Hyper V
Event Ids
1205
1069
1240
Please Help Me
Thanks And regards
Niroshan
Do we need to put a Default gateway to the replication network 10.10.10.x
Excellent article. Would you happened to know if Hyper-V cloning produces the same results as VMWare?
I am having a similar issue was this resolved and how? I am using hyper-v on 2008 R2
I found VM template issue. Cluster doesnt work if your OS is deployed from VM Template even you change SID IP/name Etc etc.
Samir Thapa
BT- Los Angeles
[email protected]
Good to know. I ran into an issue a while back regarding the NICs and using a Sysprepp'd image. I had to create both cluster nodes from scratch.
And just as a side note, SIDs on computers having to be unique is a myth. SIDs don't have to be unique on computers. You may think I'm crazy for saying this. But read this for more information:
http://blogs.technet.com/markrussinovich/archive/…
Hi there,
I have read Mark Russinovic's article about machine SIDs and he obviously knowa a lot more about the subject than I do but… The other day (in a lab) I was trying to create a forest trust where all the DCs had been deployed from the same VM template and had the same SID. This flatly failed every time. Once I ran NewSID on one machine I could create the trust, so there is definately something going on with duplicate SIDs.
Is the statement above regarding the deployment of VMs from a template the accepted situation or not? We have the same error adding second DAG members in the setup logs. Would appreciate feedback
Thanks
S
When I add second Node I am getting this error why?____E2010MBX3__Failed____Error:__A server-side database availability group administrative operation failed. Error: The operation failed with message: An error occurred while attempting a cluster operation. Error: Cluster API '"AddClusterNode() (MaxPercentage=100) failed with 0x5b4. Error: This operation returned because the timeout period expired"' failed. [Server: E2010MBX2.msdiscover.com]____An Active Manager operation failed. Error: An error occurred while attempting a cluster operation. Error: Cluster API '"AddClusterNode() (MaxPercentage=100) failed with 0x5b4. Error: This operation returned because the timeout period expired"' failed.____This operation returned because the timeout period expired____Warning:__The operation wasn't successful because an error was [email protected]__
Great article! Could you clarify one point, you specify the FSW server as having Win 2008 Enterprise. It it a requirement that this machine runs a Windows Enterprise edition or will it work on Standard edition?
Thanks,
Tim
Thanks. Enterprise not required. I updated post accordingly.
Good article. I did a similar DAG write up on mine as well.
http://chrislehr.com/2009/10/exchange-2010-databa…
http://chrislehr.com/2009/10/exchange-2010-databa…
Chris
Thanks for the links Chris. I was thinking about going into that type of detail in a Part 5 in regards to managing the DAG but decided not to. I'll link back to your articles in Part 4 of my article.
Elan, Good article!
-V
DC still says it will be the FSW in the early part of the article… Also, can you explain why disabling ipv6 is recommended?
Thanks Elan!
-Wes
Same reasons on Exchange 2007. The IPv6 support really hasn't changed.
I thought the main reason for disabling it in 2007 was the windows 2008 binding bug that prevented rpc/http from working correctly – is there another reason? thanks!
That was an Operating System specific issue. It was because the RPC/HTTP Proxy doesn't listen on port 6001 for IPv6. The issue is still there with Server 2008. I didn't even think to check for Server 2008 R2 as I've been so used to disabling IPv6. Microsoft has had us disable IPv6 for a while now for Exchange 2010 and I'm not sure if this stance has changed due to some possibility of them coding around the issue, which I doubt. I asked Microsoft about IPv6 and Exchange 2010 in regards to Outlook Anywhere. I'm awaiting a response from them and will reply back again with any information I receive.
Yes – I remember as I was an early adopter and it was a painful bug! :-)
For what it's worth, I installed ex2010 RTM on R2 with the default bindings (ipv6 enabled) and everything is working smoothly (outlook, outlook anywhere, owa, activestink, etc)…
Looks like R2 does not have this flaw!
Good to know. You didn't modify anything with your hosts file? Can you do a netstat -an | find "6001" and check to see if it's listening on port 6001 for both IPv4 and IPv6? If so, it would seem that the issue has been resolved in Server 2008 R2.
Yep, vanilla hosts file…
Here's what I got from the netstat:
C:Usersadministrator>netstat -an | find "6001"
TCP 0.0.0.0:6001 0.0.0.0:0 LISTENING
TCP [::]:6001 [::]:0 LISTENING
TCP [fe80::9d56:107e:6490:4c03%19]:6001 [fe80::9d56:107e:6490:4c03%19]:21385 ESTABLISHED
TCP [fe80::9d56:107e:6490:4c03%19]:6001 [fe80::9d56:107e:6490:4c03%19]:21386 ESTABLISHED
TCP [fe80::9d56:107e:6490:4c03%19]:6001 [fe80::9d56:107e:6490:4c03%19]:21409 ESTABLISHED
and then a whole bunch more of these established connections, all of which appear to be ipv6…
Good deal. I just logged into my lab and re-enabled IPv6 everywhere. Looks like I'm seeing the same results.
C:\\>netstat -an | find "6001"
TCP 0.0.0.0:6001 0.0.0.0:0 LISTENING
TCP [::]:6001 [::]:0 LISTENING
I'm just curious if Server 2008 SP2 fixed this for Server 2008 or some other patch. I may try deploying a Server 2008 VM tomorrow and give it a test.
Ok, it's actually port 6004 that's the problem. But either way, Server 2008 R2 listens for port 6004 on both IPv4 and IPv6.
Hi Elan, acccording to another poster on the Minasi forums the bug is still present in 2008 sp2… bummer!
Thanks for the update. I've updated my post accordingly.
So I talked with Microsoft about this. This was actually fixed in Rollup 4 for SP1 on Exchange 2007. Before Rollup 4 for SP1, the DSProxy component allowed Windows to prefer IPv6. In Rollup 4 for SP1, Microsoft coded the Exchange components to forcefully use IPv4. Because of that, with Exchange 2007 with SP1 and Rollup on Server 2008, you no longer have to disable IPv6.
The Microsoft guy referred me to this KB:
http://support.microsoft.com/kb/950138
Most admins have gotten used to disabling IPv6 and they just kept doing it without understanding that it was actually fixed and how it was fixed.
I'm liking where this is all going, but you've confused me on the FSW part. at first you say your FSW is going on the DC and then you say your FSW is going on a dedicated box. Since you don't need two, can you please explain this?
Thanks for pointing that out. I was initially going to put it on my DC but decided to put it on a member server instead. Thought I fixed all of the references but guessed I missed one. Should be fixed.
can anyone plz confirm wer to have fsw either on dc or hub& cas or in a separate member server
Don't put it on a DC. The reason I didn't is because in order for Exchange to manage the FSW on a non-Exchange Server, you must put the Exchange Trusted Subsystem Group in AD inside that machine's Administrator's group. Because a DC doesn't have the SAM database anymore, in order to do this, you would have to nest the Exchange Trusted Subsystem inside the Domain's Administrator group which is a security issue. I would place it on an Exchange Server outside of the DAG or a member server, but not a DC.
What's with the 2008 DC? Is that required for anything?
It's not a 2008 DC. It's a 2008 R2 DC. And in assumptions it says you need a minimum of 2003 SP2 DC. So no, it's not required for anything.
It's not a 2008 DC. It's a 2008 R2 DC. And in assumptions it says you need a minimum of 2003 SP2 DC. So no, it's not required for anything.
Great…thanks for the quick reply. Now I can breathe easier :)
Nice article, thanks.