Replacing Microsoft Network Load Balancer on EOL

December 14, 2020
4 min read time
Replacing Microsoft Network Load Balancer on EOL

If you are running Microsoft’s Network Load Balancer, then you are aware that the product is facing End Of Life (EOL). This EOL situation means you need to identify and compare the best Microsoft Network Load Balancer alternatives.

Anytime you are forced to change your networking infrastructure due to an EOL, it’s a great time to consider how to upgrade your capabilities in the process. This post will help you to identify a replacement load balancer suitable for Windows infrastructure and compatible with a Hyper-V hypervisor, with a framework for making this decision.

Features required to replace Microsoft Network Load Balancer

Here are the basic load balancer features you should look for as you find a replacement for Microsoft Network Load Balancer.

Full proxy (LAN or across network) Layer 7 load balancer

Many Microsoft Network Load Balancer users were focusing on internal load balancing and Layer 4. More modern load balancers can handle both Layer 4 and Layer 7. This capability is essential in balancing demands for microservices.

IPv6 / IPv4 proxying

With so many organizations moving to IPv6, not having the capability to proxy the newer version of the IP protocol will mean you will need to upgrade again in the not so distant future. Make sure, as well, that any load balancer you consider moving to has graceful handling of both IPv4 and IPv6 without requiring significant configuration changes.

Support for TCP and UDP traffic

Lots of load balancers support TCP but not UDP. TCP is more widely used than UDP in networking workloads due to the different characteristics of the two. However, certain services rely on UDP; some of these UDP services (like Remote Desktop) are critical for Microsoft-centric environments. It’s much easier if your load balancer supports both protocols.

Out-of-the-Box Full Microsoft Support

Microsoft Network Load Balancer was well-tuned to support Microsoft ecosystem products like Exchange, Sharepoint, ActiveDirectory and bandwidth-heavy applications like Teams. Your next load balancer should be plug-and-play for supporting all Microsoft products, extending into the newer cloud-flavored ones such as Azure ActiveDirectory.

An API For Detailed Analytics, Telemetry, Service Health

You will likely want to integrate your load balancer analytics with data provided by other services, applications and network components in a unified dashboard powered by a time-series database. (Prometheus and Grafana is a pairing we see a lot.) Even if you don’t have this capability yet, a well-documented and full-featured API will future proof your analytics capabilities for the time when you start to integrate all these elements.

High-Availability By Default

Some load balancers require additional configuration and policies to enable high availability. Since you are likely running critical internal applications that your team cannot live without on your Microsoft Network Load Balancer, you’ll need high availability. This observation may sound obvious, but in some open source or cloud load balancers, HA is not always easy to set up and run without manual toil.

The Upgrades

Now that we’ve gotten the basics out of the way, consider these features and capabilities as upgrades.

Integrated Advanced Security (WAF with DDoS and BotNet Protection)

If you are only planning on using your new load balancer internally, these additional features might not be necessary. But in a Zero-Trust environment, you will probably need to expose internal services and applications to the public Internet to allow workers and partners to access them. If so, having integrated security capabilities in your load balancer is useful.

Web Acceleration and SSL Offloading

If you are a Windows shop, chances are you have moved or will be moving to Office365 and other online versions of the older Microsoft software packages. This means features to accelerate web consumption will become essential for your load balancer. The two critical ones you should look for are Web Acceleration and SSL Offloading. Web Acceleration uses caching and compression to reduce the load on your network and applications. SSL Offload moves this computationally heavy activity to an optimized environment.

Full, Native Redundancy + State Sharing

Full redundancy means improved business continuity and resilience should one of your load balancers go down and become non-responsive. On top of that, you will want state sharing because your users may otherwise experience data loss or session interruption should one load balancer go down. The information state held in that load balancer goes with it. More modern load balancers have default state sharing to ensure a smooth changeover in an outage or failure.

High Throughput, Handles High RPS/TPS

Every load balancer claims to offer high throughput. Some do, and some do not. The best way to find out is by simply asking how many requests per second and transactions per second each node can handle. You should use a load balancer with enough throughput (RPS, TPS) to meet your current requirements, and with the ability to easily scale up or add additional nodes to increase total capacity as your requirements grow. Autoscaling technology and a SaaS pricing model make rapid scale-out and scale-in highly practical and cost-effective. You should also be able to test RPS and TPS in your staging environment. Since network environments are highly variable, testing it in your environment is the only way to tell for sure whether the load balancer will meet your TPS and RPS requirements.

Runs Natively On Any OS Or Hypervisor (Including Hyper-V)

While you are likely using Windows Server to run older Windows products, a growing number of organizations that used to run only Windows are now also running applications and infrastructure on Linux servers. This distinction is crucial if you are running a hybrid infrastructure that overlays cloud and on-premises resources. For hypervisors, similarly, you don’t want to be locked into using a single vendor’s product because most organizations now run multiple hypervisors for the virtual machine infrastructure. Different product or engineering groups might have preferences for different hypervisors.


These are just a handful of features and capabilities you might want to consider.

If you wish to go even further, Microsoft Network Load Balancer’s end of life might be an excellent time to consider if you want to move to a cloud-native and Container-based load balancer. These newer architectures can simplify multi-cloud infrastructure and enable faster scale-out while reducing infrastructure costs.

We hope this post has given you some food-for-thought as you deal with the EOL of Microsoft Network Load Balancer. It’s never fun to go through an EOL. Still, your upgrade possibilities are tremendous because we are currently going through a fantastic feature explosion for load balancing and application delivery controllers. Good luck!

Try Snapt's full featured load balancers today to see if we can meet your application delivery needs.

Try Snapt  

Subscribe via Email

Get daily blog updates straight to your email inbox.

You have successfully been subscribed!