Browse All Articles > SharePoint 2010 Load Balancer / Host Header Issue
In a Microsoft Windows IIS environment that is load balanced, the external load balancing hardware needs to know which servers, in the pool of servers, are available to send http traffic to for a particular website.
The rule, shown below, is a built in rule that requires each IIS Website on each IIS Web Server to have a http://healthcheck host header.
The load balancer will check each website using the http://healthcheck host header and look for an alive.html web page. Upon being able to access that alive.html web page, the load balancer will continue routing traffic to that particular website on that particular web server for another 60 seconds.
Using this built in rule administrators only have to add a healthcheck host header to each IIS Website.
This built in rule eliminates any need for administrators to create a separate and distinct set of rules for each IIS Website on each Server using the websites own distinct name.
![http_alove lb monitor]()
Now, enters SharePoint 2010 and how it is incompatible with this rule.
For the sake of an easy example, let us declare that we have three Windows 2008 R2 Servers that are running SharePoint 2010 Standard Server.
We will call them SPServer1, SPServer2, SPServer3, and they are configured as follows.
In this SharePoint 2010 Farm, we have a website called mytestsite.mytestdomain.com
On SPServer1, the IIS Bindings for http://mytestsite.mytestdomain.comcontain only the site name mytestsite.mytestdomain.com, port 80, and a blank IP Setting so that “Any Available” is used.
On SPServer2, the IIS Bindings for MyTestSite.mytestdomain.com contain the following host headers:
m contain the following host headers:
m 192.168.234.100
IP 192.168.234.100 is the IP Address that sits on the load balancer and what end users will actually access when they point their web browsers to http://mytestsite.mytestdomain.com
SharePoint 2010 has alternate access mappings for the website mytestsite.mytestdomain.com as follows.
• Internal URL – http://mytestsite
• Zone – Default
• Public URL for Zone – http://mytestsite
Having provided those details let us examine how the load balancer routes end users to the actual site.
1. An end user enters http://mytestsite.mytestdomain.com into the address bar of their web browser software.
2. The web browser software queries DNS to find the IP Address of that website.
3. DNS reports the IP Address of http://mytestsite.mytestdomain.com to be 192.168.234.100
4. 192.168.234.100 is an IP Address that has been allocated for access to http://mytestsite.mytestdomain.com on the load balancer.
5. The user is then taken to the load balancer.
6. When their web browser “hits” the load balancer, the load balancer looks to see which servers are serving up http://mytestsite.mytestdomain.com
7. Since http://healthcheck/alive.html is present and accessible on both SPServer2 and SPServer3, the load balancer will pass the end user through to http://mytestsite1.mytestdomain.com or http://mytestsite2.mytestdomain.com.
8. However, it will make sure that the end user’s web browser thinks it (the web browser) is actually going to http://mytestsite.mytestdomain.com instead http://mytestsite1.mytestdomain.com or http://mytestsite2.mytestdomain.com.
9. This is web browser behavior is possible because the host header mytestsite and mytestsite.mytestdomain.com exist on both SPServer2 and SPServer3
10. This is what allows the URL http://mytestsite.mytestdomain.com to remain present in the end user’s web browser’s address bar, instead of switching out to http://mytestsite1.mytestdomain.com or http://mytestsite2.mytestdomain.com
All the material listed above, explains how the environment works, and the purpose of http://healthcheck/alive.html as it pertains to both SPServer2 and SPServer3.
The only problem with all of this, is that SPServer1, SPServer2, and SPServer3 continuously generate 1000’s of warning messages in the application event log.
Multiple warning messages are logged every couple of minutes as shown below, which obviously chew up space by making the log file larger while consuming processor resources.
![host header warning messages]()
IIS doesn’t generate the log entries, but SharePoint 2010 does.
Conventional logic dictates that the only way to fix this type of issue is to do one of the following:
1. Eliminate the host header http://healthcheck from each IIS Website
Or
2. Add a host header entry for http://healthcheck onto SPServer1 in addition to the headers that already exist on SPServer2 and SPServer2 and then create an alternate access mapping for http://healthcheck in each SharePoint Website.
Unfortunately, executing # 1 will break the functionality of the load balancer and will prevent end users from getting to the site.
Executing # 2 is not possible because of a SharePoint 2010 product limitation that does not permit the same alternate access mapping to exist within multiple websites.
3. The only other way to fix this problem and eliminate all the excess log entries is to create a separate set of load balancer rules for every SharePoint Website.
However, making a rule change of that magnitude in the load balancer is unacceptable because a SharePoint farm that contains millions of SharePoint Websites will require countless man hours to build out millions of load balancer rule sets, one set for each website name.
Such a rule change will result in millions of sets of rules being created which will overtax the performance of the load balancer.
4. The only other possible way to fix this problem and eliminate all the excess log entries from constantly occurring is to create a separate set of load balancer rules for SharePoint Websites and make use of some kind of site name/hostname variable, so that the load balancer can use some kind of site name variable header rule to perform the same monitoring process that the http_alive rule currently provides.
Such a Site Name variable rule might look like this ¿ GET /alive.html HTTP/1.1\r\nConnection: Close\r\nHost: <%sitename%>/healthcheck\r\n\r\n
However the load balancer rule shown above does not work, and no such construct is currently promoted or supported by the load balancer vendors I have dealt with.
The folks who developed SharePoint really need to make some kind of programmatic adjustment to account for this issue, or at the very least, provide a mechanism to prevent these types of warning messages from being logged.
The rule, shown below, is a built in rule that requires each IIS Website on each IIS Web Server to have a http://healthcheck host header.
The load balancer will check each website using the http://healthcheck host header and look for an alive.html web page. Upon being able to access that alive.html web page, the load balancer will continue routing traffic to that particular website on that particular web server for another 60 seconds.
Using this built in rule administrators only have to add a healthcheck host header to each IIS Website.
This built in rule eliminates any need for administrators to create a separate and distinct set of rules for each IIS Website on each Server using the websites own distinct name.
Now, enters SharePoint 2010 and how it is incompatible with this rule.
For the sake of an easy example, let us declare that we have three Windows 2008 R2 Servers that are running SharePoint 2010 Standard Server.
We will call them SPServer1, SPServer2, SPServer3, and they are configured as follows.
SPServer1 runs the Central Administration Console, and contains all SharePoint Websites. But end users never Access the SharePoint Websites here.
SPServer2 contains all SharePoint Websites and serves as one of the servers end users can access through the load balancer.
SPServer3 contains all SharePoint Websites and serves as one of the servers end users can access through the load balancer.
In this SharePoint 2010 Farm, we have a website called mytestsite.mytestdomain.co
On SPServer1, the IIS Bindings for http://mytestsite.mytestdomain.comcontain only the site name mytestsite.mytestdomain.co
On SPServer2, the IIS Bindings for MyTestSite.mytestdomain.co
mytestsite1 port 80 ip address 192.168.4.101
mytestsite1.mytestdomain.com port 80 ip address 192.168.4.101
mytestsite port 80 ip address 192.168.4.101
mytestsite.mytestdomain.com port 80 ip address 192.168.4.101
healthcheck port 80 ip address 192.168.4.101
healthcheck.mytestdomain.com port 80 ip address 192.168.4.101
mytestsite2 port 80 ip address 192.168.4.102
mytestsite2.mytestdomain.com port 80 ip address 192.168.4.102
mytestsite port 80 ip address 192.168.4.102
mytestsite.mytestdomain.com port 80 ip address 192.168.4.102
healthcheck port 80 ip address 192.168.4.102
healthcheck.mytestdomain.com port 80 ip address 192.168.4.102
IP 192.168.234.100 is the IP Address that sits on the load balancer and what end users will actually access when they point their web browsers to http://mytestsite.mytestdomain.com
SharePoint 2010 has alternate access mappings for the website mytestsite.mytestdomain.co
• Internal URL – http://mytestsite
• Zone – Default
• Public URL for Zone – http://mytestsite
Having provided those details let us examine how the load balancer routes end users to the actual site.
1. An end user enters http://mytestsite.mytestdomain.com into the address bar of their web browser software.
2. The web browser software queries DNS to find the IP Address of that website.
3. DNS reports the IP Address of http://mytestsite.mytestdomain.com to be 192.168.234.100
4. 192.168.234.100 is an IP Address that has been allocated for access to http://mytestsite.mytestdomain.com on the load balancer.
5. The user is then taken to the load balancer.
6. When their web browser “hits” the load balancer, the load balancer looks to see which servers are serving up http://mytestsite.mytestdomain.com
7. Since http://healthcheck/alive.html is present and accessible on both SPServer2 and SPServer3, the load balancer will pass the end user through to http://mytestsite1.mytestdomain.com or http://mytestsite2.mytestdomain.com.
8. However, it will make sure that the end user’s web browser thinks it (the web browser) is actually going to http://mytestsite.mytestdomain.com instead http://mytestsite1.mytestdomain.com or http://mytestsite2.mytestdomain.com.
9. This is web browser behavior is possible because the host header mytestsite and mytestsite.mytestdomain.co
10. This is what allows the URL http://mytestsite.mytestdomain.com to remain present in the end user’s web browser’s address bar, instead of switching out to http://mytestsite1.mytestdomain.com or http://mytestsite2.mytestdomain.com
All the material listed above, explains how the environment works, and the purpose of http://healthcheck/alive.html as it pertains to both SPServer2 and SPServer3.
The only problem with all of this, is that SPServer1, SPServer2, and SPServer3 continuously generate 1000’s of warning messages in the application event log.
Multiple warning messages are logged every couple of minutes as shown below, which obviously chew up space by making the log file larger while consuming processor resources.
IIS doesn’t generate the log entries, but SharePoint 2010 does.
Conventional logic dictates that the only way to fix this type of issue is to do one of the following:
1. Eliminate the host header http://healthcheck from each IIS Website
Or
2. Add a host header entry for http://healthcheck onto SPServer1 in addition to the headers that already exist on SPServer2 and SPServer2 and then create an alternate access mapping for http://healthcheck in each SharePoint Website.
Unfortunately, executing # 1 will break the functionality of the load balancer and will prevent end users from getting to the site.
Executing # 2 is not possible because of a SharePoint 2010 product limitation that does not permit the same alternate access mapping to exist within multiple websites.
3. The only other way to fix this problem and eliminate all the excess log entries is to create a separate set of load balancer rules for every SharePoint Website.
However, making a rule change of that magnitude in the load balancer is unacceptable because a SharePoint farm that contains millions of SharePoint Websites will require countless man hours to build out millions of load balancer rule sets, one set for each website name.
Such a rule change will result in millions of sets of rules being created which will overtax the performance of the load balancer.
4. The only other possible way to fix this problem and eliminate all the excess log entries from constantly occurring is to create a separate set of load balancer rules for SharePoint Websites and make use of some kind of site name/hostname variable, so that the load balancer can use some kind of site name variable header rule to perform the same monitoring process that the http_alive rule currently provides.
Such a Site Name variable rule might look like this ¿ GET /alive.html HTTP/1.1\r\nConnection: Close\r\nHost: <%sitename%>/healthcheck\r
However the load balancer rule shown above does not work, and no such construct is currently promoted or supported by the load balancer vendors I have dealt with.
The folks who developed SharePoint really need to make some kind of programmatic adjustment to account for this issue, or at the very least, provide a mechanism to prevent these types of warning messages from being logged.
Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.
Comments (0)