First, I appreciate all of you who actually take the time to read my blog. Secondly, my last post generated some interesting comments that I thought would make a pretty cool post in itself, so I thought I would answer some of them here.
1. In general as a user, I also hate how Vista/Windows 7 has the "Please wait while Windows configures updates" screen with 3 steps that slows down logoff and the next logon after installing any update/hotfix. If XP doesn't have it, for any reason whatsoever (stability/reliable servicing), I see no reason why the "upgraded" OSes should make users wait and I don't care why. Why can't it do whatever I/O operations it does using low priority I/O introduced with Vista? After service packs or bigger updates like feature pack for wireless, TV pack the waiting time increases even more.
--I say: The reason that this happens is because the process is a lot more thorough than update.exe was. When an update attempts to install on a system, we do applicability checks against the component store to see if the update applies, is already installed, or isn’t needed.
2. Installing updates/small hotfixes is also slow because after double-clicking the MSU, it "searches" for quite a long time before applying the update.
--I say: What is going on there is we're checking the package to make sure its complete and pulling down any deltas that might be needed for the fix to your \SoftwareDistribution folder. Deltas are smaller packages that might be needed for the update to work properly.
3. The error given when an update does not apply and when it is already installed is the same (...."does not apply to your system") ??! when it should be different and clear (you can't install this again as this is already installed or it does not apply only when it does not apply).
--I say: Excellent feedback and I agree. This is changing in the WUSA implementation for Windows 7. Error handling will now display the proper message (such as "Already installed", "Not needed", "and doesn’t apply", etc.)
4. Windows Vista and Server 2008 updates are numbered the same way (Windows6.0___). I understand the 2 OSes are serviced simultaneously and share the same kernel etc but updates' numbering should be differentiated so users can figure out what to install on what.
--I say: Windows 2008 and Vista SP1 are the same codebase. There is differentiation for the service packs and major update releases that apply based on OS version. Some updates apply to both though. I actually think we do a pretty good job with this in the documentation.
5. Some updates (especially Ultimate Extras) are delivered as CAB files making it extremely difficult for end users to install them. (WUSA or PkgMgr).
--I say: I agree with you here. I am not aware of any changes but I will note this.
6. Sometimes after installing some updates using PkgMgr to install updates to Windows components (especially 2 updates that require reboots one after the other without rebooting), my Windows Installation and Servicing Store gets corrupt and Add or Remove Windows components list becomes empty. I've to use System Restore to revert and then if I install again, it succeeds without any error.
--I say: If you have an update that pends a reboot, please, reboot the machine. Because of the way the servicing stack works, we need to flush out information that is pertinent to that updates installation first before we can do additional servicing. This can, and often does, lead to corruption. You cannot QCHAIN updates like you could in the past.
7. Give me back my /nobackup switch to save disk space as I never uninstall updates.
--I say: I understand the need for space reclaiming and I promised in the comments of another post to bring this up internally. I will come through on the promise but can’t tell you what will happen as an end result.
Thanks again for all the comments, keep them coming.
1. Well, performance of this totally sucks (less slow on Windows 7 though). With just a handful of test updates during the Windows 7 beta, users never got to experience this drawback of Windows 7 which is so much slower on Vista too.
2. "Searching" before the update is applied takes as long as 1 min on some of my machines.
4. Name updates depending on the product(s) they apply to. If they apply to both, name them Windows6.0, if only the client, name them WindowsClient6.0 or 6.1, so automatically the rest will be for server or vice versa. The KB articles sometimes mention updates for both products but many times even after downloading the correct version for the cardinal point, "the update does not apply to the system".
6. I say: WTH? How then does Windows Update manage to install them all at once? What to do if I have to install lots of security updates after a clean Vista+SP1+SP2 install? Reboot after each update? Even with the /norestart switch, I'd ended up corrupting the store as a result of which my Windows components list becomes empty and further updates "install successfully" yet no files are actually updated/installed.
Installing updates is no longer as quick and I say not even as reliable as Update Installer (Update.exe). MSI/MSP is also quite reliable and fast. MSUs aren't. There's too much of (unnecessary and excessive IMO) I/O reads and writes when installing NT 6 updates and this is evident from the task manager, the constantly blinking LED of my HDD or the sheer size of WinSxS and naming complexity of the contents. The servicing mechanism is one of the reasons I chose to stay with XP for quite some time.
Points taken, and I appreciate the feedback. A lot of the servicing mechanisms are not going to change moving into Win7 and forward, but I do think that we're looking more closely at improving the mechanisms that exist. This, combined with good feedback like this, will hopefully get us to a point where everyone is happy.
It's a great blog! Your blog make me clear to understand servicing. Thanks :)
Sankim, thank you....glad you're getting something out of the blog :)
joscon wrote: "Because of the way the servicing stack works, we need to flush out information that is pertinent to that updates installation first before we can do additional servicing. This can, and often does, lead to corruption. You cannot QCHAIN updates like you could in the past."
This is progress?!?
First, undesired behavior the user can reasonable be predicted to perform (i.e., deferring a reboot) should *NEVER* lead to corruption. You want to throw up a message saying "Can't run more updates until you reboot", okay, fine. But corruption is simply *not* an acceptable outcome for this scenario.
Second, the batch update functionality provided by QCHAIN was tremendously useful. If the new servicing stack is so much improved, why are we loosing functionality?
Deferring a reboot is not what is causing the corruption in this case, its attempting to force in other updates when another update has an operation pending. When this happens, you have mechanisms in the stack that are waiting to do something (registry, files, whatever) and if they arent done in order, you can hit something like this.
QCHAIN was useful for the old servicing mechanisms, which were merely a matter of replacing an old file with a new one. While that worked a lot of the time, a lot of the time it didnt. We had numerous calls due to files being in use or caught up in a AV scan and they werent replaced properly.
The result in either case is the same...a noboot situation. The method of recovery is a little different now is the main difference.
joscon wrote: "Deferring a reboot is not what is causing the corruption in this case, its attempting to force in other updates when another update has an operation pending."
Whatever. Corruption is *still* not an acceptable outcome. If installing an update is going to corrupt things, the update should stop and say "There's another update that isn't done installing yet. You have to finish that one before I can start." It shouldn't proceed to trash the system.
I'll have to take your word for it on QCHAIN not always working before, either... although that doesn't really make me feel any better. :-(
I get what you're saying. Corruption in this case isnt the same as say disk corruption. When we speak about servicing stack corruption, we're speaking about the fact that something is causing the stack to not finish an operation. It could be something really bad (disk or file system related) or it could be something we can recover from easily with a few commands.
I totally understand your point though, no one likes corruption, especially when it comes to installing an update. That's why I started the blog, to help take some of the guesswork out of what needs to happen so that bad things dont happen <G>
"--I say: If you have an update that pends a reboot, please, reboot the machine. Because of the way the servicing stack works, we need to flush out information that is pertinent to that updates installation first before we can do additional servicing.
This can, and often does, lead to corruption. You cannot QCHAIN updates like you could in the past."
Given this, would you care to comment on the Group Policy setting NoAutoRebootWithLoggedOnUsers?
Does enabling this policy setting potentially invite servicing stack corruption?
Good question Drew, but no, that policy wouldnt invite additional corruption. The stack and WU work together, so there "shouldnt" be a time when an update which required a reboot wasnt satisfied before WU presented new updates.
Typically, you'll get a notification in WU that a reboot is pending before new updates can be installed, or something to that affect.
On chaining: I think it probably has a lot to do with PkgMgr vs WUSA.