Troubleshooting SharePoint Services Adapter
This topic focuses on troubleshooting the Windows SharePoint Services (WSS) adapter.
When using the Windows SharePoint Services (WSS) adapter, there are two options:
|Use Client OM set to Yes.||Recommended. When set to Yes, the SharePoint Services Client Side Object Model (CSOM) is used. The adapter is installed when BizTalk Server is installed. There are no additional installation steps. Note: The BizTalk Server installation also automatically installs the SharePoint Client Object Model Redistributable available at http://go.microsoft.com/fwlink/p/?LinkId=263482.|
|Use Client OM set to No.||Deprecated. Uses the SharePoint Services Service Side Object Model (SSOM).
A web service is installed on the SharePoint Services computer, which can be on the same computer as BizTalk Server or a separate computer.
To install the web service, run the BizTalk Server installation on the SharePoint Services computer and check Windows SharePoint Services Adapter. See Appendix B: Install the Microsoft SharePoint Adapter for specific installation steps.
Use Client OM set to Yes is recommended. When set to Yes, the web service is NOT installed on the SharePoint computer. If you prefer to use the web service option, you must set Use Client OM to No on the BizTalk Server.
BTSharePointAdapterWS.asmx web service
When the Windows SharePoint Services adapter is installed on the SharePoint computer, the BTSharePointAdapterWS.asmx web service is created in IIS on the SharePoint computer. Typically, BizTalk Server and SharePoint are installed on different computers. When SharePoint is installed, the content SQL database can be local to the SharePoint computer or on a remote SQL Server.
Application Pool uses Domain account
When BizTalk and SharePoint are on different computers, the IIS application pool running the BTSharePointAdapterWS.asmx web service must use a domain account. If BizTalk Server, the BizTalk databases, SharePoint Services and the SQL Server SharePoint databases are all installed on the same computer, then a local account can be used.
When there are three computers involved (BizTalk Server, SharePoint Services and SQL Server), there is a double-hop scenario that requires Kerberos authentication. The SharePoint adapter on the BizTalk computer does a POST request to the BTSharePointAdapterWS.asmx web service on the SharePoint computer. The SharePoint computer then queries its databases on the SQL Server computer.
This POST request from the BizTalk adapter must complete successfully. If you suspect an authentication failure, review the IIS logs. By default, the IIS logs are in c:\inetpub\logs\LogFiles\W3SVCx. The POST request should display a 200 (success) status code. If a failed status code is returned, like a 401.2, followed by a 401.1, following by another 4xx error, then authentication may be failing.
When Kerberos authentication is used, service principal names (SPN) are required and delegation must be enabled.
Enable Kerberos Authentication
In a double-hop scenario, Kerberos authentication and enabling delegation are required. Steps include:
Enable Negotiate on the IIS/SharePoint server. 215383: How to configure IIS to support both the Kerberos protocol and the NTLM protocol for network authentication lists the steps.
Service Principal Names (SPNs) are required for the domain accounts executing the SQL Server Service and the Application Pool on the IIS/SharePoint computer. To create an SPN, use the SetSPN.exe command-line tool:
Windows Server 2003: An update for Setspn.exe in Windows Server 2003 is available
Windows 8, Windows Server 2008 SP2, Windows Server 2008 R2 and Windows Server 2012: SetSPN
SetSPN requires Domain Administrator rights and can be executed from any computer in the domain.
To return a list of all SPNs registered to a domain account:
setspn.exe -l Domain\UserAccount
Create the SPNs:
Create an SPN for the FQDN of the IIS/SharePoint computer:
setspn.exe -s http/IISSharePointComputerName.domain.com domain\IISApplicationPoolDomainAccount
Create an SPN for the NETBIOS name of the IIS/SharePoint computer:
setspn.exe -s http/IISSharePointComputerNamedomain\IISApplicationPoolDomainAccount
Create an SPN for the FQDN of the SQL Server computer used by the IIS/SharePoint computer:
setspn.exe -s mssqlsvc/SQLComputerName.domain.com domain\SQLServerServiceDomainAccount
Create an SPN for the FQDN and TCP Port of the SQL Server computer used by the IIS/SharePoint computer:
setspn.exe -s mssqlsvc/SQLComputerName.domain.com:1433 domain\SQLServerServiceDomainAccount
Create an SPN for the NETBIOS name of the SQL Server computer used by the IIS/SharePoint computer:
setspn.exe -s mssqlsvc/SQLComputerNamedomain\SQLServerServiceDomainAccount
Create an SPN for the NETBIOS name:TCP Port of the SQL Server computer used by the IIS/SharePoint computer:
setspn.exe -s mssqlsvc/SQLComputerName:1433 domain\SQLServerServiceDomainAccount
On the Domain controller, go to Active Directory Users & Computers and do the following:
Check Trust this computer for delegation to any service for the following computers:
SQL Server used by SharePoint
Check Account is Trusted for Delegation and uncheck Account is sensitive and cannot be delegated for the following domain accounts:
SQL Server service domain account
IIS Application Pool domain account
For additional troubleshooting, go to Troubleshooting the Windows SharePoint Services Adapter