Archive for the ‘Web Services’ Category

One I’ve been meaning to blog for a while, but just never got round to it Surprised smile

I came across an error when Creating a Custom web service for SharePoint when trying to deploy the web service to the ISAPI  folder, allowing me to access a web service through the  _vti_bin of SharePoint. 

When you create a web service and deploy it to a mapped folder the code behind, as expected goes into the GAC. However, there is no WSDL or DISCO file associated with the web service, so it doesn’t work. 

To create a web service which deploys to the _vti_bin

  1. Add a text file to the {SharePointRoot}\ISAPI mapped folder of your SharePoint project.
  2. Rename your text file to <ServiceName>.asmx. Now you have the service you now need to associate it to the code behind.
  3. Create a class and name it <ServiceName>.cs or .vb if you are that way inclined !!
  4. Add the following attributes to your class
       [WebService(Namespace = "/sharepoint/services/")]’>http://<yourdomain>/sharepoint/services/")]
       [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
  5. Next, return to your asmx file created in step 2 and add the following to the top of the file
    <%@ WebService Language="C#" Class="<NameSpaceOfAssembly>.<NameOfServiceClass>, <NameSpaceOfAssembly>, Version=<VersionOfYourAssembly>, Culture=neutral, PublicKeyToken=<PublicKeyOfYourAssembly>" %>
    Note: If you don’t know the public key, build your project, open a Visual Studio command prompt and naviate to your debug folder. Then run the command sn –T <NameOfYourDll>.dll
  6. Next, you need to deploy your solution to get the asmx file into the ISAPI folder and your class into the GAC.
  7. Once deployed, navigate to the web service at <SharePointSite>_vti_bin/<PathIfAny>/<ServiceName>.asmx and you should see your service with any web method you have added.
  8. Next, you will need to create WSDL and DISCO files to allow your to add reference to the service from a project.
  9. For some reason you don’t seem to be able to do this from the ISAPI folder, you receive a file not found error seen below. image
    So,  you need to copy the deployed file from the ISAPI folder to the LAYOUTS folder.
    Then run the command from the Visual Studio command prompt, ran as Administrator



  10. Once you have successfully ran this for the instructions in the “Generating and Modifying Static Discovery and WSDL Files” section of the Creating a Custom ASP.NET Web Service page on MSDN. 
  11. Copy these newly create wsdl and disco files back into your project and redeploy.

Please note: This tedious process will have to be redone anytime you add a new web method to your service.

Scenario: SSRS, in SharePoint integrated mode, is calling a custom web service located in the SharePoint ISAPI folder access through _vti_bin.  This service is using LINQ 2 SharePoint to query multiple lists in the SharePoint WFE.

A layout of the set up can be seen below. Okay, network diagrams is not my strong point! 


Because the authentication is being passed over more that 2 boundaries it looses the user and passes null and the only way to fix this is to use Kerberos.

So here’s how I went about setting it up:

Service Principal Names (SPN) for Service Accounts   

In order pass the Kerberos token you need to set up SPN’s. 

Note: Although I’ve not found confirmation of this SPN’s appear to be case sensitive

setspn.exe -A HTTP/<SSRS_FQDN> SSRSService
setspn.exe –A HTTP/<SSRS_NetBIOSName> SSRSService

Set the <SSRS_FQDN> to the FQDN of the server hosting the SharePoint Integrated SSRS and the <SSRS_NetBIOSName> as the Server name.

These entries can be confirmed by running

setspn.exe –L SSRSService

This should give an output similar to below.


The onto the WFE’s

setspn.exe -A HTTP/<SP_WFE_FQDN> SPService
setspn.exe -A HTTP/<SP_WFE_NetBIOSName> SPService

Set the <SP_WFE_FQDN> to either: the name of the server hosting the Sharepoint WFE or if this is an NLB cluster use the cluster name and the same goes for the <SP_WFE_NetBIOSName>

setspn.exe -A MSSQLSvc/<SQL_FQDN>:1433 SqlDbService
setspn.exe -A MSSQLSvc/<SQL_NetBIOSName>:1433 SqlDbService

Set the <SQL_FQDN> to either: the name of the server hosting SQL or if this is a cluster use the cluster name and the same goes for the <SQL_NetBIOSName>

Active Directory Users and Computers

Next, Open Active Directory Users and Computers and change each of the 3 accounts, selecting the Trust this user for delegation to any service (Kerberos Only) option on the delegation tab. 


SSRS App Server Changes

On the SharePoint Application Server which is hosting SSRS Open the Local Security Policy and Go to User Management Rights. Change to  “Act as a part of Operating System and “Impersonate a client after authentication” to include the users for both the WFE’s App Pool and SSRS Service Account


Report Server Configuration Changes

Open the RsReportServer.config file and locate the <AuthenticationTypes> section. Add <RSWindowsNegotiate/> as the first entry in this section.

Central Admin Changes for Web Application

Next, open Central Admin and Navigate to Application Management –> Manage Web Application


Then, select the application, then the authentication providers


In the pop-up click on the “Default” link in the Edit Authentication window scroll down to IIS Authentication Settings and choose Negotiate.


Scroll Down and Save.

Give this a minute to propagate to the other Servers in the farm and you should now be able to access the Reports which call the web service. 

I received the above message on some SSRS reports when the reports were using a shared data source and accessing a custom built, SharePoint, web service, in the ISAPI folder, . However, the following error left me very confused when some of the web methods were returning the data okay and the rest were returning this error.

Error while reading xml response.
DTD is prohibited in this XML document.


To try and figure out what was going on I built a window forms test harness to allow me to test the service in isolation of SSRS and to measure the time taken for each call.  My findings were that the response error was not caused by the the XML returning from the service but, by a redirection to a error.aspx page on timeout. Firing up Fiddler also confirmed this as can be seen in the html below.

<html><head><title>Object moved</title></head><body>
<h2>Object moved to <a href="http://sharepoint/hr/_layouts/error.aspx?ErrorText=Request%20timed%20out%2E">here</a>.</h2>

The other purpose of the windows form was to measured the time before the failure.  My findings were that this was approximate 2 minutes.

After some more Google-ing about I discovered the problem:

The time-out of a .NET web service is 110 seconds by default. To fix this I simply had to increase the executionTimeout element of the httpRuntime Element (ASP.NET Settings Schema) in the web.config on all of the SharePoint WFE’s of the port I was accessing the _vti_bin/Service.asmx through.

Replace this:

<httpRuntime maxRequestLength="51200"/>

with this:

<httpRuntime maxRequestLength="51200" executionTimeout="600"/>

After increasing the timeout on all 3 WFE’s and hey presto, my data returned.

It took a while but, as always, the solution was staring me in the face. I hope this blog post helps someone avoid the grief I had figuring it out.

PS I also change the data-retrieval-services-timeout –propertyvalue but it never changed anything that i seen. I case you need reference to it use:

stsadm.exe -o setproperty -propertyname data-retrieval-services-timeout –propertyvalue 600