Won Yoo's Blog : Servicing

Vista/Windows Server 2008 Service Pack 2 (SP2)

wonyoo — Tue, 10 Feb 2009 05:12:00 GMT

In December 2008, Vista/Windows Server 2008 SP2 beta was made public. Yes, it is the first service pack for Windows Server 2008, but it is named SP2 since Windows Server 2008 RTM is really Vista SP1. In this blog post, I will high light some of the key changes for IIS 7.0 in SP2. (For more information on SP2 in general, here is the official SP2 site.)

Request Filtering Update

The request filter is now updated to include the following features:

Requests can be blocked based on query string sequences.
Rules can be scoped by the file extension in the request.
It is possible to declare specific URLs that are exempt from filtering.

These updates bring the Request Filter to feature parity with UrlScan 3.1.

Application pool identity.

SP2 introduces a new and temporary account called appPool identity for running application pools. On the local machine, this virtual account behaves just like a local user account, making it more secure than NETWORK SERVICE by providing further isolation between application pools. On the network (ie. accessing remote resources), it behaves like NETWORK SERVICE by assuming the machine's identity.

Custom errors are delegate-able.

This is something that shared hosters have been asking for since Windows Server 2008 RTM. With SP2, custom errors are delegation safe by allowing relative paths.

In addition to above, there are several bug fixes, including all the QFEs that we have done since Windows Server 2008 RTM.

SP2 beta can be downloaded from:

ISO for Windows Server 2008 x86/x64/ia64 and Windows Vista x86/x64
x86 for Windows Server 2008 and Windows Vista x86
x64 for Windows Server 2008 and Windows Vista x64
IA64 for Windows Server 2008 ia64

IIS Extensions and servicing

wonyoo — Sat, 26 Jul 2008 08:33:00 GMT

This week, IIS team has released two servicing patches for the following IIS Extensions:

FTP for IIS 7.0 (KB955136)

WebDAV for IIS 7.0 (KB955137)

They are the first servicing releases that the IIS team has done for IIS Extensions and I wanted to take this time to explain how we plan on servicing IIS Extensions and highlight some of the key differences between the Windows OS components servicing and IIS Extensions servicing.

Deployment technology: I have written a few blogs about CBS (component based servicing). CBS was first introduced in Windows Vista and for both Windows Vista and Windows Server 2008, CBS is how operating components, including IIS, are serviced. For IIS Extensions, the deployment technology is MSI (Microsoft Installer) which is the most common way of installing applications on Windows OSes. An update to a MSI is done via MSP (Microsoft Installer Patch) and the IIS Extension servicing releases are packaged in MSPs.

Scope and frequency: The servicing Hotfixes (also sometimes referred as QFEs - Quick Fix Engineering) for operating systems are targeted in that one Hotfix addresses one specific bug. Also, because the scope is small, the turn-around time is relatively quick, depending on the priority and the severity of the bug and the associated SLA (Service Level Agreement). With IIS Extension servicing, as you may have noticed from the KB articles for FTP and WebDAV, the MSPs may contain one or more bug fixes. Naturally, the frequency of IIS Extension servicing releases will vary based on the priority and the severity of the bugs and the scope of the release, determined both by the number of bug fixes and the complexities.

Distribution: Typically, the OS Hotfixes are made available to customers who contact the Microsoft support team. As noted above, the Hotfixes, by definition, address very specific and targeted problems. Given this nature, most Hotfixes are not applicable to every user of Windows. There are exceptions, such as security fixes, and in those situations, we make the bug fixes available to the general public. For IIS Extension servicing releases, they are made publicly at Microsoft Download Center.

Servicing via CBS (component based servicing)

wonyoo — Sun, 22 Jun 2008 23:49:00 GMT

In Vista and Windows Server 2008, the operating system is made up of components. In a simplest sense, a component is a small grouping of files based on a feature area, functionality, and reusability. A manifest defines how the files are grouped in a component and largely, this is something that each product group at Microsoft has defined for their own product.

Using IIS as an example, when certain IIS role services are installed or uninstalled, you are effectively installing or uninstalling the corresponding components. Note, however, that there is no one-to-one relationship between a role and a component. A role service may consist of several components.

Having said above, the when it comes to servicing, a component is the smallest unit of measure and this creates an interesting patching behavior. As mentioned above, a component may contain several files. So, even if a fix for a particular bug is localized to one file, if the file belongs to a component that consists of other files, the patch will contain all files in the component. All files, regardless of whether they are changed or not, are built, their version numbers incremented, and packaged in the hotfix. When the hotfix is applied, the component in the component store is updated, and all files included in the component are updated on the file system. In a KB article that accompanies the hotfix for Vista and Windows Server 2008, you will notice that there is a section to document the list of included files in the hotfix and another section to document which file is actually changed.

Lowering administration overhead with granular servicing of IIS modules (Part 1)

wonyoo — Fri, 14 Mar 2008 16:46:00 GMT

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.