none
WSUS - Downloading updates - Computer Slowness

    Question

  • Hi Everyone

    I have recently implemented WSUS and i have found that the computers run at a slow rate when they download new updates from the WSUS Server. I have established this theory when a pattern was emerging with a system process which runs when downloads are being downloaded. I have temporarily put a group policy in place to disable the automatic updates service in xp and the performance on the client computers has improved and running at the expected level. In other words, i have taken WSUS out of play until i can find a way round this. The slowness is affecting all computers, and is not dependent on their specifications.

    I am having problems with the interval in which the computers check in and download updates. You can set an interval between 1 and 22 hours in the group policy. However this isn't consistent as if a computer is switched off during this time and then powered on, the client computer will check for updates and download any new ones available.

    It would be ideal to be able to configure a time for downloading updates and in which case, i could set the updates to download out of hours at a specific time, set the group policy to install updates a few hours after the download and use power management server software (which we have and are using) to power down the computers later in the evening. I have set a policy to remove the shutdown options, and therefore the users can only log off.

    Does anyone know a way that i can set a time for download, or a better method of managing this problem?

    I am aware that their is software out there which enhances WSUS, but if anyone is aware of how i can add a download time, that would be great.

    Kind regards

    Matthew

    Wednesday, July 31, 2013 10:42 AM

Answers

  • We have about 150 computers. I initially added a separate WSUS policy defining a different time and day for install on each departmental OU, but with the same interval.

    But installation times are irrelevant, because first the update installation files must be downloaded to the client before they can be scheduled. More significantly, the installation time does not determine when udpates are downloaded, but exactly the opposite -- when updates are downloaded determines when they can be scheduled for installation (in compliance with the policy guidelines).

    So if you had 150 computers all trying to download updates at the same time, that could be the problem itself. Consider this: Per my previous post... if you apply a GPO to all 150 clients at the same time making them new WSUS clients, the regular group policy refresh cycle means that over the course of the next 2 hours, every one of those 150 clients is going to launch a detection event against that WSUS server. If you've already approved updates (maybe not,  since at this point it's unknown what is actually needed), those clients will begin downloading the files for the updates that are available for download. This, itself, could be sufficient impact to clog up your network.

    If you had not yet approved updates at that point, but then did approve them shortly thereafter (once they'd all reported in and identified needed updates), a secondary challenge occurs, with respect to when the next detection occurs. Because they all executed detections within that 2 hour window, they all are going to execute detections within another confined six hour window about 18 hours later (unless you've reconfigured the detection interval to be significantly shorter). In any event, you'll still have 150 clients all sucking content down from the WSUS server simultaneously.

    Once the around-the-clock offsets of those detections sort themselves out -- in about 4-5 days as I commented in the previous post, then you'll have those 150 systems spread out across 24 hours, about six systems an hour, or one every 10 minutes, and the performance on both the network and the WSUS server will be invisible.

    As mentioned above by one or two of you, its likely that computers that haven't had updates for a long while, are going to suffer the most as they need to play catch up.

    Yes, this is an additional potential complication. Even for computer that were already up to date (i.e. patched in June), just the nominal volume of July updates, for 150 systems simultaneously downloading, could exhibit such symptoms.

    I will check the BITS as you mentioned above. For now i am going to get the updates to install over the weekend while they catch up, and then reconvene with week days after a couple of weeks.

    Thanks again



    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2013)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.


    Friday, August 02, 2013 2:38 PM
    Moderator

