Compartilhar via

Addressing some comments given so far....

  • Artigo

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.

Comments

  • Anonymous
    January 01, 2003
    Ben 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>

  • Anonymous
    January 01, 2003
    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.

  • Anonymous
    January 01, 2003
    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.

  • Anonymous
    January 01, 2003
    On chaining: I think it probably has a lot to do with PkgMgr vs WUSA.

  • Anonymous
    January 01, 2003
    Sankim, thank you....glad you're getting something out of the blog :)

  • Anonymous
    January 01, 2003
    It's a great blog! Your blog make me clear to understand servicing. Thanks :)

  • Anonymous
    January 01, 2003
    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.

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    August 11, 2009
    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?

  • Anonymous
    August 12, 2009
    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.  :-(

  • Anonymous
    February 16, 2011
    "--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? technet.microsoft.com/.../cc720464(v=ws.10).aspx Does enabling this policy setting potentially invite servicing stack corruption?

  • Anonymous
    February 17, 2011
    Thanks Joseph.