Exchange Team no longer recommend Windows NLB for Client Access Server Load Balancing

One of the interesting nuggets of information coming out from TechEd a couple of weeks ago relates to Microsoft’s changing advice on whether Windows’ Network Load Balancing should be used with Client Access Servers to balance client traffic.

The new advice from Ross Smith IV’s session entitled UNC311 – How Outlook connects to Exchange 2010 Client Access Server is in some ways contrary to the TechNet documentation online, which specifically recommends using NLB. However given the source, and that it comes direct from the Exchange team along with reasons why, it’s certainly advice worth following.

You can (and should) watch and listen to the whole session online, but for quick reference I’ve transcribed the relevant part as delivered by Ross along with a little context:


"What we [Microsoft] recommend is a hardware load balancer for most deployments.. there are several reasons..

Hardware load balancers provide you service awareness, so you can actually get down to the individual, not only the individual TCP port, TCP 443 as an example, but you can potentially get down to the individual application as part of that service, depending on the load balancer you deploy. So now you can know if the web service, or the EWS service I should say, is failed – but OWA is still functioning on the CAS array. And you could take that member out of service as the result of that one failure because maybe you have.. Lync deployed and you rely heavily on the EWS service.

Hardware load balancers allow you to deploy different types of persistent methods for the different types of clients, which can then enable you to do different thing depending on your architecture.

What we don’t recommend – is DNS round robining; DNS round robin does not provide persistent. It merely provides a means to alternate which servers are responding at a particular time. It does not provide any sort of persistence, or necessarily fault tolerance. So we don’t recommend it.

We don’t recommend Windows Network Load Balancing, and from a cross site architecture, while there are ways to deploy a single, unified, namespace across multiple datacentres, it’s extremely complex, it requires extremely expensive load balancing solutions – you can do it, but it is an operational cost that you have to manage.

So – from our perspective, we recommend creating two separate namespaces, and accessing those namespaces from that perspective."


"Why not Windows Network Load Balancing? Well – there’s several issues with it.

One – it only provides the ability to do IP-based affinity. So we don’t get the persistent capabilities that we need.

Two – it doesn’t provide service awareness… it’s "server-aware". If the web service fails, Windows Network Load Balancing has no concept of that. It just continues to route requests to that and then the user has a broken experience.

It doesn’t scale well. When we talk about Outlook connectivity, and Outlook going to this load balancing solution, you know, if it’s just direct Outlook connectivity, at a minimum we’re doing 4 TCP sessions – plus one or two HTTP sessions, for that connectivity. So – 4 MAPI sessions, 2 HTTP sessions. So that’s 6 sessions that you have to deal with, per Outlook client at a minimum. And then, you look at the perspective that you might have 50,000 of those clients, or a 100,000 of those clients, all connecting to this array. That’s just a scale that Windows Network Load Balancing does not deal with.

So anything over 8 nodes – we don’t recommend that you use Windows Network Load Balancing.

It also isn’t supported with Windows Failover Clustering. So you cannot co-locate CAS and the Mailbox roles and expect to be able to use Windows Failover Clustering and Windows Network Load Balancing on the same machine.

And then, the last one – adding or removing a single node does cause all clients to have to be reconnected to the Network Load Balancing Array.

So there are a multitude of problems of why we no longer recommend Windows Network Load Balancing with Exchange 2010 in enterprise type deployments. Obviously in certain scenarios like a branch office, where you only have a small set of user populations, it obviously makes sense from a cost perspective."

So there you have it. In most circumstances, Windows NLB is not recommended because (as you probably already know) it has no clue as to whether OWA, EWS or any other Exchange service is available on your CAS, it doesn’t have decent affinity, and doesn’t scale. The first two reasons will apply to every load balanced CAS array designs, so if you budget allows it you should consider a hardware load balancer (or even two, for redundancy!).

If by any chance you’re now looking for Microsoft’s list of qualified Hardware Load Balancers for Exchange 2010 check out the Microsoft Unified Communications Load Balancer Deployment page on the Microsoft site, and if you’re looking for a good article on setup and further recommendations, check out Henrik Walther’s multi-part article Load Balancing Exchange 2010 Servers using a Hardware Load Balancer Solution at

