Addressing some comments given so far....

re: Addressing some comments given so far....

Yuhong Bao — Sun, 19 May 2013 05:47:45 GMT

On chaining: I think it probably has a lot to do with PkgMgr vs WUSA.

re: Addressing some comments given so far....

Drewfus — Thu, 17 Feb 2011 23:09:57 GMT

Thanks Joseph.

re: Addressing some comments given so far....

joscon [Microsoft] — Thu, 17 Feb 2011 12:15:09 GMT

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.

re: Addressing some comments given so far....

Drewfus — Thu, 17 Feb 2011 05:00:31 GMT

"--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?

re: Addressing some comments given so far....

joscon [Microsoft] — Thu, 13 Aug 2009 02:28:06 GMT

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>

re: Addressing some comments given so far....

Ben Scott — Wed, 12 Aug 2009 20:29:18 GMT

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. :-(

re: Addressing some comments given so far....

joscon [Microsoft] — Wed, 12 Aug 2009 04:12:15 GMT

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.

re: Addressing some comments given so far....

Ben Scott — Tue, 11 Aug 2009 17:01:55 GMT

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?

re: Addressing some comments given so far....

joscon [Microsoft] — Wed, 22 Jul 2009 19:09:25 GMT

Sankim, thank you....glad you're getting something out of the blog :)

re: Addressing some comments given so far....

Sang Wok Kim_ — Tue, 21 Jul 2009 17:20:32 GMT

It's a great blog! Your blog make me clear to understand servicing. Thanks :)