Login / Sign Up
blog posts
Contributed on November 9, 2012
873

IIS : A Recent History

I’ve been setting up a new Windows 2008 R2 Server today and configuring the Web Server role. I had an unanswered question or two so went about ‘googling’ for some clarification. Forgetting that I’d set my local Evernote content to be shown as part of google searches, I found some of the answers from some reasonably old notes I’d made when Win Server 2008 R2 was first released.  With these notes on screen and the fact that it’s Friday night and I’m thinking about beer more than posting a new article, I thought I’d take some of the usable content  (minus my drivel and spelling errors) from the notes and post them up here. A little random, but hopefully some use in illustrating the evolution of the most recent editions of Internet Information Services.

IIS Feature History (Recent – since 6.0)

IIS 6.0 – Included with Win Server 2003 / Windows XP Pro

  • Introduced application pools. These are boundaries that exist to seperate sets of applications / sites from each other. They have their own security context.
  • Introduced worker processes (w3wp.exe, of which there can be many associated with an application pool.) The w3wp.exe is created when traffic is received and not is resident all of the time.)
  • Introduced the HTTP.sys as the protocol listener for HTTP/S, which listens for HTTP requests on the network and hands them to the application pool queues
  • Removed winsocks (windows sockets API) component which was previously used to listen and transfer HTTP requests
  • Security Account – IUSR_NameOfServer / Group – IIS_WPG
  • WWWService managed the application pools and worker processes
  • Used the ‘metabase’ for server / site level configuration

IIS 7.0 – Included with Win Server 2008 / Windows Vista

  • Complete re-write
  • New modular design to reduce attack surface (feature modules must be turned on before use)
  • Hierarchical configuration
  • Greater .NET support
  • Security Account – IUSRS / Group – IIS_IUSRS (no server name used now so easier to migrate)
  • IIS_IUSRS group has access to wwwroot by default, meaning that access is open to anonymous users accessing wwwroot. In order to restrict access to a certain folder of the web service, you must remove NTFS permissions from the IIS_IUSRS group.
  • You can create your own protocol listeners in WCF (which listen out for certain protocols)
  • WAS (Windows process activation service… named as it activates/creates windows processes) now takes care of managing application pools and worker processes (WWW Service is now used to manage performance tokens). A protocol listener will pickup a request and ask WAS to determine whether an application pool and worker process is available. If there is no worker process available in the application pool, WAS will start (activate) a new one.
  • Introduced the applicationHost.config XML configuration file in place of the ‘metabase’ (similar idea to having a machine.config for .NET applications). It contains the configuration/definitions of all sites, applications, application pools and global settings. It also contains the location of custom ‘modules’ written in .NET that you can implement in IIS and the native modules that ship with IIS. Config file is found in %winDir%system32inetsrvconfig

IIS 7.5 – Included with Win Server 2008 R2 / Windows 7

  • Powershell support added
  • Improved WebDev and FTP modules
  • New management tools
  • Configuration file logging. Enables auditing of access to config files.
  • Hostable web core. This means the core web components can be hosted by other applications, meaning applications can accept and process HTTP requests.

IIS HTTP request handling

Request processing follows a similar model in IIS6/7/7.5. The below shows the processing model for HTTP requests. If another protocol was being used, the listener would be different but the processing would be the same.

  • When a client browser initiates an HTTP request for a resource on the Web server, HTTP.sys intercepts the request.
  • HTTP.sys contacts WAS to obtain information from the configuration store.
  • WAS requests configuration information from the configuration store, applicationHost.config.
  • The WWW Service receives configuration information, such as application pool and site configuration.
  • The WWW Service uses the configuration information to configure HTTP.sys.
  • WAS starts a worker process (w3wp.exe) for the application pool to which the request was made if one is not already available.
  • The worker process processes the request by running through an ordered list of events that call different native and custom ‘managed’ modules (custom .net assemblies design to process web traffic)
  • The worker process executes the server side logic in the context of the user identity configured in the application pool and then returns a response to HTTP.sys.
  • The client receives a response.

IIS Server Modules

Unlike IIS 6.0, IIS 7.0 introduced a core web server engine (below in blue) that can have modules (functionality) added or removed from it. These modules are used by the core web engine to process requests. You can add or remove the native modules or create your own custom modules. This module based approach is more secure than IIS 6.0 because it reduces the attack surface and memory consumption footprint by letting you choose which modules to activate. It also makes the web server extensible in the form of custom managed modules (.dlls). The module types are:

  • Native modules – These ship with IIS and can be found in the %winDir%system32inetsrv folder of the server. e.g. Cachhttp.dll is the http cache module.
  • Managed modules – These are .NET based modules that come with the .NET framework and plug into the engine. e.g. System.Web.Security.UrlAuthorizationModule. You can create your own custom managed modules using the .NET Framework SDK.

The below image shows the ordering of events that a worker process carries out to process a request. It shows the modules that are invoked by the worker process. First native modules are called, then CLR hosted ‘managed’ modules in the form of .net assemblies installed to the server and registered in the applicationHost.config file.