Troubleshooting a Botched Install of SQL Reporting Services 2005

New Toy!

Recently I set up a new Dell PowerEdge 840 server at my house to have a place to learn new technologies and basically mess around. A friend of mine and I installed Windows Server 2008 and SQL Server 2005 including SQL Server Analysis Services ( SSAS ) and SQL Server Reporting Services ( SSRS ). The installations were pretty simple, which was surprising. For now I didn’t want to complicate the SQL installation, so I installed it with only one service account to handle all the services.

Well I made a very newbie mistake by forgetting all the passwords we had set for the windows accounts we set up during installation. Since my friend has a limited number of installations of Server 2008, I had to find a way to either get ahold of the passwords or find a utility to change the passwords. I couldn’t just rebuild from scratch. I found this utility (Offline NT Password & Registry editor), which allowed me to change the account passwords via a boot disk.

Wow! That was easy

Everything is gravy right? Wrong! It turns out to change the service account information for SSRS you must first backup the key used to create the encryption SSRS uses because you need to restore the key to change the service account info. Well I had changed the service account’s password hash on the disk and so never had a chance to create the backup key. All of the account information was now locked into the encryption.

Some uninstallations were in order. I uninstalled and reinstalled SSRS, but it didn’t solve my problem.  The uninstaller didn’t remove the SSRS instance files from the drive.  When I reinstalled SSRS, all of the connection information was still intact.  I also uninstalled and reinstalled IIS, but the SSRS application information and virtual folders were still intact.  I had to get a lot more medival.  To make a long story short, here’s the list of what I did to clean up the server:

Google powers, activate!

• Completely uninstalled SQL 2005
• Deleted both the 64bit and 32bit SQL folders on C:\
• Noticed the SSRS service (ReportServer$SQL2005) was still on the machine with the account credentials I had given it the first time around – Used sc.exe to remove it
• Ran  C:\>SC.EXE query | find /i “SERVICE_NAME: SQL” to locate any other SQL services I and the uninstaller missed
• Removed the SQL instance registry keys
• Deleted the residual SSRS server application information and application pools from IIS

All of this work created a nice, clean server once more.  I then reinstalled SQL 2005, including all components.  During the first installation, my friend and I installed some additional IIS 7.0 role services In order for SSRS to function correctly.  I couldn’t remember what they were, but my google powers found this gem of a list.  Additional IIS role services installed, I then ran SQL Server 2005 SP3 (most importantly for this post, it corrects some bugs with SSRS configuration manager).  I then promptly opened the SSRS configuration manager.  Low and behold, everything was fixed!

Onward with discovery

I hope this article can shed some light on how to fix a bad install of SS Reporting Services 2005.  I know I had a hell of a time finding help with troubleshooting.  It seems every work on how to install and configure SSRS assumes each step is automatically successful.  It would be nice if they also added some notes on what to do if the step does NOT install or configure as expected.

Now it’s time to dig in deeper to this thing called Reporting Services….