ConfigMgr 2012 Reports Node Empty / HTTP Error 404

Posted on Updated on

Are you experiencing a problem with your ConfigMgr 2012/R2 console not showing reports in the Reports node?  I was recently for implementation at a customer site!


When a console user select this node, the console queries SRS website directly then returns the results.  That’s how it keeps up-to-date with any new reports which may be created.  In this particular case, SRS was configured to use only the NETBIOS name as the URLs for the websites.  To know which URL your console is trying to use, simply click on the root Reporting node.


So when we’d attempt to access the website directly via a web browser, it would generate a 404 not found error.  Long story short, this was because of the use of a proxy server.  The URL would be redirected to the Internet and couldn’t find any website named “http:\\server\reports”.

To fix this, we needed to change how SRS was configured so as to force it to use a FQDN address.  There are a couple of ways which this could be completed.  One way could be to configure the reporting services point for HTTPS to improve reporting security.  The other way could be to reconfigure the URLs in SRS to use a specific host header name (outlined below).

1.  Open SQL Server Reporting Services Configuration Manager.  Go to the Web Service URL and click Advanced.  In the image below, note by the arrow that the URL is only the NETBIOS name.


2.  Next, change the IP Address from “All Assigned” to use the FQDN.  Save all of the changes.


The new URL result will look as follows:


3.  Repeat the above steps for the Report Manager URL.

4.  Finally, reinstall the Reporting Service Point role in ConfigMgr.


Then voila!  The console will now use the FQDN for reports, which will now be displayed.




3 thoughts on “ConfigMgr 2012 Reports Node Empty / HTTP Error 404

    CharleM said:
    October 2, 2014 at 4:41 am

    Great stuff!!!!!
    Thanks for this post…

      Nik said:
      May 19, 2016 at 11:06 am

      This information, found after 2 days of pulling hair out solved 2 issues. The on you describe and update deployments failing. Some proxy changes had affected both it seems. Thank you so very much!

        N. Moseley responded:
        May 20, 2016 at 7:53 am

        Awesome Nik – thanks for sharing that it helped you!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s