Emal design Verification

There are definitely a few issues with your architecture. Enough so that I don't think I could cover them with any depth in a forum post. You should really bring in a consultant based on what I'm seeing.

Exchange 2013 is stable. Like Exchange 2010, some of the CUs are better than others. Quality control has been a struggle for the Exchange team. But overall 2013 is functional and I'd usually recommend it over 2010 for new deployments.

Personally, this is not a design I would run with.

There is really no need to split out Exchange roles. I haven't done it in years. I would consider going multi-role on all your servers. In fact, check out Ross Smith IV's architecture keynote from MEC 14 and he explains Microsoft's shift from breaking out roles to keeping everything together. http://channel9.msdn.com/Events/MEC/2014/ARC302

Unfortunately, there is no enough information to go on to make decisions on the rest of the design. We don't know how many users you have, how large their mailboxes are, or, what kind of profile they fit in (how many messages they send and receive). So we can't really assess how many multi-role servers you would need.

The other problem here is I see no mention of a Database Availability Group for your mail servers. I hope you are going with one.

Plus I am not seeing any form of load balancing.

I would do something like this. Again. Generalizations based on what I see here.

You have 4 dedicated Exchange servers in your diagram. Make all these multirole, configure them in a 4 member DAG with a File Share Witness and put a load balancer in front of them (hopefully a nice Layer 7 KEMP HLB) to load balance client connections across your 4 new multi-role servers.

Again, generalizations.

With regard to the Edge Server, that is optional. Personally I have never been a big fan of the Edge Server. If you are looking for message hygiene and routing I tend to lean more towards Barracuda or something similar. Or a Cloud Service like Exchange Online Protection.

With regard to the stability of Exchange 2013, its rock solid. And its several Cumulative Updates deep now. I was a huge fan on 2010 but I love 2013 more now.

Also, keep in mind that Exchange 2010 exited mainstream support in January. So, Exchange 2010 will not see any more development. All new development will go towards 2013 (and Exchange 2016). You will get patches and tech support for 5 more years.

Exchange 2013 CU5 is very stable version. Go for this version and implement Exchange 2013. Exchange 2013 doesn't require HUB server role install separately on new server.Also additional advantage Exchange 2013  CAS server roles  does automatic load balancing.

@ Manoj Bojewar

Exchange 2013 doesn't require HUB server role install separately on new server

Although there is not a single role for Hub Transport there is in fact a Hub transport service on both CAS and Mailbox server. CAS being the Front-End Transport Service and Mailbox server role has the Backend Transport Service.

@Manoj Bojewar

Exchange 2013  CAS server roles  does automatic load balancing.

CAS does not load balance itself. You still require a load balancing solution, i.e hardware load balancer, or WNLB (not recommended for production deployments).

CAS in 2013 does not have persistent connections anymore to mailbox servers it only proxies connections now. This means that you can load balance at Lyaer4 or Layer7. Layer7 is still recommended as it is Service Aware, where Layer4 is only Server aware.

Will.

You can use Layer 4 with multiple namespaces to get the same effect of Layer 7. But Layer 7 is so much better. :)

You can use Layer 4 with multiple namespaces to get the same effect of Layer 7

This is what you had to do in Exchange 2010 if you wanted to use Layer4 load balancing. It can still be used but requires  multiple namespaces and Exchange 2013 has simplified the namesapces to 2 autodiscover.domain.com and mail.domain.com.

But i can be done :-)

Will.

@Will.

I meant for having more than 1-2 health checks. If you wanted to monitor all health checks, like you can in Layer 7, for all the different virtual directories. You would need multiple namespaces on a layer 4. For example, owa.yourdomain.com, ews.yourdomain.com, and so on. I was basing it on Ross Smith's diagram below from MEC 2014.

@Gareth
Misunderstood, yeah monitoring this way is possible but it is not as clean as using a L7 LB.

Having multiple name spaces just requires more management.

Will.

Right. I never recommend it. But it is a possibility that Microsoft throws out there. Its the old money vs time. Most times its worth it to just spend the extra $$$ to save time.