Home > MOSS 2007, SSRS > Say Goodbye to IIS, Say Hello to HTTP.SYS!

Say Goodbye to IIS, Say Hello to HTTP.SYS!

October 20th, 2008 Leave a comment Go to comments

With all the issues IIS caused in the previous versions of SSRS, specially to configure it to interact with other applications (such as SharePoint) hosted in IIS , in SSRS 2008, Microsoft made a major architectural shift to move toward to a *real* Single Service Architecture that would eliminate dependency on IIS.

You no longer require having IIS installed on the RS box and, even nicer; you don’t have to install SQL on that RS box! Well, let me rephrase what I just said above. SSRS doesn’t require IIS to function, but this only applies when you configure it in native mode. In integrated mode and since you have to join the SSRS machine to the farm, you have to install SharePoint WFE components on RS machine and this means dependency on IIS, but again that’s the dependency SharePoint has on IIS , not SSRS!

This shifting architectural decision took care of two very serious issues bugging customers constantly:

  1. SSRS trying to take over port 80 which was in control of SharePoint and subsequently throwing an unrelated exception that tipped many people over the edge when configuring SSRS in integrated mode.
  2. Hosting IIS on the database server and potentially exposing security threats.

In the previous version of SSRS, there were two services (Web Service and Windows Service) that worked hand-to-hand and collaborated (Collab sounds familiar eh? 😉 ) to execute the reports, but in the new version they rearchitected and abstracted everything to a SINGLE service – SSRS Windows service. Obviously, WMI APIs are still available for configuration tools, third party apps and your enterprise deployment scripting fun, but Windows service is just serving as the main entry into all of the background and foreground services SSRS offers!

Well, finding a suitable host to support the shifting decision was not that difficult. They just shoved everything into the common architectural layer as with SQL Server uses, but the idea of hosting ASP.NET inside SQL CLR inside SSRS service process was extremely intuitive. I was like WOW when I first saw it  (my jar hitting the floor kind a) – SSRS team literally came up with their own mini IIS with many similar characteristics. Wait! It doesn’t mean that you have another web server hosted in SQL CLR. It’s just there for them to serve incoming HTTP requests using SQL Server networking interface and again mainly for departing from IIS land.

Why am I using the word mini IIS here is because, first SSRS uses the same underlying network layer as IIS 6 and higher uses, built right into the operating system– a.k.a HTTP.SYS layer. Secondly, SSRS 2008 has all the IIS components it requires to function without having any dependencies on IIS. Moving away from IIS, called for two major actions to be taken care of by SSRS team:

  1. Disabling some of the functionalities IIS handles which there are no equivalent in SSRS 2008 , such as anonymous, client certificate and ISAPI crap. (I have allergy to ISAPI – sorry!)
  2. Enabling some of the functionalities that IIS used to handle for SSRS before. Things such as ability to add virtual directory, port, SSL certificate, W3C compliant logging mechanism and so on so forth.

A lot of new IIS-Like settings are configured by Reporting Service Configuration Manager (picture below) , a tool that is significantly changed since the previous version. In this tool, Web Service URL tab is a just a new (and a very important) tab that offers creating Virtual directory , assigning ports and applying SSL certificates, but there is this important drop down that has the same behavior as IIS: IP Address.

As you can tell, the recommended option is All Assigned. This means that any HTTP requests that come in the specified port (TCP Port text box) and uses the specified URL reservation and virtual directory name (Virtual Directory text box) should be served by Reporting Services. So if you see something like http://+:80/ReportServer , the wildcard sign (+) indicates that you are using port 80 and All assigned when configuring the URL reservations settings for your report server.

On the other hand All Unassigned indicates that if there are no other listeners (services) registered for a specific URL reservation , on this port , for this virtual directory then give me (not me , I mean SSRS 🙂 ) the request. As you can see it fully supports IPv4 and wild card IPv6 addresses  and exactly like IIS you can load balance the incoming requests if your server happens to be using more than one NIC cards. Very nice, eh?

Let’s have some fun here:

