Reporting Services Web Service only works with localhost after Windows Updates

Question

On an ASP.NET web application I have a set of reports that are accessed via the 2010 report viewer. The application was working fine in production until an admin installed windows updates. Since then I now receive the following error message:

The attempt to connect to the report server failed. Check your connection information and that the report server is a compatible version.
The request failed with HTTP status 404: Not Found. 

SSRS is located on the same server and I use a FQDN so that I can use host-headers instead of port numbers, i.e.:

http://rs.myserver.my.domain.net/ReportServer

This has been working until the update, now since the update the above error is displayed and the only way to restore functionality is to set ReportServerUrl to a localhost, port based binding, i.e.:

http://localhost:8080/ReportServer

Also note that I can access the Report Manager and the Reporting Services Web Service by the FQDN despite the fact that I get the above error message from report viewer.

What I found most interesting is that on my development server I was able to replicate the problem (which did not exist despite being updated the same day, although I have not determined whether the same updates ran on both). What I did to replicate the problem was simply installing the Report Viewer 2012 runtime. Interestingly, this runtime was not installed in the development environment, yet it was installed last year on the production environment. Updating or uninstalling the runtime leaves the system in the same broken state.

Hopefully someone can provide some insight so that I can restore my desired setup.

Thanks!

Answer 1

This sounds like loopback detection on the server. Loopback detection is designed to prevent reflection attacks and manifests when a link from a server loops back to the same server using something that looks like an external link. This is why localhost works but your FQDN doesn't - the server knows that localhost is itself but the FQDN looks like an external link. This check does get installed with certain service packs on Windows Server.

Check Microsoft Knowledge Base article 896861 for the ways to fix this. Method 1 involves putting the host name in multi-string value registry entry called BackConnectionHostNames in the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0. Method 2 disables loopback detection entirely (less recommended) by putting a DWORD registry entry called DisableLoopbackCheck with the value 1 in the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.