In the last couple of weeks, we had to move a custom application from one SharePoint 2010 farm to another. We tested our migration method by moving it to a test farm first, which highlighted a few things that we needed to change, but it was otherwise successful.
However, when we moved it to the new production farm, we ran into an error that we hadn’t seen in test. It occurred when we opened an InfoPath form that was calling the User Profile web service. The error presented to the user was a dialog with this: “An entry has been added to the Windows event log of the server. Log ID:7893” .
When we looked it up in SharePoint’s ULS log, we found this entry:
InfoPath Forms Services
Runtime – Data Connection
The following data connection (GetUserProfileByName) has exceeded the maximum configured time limit. This threshold can be configured by using the SPIPFormsService -MaxDataConnectionRoundTrip PowerShell commandlet
Scouring the internet, I found tips that suggested the identity of the application pool for the “SharePoint Web Services Root” should be something other than localservice. However, I then found a blog post by Spence Harbar stating that it was ok to be localservice.
I also found a tip that suggested increasing the timeout limits on the InfoPath Forms Services. I tried that without luck.
After discounting everything I found online, I went back to my list of differences between our test environment and our production environment. After hours of combing through service account permissions both in SharePoint and SQL, I finally decided to check the HOSTS file on the SharePoint servers.
Turns out the fix for us was to add an entry to the hosts file that pointed the SharePoint URL to 127.0.0.1 (the loopback address). We had already configured this for the other three SharePoint web application we had launched. We had neglected to do this with our new web application, which was only recently put into production.
So, we learned a couple of lessons again:
First – do everything you can to make your test environment mirror your production environment. I thought our environments were pretty well matched, including having a separate web front end from the app server, a separate SQL server, and even a separate FAST server in test. The one thing we don’t have is a load balancer with multiple WFEs.
Second – document your processes. We should have had a checklist to refer to when creating the new web application.