Sharepoint 2007 Conflicts with Reporting Services

EDIT Hopefully this is now a thing of the past now we have SQL Server 2005 SP2!

I have to confess that I have not tried an install of Reporting Services in Sharepoint 2007 yet (Fingers crossed for a clear run in January).

My attention was drawn to this post by Finntastic that says:

Many times this is caused by a 3rd party application (or other Microsoft application such as Reporting Services) that installed itself into the website running on port 80.  This can cause a couple of issues:
1) If SharePoint 2007 was installed on the server first and created a web application running on port 80 – the web.config file at the root of the site will be formatted for SharePoint and will most likely cause errors for the 3rd party application.
2) The 3rd party application will be using an app pool which might have permissions that are not correct for the 3rd party application to run properly.
3) The virtual directory(s) that the 3rd party application might (not likely) cause errors with SharePoint.

Now this sounds like the same sort of pain that the “old” Sharepoint had.

To resolve it in the old version you had to use the STSADM.exe tool to tell Sharepoint to “Butt out” (unless you were using Business Portal from GP)

Moving Reporting Services to another site away from the “Default Web” is always the last line of attack and the details on how to do it are here; How to: Configure Reporting Services to Use a Non-Default Web Site (Reporting Services Configuration)

From Books Online: <Quote>

Configuration Steps for Side-by-Side Deployment

The following steps explain how to run Windows SharePoint Services and Reporting Services together after both products are installed. You can configure the report server for deployment before or after the following steps are complete.

Run the following commands to add the Reporting Services virtual directories to the Windows SharePoint Services list of exclusions. If you installed Reporting Services using the default virtual directories, run the following at the command prompt:

STSADM.EXE -o addpath -url http://localhost/ReportServer -type exclusion STSADM.EXE -o addpath -url http://localhost/Reports -type exclusion

 By default, the stsadm.exe file is located in C:\Program Files\Common Files\Microsoft Shared\Web server extensions\60\bin.

Run the Reporting Services Configuration tool. If you have not yet configured the report server for operation, you must create the report server and Report Manager virtual directories, specify service accounts, and create the report server database. For more information about how to set the options in the tool, see Reporting Services Configuration F1 Help.

If you configured the report server before installing Windows SharePoint Services, check the application pool settings for the Web service to verify they are correct:

Open the Web Service Identity page.

Verify that the application pool for the report server and Report Manager is set to Default Application Pool (or another application pool that you defined for the service). The application pool used by the report server must be different from the one used by SharePoint Services.
In the previous release, the documentation recommended that you enable session state. Enabling session state is no longer a requirement. However, if you do not enable session state, session state for Report Manager folder pages that get set in detail view will not be preserved. If you require session state for detail view, enable session state by setting enableSessionState to true in the SharePoint Web.config file located at C:\Inetpub\wwwroot.

<end Quote>

Given the new integration of the Reporting Services capabilities with Sharepoint 2007 in SQL Serer SP2 I hope that these issues are in the past.