Houston, we have a problem!
My last project at the customer was a good one, we solved a lot of issues and came back with better and stable solutions. But we faced a very diffecult problem, some of the other blogs helped us by finding the solution. Not all the blogs where a solution to our problem. After some debugging, decompiling and other stuff we found the root cause of the problem.
Steps we flew by investigating the problem.
In this section I will give you an overview of the steps we made to investigate the problem.
You could think that you can do better and you are absolute right. I’m a young guy that tries to expand his knowledge and maybe some of you have more experience and knowledge than me, but I give it a try to blog about my problems and my solutions.
- First, we looked at the traffic that goes between the SharePoint Server and the Internet. => No results.
- Then we looked throughout the SharePoint components and the settings, maybe there was a misconfiguration of a property that was not changed. => No results, all settings where clean and configured as well.
- Without any results of the monitoring of the network and the settings of SharePoint we decide to use Fiddler. Fiddler is a great tool to capture the network traffic. Fiddler runs as a web proxy that filter and check all the traffic that is going from the server or PC to the internet. => No results 🙁
Or options are slinking and the methods to test also.
Decompiling the SharePoint code.
Our last hope was to decompile the SharePoint code that was used to make the request to the Office Store. But where do you begin to search in that piece of code???
Now, when we analyzing the ULS log we found a stack trace that throws the error, so we had a begin point where we could start searching for some settings or other stuff that would be used to initialize the request.
The only thing we found it the HttpRequest component that was used to make the request. So we are searching for some problems in that default component of .NET. After some trial and error in our brainstorming we had an idea to use Fiddler to monitor all the request from the W3WP process.
Why the W3WP process?
Well, we thought that the connection is made by the service application pool of the SharePoint Web application (and the default proxy of the services in SharePoint). After some googling (link ) we found that we must change the web.config to use Fiddler as the Proxy.
<defaultProxy
enabled = “true”
useDefaultCredentials = “true”>
<proxy autoDetect=”false” bypassonlocal=”false” proxyaddress=”http://127.0.0.1:8888” usesystemdefault=”false” />
</defaultProxy>
After we changed the web.config file we saw that the request of the W3WP process is logged in the Fiddler tool, so that was great news. I went to SharePoint and clicked on the app store. We passed through the Fiddler proxy and surprise the store works!!
We are confused, so we are playing with the settings in the <defaultProxy /> code of the web.config and when we changed the code to <defaultProxy enabled=”false” /> the store works perfectly, so we had a workaround for our problem, but not yet the root cause of this problem.
The solution
When we went for a break at the coffee machine we were talking about the solution and, one of the technical solution experts for the network tells us this:
It’s normal because of the settings on our DHCP server. If you don’t set a proxy setting for the application like SharePoint or IIS then the network will take the default proxy of our network. So that’s the reason why only te configuration works when we completely disable the proxy setting.
Great news and a Happy ending of the problem!!
Hopefully this article is also a good knowledge for you guys, because this was very painful and deep to cover the exact problem and for finding a good solution.
sources:
http://www.techazine.com/2015/08/11/configuring-system-wide-proxy-for-net-web-applications-including-sharepoint/
http://54.146.253.9/2012/12/07/resolving-errors-running-sharepoint-2013-app-store-behind-a-proxy/
