asked on
Exchange 2010 Multiple NICS in CAS and HUB Servers
We are setting up a new Exchange 2010 environment. We will have individual servers for each role. 2 CAS Servers, 2 HUBS, 3x Mailbox.
The CAS server will be front-ended with a HW LB, so we will not be using NLB. We will set the CAS in a CAS Array.
We are considering putting two NICS in the CAS and HUB servers. I'll call them the "Front End" and "Back End" NICs.
For the CAS servers one which will be facing towards the HW LBs (Front End) and ultimately the Internet to handle Internet based Client Access, which will be the only Client Access we will have for OutLook Anywhere and OWA, etc. The other NIC will be for the Back End MAPI network connecting to the mailbox and hub servers, etc. For the HUBs one will face the Internet for SMTP in/out and the other the MAPI network.
I have a few things I am trying to figure out with this approach.
1. Is it necessary and/or best practice to have two NICS in the CAS and/or HUB servers?
2. The "Internet Facing" NICS will have the gateway set to the FW/LB while the "backend" NIC will have no gateway, seeing as all the other Exchange servers are on the same subnet. That should be fine for now, but what if we put Exchange servers in another Data Center and need to and split a DAG across, and perhaps want to provide CAS and HUB servers from the secondary data center if the primary fails. Do we have to make sure that the CAS and HUB servers communicate via the MAPI nework rather than going out the "front-end"?
3. Finally, on the FW/LB facing NICS, should they be registered in AD DNS. I suspect note because we want all the MAPI traffic hitting the "backend" NICs.
The CAS server will be front-ended with a HW LB, so we will not be using NLB. We will set the CAS in a CAS Array.
We are considering putting two NICS in the CAS and HUB servers. I'll call them the "Front End" and "Back End" NICs.
For the CAS servers one which will be facing towards the HW LBs (Front End) and ultimately the Internet to handle Internet based Client Access, which will be the only Client Access we will have for OutLook Anywhere and OWA, etc. The other NIC will be for the Back End MAPI network connecting to the mailbox and hub servers, etc. For the HUBs one will face the Internet for SMTP in/out and the other the MAPI network.
I have a few things I am trying to figure out with this approach.
1. Is it necessary and/or best practice to have two NICS in the CAS and/or HUB servers?
2. The "Internet Facing" NICS will have the gateway set to the FW/LB while the "backend" NIC will have no gateway, seeing as all the other Exchange servers are on the same subnet. That should be fine for now, but what if we put Exchange servers in another Data Center and need to and split a DAG across, and perhaps want to provide CAS and HUB servers from the secondary data center if the primary fails. Do we have to make sure that the CAS and HUB servers communicate via the MAPI nework rather than going out the "front-end"?
3. Finally, on the FW/LB facing NICS, should they be registered in AD DNS. I suspect note because we want all the MAPI traffic hitting the "backend" NICs.
Exchange
Last Comment
Dave
ASKER CERTIFIED SOLUTION
Log in or sign up to see answer
Become an EE member today7-DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
Not exactly the question you had in mind?
Sign up for an EE membership and get your own personalized solution. With an EE membership, you can ask unlimited troubleshooting, research, or opinion questions.
ask a questionExperts Exchange has (a) saved my job multiple times, (b) saved me hours, days, and even weeks of work, and often (c) makes me look like a superhero! This place is MAGIC!
Walt Forbes
I wouldn't expose the CAS servers directly to the Internet. I would always do this via TMG but sadly you can no longer buy TMG licences, you have to now buy UAG which also requires CALs.