I have installed and configured several SQL Server Reporting Service (SSRS) 2005 instances at my current employer.  Recently, I was asked by my development group if we could upgrade to SSRS 2008.  Since I am always up for a challenge, I said "yes," and I worked with my server team to get a sandbox environment set up for testing.   Books Online (BOL) and MSDN were my primary references for the article and again provided me with all the steps I needed to solve my problem. 

In this article I will explain how to get the Report manager and Report Server site up and running after an upgrade to SSRS 2008.  The article takes all the steps from BOL and MSDN into one consolidated document for finalizing the SSRS upgrade of a Scaled-out SSRS deployment that uses a custom website.

Note: This document is specific to a scaled-out deployment of SQL Server Reporting Services 2008 that does not use the DEFAULT Website.

All of our SSRS installments are scaled-out deployments that include several servers.  As a result, my sandbox consisted of two SSRS servers and one SQL Server.  The servers were configured in a way that mimicked our production environment.  I also had our Report Manager deploy all of our SSRS reports in the sandbox environment.  This way we could ensure that all the existing SSRS 2005 reports behaved as they do in SSRS 2005. We did some smoke testing in this environment to make sure that it was accessible from the Report Server, Report Manager and that all of our custom applications that consumed the SSRS web service still function properly.   Smoke Testing is a method of testing that focuses on the most crucial functions of the software, typically ignoring the details.  As expected, everything worked accordingly. 

Note:The URLs provided below are for demonstration purposes. You will need to change them to suit your environment.

The next step was to perform the upgrade.  There was nothing difficult about this; just your normal Microsoft upgrade wizard, Point, Click and Go.  For more information on upgrading SSRS 2005 to SSRS 2008 see BOL (ms-help://MS.SQLCC.v10/MS.SQLSVR.v10.en/s10rs_4deptrbl/html/851a19a8-07ab-4d42-992f-1986c4c8df55.htm).  Once the upgrade on both web servers was complete I tried to browse to the Report Manager (http://<servername>/reports).  No go; I received a Nasty 401 Unauthorized.  Then I tried to access the Report Server (http://<servername>/reportserver).  Another 401 error.

Since SSRS no longer depends on IIS, the first thing I did was open IIS and remove both the Reports and ReportServer virtual directories, which was in the documentation that I read in BOL about the upgrade.  I then removed the host headers from the website, if applicable, which I did not find in BOL.  Then I tried to access the Report Server and Report Manager.  Still a no go. 

Resolution

Since most of the configuration of Reporting Services is accomplished via the Reporting Services Configuration Tool I decided to start there.  In the side menu bar you are presented with several options. 

Each option allows the user to configure a specific section of the selected Report Server Instance.  My problems were related to accessing the Report Server and Report Manager URLs.  Therefore, I decided to start with the Web Service URL option. The first option on this screen to set is the Report Server Virtual Directory.  The default value provided is ReportServer, which I accepted.  The next section, Web Service Site identification, is where you specify the IP address that uniquely identifies the report server computer in the network, the TCP Port, and the SSL certificate. 

First, let’s talk about the Port and the SSL Certificate; I will discuss the IP address a little later.  Since we are not using an SSL Certificate no configuration was required.  I accepted the default TCP of 80 because it can be shared with other applications and I intended on running several other applications on this web server.  If you do decide to use a custom port you will have to specify it in the URL used to access the report server.  For example:  http://yourserver:83/ReportServer, where 83 is your custom port. 

Those were easy configurations; the IP address on the other hand required a little more effort. The drop down list for IP Address for my reporting service installations presented me with four options:  All Assigned (recommended), All Unassigned, the IP Address of the Server, and 127.0.0.1.  BOL provides detail information regarding each choice, unfortunately neither was an option for my deployment.  Instead, BOL suggested that I used the advanced options to configure my ReportServer URL.  I clicked the button labeled Advanced… and was presented with this screen:

I noticed that there was already an entry in the section Multiple HTTP identities for the Report Server Web Service labeled.  BOL suggested that I ADD a new entry.  I figured I had two choices remove the existing entry and follow BOL or EDIT it.  I chose the later of the two.  When I click edit the following dialogue box appeared:

Again I was presented with the IP Address drop down list that contained the same values as mentioned earlier.  However, I now had a new choice, Host Header Name.  This is exactly what I needed.  I chose that radio button and typed in my host header (dev.reports.company.com).  This was the same host header that was used in IIS. I accepted port 80 and left the SSL section as is and clicked OK.  Before you click Apply ensure that if IIS is installed, that you have removed the ReportServer virtual directory.  These exact steps were followed for the Report Manager URL configuration. 

Books Online and MSDN provides more details regarding the IP Address, TCP and SSL Certificates here:

·        http://msdn.microsoft.com/en-us/library/ms157412%28SQL.90%29.aspx (MSDN)

·        ms-help://MS.SQLCC.v10/MS.SQLSVR.v10.en/s10rs_4deptrbl/html/851e163a-ad2a-491e-bc1e-4df92327092f.htm (Books Online)

Remember that my deployment was scaled-out.  As a result, this had to be done on all servers involved in the deployment.  I restarted the Reporting Server service, just as a precautionary measure, tried the Report Server and Report Manager and it worked!!.  Happy days, at least I thought. 

Summary

In this article I explained how to use the Reporting Services Configuration Manager to successfully configure the Report Server and Report Manager URLs for scaled-out deployments that used a custom website. These steps did fix the problems with accessing the Report Server and Report Manager, but we faced a new problem and a new challenge that reared its ugly head when we tried to access the SSRS 2008 web service from our .Net Applications.  Part 2 of this article will explain how we solved the SSRS Web Service Problems.