I wanted to do a multi-part blog from a high level on how servicing in Windows works. The majority of this will apply to Vista, Win7, 2008 and 2008R2, however there are some things that happen in Win7/R2 that do not happen in Vista/2008. When appropriate, I’ll try to call those out.
So first, a few of the basics. What is servicing? Servicing is the act of installing a role, feature, service pack or windows update against a Windows OS. Most of the time servicing is done in an online state. In this case, online means that the operating system is up and running when a change is made. Online servicing is what most people do and is usually done via Windows Update or double clicking a downloaded update. There is also an offline state. Offline, of course, means that the installation is happening against a non-running version of Windows. This is what a lot of larger corporations and OEMs do with their image files, they mount them with IMAGEX or DISM and then install hotfixes or other updates against those images to reduce their patch time when the image is rolled into production. The reason this distinction is important is because certain operations cannot be done offline. Namely, service pack installations. It’s a request we get all the time and it cannot be done. There are several reasons for this but I wont go into them here, just take it from me, you cant do it 🙂
Now that we have OS state out of the way, let’s talk a little bit about the various servicing components and what they’re actually there for:
- The component store: To us, this is the \Windows\winsxs directory. Think of this as a coorelation to having a flat of the OS on your system. It takes up the most space because its what holds all of the payloads for installing the various binaries on a system. Thats also why it is such a large directory. Ever wonder why you are no longer prompted for media in Vista and higher operating systems? It’s because of this directory. This directory also holds previous versions of binaries that have been updated on a system, another reason for folder growth.
- The package store: This is the \Windows\servicing\packages directory. This holds the component packages that allow Windows to know what to install and where to install it to. Packages are going to be .mum files and will have a package manifest that defines what payloads it carries. Those payloads are then moved to the component store for reflection back to the file system. Packages themselves have states, just like the OS does. Packages can have several states but the three main ones to be concerned about are:
- Installed: As you can guess, this means that the payload for a package is installed on the file system and is active. This is the state of many system files.
- Staged: Staged means that the package is on the file system, but is not being actively loaded. This is the state of many roles/features on a system when you first install Windows. We use this state in a few ways, but the most common way people see this is via installable roles/features. When a role/feature isnt active (let’s say the Hyper-V role on a newly installed server), that role is in a staged state. You can see it in server manager by noticing that the check box isnt checked. Checking the check box to install the feature will start the process of moving its binaries from a staged to an installed state. One of the other nice things about servicing mechanisms in Windows now is that we can actively stage payloads to resolve security issues before the role or feature is ever installed, this helps to alleviate security problems before they occur.
- Absent: Absent means that the package or component isnt installed on the system. This state is typically queried to make sure that we arent attempting to install something for a binary that isnt on the machine.
- The registry: Most of the registry information for the servicing operations is held in the following key tree: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing. I plan on writing some information about the registry in a later post. Basically we hold information here about package states, what package is “winning” and what should be installed on the OS. We also have information here that allows us to know what to do on a reboot.
So, those are the three big moving parts. I’ll break them down more as this series progresses, but I wanted to start with this. We’ll look at whats held in each of these parts over the next couple of weeks and then walkthrough a package installation.