An engineer on my team, Jim Collins, worked on this blog entry and I know its something that we see a lot of questions on here internally. Enjoy, and thanks Jim!
I'd like to talk about Multi branching support for Windows component based servicing. To start let's define some terms that I will be using extensively during this blog.
General Distribution Release (GDR) - GDR updates can be found on Windows update and come in the form of Security Updates, Feature Packs, Update roll-ups, Drivers, and Critical updates. These are released on Windows update so that they are available to a wide audience and go through extensive testing.
Limited Distribution Release (LDR) - LDR updates are created for specific issues that only a fraction of users may encounter. Because of this they do not go through as extensive testing as GDR updates.
Quick Fix Engineering (QFE) - QFE's are synonymous to LDR updates. In previous version of Windows, we used the term QFE to describe these types of updates. In current versions of Windows, we use the term LDR. Expect to hear both terms used interchangeably.
When you install Windows all the files on the system are on the GDR branch. If patching is done via Windows update, Microsoft Update and/or WSUS, then you will always remain on the GDR branch. Some KB articles have hotfixes that are not distributed via Windows update and are only packaged with LDR versions of the files to be updated. When an LDR version of a fix is installed, it will move the files updated to the LDR branch and these files will remain on the LDR branch until the next Service Pack is installed.
Note: When talking about the GDR and LDR branches we are speaking on the file level, not the OS level.
Note: All patches distributed via Windows update are considered dual branch updates; they contain both the GDR and LDR versions of the files.
Note: Service Packs contain only GDR branch versions of files. So installing a Service Pack will put all your files back on the GDR branch.
I hope that that clears up what branching is. Now let's talk about how to tell what branch you are on for a specific file.
If you pull up the listing of files for a Windows Update available for Windows 7 and Windows Server 2008 R2, you may see a listing that looks like the following:
Windows7 and Windows Server 2008 R2
For Windows Vista and Windows Server 2008 installations, the KB file listing might look like this:
Windows Vista SP1 and Windows Server 2008 SP1
Windows Vista SP2 and Windows Server 2008 SP2
In both cases, the first two numbers represent the product version. Therefore, for the top chart 6.1 refers to Windows 7 or Windows Server 2008 R2 installations. The next four numbers represent the milestone for the version, once again, for the first chart, 7600 represents RTM and 7601 represents SP1. The last group of numbers indicates whether the file is on the GDR or LDR branch. The rule of thumb is if the last group starts with the number 1, you are on GDR branch and if the last group starts with the number 2, you are on the LDR branch.
When a Service Pack is released for Windows, it needs to contain all update packages due to multiple versions of files. One would be for the most current Service Pack level (N) and one for the previous version (N-1). With this in mind, all post Service Pack Windows Updates will contain four versions of the files, when the update applies to both RTM and Service Pack levels.
From here, three attributes determine how a file is updated when applying updates. These are:
· Existence Holder - This attribute gets set when the file is installed and only changes when a milestone update is applied. In the diagram below, the existence holder for an RTM system would be RTMGDR1.0.
· Branch Holder - This attributes determines which branch of an update is applicable. There will always be a winner for this attribute. If a component contributes to this attribute, it will become the holder. In the diagram below, the branch holder for an RTM system would be RTMGDR or RTMLDR.
· Revision Holder - This attribute determines which revision of an update is applicable. This will always be the newest revision of the update on the branch that is the branch holder. In the diagram below, the Revision holder would be the 1.x for RTM updates and 1.x or 2.x for post Service Pack 1 updates.
Note: LDR 5 represents a fix created after SP1, which includes RTM and SP1 files for the fix.
Let's look at the progression of a file when updated with GDR and LDR updates.
For this scenario, three updates are applied to a system (RTMGDR1.1, RTMLDR1.2 and RTMGDR1.4). The order in which the updates are installed is irrelevant. The updates are:
· RTMGDR1.1 - This update was installed and became the Branch holder and Revision holder.
· RTMGDR1.4 - The branch holder remains RTMGDR and since the revision is higher, this becomes the revision holder. Therefore, this is the update that will be present on the machine.
· RTMLDR1.2 - Since this is LDR, it becomes the Branch holder and since the revision of the previous update is higher it keeps that revision, so the update that will be present on the machine is RTMLDR1.4
In this scenario, the file will be RTMLDR1.4.
For the next scenario, let's add RTMLDR1.5 as diagramed below.
Recall, this update was created after Service Pack 1 was released, but it was installed before the Service Pack was installed on the system. In this case, the file would be at RTMLDR1.5. That is straight forward, but what if we install Service Pack 1 after this update is installed?
This is where the GDR N-1, LDR N-1, GDR N, LDR N mentioned earlier comes into play. All windows updates released after a Service Pack will have both RTM files for the update as well as Service Pack 1 files for the update. So the GDR N would be the Service Pack version of the update and the GDR N-1 would be the RTM version of the update.
This would be the only scenario, where a Service Pack install would not change a file back to the GDR branch. Since this fix was released after the Service Pack was released, it will stay on the LDR branch, but update to the Service Pack 1 version of the file. Therefore, in this case, the file will be SP1LDR2.5
I hope this clears up some of the grey areas around branching.