24 thoughts on “Exchange Team no longer recommend Windows NLB for Client Access Server Load Balancing

  1. Pingback: Buying a HLB costs less than you think… | Exchanging Tech

  2. Pingback: Windows NLB vs. Hardware Load Balancer (Concluded) | Manoj Viduranga's Cyber Journal.......

  3. Pingback: Tap the power of Windows network load balancing « cv srinivas's blog

  4. Windows NLB is a very cost-effective solution for ‘small’ environments (Small being a relative term). I believe it works well enough although it lacks service awareness. Unless the port does not respond, the NLB will not failover.

    I’m no programmer but, It ocurrs to me that one could try giving WNLB some ‘intelligence’ by programing a ‘synthetic transaction’ script of sorts to query OWA, SMTP, POP etc. and then handling the failover of the NLB using the NLB.exe command if the transaction fails. This more or less what F5 does. Otherwise it is just a dumb NLB just like WNLB.

    Bussiness opportunity maybe?!!?


  5. Thanks much for the comparison. I’ve been reading so many conflicting articles preparing for our EX2010 deployment, it is nice to have the source material referenced. We are a small, single site with only 500 mailboxes. However, we have a demanding user community and the lack of service awareness in WNLB alone is enough to convince me not to use it, despite our size.

  6. I have been looking high and low and can’t seem to find a direct answer. Is a WNLB CAS array supposed to fail over? I have 2 servers in my array. The only role on those two servers is the CAS role. They are physical and they are using the WNLB. When I do maintenance on one of the servers that requires a reboot, during the time of the reboot all users that are connected through that server are offline until it comes back up or until they reboot their workstation. All of the outlook clients are pointed towards the array FQDN. Should the outlook clients fail over to the other server when one goes offline?

  7. Pingback: Using the KEMP LoadMaster with Exchange Server 2010 | Steve Goodman's Exchange Blog

  8. Pingback: Exchange Team no longer recommend Windows NLB « MidThought's

  9. Although if you talk to F5, they’ll tell you many customers are ripping out KEMPs all over the place. Yet Microsoft are apparently recommending KEMP, as a result of having changed their own stance on WNLB as per your article above. Will be interesting to see how the debate rages 🙂

    • Of course F5 is going to say “many customers are ripping out Kemps all over the place”. They are a direct competitor and I would say F5 is not happy about losing the market share. Kemp is a solid device/virtual appliance and they are being deployed all over the place.

      This is a good article. I haven’t found any other articles on the web with direct references from MS not to use NLB. I’ve always disliked NLB and MS has always recommended against it in the large environments I have worked in, but its good to have this info to explain to some of the SMBs I am working with.

  10. Pingback: Free Load Balancer For Lab Environments » It Worked In The Lab...

  11. Pingback: SSL certificates for multiple exchange 2010 servers

  12. The title should read “Exchange team no longer recommends Windows NLB for Client access Server load balancing in the Enterprise”. Seriously, how many companies who run Exchange have over 50,000 active users? Of course you’d use a hardware load balancer in that case.

    The only real downsides to NLB is that it’s not service-aware and the disconnects when adding a node. But how often does the latter one happen? Once a year at best? Schedule a maintenance window over Christmas if it’s that big a deal.

    And as for the former, having another CAS server available that users can access while you troubleshoot the other one give IT a lot of breathing room, as opposed to only having one and everyone breathing down their neck to get it fixed – even if the end users report and issue. with NLB you can just eject that node from the NBL cluster and another CAS server takes over.

    NBL is a great solution for the SMB market, especially when you consider the price.

    • Actually we run in to this discussion every other week with SMBs (less than 10,000m mailboxes), who now want to migrate to Ex2010. The fact is the HLB purchase is never on their radar if wanting to deploy any kind of HA. The only solution to this is KEMP who fit in nicely with their physical and virtual offerings – see . I’ve saved 3 clients well over $120k this last month who had previously assumed a Cisco ACE/F5/NetScaler x 2 was the only option.

    • I agree Miles, Ive used WNLB in deployments of up to 25,000 With the only issue of having disconnects, when adding nodes,, other than that it has been great, if the application fails its rare & nothing that drain stop cant fix….

      Not sure how virtual NLB will work baeeter than a hardware solution

  13. Pingback: Windows NLB niet langer ondersteund met Exchange 2010? « UC Labs

  14. Pingback: Exchange CAS & NLB |

  15. Pingback: Exchange Team no longer recommend Windows NLB for Client Access Server Load Balancing | Steve Goodman’s Tech Blog « JC’s Blog-O-Gibberish

  16. Pingback: Exchange Team já não recomenda o Windows NLB para o Client Access Server Load Balancing « Aislan Cunha – Microsoft Systems Specialist

  17. Pingback: Windows NLB not for CAS recommended anymore | Microsoft Exchange Server Blog

  18. Pingback: Windows NLB niet langer ondersteund met Exchange 2010? - Jaap Wesselius Exchange Ervaringen...

  19. Pingback: Tweets that mention Exchange Team no longer recommend Windows NLB for Client Access Server Load Balancing | Steve Goodman's Tech Blog --

Comments are closed.