As you can imagine, we get all sorts of calls in CSS regarding different things in Windows. Because I mostly am asked questions about servicing the OS, one question that popped up a couple of times this week prompted me to write this entry.
The question is "How many fixe(s) have been released for <insert Windows OS> since <insert date>?"
Usually this has to do with a new build process being enacted on the part of the customer and is used as a benchmark for determining overall build times. I understand the idea of the question but I wanted to provide why Microsoft engineers will typically give you the answer "It's really hard to tell". The reason for the answer is that there are too many variables in place for this question to have just one answer. For example, let's say you are installing Windows 2008 SP2 as the base image. If all you wanted to know was the number of fixes that have been released from that end marker to your current date, Windows Update (and maybe a reboot or two) will give you that answer. So in a sense, that one is easy to answer.
Where the problem comes in is when you add roles/features/applications to the mix. Specific roles may have updates that apply to them alone and wouldnt appear on the scenario above because the role was not present when the Windows Update scan was run. Additionally, items like the .Net framework may have multiple updates that are chained, meaning that they will not present the next update until some sort of applicability check is satisfied which tells the Windows Update service to present the next update. As you can see, add a role/feature or two and then a few things and the variables become unmanageable in regards to answering the question.
The next question that invariably is asked is "and how many reboots are needed for all of these updates?". Again, this is almost impossible to answer in an easy manner. Restarts for servicing operations are dependant on the author of the component and whether or not they need to do something specific that might require a reboot (such as setting a registry key or starting a service). We attempt to limit the times we reboot as much as possible but they are a fact of life for getting files set up properly on a system. If an update prompts you to reboot your system, you must do that prior to attempting any other servicing operation on the system. Usually we wont even let you attempt another installation without giving you a prompt.
Hope that helps clear up some of the confusion and frustration that occurs when the question is asked.
Number of fixes in service packs:
Windows NT 4.0 SP1 => N/A
Windows NT 4.0 SP2 => N/A
Windows NT 4.0 SP3 => N/A
Windows NT 4.0 SP4 => 706
Windows NT 4.0 SP5 => 245
Windows NT 4.0 SP6 => 275
Windows 2000 SP1 => 262
Windows 2000 SP2 => 587
Windows 2000 SP3 => 1014
Windows 2000 SP4 => 675
Windows 2000 post-SP4 => 510 (I have them all up to 2009)
Windows XP SP1 => 319
Windows XP SP2 => 830
Windows XP SP3 => 1174
Post XP SP3 => Not counted yet
Windows Vista SP1 => 570
Windows Vista SP2 / Windows Server 2008 => 838
Post Vista SP2 => Not counted yet
Btw I miss the days when the list of hotfixes and security updates was a support article instead of an Excel spreadsheet. Please publish service pack KB lists in support articles.
Total number vs total applicable to situation is what I was referring to in the post.
"Where the problem comes in is when you add roles/features/applications to the mix. Specific roles may have updates that apply to them alone and wouldnt appear on the scenario above because the role was not present when the Windows Update scan was run."
This contradicts what you said in this post
"We can do this for files in a patch or by proactively patching for a feature like IIS before you even install the feature."
Fair point, bad wording on my part. We dont proactively service a feature that isnt on the system. So, that is true. However, if you were to install a critical update that referenced a role/feature in its component manifest, that would be staged and allow for the component to be proactively patched.
Ug. So you don't proactively service but you do proactively service sometimes. Ok.
It seems to me that the servicing stack could use some simplification and sorting out. I mean narrow things down some. It's kind of like your on version .85 and you haven't quite got to 1.0 yet. Either proactively patch everything or don't do it at all. I don't really see what the advantage is anyway. When you install a feature or role Windows Update or WSUS will kick in anyway. I guess it would patch say a few hours faster which is good security wise but then be consistent and do it for everything.