Today! (Cleaning up Reporting Services SharePoint Add-In Setup Problems)

Some people have had problems during installation of the new Reporting Services Add-in for Microsoft SharePoint. If the add-in setup fails while to add the Reporting Services feature to the sites, some of your SharePoint sites will no longer work.  You can tell if the custom action failed by looking for a file named RS_SP_#.log in your %temp% directory.  If you have a log file there and your install failed, you will need to manually clean up your web.config files to get SharePoint up and running again.

First, you will need to locate the SharePoint virtual directories on your server.  Typically these are located at c:\inetpub\wwwroot\wss\VirtualDirectories. This folder contains several folders with names which are numbers representing the ports used by your SharePoint sites.  In each folder you will need to remove the following entries from the web.config file:

      <SafeControl Assembly="Microsoft.ReportingServices.SharePoint.UI.WebParts, Version=, Culture=neutral, PublicKeyToken=89845dcd8080cc91" Namespace="Microsoft.ReportingServices.SharePoint.UI.WebParts" TypeName="*" />
      <SafeControl Assembly="Microsoft.ReportingServices.SharePoint.UI.ServerPages, Version=, Culture=neutral, PublicKeyToken=89845dcd8080cc91" Namespace="Microsoft.ReportingServices.SharePoint.UI" TypeName="*" />
      <add verb="*" path="Reserved.ReportViewerWebPart.axd" type="Microsoft.ReportingServices.SharePoint.UI.WebParts.WebPartHttpHandler, Microsoft.ReportingServices.SharePoint.UI.WebParts, Version=, Culture=neutral, PublicKeyToken=89845dcd8080cc91" />
      <add verb="*" path="_vti_bin/ReportServer" type="Microsoft.ReportingServices.SharePoint.Soap.RSProxyHttpHandler, RSSharePointSoapProxy, Version=, Culture=neutral, PublicKeyToken=89845dcd8080cc91" />


  <location path="_vti_bin/ReportServiceAuthentication.asmx">
        <allow users="*" />

Once you remove these lines, save the file.  You must do this for every web.config file under the above directory.

To get around the issue, you need to add the user who is running setup as one of the Site Collection administrators before you run the setup. You can do this though the Site Adminstration page.

This is a known issue with our CTP2 setup and has been addressed in CTP3.