Troubleshooting load balancing issues with SharePoint

Dec 13, 2016

A few weeks ago, I’ve had to get hands on a customer’s SharePoint farm showing performance problems. They also had inconsistencies with display data between multiple calls.

I quickly suspected a configuration issue for the load balancer dispatching calls between the front-end servers. However, I only had access to the SharePoint farm and I had to provide data so the network team so they could start investigating.

Hence the question: how can we determine which server served the request between multiple calls?

Most of the content out there suggests adding a text file containing the server’s name to the root of the web application. I’m not a big fan of this situation for multiple reasons:

  • Adding/deleting files to SharePoint’s content is not something to do without being cautious, especially if you don’t know SharePoint very well.

  • You can have cases, depending on the load balancer’s configuration (and especially if it’s not configured properly), that a server answers to one request and another one to the next one in subsequent calls. You have to determine which server has served each request.

Obviously I didn’t try solutions like “deploy this custom solution and add that custom web part which is going to tell you which server is doing what”.

I decided to add a Http response header that the server is going to send over with each request.

The only downside of that solution is that it’s that setting up the header will recycle the application pool, causing a service interruption.

To setup the header go to the IIS management console and select the web application you’re working with.

Click on “http response headers”


Add a new entry giving the name you want and the server name as the value.


(repeat those steps for each server of the farm)

Using any browser, open developer tools (most likely pressing F12), enable requests tracing and go to the response’s headers of any request. You’ll see your header with the name of the server as the value.


Once you’re done troubleshooting, don’t forget to remove the header for two reasons:

  • Http headers, before Http2 (which as of today is far from being widely implemented), are not being compressed which will increase network traffic.

  • For security reasons, it’s never good to expose your server’s names.

Have fun troubleshooting your load balancers.

Last edited Oct 18, 2021 by Vincent Biret