Hi We have two load balanced WFE with several web applications on port 80. For each site there is a correct AAM and host header. We use sticky sessions on the load balancer. The problem is now that when a user makes a POST to a web service (in this case for Excel Services and Reporting services) the request is sent to the load balancer again and then to the other server. As we use NTLM this double hop will make the request fail with a 401. I have read the documentation for Reporting Services (8.2 in here: http://msdn.microsoft.com/en-us/library/ee384252(SQL.100).aspx) and it pointed to a solution where you put the host header in the local host file for each WFE. This would make the request stay on the same server. It worked perfect in our test environment but in production it doesn't work. If I PING the adress then it points to the local server so it only seems that SharePoint ignores the HOST file. Has someone experienced this type of problem? Best regards, Niclas Niclas Carlsson

Did you disable Loopback check? http://support.microsoft.com/kb/896861Oleg

Hi Yes we have disabled the loopback check //NiclasNiclas Carlsson

Hi Oleg Thanks for your answers but I didn't really understand what you mean in your last post. Best regards, NIclasNiclas Carlsson

hello Sharepoint as any other application can't ignore hosts files as it is applied on OS level (hosts file is commonly used for solving NLB-related issues in MOSS, e.g. for configuring dedicated WFE for crawling when there are several static IP addresses, etc). So lets clarify the calling sequence. Check that I understood correctly: 1. Client makes POST to a web service in context of web application which is running on your WFEs, e.g. http://example.com/_layouts/foo.asmx 2. Request goes to load balancer 3. Load balancer selects WFE from rotation and transmits requests to that WFE (WFE1) Until now evrything is ok, as it is standard schema. Now come problems: 4. Request from WFE1 is sent to load balancer again and after that goes to WFE2 Am I right? So how did you setup your hosts file? There are several ways: 127.0.0.1 example.com also if you use static IP addresses on your WFE it is better to use them (in this case records will be different on both WFEs): xxx.xxx.xxx.xxx example.com Try run fiddler tool on WFE1 and see on which addresses requests are coming to and from. Probably on step 4 requests is going to another domain name because of some reason. Notify about your resultsBlog - http://sadomovalex.blogspot.com CAML via C# - http://camlex.codeplex.com Graphs visualization in Sharepoint - http://spgraphviz.codeplex.com

Hi Actually, this is the order 1. Client loads a SharePoint page with a web part on it. This initial load is on WFE1 2. The web part makes makes POST to a web service in context of web application. 3. Request goes to load balancer 4. Load balancer selects WFE from rotation and transmits requests to the other WFE (WFE2). During this hop between servers the authentication is lost. My host file is set up as xxx.xxx.xxx.xxx example.com with the server IP. Niclas Carlsson

did you checked on what exact address web part makes a POST? Is it the same address which specified in hosts file (with the same port)? Also try to flush dns caches on both WFEs (ipconfig /flushdns)Blog - http://sadomovalex.blogspot.com CAML via C# - http://camlex.codeplex.com Graphs visualization in Sharepoint - http://spgraphviz.codeplex.com

Try to do simple test: 1. Ping WFE2 from WFE1 2. Ping WFE1 from WFE2 3.Ping WFE1 from WFE1 4.Ping WFE2 from WFE2 Every time when you do ping the target IP address should be Internal IP. Can you check it?Oleg

Hi Oleg The correct IP is shown in all the cases. Best regards, NiclasNiclas Carlsson

Hi Our latest findings is that the POST to the web service makes a request to our proxy server. The proxy server is only there for handling connections to internet for other functionality like the RSS web parts. We can see that the server that doesn't work actually identifies itself as the other server against the proxy so that can explain the strange behaviour. It seems strange that the request should go to the proxy at all and we can't see the same behaviour in our test enviroment but we'll continue to investigate this track.Niclas Carlsson