SQL Server Reporting Services 2005 and Windows Server 2008

I recently needed to create a “duplicate” of my production environment which was running SSRS 2005 SP3 on Windows Server 2003.  We had two instances of the reporting server, one was integrated with SharePoint 2007 SP2 and the other was a native instance.

I found several issues while running the installation on my new testbed servers.  Basically, the organization no longer was fully supporting Windows Server 2003 installs as the install had to be manually patched.  They had a good image for Windows Server 2008, so we decided that there would likely be a minimal impact for installing SharePoint 2007, SSRS 2005, SQL 2005, PPS 2007, and ProClarity in this environment.  Well, we were wrong and this blog is about the issues faced an how to overcome them.

First, here was the server topology:

• 1 SQL 2005 box running on Windows Server 2008 (SSAS, DBMS, SSIS).  No issues with install and configuration.
• 1 SharePoint 2007 WFE on Windows Server 2008.  No issues with install and configuration
• 1 Application Server box running –
• SharePoint 2007 – no issues with install & config
• PPS 2007 – no issues with install & config
• SSRS 2005 native and integrated – problems here see below
• ProClarity – problem here which will be touched on as it impacted SSRS 2005 eventually too

So, first, the SSRS configuration issues.  You can read an earlier post in my blog about how SSRS 2005 is configured on Windows Server 2003.  (I have not linked it since all Live blogs will be migrating to WordPress).  For the native and standalone installs, I had problems getting the web service identity to configure.  I had created the stub web sites and application pools in IIS 7 for the SSRS sites.

The following are the key steps for the config wizard to run:

1. I had assigned a domain account to run the application pools and changed the application pools to run in classic mode.
2. I had to create a local group on the server for IIS_WPG.  For some reason, this group does not exist on Server 2008 and must be created manually.  I believe this step is the secret sauce for a clean service account configuration using the SSRS configuration wizard.
3. If your service accounts still do not configure cleanly, then follow this KB – http://support.microsoft.com/kb/938245 (regedits, be warned)
4. The DB script will not generate properly no matter what from what I found.  Please see this connect article on how to properly get the DB scripts to generate

Now for the last points on ProClarity-

ProClarity will want to use the default web application and will want that web application to run in 32bit mode.  If you are running a 64bit SSRS install (which you should use on a 64bit server) and install SSRS after ProClarity, you will need to modify the default site’s application pool to install otherwise it will not pass a pre installation check which will gray out the SSRS installation option.  Here is how you can fix this:

1. Right click on the application pool for the default web site and choose “Advanced settings”.  Update “Enable 32-Bit Applications” setting to “False”

2.  Go to your Windows system folder and navigate to the applicationHost.config file (C:Windowssystem32inetsrvconfig) and find the following tag:

<applicationPools>
    <add name="DefaultAppPool" enable32BitAppOnWin64="false" />

Make sure the setting is “false” and run an iisreset to consume the change.

Now SSRS will not complain about the ASP.NET runtime being incorrect and the bits can be installed and configured.  Be sure that you do not use the Default Web Site for SSRS though as you will need to set this back to 32bit for ProClarity to run again.