Load balancing Microsoft SharePoint
Benefits of load balancing Microsoft SharePoint
Load balancing Microsoft SharePoint offers the following benefits:
- High Availability (HA): Load balancing is crucial for ensuring that the SharePoint environment remains available even if one server fails. The load balancer continuously monitors the health of each SharePoint server. If a server becomes unresponsive, the load balancer automatically takes it out of the rotation and redirects all traffic to the remaining healthy servers. This process ensures that users can continue accessing SharePoint without interruption, drastically reducing downtime and improving fault tolerance.
- Improved performance: The load balancer ensures that the load is spread evenly across all active servers, preventing a single server from being overwhelmed and maximizing the utilization of hardware resources. By avoiding overloaded servers, load balancing minimizes response time, leading to a much better user experience.
- Scalability: By distributing the workload, load balancing optimizes resource usage and allows the SharePoint environment to handle more users and requests. When user demand grows, new SharePoint servers can easily be added to the farm behind the load balancer, which will instantly start distributing traffic to the new server, allowing for horizontal scaling with minimal disruption.
About Microsoft SharePoint
Microsoft SharePoint is Microsoft’s enterprise collaboration platform. SharePoint makes it easier for people to work together. Using SharePoint, staff can set up websites to share information with others, manage documents from start to finish, publish reports to help everyone make better decisions and search across a range of internal and external data sources to find answers and information more quickly and effectively.
Microsoft’s Enterprise solutions are at the heart of businesses everywhere. Loadbalancer.org is officially certified for all of Microsoft’s key applications which you can find here. More details on the SharePoint components, how it works, and prerequisites for load balancing can be found in our deployment guide, available to view below.
Why Loadbalancer.org for Microsoft SharePoint?
Loadbalancer’s intuitive Enterprise Application Delivery Controller (ADC) is also designed to save time and money with a clever, not complex, WebUI.
Easily configure, deploy, manage, and maintain our Enterprise load balancer, reducing complexity and the risk of human error. For a difference you can see in just minutes.
And with WAF and GSLB included straight out-of-the-box, there’s no hidden costs, so the prices you see on our website are fully transparent.
More on what’s possible with Loadbalancer.org.
How to load balance Microsoft SharePoint
The load balancer can be deployed in 4 fundamental ways: Layer 4 DR mode, Layer 4 NAT mode, Layer 4 SNAT mode, and Layer 7 Reverse Proxy (Layer 7 SNAT mode).
For Microsoft SharePoint, Layer 7 Reverse Proxy (HAProxy) is recommended. This mode offers high performance and is simple to configure since it requires no mode-specific configuration changes to the load balanced SharePoint Servers.
Layer 4 DR mode, NAT mode and SNAT mode can also be used if preferred. For DR mode you’ll need to solve the ARP problem on each AD FS server. For NAT mode the default gateway of the SharePoint servers must be the load balancer. For Layer 4 SNAT mode no mode specific server configuration changes are required.
Virtual service (VIP) requirements
It is possible to configure a single VIP that includes all required ports outlined in the deployment guide, below. However, to enable more granular control and improved health-check monitoring, multiple Virtual Services are recommended.
The list below shows the general approach used in this guide:
- VIP-1: For the Load balanced SharePoint Central Administration site running on the selected port. In this guide, HTTP port 8080 & HTTPS port 8443.
- VIP-2: For the load balanced SharePoint User Portal, typically running on the default ports: HTTP (80) & HTTPS (443).
- VIP-3 etc.: Used for additional SharePoint Web Applications/IIS sites that require a different IP address to be used.
Load balancing deployment concept
Example load balanced SharePoint front end deployment illustrating SSL termination, WAF traffic inspection and SSL re-encryption:

Supported Microsoft SharePoint protocols
| Protocol | Ports | Load balancing methods |
|---|---|---|
| HTTP | 80 |
Layer 7 Reverse Proxy: Using Reverse Proxy mode is the easiest and most flexible load balancing method, offering advanced URL switching, cookie insertion and WAF capabilities. Layer 4 DR Direct Routing has the advantage of being fully transparent and seriously fast but requires solving the arp problem. Layer 4 NAT Traditional NAT mode gives easy to implement fast and transparent load balancing but usually requires a two-arm configuration (two subnets). |
| HTTPS | 443 | All load balancing methods can be easily configured for SSL Pass-through. This has the advantage of being fast, secure and easy to maintain. Identical SSL certificates will need to exist on each of your backend servers for pass-through security. SSL Termination or off-loading must be used when advanced Layer 7 functionality such as cookies or URL switching is required. You can also implement SNI if you have multiple domain certificates one one public IP address. Optional re-encryption is also available between the load balancer and IIS. |
About Layer 7 Reverse Proxy
Layer 7 Reverse Proxy uses a proxy (HAProxy) at the application layer. Inbound requests are terminated on the load balancer and HAProxy generates a new corresponding request to the chosen Real Server. As a result, Layer 7 is typically not as fast as the Layer 4 methods.
Layer 7 is typically chosen when enhanced options such as SSL termination, cookie based persistence, URL rewriting, header insertion/deletion etc. are required, or when the network topology prohibits the use of the Layer 4 methods.

Because Layer 7 Reverse Proxy is a full proxy, any server in the cluster can be on any accessible subnet, including across the Internet or WAN.
Layer 7 Reverse Proxy is not transparent by default i.e. the Real Servers will not see the source IP address of the client, they will see the load balancer’s own IP address by default, or any other local appliance IP address if preferred (e.g. the VIP address). This can be configured per Layer 7 VIP.
If required, the load balancer can be configured to provide the actual client IP address to the Real Servers in two ways:
- Either by inserting a header that contains the client’s source IP address, or
- By modifying the Source Address field of the IP packets and replacing the IP address of the load balancer with the IP address of the client.
Layer 7 Reverse Proxy mode can be deployed using either a one-arm or two-arm configuration. For two-arm deployments, eth0 is normally used for the internal network and eth1 is used for the external network, although this is not mandatory.
No mode-specific configuration changes to the load balanced Real Servers are required.
Port translation is possible with Layer 7 Reverse Proxy e.g. VIP:80 → RIP:8080 is supported. You should not use the same RIP:PORT combination for Layer 7 Reverse Proxy VIPs and Layer 4 SNAT mode VIPs because the required firewall rules conflict.

