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).