> "VJ" <VJ[ at ]discussions.microsoft.com> wrote in message
> news:7D695959-7F66-4C67-8B9A-B3BDFF3F57ED[ at ]microsoft.com...
> > We have a Policy that sets the updates to install [ at ] 4am every morning well
> > after they synchronize to the WSUS server. The problem is most of the
> > clients are reporting they have downloaded the updates but have not
> > installed
> > them.
>
> Part of this can be misunderstanding the entire end-to-end process of WSUS
> update deployment.
>
> The end-to-end process is such:
>
> [1] The WSUS Server synchronizes at specified time(s) throughout the day,
> plus/minus a small offset to ensure servers on the same sync schedule are
> not synchronizing simultaneously.
>
> [2] The WSUS =clients= synchronize (detect/report) at random times
> throughout the day. By default this is every 22 hours (minus a random offset
> of 1-20%), effectively creating a rolling synchronization schedule for
> clients intended to ensure that the client load is evenly spread out around
> the clock.
>
> [3] The WSUS clients download, using BITS. BITS is a background,
> bandwidth-throttled service to download files based on *available/unused*
> bandwidth. The availability of this bandwidth is measured at each client's
> LAN interface, and is dependent on the utilization of that specific
> interface. On a client connected via switch, this would be based on the
> client's actual utilization of the switched bandwidth; however, on a client
> connected via HUB, this would be bsaed on the segment's shared bandwidth
> utilization, and in a highly utilized hub-based segment, could result in
> extremly low throughput for a particular client.
>
> [3] The WSUS clients =install= at a specified time, once-per-week, or
> once-per-day, by default this is "EveryDay-3am". In order for this
> installation to happen, the update must have been fully downloaded (and
> scheduled) prior to the actual scheduled installation time. Thus, it's quite
> common that what you've experienced is that a client executed a normal
> detection at 2am, initiated downloads, but the download did not complete
> prior to 3am, thus missing the scheduled installation.
>
> > Some of the logs mention something that some security updates for
> > office will be installed once the Administrator logs in.
>
> Another reason this might happen is that you *intend* for the client to be
> configured with AUOptions='4' and a Scheduled Install time of EveryDay-3am,
> but the policy has not properly applied, or the policy has been
> misconfigured, or there are multiple police objects with conflicting
> configurations -- and the client is actually configured with AUOptions='3',
> which prevents an automated scheduled installation.
>
> Or, if the client is still pending a reboot from a previous update
> installation, ALL subsequent installations will be scheduled as
> "administrator-required" activities, rather than scheduled at the regular
> installation time. In this case the "administrator-required" activity is to
> reboot the system, so that subsequent update installations can be
> performed/scheduled.
>
> I've also seen installations missed, with great wonderment by admins,
> because the PCs were powered off. Contrary to great fantasy-based desires,
> the client system must be powered on in order to install updates at the
> scheduled time. I presume this is not the case with your situation, but
> since you are instructing your users to "reboot... before leaving", you
> should ensure that they're not actually shutting the systems down, or that
> something is interfering with the 'reboot' causing to hang in a
> 'shutting-down' status.
>
> Personally, I would teach the users how to =LOGOFF= the system, which will
> accomplish the same desired results AND ensure that the system remains
> powered on for necessary maintenance activities.
>
>
> > Not sure what else to look for.
> > I've recently setup a new client to test the synchronization and will
> > update with results.
>
> All details surrounding the entire state of the client, and activites
> occuring during the scheduled installation event are captured in the
> %windir%\WindowsUpdate.log. I would suggest a thorough review of the
> WindowsUpdate.log from a selected client displaying this behavior. Post the
> most recent detect and installation event entries if you'd like assistance
> interpreting the log entries.
>
>
>
>
> --
> Lawrence Garvin, M.S., MCITP(x2), MCTS(x5), MCP(x7), MCBMSP
> Principal/CTO, Onsite Technology Solutions, Houston, Texas
> Microsoft MVP - Software Distribution (2005-2009)
>
> MS WSUS Website:
http://www.microsoft.com/wsus> My Websites:
http://www.onsitechsolutions.com;>
http://wsusinfo.onsitechsolutions.com> My MVP Profile:
http://mvp.support.microsoft.com/profile/Lawrence.Garvin>
>