> "Ed Wyche" <none[ at ]none.com> wrote in message
> news:87E707F0-BACA-4FCF-A9FF-0516FE79181E[ at ]microsoft.com...
>>I was wondering when the updates actually download to the computer.
>
> Generally they download to the client computer immediately after the
> client computer successfully executes the detection event, and determines
> that there are updates that are needed.
>
>> I have
>> some computer that have long bootup and logins into the domain. I was
>> wondering if the updates are downloaded when the computer first boots up.
>
> Generally, no. On the off chance that a computer was powered down while
> updates were being downloaded, the downloads would be auto-resumed by the
> BITS service, when the BITS service restarts -- which would be shortly
> after the bootup starts, but generally long before a user actually presses
> Ctrl-Alt-Delete to log on.
>
> But, even if they were, BITS activity would not be interfering with other
> normal network activity, since BITS works on a "bandwidth available"
> condition.
>
> In order to further diagnose this situation, you need to isolate whether
> you have [a] a long bootup sequence, [b] a long logon sequence, or [c]
> both which would indicate two separate (but possibly related) issues.
>
> Long bootup sequences are generally symptomatic of one or more of the
> following:
> [a] network delays during the "Network Settings" phase of the bootup
> sequence, which can be the result of defects in DHCP (trying to get an IP
> Address); or
> [b] DNS (trying to locate the IP Address of the DC); or
> [c] AD/GPO (poor response time from the Domain Controller trying to get
> the computer policies); or
> [d] excessive policies being transferred during the "Computer Settings"
> phase of the bootup sequence, or [c] other timeouts caused by services
> failing to start up.
>
> Long logon sequences are generally symptomatic of one or more of the
> following:
> [a] AD (poor response time from the Domain Controller trying to
> authenticate the user; or
> [b] AD/GPO (poor response time from the Domain Controller trying to get
> the user policies); or
> [c] Netlogon (issues with logon scripts -- i.e., commands timing out,
> inefficient scripting); or
> [d] Local Startup (issues with auto-start applications, either
> registry-based or defined in the Startup folder).
>
>
> There is, however, a known issue that relates to a certain combination of
> Office 2003 RTM components and older WUA clients, that resulted in 100%
> CPU utilization in the svchost.exe that manages the Automatic Updates
> service. This issue should be non-existent on WSUS 3 systems; however, it
> has been reported (and still unresolved) in a few cases of WSUS 3 systems.
>
> To isolate this particular issue, set the Automatic Updates service on the
> client to DISABLED and reboot -- with nothing else changed, if the long
> bootup/logon times disappear, it's possible that svchost.exe is the
> culprit.
>
> If you see no change in behavior, then refer back to the typical issues
> known to contribute to this behavior.
>
>
>
> --
> 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>