Exchange 2016 DNS Round Robin vs NetScaler

Since Exchange 2016 no longer support CAS Arrays and everything is on the mailbox server, and users connect to the client access service on the mailbox server hosting the active DB for the user mailbox, is there a reason to logically use a netscaler for load balancing Exchange 2016 as opposed to using DNS Round Robin? If so what is the reason for using either in your professional opinions. I will still use the single name space. Any suggestions and opinions are appreciated.
Who is Participating?
Dinesh SinghConnect With a Mentor ArchitectCommented:
Here are disadvantages of DNS Round Robin for CAS load balancing

EDIT BY Mr Wolfe: Information below from

No health monitoring - DNS Round Robin is done entirely at the DNS level which is separate from Exchange. For this reason, an Exchange server failure will not stop that IP being passed on to clients for them to connect to until an administrator removes the A record from DNS. The failover happens at the client level as when it fails to connect to an IP, it’ll connect to the next IP.
No load monitoring - for the same reason as above, DNS is unaware if one of your Exchange servers has an extremely high load or other issue causing a performance impact on the server.
No ‘weighting’ - with DNS round robin, you cannot specify that 70% of connections are handled by one server with more compute resources whereas the other server handles only the remaining 30%. DNS round robin gives equal weight to each server. For example, if you have two servers, they will be load balanced 50:50 and this cannot be changed.
No active/passive load balancing - for the same reason as above, you cannot have an active/passive setup. Each server has handles the same load.
No reporting or logging - some load balancers provide failover reporting and almost all provide logging. This can be helpful if you repeatedly have failovers and you’d like to troubleshoot in more detail.
Stopping a server is not instant - if you find that an Exchange server is still accepting client connections but has a problem and you need to remove it from the load balancer, you need to remove the A record associated with the server. The time this takes will depend on the Time To Live for the A record and it certainly won’t be instant as when you force stop a server in a hardware load balancer.

As you mentioned you are using the Single Namespacethan in this scenario, a single namespace is deployed for all the HTTP protocol clients ( The load balancer is configured to maintain session affinity (layer 7), meaning SSL termination occurs and the load balancer knows the target URL. The load balancer is also configured to check the health of the target Mailbox servers in the load balancing pool; in this MBXs, the health probe is configured on each virtual directory.

As long as the OWA health probe response is healthy, the load balancer will keep the target MBX in the OWA load balancing pool. However, if the OWA health probe fails for any reason, then the load balancer will remove the target MBX from the load balancing pool for OWA requests. In other words, in this example, health is per-protocol; this means that if the health probe fails, only the affected client protocol will have to be directed to another server.

for deep dive-
AmitConnect With a Mentor IT ArchitectCommented:
Here are the primary reason for not using or recommend DNS round-robin:

1) Monitoring: How you are going to monitor DNS Round-Robin for any issue.
2) You cannot distribute load using DNS RR.
3) With DNS RR Active/Passive setup not possible.
4) No reporting
5) DNS RR is not application aware solution, so if Exchange server is down, client might still be connecting to failed server.

HLB is must requirement for Exchange. I known it add extra cost to the overall setup, however MS recommended to use HLB.
Simon Butler (Sembee)ConsultantCommented:
The CAS Array didn't give you high availability either - therefore I am not sure why you have mentioned the removal of CAS array causing this problem.
It was just a virtual Exchange server that made it easy to point to a hardware load balancer. Therefore what were you doing before?

In the above list - number 5 is the biggest issue. DNS has no knowledge that the server is available. If you need to have automatic availability then you need to have a hardware load balancer - although you can get cheaper options than Netscaler - Kemp and JetNexus are the two that I deploy most often.
AmitIT ArchitectCommented:
Dinesh, looks like you copy pasted from other site:

Is this article created by you or site belongs to you?  You should not copy/paste from other site. That is copyright violation.
Michael LeonardPrincipal Product Marketing ManagerCommented:
There are lots of reasons to use NetScaler with Exchange, such as

Load balancing of multiple Exchange Servers
Content Switching for single-IP access and redirection of queries to the correct virtual servers
Rewrite for redirecting users to secure pages
SSL offload of processing to the NetScaler reducing the load on the Exchange server

Citrix provides a detailed guide for deploying NetScaler with Exchange 2016. This guide will explain the benefits of using NetScaler and help you get up and running and configured so that you will get the best performance.

Guide to deploying NetScaler with Microsoft Exchange 2016

You will find more NetScaler deployment guides here
All Courses

From novice to tech pro — start learning today.