Recently when I tried to access Reporting Services' Report Manager for a SQL Server 2008 Developer Edition SP1 instance on a Windows 2008 R2 Server, I got a completely blank screen. It was not a mostly blank screen still showing the header, nor was I getting the blank page after being prompted for my user credentials three times. No, the page was loading immediately and was completely blank. I checked the Windows logs, the SQL Server logs, and the Reporting Services log, and no errors were being logged.
Fortunately I knew that the security department had recently made changes to that instance to enable Kerberos authentication in order to support Kerberos delegation for a web app that connected to our SQL Server and Reporting Services. They'd dutifully documented all of the changes, and so since I didn't have any error logs to go on, I knew this was the only change that had happened recently and likely had to be the culprit.
We used the same domain account to run both the SQL Server service and the Reporting Services in order to make our lives a tad bit easier, and I double checked that all of the SPNs were registered properly for the web server, SQL Server, and Reporting Services. Figuring it had to be something related to the Reporting Services configuration, I noticed that they'd changed a setting in the RSReportServer.config file, located at C:\Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\ReportServer in a default install, and noticed they'd changed <AuthenticationTypes> to <RSWindowsKerberos/>. I wanted to accept Kerberos or NTLM tokens, so BOL pointed me in the direction of using <RSWindowsNegotiate/>. But, despite BOL suggesting that this setting would be omitted if I were running in native mode and using a domain user for the service, I caved to my rebellious streak, removed <RSWindowsKerberos/>, replaced it with <RSWindowsNegotiate/> and hoped for the best. It worked! The web app continued to work via Kerberos authentication/delegation, and I was able to access my Report Manager again.
I'm sure there's a moral to this story somewhere. Mainly, though, I'm just very pleased that the security department and the consultant they had helping them were so diligent in documenting their changes. I probably owe them a cookie or something.