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.
<p>To me it looks quite confusing that you say development (RTM/SP) branches are GDR. But the article is a good starting point anyway. Thanks folks.</p>
<p>Thanks Joseph for Sharing & Jim for writing!!</p>
<p>Could you please increase the size of the images and re-post.</p>
<p>Yeah, I know what you mean (milestone vs. GDR) but its easier to grasp it conceptually this way IMO.</p>
<p>No problem! Selecting the images should open them in a more readable format. Let me know if that doesnt work.</p>
<p>So /b:spxqfe switch present in Hotfix Installer is gone now. :( What was the use and advantage of that switch on legacy Windows?</p>
<p>@xpclient: On legacy operating systems we would sometimes need to force the branching of a file/fix to ensure that it was running the right code. We dont need to do this in current operating environments because of the servicing stack, it knows which branch to be on based on the transaction.</p>
<p>I'd like to uninstall hotfixes that have been superceded.</p>
<p>Say the GDR version was installed, followed by the LDR (by installing the update-bf.mum). Will wusa /uninstall /kb:123 uninstall both the GDR and LDR?</p>
<p>If the hotfix was updated, eg kb001 installed, followed by kb001-v2, what is the good way to uninstall kb001? Thanks.</p>
<p>This is actually two different questions.</p>
<p>The first is the uninstall, this can be done normally via the UI or using WUSA if you prefer.</p>
<p>The second is what happens when the file is uninstalled. The file on the system moves to the "staged" state in the component store, its not removed from the component store. The branch which was not installed (GDR in your example) is already on the file system in the staged state as well.</p>
<p>If you're looking to completely remove the fix from your Windows install, that would need to be done manually. The component store will scavenge itself on it's own though, so this isnt really recommended.</p>
<p>if you really, really want to force LDR branch, please read <a rel="nofollow" target="_new" href="http://social.technet.microsoft.com/wiki/contents/articles/how-to-forcibly-install-the-ldr-branch-from-a-particular-hotfix-package.aspx">social.technet.microsoft.com/.../how-to-forcibly-install-the-ldr-branch-from-a-particular-hotfix-package.aspx</a> (don't do this at home. Er, I meant in production).</p>
<p>I notice when installing hotfixes via WUSA, the installed files have the dates when microsoft created them. However when using DISM or PkgMgr the installed files have 'todays' date.</p>
<p>Was this behavior on purpose?</p>
<p>Have there been requests for DISM or PkgMgr to behave like WUSA with regards to the timestamp on the installed files? It is quite handy to have the timestamps to be 'when they were created at Microsoft'. Thanks.</p>
<p>To be honest, I've never really noticed because we don't use date as a measure of whats installed. The best way to determine what is installed is the version of the binary, not the date. But to answer the other question, no, I haven't requested something like DISM be changed to act like that.</p>
<p>BTW, PKGMGR was deprecated, so I wouldn't use it for anything. I would use DISM.</p>
<p>I saw this too in Vista/7 and in Win8 it seems to be fixed.</p>
<p>@Pronichkin, thanks but I meant an *easy* way. That method is too complex, time consuming and involving too many steps, just like most servicing related operations are post-Vista. Anyways, it's clear that forcing a branch isn't needed any more.</p>