I was up til 2am on this one.

A client’s relatively shiny-new SQL Server 2008 R2 Reporting Services Express install was failing to start. Pinging the relevant URLs:

http://server/reports
http://server/reportserver

Was continually responding with a 503 error. No further detail, just a HTTP 503 response, which translates to “Service unavailable”. The Windows “Report Server” service was running, and started/stopped just fine. My normal response to this kind of problem is to start looking at logs – Windows logs were all clear. I

googled around the subject, which gave several “poke and pray” solutions, not too helpful.

To fix a problem like this, you need logs. Every single StackOverflow, or forum response to this problem should read “check what’s going on in your logs”. You don’t diagnose a medical condition without some evidence to back it up. You need data.

A few responses pointed to this MSDN article which gives you details for turning on HTTP event logging. Genius! Except that all you get is a line which reads:

2012-02-17 17:51:38 192.168.23.204 1222 192.168.23.240 80 HTTP/1.1 GET /Reports 503 - N/A -

Not very helpful. Eventually, after ingesting far too much caffine and having to dig around in Reporting Services textbooks, I found a reference to the Reporting Services log files, in this case located here:

C:\Program Files\Microsoft SQL Server\MSRS10_50.SQLEXPRESS\Reporting Services\LogFiles

From there I was able to diagnose the problem as relatively trivial and fix the configuration problem. In my case (yours will most likely be different), the problem was related to an empty RSWindowsExtendedProtectionlevel XML tag in the rsreportserver.config file. For your own individual problem – READ YOUR LOGS.

Today I feel it is appropriate to finish with: