{"id":748,"date":"2008-10-20T15:53:16","date_gmt":"2008-10-20T20:53:16","guid":{"rendered":"http:\/\/blogs.devhorizon.com\/reza\/?p=748"},"modified":"2008-10-20T23:57:57","modified_gmt":"2008-10-21T04:57:57","slug":"say-goodbye-to-iis-say-hello-to-httpsys","status":"publish","type":"post","link":"https:\/\/blogs.devhorizon.com\/reza\/2008\/10\/20\/say-goodbye-to-iis-say-hello-to-httpsys\/","title":{"rendered":"Say Goodbye to IIS, Say Hello to HTTP.SYS!"},"content":{"rendered":"

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.<\/p>\n

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!<\/p>\n

This shifting architectural decision took care of two very serious issues bugging customers constantly:<\/p>\n

    \n
  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.<\/li>\n
  2. Hosting IIS on the database server and potentially exposing security threats.<\/li>\n<\/ol>\n

    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? \ud83d\ude09 ) to execute the reports, but in the new version they rearchitected and abstracted everything to a SINGLE service \u2013 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!<\/p>\n

    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\u00a0 (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.<\/p>\n

    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\u2013 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:<\/p>\n

      \n
    1. Disabling<\/strong> 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 \u2013 sorry!)<\/li>\n
    2. Enabling<\/strong> 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.<\/li>\n<\/ol>\n

      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<\/strong>.<\/p>\n

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

      On the other hand All Unassigned<\/strong> 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 \ud83d\ude42 ) the request. As you can see it fully supports IPv4 and wild card IPv6<\/a> addresses\u00a0 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?<\/p>\n

      <\/p>\n

      \n\n\n<\/p>\n