Sign in
 
HomeWindows Server 2012Windows Server 2008 R2Windows Server 2003LibraryForums
Windows Server TechCenter >
> 
> 
WSUS question

Answered WSUS question

  • Friday, January 04, 2013 5:13 PM
     
     
    Sign In to Vote
    0

    Our office uses WSUS for distributing Microsoft updates.  However, we have a number of remote locations with low-speed connections, but relatively high computer counts, including some servers.  We want to have updates install automatically on a schedule, but we need to schedule the downloads for overnight.  I don't see a way to schedule the downloads in WSUS.  I've seen BITS offered as a solution, but if I understand the concept, it's not a good fit for us.

    I'm considering the following solution and I'd like some feedback.  I'm considering a script that uses the WSUS API's to download the updates and set the NextDetectionTime value in the registry to two days out.  (This should prevent WSUS from downloading updates on its own.)  A GPO would schedule a task to run the script afterhours.  Another GPO would schedule WSUS to do the installs later in the early morning, allowing time for the downloads.

    Any thoughts?

     

All Replies

  • Friday, January 04, 2013 11:53 PM
     
     
    Sign In to Vote
    2
    Do you have downstream WSUS servers at those remote sites?

    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

     
  • Monday, January 07, 2013 12:32 PM
    Moderator
     
     
    Sign In to Vote
    1

    Hi,

    Thank you for the post.

    You might use WSUS to download updates once from the Internet and then distribute those updates to branch offices with downstream servers.

    Regards,

    Nick Gu - MSFT

     
  • Tuesday, January 08, 2013 1:42 PM
     
     
    Sign In to Vote
    0

    No, we don't.  But that is a thought.  We could set them to synchronize with the main WSUS server afterhours.

    Thank you for the idea.

     
  • Tuesday, January 08, 2013 1:44 PM
     
     
    Sign In to Vote
    0

    Don had a similar suggestion.  These are Motor Vehicle Department computers that run an old application that can't accept certain updates, so we'd want the downstream servers to pull from the main WSUS server.

    Thank you.

     
  • Tuesday, January 08, 2013 11:18 PM
    Moderator
     
     Answered
    Sign In to Vote
    0

    Our office uses WSUS for distributing Microsoft updates.  However, we have a number of remote locations with low-speed connections, but relatively high computer counts, including some servers.  We want to have updates install automatically on a schedule, but we need to schedule the downloads for overnight.  I don't see a way to schedule the downloads in WSUS.  I've seen BITS offered as a solution, but if I understand the concept, it's not a good fit for us.

    I'm considering the following solution and I'd like some feedback.  I'm considering a script that uses the WSUS API's to download the updates and set the NextDetectionTime value in the registry to two days out.  (This should prevent WSUS from downloading updates on its own.)  A GPO would schedule a task to run the script afterhours.  Another GPO would schedule WSUS to do the installs later in the early morning, allowing time for the downloads.

    Any thoughts?

    A couple of thoughts...

    First, to Don's point ... remote sites with low-speed connections and high computers counts should have an ONSITE WSUS Replica Server, and it appears from your response to Don that you do not have these -- so this should be your very first objective. Truth is, if you don't have replica WSUS servers, and your remote clients are all trying to update from a central WSUS server -- then NONE of the above ideas will address your issue at all (except to the point that the clients can be configured, via BITS, to only download updates after hours -- which will, most likely, seriously impact the timeliness of update deployments to those systems).

    Second.. a downstream WSUS SERVER downloads installation files for APPROVED updates immediately after synchronization, so Step #1, then, is to schedule your downstream server synchronization times to be just after the end of the business day, so that the files have ALL NIGHT to download. (Note: There is a practical limit to this scenario, as the upstream server experiences significant loads during a replica synchronization, and running multiple replica synchronizations simultaneously has been known to result in downstream server synchronization timeouts, and outright failures.

    Third, the WSUS APIs are not used to download updates to the WSUS SERVER. WSUS sends a request to BITS, and BITS manages the downloads. So, to repeat the previous point, the correct way to manage downloads is by managing BITS. So, Step #2, as previously offered, is to configure BITS so that it STOPS any in-progress downloads at the start of the business day and resumes those downloads after the end of the business day. Likewise, client updates are handed off by the WUAgent to BITS, although invoking a detection event on the client will trigger a download request to be queued for any needed and available updates.

    Fourth, setting the NextDetectionTime identifies (not controls!) when the WUAgent will next check in with AU/WSUS -- whichever the system is configured to use. This value is not absolute, and setting this value via a script will not guarantee that the client detection does not occur prior to that time. I would not recommend trying to manipulate this value to manage a client; the better option would be to set the Windows Update service to Stopped/Manual, and then invoke a call to wuauclt /detectnow in the script, which will start the WU service and launch the detection. Following the completion of all of the requisite activiites (or at the start of the next business day), invoke another script to stop the WU service. (Note: Even this methodology is not foolproof, and examining all the things necessary to make it foolproof is really not an efficient use of anybody's time, IMHO; the better option, again, is to manage bandwidth consumption with BITS.)

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

    • Proposed As Answer by Mallikarjuna YH Wednesday, January 09, 2013 1:21 AM
    •  
     
  • Friday, January 11, 2013 8:07 PM
     
     
    Sign In to Vote
    0

    Thank you for your input.  I really appreciate it.

    My only concern with BITS is the impact it might have on other applications.  I understand it is BACKGROUND intelligent transfer service.  So hopefully, our Sophos anti-virus will be impacted as well, as at times it tends to be an even bigger traffic problem than WSUS.  But it's important our MVD applications won't be affected.  Is it based on the port the traffic uses?

    By the way:  The idea of the API's was to download the updates to the clients, not the server.

     
  • Saturday, February 02, 2013 9:11 PM
    Moderator
     
     
    Sign In to Vote
    0

    My only concern with BITS is the impact it might have on other applications.

    This is definitely something to be aware of; however, in my observations very few applications actually use BITS so the impact may not be as significant as you might thinkg.
    our Sophos anti-virus will be impacted as well, as at times it tends to be an even bigger traffic problem than WSUS.
    You should ask Sophos. :-)
    Is it based on the port the traffic uses?
    It's based solely on the observed package load at the NIC. Which is also significant, because if the client is on a Gigabit connection, and the WAN link is a 256k Frame Relay, one client all by itself can saturate the WAN link. In addition, depending on the version of BITS, the downloads may be single-stream or multi-stream. Threaded operations were added in BITS 3.5 (I think that's when), so those systems can support simultaneous downloads from the BITS queue.
    The idea of the API's was to download the updates to the clients, not the server.
    Okay, but in either event, the WSUS APIs would be of no use. It is not the WSUS server that pushes updates to the client, but rather the Windows Update Agent that pulls updates from WSUS. As such, to initiate a download from the client-side would require scripting/programming against the WUAgent API, not the WSUS API.

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