Setup a SharePoint Web application on port 80 (let’s say http://mossdev) and then in configuration tool choose the same port for SSRS – for example http://mossdev/reportserver , with All Assigned option selected. If you note you can share the port with IIS hosted Web app. Then create a team subsite in SharePoint called ReportServer (http://mossdev/reportserver) – Once the proviosning of the site is finished, you will be redirected to SSRS – I laughed 🙂 !Change the SSRS virtual directory name or port number, issue is fixed. As you can see, understanding URL reservation is extremely important.

If you would like to see all of the URL reservations currently in place on your server , just be aware that HTTP.SYS comes with a set of command line utils. For example,  by typing “netsh http show urlacl” command , you would get all of the URL reservations echoed for ya. If you note in this particular case I am using a different port (Heck!It can even be a different URL!) for Report Manager and Report Sever.


If any one of you understand what those security descriptor strings (SDDL) mean , please drop me a line and educate me as well 😉

These URL reservation must mach the URL Resevation node in the RS configuration file as shown below, otherwise when you start the Windows service , there are going to be some inconsistencies in services SSRS offer:


Categories: MOSS 2007, SSRS Tags: , ,
  1. October 20th, 2008 at 17:16 | #1

    Great post, Reza! Thanks for sharing this!

  2. Reza Alirezaei
    October 20th, 2008 at 19:55 | #2

    Thanks Muhanand! more to come ….

  3. Jay Pounds
    November 24th, 2008 at 15:05 | #3

    Just a note — afaik the netsh http commands only work on Windows 2008, and are unavailable on earlier versions.

  4. Reza Alirezaei
    November 24th, 2008 at 17:17 | #4


    Thanks for letting me know. I have switched my entire dev enviro to Win2k8 since it was RTMed , so I didn’t give it a try on any other Winodws server platofrms.

  5. Manu
    September 30th, 2009 at 23:23 | #5

    Looks like ISAPI is foreign for you. I used extensively, belive me it is really powerfull

  6. Stogie
    December 21st, 2009 at 14:49 | #6

    Hi Reza,

    I’m wondering if there’s a way to run SSRS 2008, or more specifically, configure the URL to eliminate the “/Reports” part of the URL… i.e. http:///Reports/Pages/Folder.aspx (is the Report Manager Home). Using the Config Manager, it forces a Virtual Directory. I just switched our company’s primary reports site from an old server running SSRS 2005, where we had configured it to not have the “/Reports” in the URL, to a new server (which took the old server’s name) running SSRS 2008 and I was trying to keep all my users who had IE favorites set up from having to change the URL.

    At this point we’ve already switched everyone over, but I’m wondering if there was a way I could have saved all the trouble. Thanks!!

  7. Jed
    February 25th, 2011 at 14:04 | #7

    windows XP and 2003 use ‘httpcfg’ instead of ‘netsh http’, which can be downloaded as part of the “Windows XP Support Tools” / “Windows Server 2003 Support Tools”.

    The syntax is “httpcfg.exe query urlacl”.

  8. March 31st, 2011 at 11:35 | #8


    It’s been over a year since your post. I am replying for the sake of answering a question, regardless of the delay.

    You could write a small web server service that uses http.sys, which forwards all requests to the SSRS virtual directory.

  9. vinay
    March 6th, 2012 at 00:25 | #9

    Very nice article and a great intro for SSRS 2008!

  10. Dimitry
    November 1st, 2012 at 14:54 | #10

    I’ve installed SSRS2012 syde-by-side to SSRS2008R2.
    Under SSRS2008R2 I use rs.exe to start report with store in excel.
    Due to 256 column limitation i have try to use SSRS2012.

    I got next error:

    —–Try to start rs.FireEvent(TimedSubscription)
    !!!!!!!!!!!!!!!!!Got an Exception System.Web.Services.Protocols.SoapException: T
    he permissions granted to user ‘box\myAccount’ are insufficient for pe
    rforming this operation. —> Microsoft.ReportingServices.Diagnostics.Utilities.
    AccessDeniedException: The permissions granted to user ‘box\myAccount’
    are insufficient for performing this operation.
    at Microsoft.ReportingServices.Library.ReportingService2005Impl.FireEvent(Str
    ing EventType, String EventData, Guid batchId)
    at Microsoft.ReportingServices.WebServer.ReportingService2005.FireEvent(Strin
    g EventType, String EventData)

    the match information in log:
    library!ReportServer_0-2!1ed8!11/01/2012-13:54:51:: i INFO: Call to FireEventAction(TimedSubscription, , ).
    library!ReportServer_0-2!1ed8!11/01/2012-13:54:51:: e ERROR: Throwing Microsoft.ReportingServices.Diagnostics.Utilities.AccessDeniedException: , Microsoft.ReportingServices.Diagnostics.Utilities.AccessDeniedException: The permissions granted to user ‘WIN-5PRKSLBIC68\soften3’ are insufficient for performing this operation.;

    All security settings completed – user, folder – match to SSRS2008
    it is possible that issue in IIS authorization – but there is HTTP.SYS!!!!!!

    What way i can fix this issue?


  11. November 9th, 2012 at 12:06 | #11

    Say goodbye to IIS say hello to billions of broken web services that try to bind to port 80.

You must be logged in to post a comment.