All replies

  • Hi Matthew,

    Indeed you can set time to install or download your updates.

    You have to manage this over the Group Policies Editor and to apply. But I'm sure you already checked over the wuau config to set it downloading silently and to schedule the install at time computers are not that used.

    Can you copy us your GPO settings as we could see how to improve it ?

    TiGrOu.

    Wednesday, July 31, 2013 11:13 AM
  • Hi Tigrou, Thanks for your reply, please see below

    Policy definitions (ADMX files) retrieved from the local machine.
    Windows Components/Windows Updatehide
    Policy Setting Comment
    Allow Automatic Updates immediate installation Disabled
    Allow non-administrators to receive update notifications Disabled
    Automatic Updates detection frequency Enabled
    Check for updates at the following
    interval (hours): 22
    Policy Setting Comment
    Configure Automatic Updates Enabled
    Configure automatic updating: 4 - Auto download and schedule the install
    The following settings are only required
    and applicable if 4 is selected.
    Scheduled install day: 5 - Every Thursday
    Scheduled install time: 21:00
    Policy Setting Comment
    Delay Restart for scheduled installations Enabled
    Wait the following period before
    proceeding with a scheduled
    restart (minutes): 1
    Policy Setting Comment
    Do not adjust default option to 'Install Updates and Shut Down' in Shut Down Windows dialog box Enabled
    Do not display 'Install Updates and Shut Down' option in Shut Down Windows dialog box Enabled
    No auto-restart with logged on users for scheduled automatic updates installations Disabled
    Re-prompt for restart with scheduled installations Enabled
    Wait the following period before
    prompting again with a scheduled
    restart (minutes): 1
    Policy Setting Comment
    Reschedule Automatic Updates scheduled installations Disabled
    Specify intranet Microsoft update service location Enabled
    Set the intranet update service for detecting updates: http://parrot
    Set the intranet statistics server: http://parrot
    (example: http://IntranetUpd01)

    Wednesday, July 31, 2013 12:34 PM
  • If I quote the GPO settings :

    The exact wait time is determined by using the hours specified here minus zero to twenty percent of the hours specified. For example, if this policy is used to specify a 20 hour detection frequency, then all clients to which this policy is applied will check for updates anywhere between 16 and 20 hours.

    So you need one of your computer to be powered on every 18 and 22 hours to have it check updates.
    But this means also that the first day it will check between 6:00pm and 10:00pm for example, the day after between 4:00pm and 8:00pm, etc.

    I don't know what sets the first timeline (the GPO creation, the GPO last change or the DC replication) but you will always have it to run during working hours because of the 20% detection frequency.

    But I think the major problem here is the amount of update you need to download the first time.
    Indeed once all your computers will be up to date, you won't have that much powerloss every scheduled downloaded time.

    TiGrOu.

    Wednesday, July 31, 2013 1:36 PM
  • I have recently implemented WSUS and i have found that the computers run at a slow rate when they download new updates from the WSUS Server.

    And how many client systems are attempting to download updates from the WSUS server at one time?

    Are these clients also trying to obtain files concurrently with the WSUS server downloading files from Microsoft?

    (Both questions can be strongly hinted at by telling us how many updates you have actually approved at this time.)

    I am having problems with the interval in which the computers check in and download updates. You can set an interval between 1 and 22 hours in the group policy. However this isn't consistent as if a computer is switched off during this time and then powered on, the client computer will check for updates and download any new ones available.

    Correct. This is by design and exactly how Windows Update has worked for 15 years. Nothing different just because a WSUS server is involved. If the scheduled installation event is missed because the system was powered off, it will perform the detection at the next power-on cycle. Reducing the client detection interval will actually increase the likelihood of this occuring. If your organizational practice is to power off systems overnight, then you should leave the detection interval set to the default of 22 hours.

    NOTE: The detection event uses almost no resources at all under normal operation, except when you have an organization full of client systems that have never previously had a managed patch environment. In that case, you've probably got dozens of clients missing dozens of updates, and they've got a lot of work to do to catch up. I would not loose a lot of sleep over the fact that some of your systems will perform a detection at power-on because they had been powered off and missed a scheduled detection event. This is by-design behavior and is not a performance-related factor in the normal operation of a WSUS environment.

    It would be ideal to be able to configure a time for downloading updates

    You can manage the bandwidth utilization of the clients by configuring the Background Intelligent Transfer Service (BITS) via Group Policy. This is discussed in the WSUS Technical Reference Guide: Improve WSUS Download Performance with BITS.

    i could set the updates to download out of hours at a specific time, set the group policy to install updates a few hours after the download

    I would point out that this is a very risky plan. By constraining the time of day when updates can be downloaded, and depending upon the number of clients funneled into that constrained time period, it could actually take more than "a few hours" for any given client to download the needed updates. In fact, there is no actual way to know when those downloads have been completed, except by inspecting the logfiles on each individual client, or running a report from WSUS and inspecting every NotInstalled update for each individual client.

    I would suggest that you plan for your installation events to actually occur as much as 2-3 days after you issue update approvals. More or less depending on the number of updates approved and the number of clients needing those updates.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2013)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Wednesday, July 31, 2013 9:10 PM
    Moderator
  • Hi Tigrou

    Thanks for advice. So i take it i cant get it to check for updates after 6 every day?

    Thursday, August 01, 2013 12:57 PM
  • Hi Lawrence. Thanks for your reply. We have about 150 computers. I initially added a separate WSUS policy defining a different time and day for install on each departmental OU, but with the same interval.

    As mentioned above by one or two of you, its likely that computers that haven't had updates for a long while, are going to suffer the most as they need to play catch up.

    I will check the BITS as you mentioned above. For now i am going to get the updates to install over the weekend while they catch up, and then reconvene with week days after a couple of weeks.

    Thanks again

    Thursday, August 01, 2013 1:16 PM
  • If I quote the GPO settings :

    The exact wait time is determined by using the hours specified here minus zero to twenty percent of the hours specified. For example, if this policy is used to specify a 20 hour detection frequency, then all clients to which this policy is applied will check for updates anywhere between 16 and 20 hours.

    So you need one of your computer to be powered on every 18 and 22 hours to have it check updates.

    Clarification... it is not necessary to have the system powered on every 18-22 hours. If a previously scheduled detection event is missed, it will run when the system powers on. This is built into the Windows Update Agent and is not configurable.

    But this means also that the first day it will check between 6:00pm and 10:00pm for example, the day after between 4:00pm and 8:00pm, etc.

    While roughly an approximation of what will happen, it's not quite this simple. The next synchronization event is calculated at the end of a completed one, and each new scheduled time uses a random offset.

    Ergo, if the detection interval is 20 hours and the initial detection occurs at 6pm, the next detection will occur at specified time (this is logged) between 10am and 2pm the next day.

    After that detection is completed, a new detection event is calculated with a new offset value, and that detection could occur anytime between 2am (16 hours after 10am) and 10am (20 hours after 2pm). As you can see the window is significantly larger on the second day (8 hours).

    By the third day the window will be almost the entire day (16 hours), so it's functionally impossible to predict, or describe, when subsequent detections will occur. The only thing that is known is that it will occur between 16 and 20 hours after the completion of the current detection event.

    It's entirely probable in this scenario that several clients will actually complete two detections on the same calendar day (if left powered on) at least once a week.

    I don't know what sets the first timeline (the GPO creation, the GPO last change or the DC replication) but you will always have it to run during working hours because of the 20% detection frequency.

    The initial detection event for purposes of a WSUS client is the time that the Group Policy is applied and the UseWUServer value is flipped from FALSE to TRUE.

    However, you cannot say that the detection will always run during working hours, unless the detection event is set to 8 hours or less. Also be cautious of setting the value too low. A value of 1 hour with server-side targeting is quite problematic, and a value of less than 12 hours when machines are powered off overnight will result in all clients performing detections during power-up every morning, and the value of around-the-clock detections that are designed into the agent will be completely lost.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2013)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.


    Friday, August 02, 2013 2:13 PM
    Moderator
  • We have about 150 computers. I initially added a separate WSUS policy defining a different time and day for install on each departmental OU, but with the same interval.

    But installation times are irrelevant, because first the update installation files must be downloaded to the client before they can be scheduled. More significantly, the installation time does not determine when udpates are downloaded, but exactly the opposite -- when updates are downloaded determines when they can be scheduled for installation (in compliance with the policy guidelines).

    So if you had 150 computers all trying to download updates at the same time, that could be the problem itself. Consider this: Per my previous post... if you apply a GPO to all 150 clients at the same time making them new WSUS clients, the regular group policy refresh cycle means that over the course of the next 2 hours, every one of those 150 clients is going to launch a detection event against that WSUS server. If you've already approved updates (maybe not,  since at this point it's unknown what is actually needed), those clients will begin downloading the files for the updates that are available for download. This, itself, could be sufficient impact to clog up your network.

    If you had not yet approved updates at that point, but then did approve them shortly thereafter (once they'd all reported in and identified needed updates), a secondary challenge occurs, with respect to when the next detection occurs. Because they all executed detections within that 2 hour window, they all are going to execute detections within another confined six hour window about 18 hours later (unless you've reconfigured the detection interval to be significantly shorter). In any event, you'll still have 150 clients all sucking content down from the WSUS server simultaneously.

    Once the around-the-clock offsets of those detections sort themselves out -- in about 4-5 days as I commented in the previous post, then you'll have those 150 systems spread out across 24 hours, about six systems an hour, or one every 10 minutes, and the performance on both the network and the WSUS server will be invisible.

    As mentioned above by one or two of you, its likely that computers that haven't had updates for a long while, are going to suffer the most as they need to play catch up.

    Yes, this is an additional potential complication. Even for computer that were already up to date (i.e. patched in June), just the nominal volume of July updates, for 150 systems simultaneously downloading, could exhibit such symptoms.

    I will check the BITS as you mentioned above. For now i am going to get the updates to install over the weekend while they catch up, and then reconvene with week days after a couple of weeks.

    Thanks again



    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2013)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.


    Friday, August 02, 2013 2:38 PM
    Moderator