Edit

Share via

Troubleshooting SharePoint Services Adapter

  • Article

This topic focuses on troubleshooting the Windows SharePoint Services (WSS) adapter.

Installation

When using the Windows SharePoint Services (WSS) adapter, there are two options:

Option Description
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..
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.

IIS

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.

Double-Hop Scenario

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:

  1. Enable Negotiate on the IIS/SharePoint server. For more information, go to Windows Authentication <windowsAuthentication>.

  2. Service Principal Names (SPNs) are required for the domain accounts executing the SQL Server Service and the Application Pool on the IIS/SharePoint computer. For more information about configuring Service Principal Names, go to Service principal names (SPN).

    Windows 8, Windows Server 2008 SP2, Windows Server 2008 R2 and Windows Server 2012: SetSPN

    Important

    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:

    1. Create an SPN for the FQDN of the IIS/SharePoint computer:

      setspn.exe -s http/IISSharePointComputerName.domain.com domain\IISApplicationPoolDomainAccount

    2. Create an SPN for the NETBIOS name of the IIS/SharePoint computer:

      setspn.exe -s http/IISSharePointComputerNamedomain\IISApplicationPoolDomainAccount

    3. 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

    4. 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

    5. Create an SPN for the NETBIOS name of the SQL Server computer used by the IIS/SharePoint computer:

      setspn.exe -s mssqlsvc/SQLComputerNamedomain\SQLServerServiceDomainAccount

    6. 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

  3. On the Domain controller, go to Active Directory Users & Computers and do the following:

    1. Check Trust this computer for delegation to any service for the following computers:

      • SharePoint/IIS server

      • SQL Server used by SharePoint

    2. 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

See Also

Configure SharePoint Services Receive Location Configure SharePoint Services Send Port CSOM: SharePoint Services Adapter