Archive for July, 2011

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. 

Came across the above error on all the reports served through SharePoint in integrated mode. Not sure why this happen, but you seem to be able to resolve it by restarting the reports service.

Go to the Reporting Services Configuration Manager ( seen in figure below), connect to the server, then stop and start the service


After deploying several event receivers to a variety of lists I found that one of the event receivers did not seem to be working, but instead was firing a old version of the DLL.

So, to check that it was indeed attached, I ran the following PowerShell command.

$spWeb = Get-SPWeb –Identity <SharePointWebUrl> 
$spList = $spWeb.Lists["List Display Name"]  
$spList.EventReceivers | Select Name, Assembly, Type

After running this I discovered that one of the event receivers had been attached to the list twice! I’m not entirely sure why or how this happened, but my problem was resolved by deleting the duplicate receivers and reattaching it once.

The script is used to delete was:

$spWeb = Get-SPWeb –Identity <SharePointWebUrl> 
$spList = $spWeb.Lists["List Display Name"] 
$eventsCount = $spList.EventReceivers.Count
$assembly = "Company.SharePoint.Client.EventReceivers, Version=, Culture=neutral, PublicKeyToken=570c484d87a3aa61" 
$class = "Company.SharePoint.Client.EventReceivers.ProvisionServiceAreaSecurityGroups.ProvisionServiceAreaSecurityGroups" $name = "ProvisionServiceAreaSecurityGroupsItemUpdating" 
$type = 2 
for ($i = 0; $i -lt $eventsCount; $i+=1)
     if ($spList.EventReceivers[$i].Assembly -eq $assembly –and
         $spList.EventReceivers[$i].Class -eq $class –and
         $spList.EventReceivers[$i].Type -eq $type –and
         $spList.EventReceivers[$i].Name -eq $Name)


And to add it was:

$spWeb = Get-SPWeb –Identity <SharePointWebUrl> 
$spList = $spWeb.Lists["List Display Name"] 
$spEventReceiver = $spList.EventReceivers.Add() 
$spEventReceiver.Assembly = "Company.SharePoint.Client.EventReceivers, Version=, Culture=neutral, PublicKeyToken=570c484d87a3aa61" 
$spEventReceiver.Class = "Company.SharePoint.Client.EventReceivers.ProvisionServiceAreaSecurityGroups.ProvisionServiceAreaSecurityGroups" $spEventReceiver.Name = "ProvisionServiceAreaSecurityGroupsItemUpdating" 
$spEventReceiver.Type = 2 
$spEventReceiver.SequenceNumber = 1000 
$spEventReceiver.Synchronization = 0 


That’s it Winking smile

Bizarre one this: Using SharePoint 2010’s new Modal Popup functionality a link had been created from a tab control to launch the new form for the list items associated with the tab. However, every time the form was submitted, it overwrote one of the existing records in the list. Firstly, I thought I was imagining things !!! But, it turned out that this was caused by using the ID  key in the query string.  I changed ID to RefID all was well.

It makes sense when you know, but it took a while to figure out why this was happening.

Lesson Learned: Don’t every use ID in the query string of a NewForm.aspx

Scenario: Using a Data View Web Part to create a form to submit anonymous user’s enquiries.  These enquiries were submitted to a list called “Contact Us” on the root sites.  This was all very well, but as it was a internet exposed publishing site,  the anonymous user had to have RW access to the list to allow it to write the enquires.   Unfortunately, it is not possible to give the anonymous user write only access to a list. 

Solution: To block browser access you need to add a location path to the web.config on all of the front end servers. In this instance it was the Contact Us list which was done as follows.

     <location path="Lists/Contact Us">
            <deny users="?"/>

Note: A space is used in the path, not %20

This is only applicable to the top level site and if you want to restrict access to lists on sub sites, they will need to be prefixed with the site name.

To see some other security factors use the Plan for and design security and Plan security for an external anonymous access environment pages on MSDN

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