Lowering administration overhead with granular servicing of IIS modules (Part 1)
IIS 7.0 is made up of more than 40 separate feature modules. Each feature module can be installed independently, and because only the installed modules need to be managed, it helps to reduce the attack surface of the server and the administration overhead.
But how does the IIS 7.0 servicing work exactly?
Glad that you asked. The servicing behavior largely depends on the installation technology. IIS uses both CBS (Component Based Servicing) and MSI. More specifically, the IIS feature modules use CBS (what you get on Windows Vista and Windows 2008) while the IIS extensions use MSI (what you download from www.iis.net and download.microsoft.com).
In this blog, I will focus on CBS. The 40 separate feature modules mentioned previously are known as optional components in Windows. They are optional, because IIS is not installed by default and does not have to be installed at all. These components are staged in what we call a component store. When a component is turned on, it is installed from the component store and the state of the component changes from "staged" to "installed". (Naturally, when you turn off the component, the state changes from "installed" to "staged".)
This model has several benefits, but one of them is the ability to update the components that are "staged" in the component store. Why would you want to update the components that have not yet been turned on? If you are relying on Windows Update for your security patches, you may have experienced a scenario where you had to download several security patches after enabling a new server role. With CBS, if the "staged" components are already updated, then all the patches are already applied when the component is turned on. Note that I said "if". This behavior becomes a bit more complicated when you throw in Windows Update into the mix.
Windows Update uses an applicability and detection logic that may not be directly correlated to the components. It is possible to have a package that contains updates to several components. In this case, if Windows Update detects that at least one update is applicable to the server, then the entire package is downloaded and all updates are applied to the components in the component store, regardless of whether the components are turned on or not. As for the components that are turned on, the updates are further applied to the server.
So, what does all this mean to servicing IIS 7.0? If you are relying on the Windows Update, then the experience varies based on how the update is packaged. Most security fixes are very specifically targeted. So if your system does not have the affected module turned on, then the package would not even be downloaded. However, in a case of large package, such as a service pack, the entire package would be downloaded and if the affected component is turned on, then both the component store and the system are updated. If the affected component is not turned on, then only the component store is updated.
As for the IIS extensions, these use MSI and there is no concept of a component store. It works the same way it always have been. I will write about the MSIs in a separate blog.