Last night in my house I witnessed a prolonged discussion between two people of different
Got BizTalk 2010, SharePoint 2010 and HTTP 401.2 Unauthorized errors?
On a recent project we were having problems configuring the Windows SharePoint Services Adapter onto a SharePoint 2010 farm. This is basically a BizTalk 2010 web service that gets deployed to your SharePoint farm. It allows BizTalk to deposit documents into SharePoint document libraries.
The adapter was deployed and configured without error, but when calling the web service from BizTalk it generated HTTP 401.2 Unauthorized errors. In the Windows System Event log on the BizTalk server the following details were logged:
*The adapter “Windows SharePoint Services” raised an error message. Details “The Windows SharePoint Services adapter runtime does not have permissions to invoke the adapter Web service. In order to fix this issue, you have to add the DOMAINbiztalk_service_account Windows account to the “SharePoint Enabled Hosts” Windows group on the Windows SharePoint Services machine. This operation will allow BizTalk host instances running under DOMAINbiztalk_service_account Windows account to invoke the adapter Web service in order to send and receive messages to or from SharePoint sites. The group membership will not take effect until you restart the BizTalk host instance. *
When you configure the adapter it creates a local security group on the server which is named “SharePoint Enabled Hosts”. The above error indicates that the service account that the BizTalk process is running under needs to be added to this local group. We tried this and tried this and tried this. After several unconfiguration, reconfiguration cycles we were stuck with the same error.
This appears to be a pretty common problem. A lot of people griping about the local security group approach (justifiably!).
Richard recommends modifying the SharePoint web application – we tried that approach and it didn’t work for us.
What solved this in our circumstance was to manually edit the web.config file for the virtual directory that is hosting the BizTalk web service.
The original authorization block looked like this:
Instead of stuffing around with the local group, I changed the allow line to specifically use the BizTalk service account (a domain account), and also removed the deny tag, so it looked like:
This fixed it for us, no more authorisation problems. It means that the BizTalk service domain account is still the only account that can invoke the web service.
If you have multiple web front end servers in your SharePoint farm, you need to configure the adapter and apply this ‘fix’ on each. Your mileage may vary on this, I’m just sharing what worked in our situation.