Partager via

Everybody (Why Leave IIS?)

  • Article

If you have gotten a chance to try an early build of SQL Server Reporting 2008 Reporting Services, you know that one of the changes in the product is the removal of the Internet Information Services (IIS) dependency. I have gotten some questions about the motivation behind this change so I thought I would give you a quick peek behind the decision.

The first reason we moved away from IIS is for better configuration. IIS was built several years ago to do lots of things, including serving up web pages from the file system, host ISAPIs, Internet printing, etc. SSRS 2005 uses very little of IIS, mainly as a port 80 listener, client authentication, and process hosting. But when you install IIS, you got a bunch of stuff that RS really doesn’t need at all. It turns out that all of the parts of IIS that we didn’t use got configured in very strange ways and made RS not work.

This is especially true in the case where there were other IIS applications on the same server as RS. Not only did other application settings conflict with RS, any application running under the same Application Pool identity is granted full access to the RS catalog. By moving out of IIS, we have actually significantly reduced the surface area that you to configure and secure.

To be fair, IIS7 (in Windows Vista and Windows Server 2007) does address many of these issues by making IIS more modular and easier to configure. However, RS needs to support previous operating systems and the fact that IIS is an independently managed, shared resource can still cause us configuration headaches.

The second reason for the change is a need for better resource management. IIS has a pretty simple model for thread, memory, and state management. This works well for most applications that are serving up static or dynamic HTML pages. However, it wasn’t really built to host an enterprise server responsible for serving up reports with gigabytes of data in multiple formats to thousands of users simultaneously. By hosting the service engine ourselves, we gain much more control over resource management. For example, RS 2008 has a new on-demand processing model to ensure that no report executions will run out of memory. It does this by paging and releasing allocated memory to the disk when it gets memory pressure notifications. This would have been very difficult to implement using the IIS hosting model.

Using this new architecture, we are also able to simplify the dual-process model of Reporting Services 2005. In addition to the IIS application pools that handle on-demand requests, RS 2005 has a windows service to handle asynchronous processing (scheduled executions or subscriptions). To minimize the encryption surface area, these two processes use LRPC to communicate key information for each request. Merging these two processes removes this communication channel and allows us to balance resources across these two domains. For example, we can cap memory for the entire report server (to play nice with other servers) or say that scheduled executions get less memory working set than on-demand report executions, or vice versa.

A final motivation for the change was to remove adoption blockers. For example, some companies have a policy of not allowing IIS on the same server as SQL Server or don't want any web servers other than Apache. Whether or not these were useful policies, they kept us out of some deployments.

What does this mean for the users and external applications? They should see no changes. Most common IIS settings are supported (IP addresses, host headers, multiple ports, SSL, Authentication modes) and the tools and APIs have been updated for the changed settings. There are a few IIS settings not supported in RS 2005 that are now not allowed, including Anonymous authentication, Digest authentication, and Client certificates. If these settings are required, they can often be handled using a proxy like ISA Server. In most cases, the new server can peacefully co-exist with IIS on the same ports on a single (on 32 bit XP, you will need to put RS and IIS on different ports).

Comments

  • Anonymous
    December 04, 2007
    Title says it all, but is this really a feature you can benefit from or is it some piece of random engineering
  • Anonymous
    December 05, 2007
    Microsoft has severed the IIS dependency for SQL Server Reporting Services (SSRS) in the 2008 version,
  • Anonymous
    December 05, 2007
    Will Forms Authentication still be available?  
  • Anonymous
    December 05, 2007
    Появилась пара источников в сети (http://blogs.msdn.com/bwelcker/archive/2007/12/04/everybody-why-leave-iis.aspx...
  • Anonymous
    December 05, 2007
    Yes, custom authentication (including forms) will work the same way as RS 2005.
  • Anonymous
    March 02, 2008
    I still think that if this is the route MSSQLRS is to take on RTM, then IIS should be aware of the port and virtual directory used by reporting services and vice-versa.  As of the February 2008 CTP, you can create a virtual directory in ISS that uses the same port and virtual directory as reporting services, yet it will only serve the content if reporting services is off.I also feel the RS Report Manager and Web Service URL administration snap-in feature set is incomplete. I would like to set credentials by which to run the site under, and even have access to defining the application pool within the same interface, similar to what IIS 6/7 have available. I submitted feedback to the connect site, and while acknowledged, it does not look promising.https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=317287For the looks of this post, and others on the internet, I must be the only one that has deployed reporting services on an extranet site, and locked-down access by creating an application credential and building the relationship between these credentials and the reporting services browser access within the report portal interface as a way to create a secured anonymous access to individual reports while locking down access to browsing the folder hosting the individual reports, all without having to resort to custom authentication or forms authentication. This worked specially good when integrating reporting services with SharePoint.I hope I am not alone and this is changed by RTM, or at least SP1 of SQL 2008
  • Anonymous
    February 08, 2009
    You are not alone jcnovoa. I have the same issue/concern. Hopefully, IIS integration is made optional.
  • Anonymous
    January 27, 2011
    So clients don't want to deploy a web server other than Apache on the server but removing the dependency on IIS does not solve this problem. Now you're deploying another web server in any case but it's not Microsoft's default product that has been proven and is developed by a team whose absolute focus is building a web server. You're now installing a web server built by a group whose focus is databases. This is not a great move in my opinion. Will you guys be moving back to IIS 7 or greater once Windows Server 2003 is end-of-life?