After reading
the Deployment Guide, one would think that the Pending identifier on the
Status flag would be used frequently, and would therefore make it easy to
identify machines that have an update ready to install, but I have yet to
see 'S=p'
in any WUTRACK.BIN GET requests. The Deployment Guide indicates that perhaps
a GET of WUTRACK.BIN only occurs in these cases (note that pending refers
only to the self update, which is the IU controls,right?):
When does the Automatic Updates client return results that IIS will log?
The Automatic Updates client returns status on the following:
- During Self-update:
self-update pending
- After Self-update:
self-update success/failure
- During Detection :
initialization success/failure
- After Detection:
detection success, detection failure
- After Download: download
success/declined/failure
- After Installation:
installation success/declined/failure
Shouldn't there be a
"Pending Installation" following "After Download"? "After Download" just
tells me that a system has successfully downloaded a particular patch, but I
want to know if a system is ready for installation!
From the microsoft.public.softwareupdatesvcs
newsgroup
I did some checking on this, and found that the pending status is also set
when an exclusive update is installed. An "exclusive" update is of the type
that must be installed by itself, so that even if a client machine detects 4
updates, if one of them is marked as exclusive it will be downloaded and
installed by itself. The install of an exclusive update is not performed by
AU, so when the install starts we can't definitely say that it's successful
(we'll only know that after a reboot) so the pending status is also set in
this situation.
The client does write to the event log when installs are ready, and that was
intended to be the way that network administrators would discover the
pending install of updates. In retrospect, it would probably be easier if
you could see how many machines have pending installs from the pingbacks,
since you are consistently checking the pingback info instead of checking
the event logs on each client machine. I know that reporting is being
redesigned and enhanced for the next version, and hopefully you'll see
improvements like this suggestion.
|
