none
WSUS Downstream Server - How to point clients to it

    Question

  • So I have WSUS 3.0 SP2 configured and working great. The server sits in a main office and pushes out updates to the main office as well as 4 other offices connected via T1 connections. All offices are in the same domain but  have their own organizational units. All offices have their own subnets. One of these offices is 100+ users and it really saturates our T1 connection to that office when updates are pushed out. I have configured a downstream server in that office. It appears to be getting all the updates from the upstream server. I'm trying to figure out how to force the clients in that office to get it's updates from the downstream server instead of the main WSUS server.

    Right now, my group policy (specify intranet Microsoft update service location properties) is applied at the domain level and points computers to the main WSUS server. My best idea so far for what I'm trying to do is to stop applying this policy at the domain level and set it up individually for each of our OUs (therefore each office). Is this a fairly common way to handle what I'm trying to do or is there a better way?

    Thanks.
    • Edited by gradster79 Monday, October 12, 2009 5:16 PM spellin
    Monday, October 12, 2009 5:14 PM

Answers

  • > I thought WSUS clients used BITS by default?

    They do! But BITS is somewhat of a misleading entity, as it determines bandwidth availability based on the =LAN= connection of the machine, not the slowest pipe in the entire download path. That's where using Group Policy to configure bandwidth availability (either by throughput, or by time of day) becomes essential. If there's more than a megabit of available bandwidth on the LAN connection (and there always is these days), then BITS will try to use that bandwidth on the WAN connection.

    > A decent amount of our users will shut down their computers at night - meaning they wouldn't get the updates.
    > Management pretty much never backs IT at my shop, so enforcing policies proves to be extremely difficult for
    > IT. I am working on a wake on LAN solution for a separate project that may help me out with WSUS, but it's still
    > several months away from implementation.

    The default configuration of the WUAgent can actually be of some help to you here. If the scheduled installation event is missed overnight (because the PC is powered off), the WUAgent will initiate the installation of those scheduled updates at one minute after the Automatic Updates service restarts at boot time. (This value can be extended to up to 60 minutes, via Group Policy.) You let those users get annoyed enough by those power-on installation/reboot scenarios, and then point out that all they need to do to avoid that inconvenience is leave their machine powered on overnight, and the problem will solve itself. (You can help the scenario by sending a notification when you approve updates for deployment to a particular site.)

    ALSO... note that Windows XP SP2 and later systems support the installation of updates at the SHUTDOWN event, and if the natural practice is to power off machines at the end of the day, then also encourage your users to use the "Install Updates and Shutdown" feature to avoid the inconvenience of installations at power on.

    As for "Management"... I learned a long time ago -- The best way to get Management to support something I wanted, if I couldn't achieve it by simple intelligent logic, was to make "not supporting it" as unpleasant as possible for them. In other words -- your biggest cheerleader for leaving machines powered on, or using "Install Updates and Shutdown" will be inconveniencing the CIO, or staff members who whine and cry to the CIO, when he/they have to sit through morning restarts in order to install updates at power on. Your Excuse: "Uhh... Sorry. That's the behavior of the WUAgent. I can't change it." (They'll never check the documentation to find out that's not entirey true. >;-D


    Lawrence Garvin, M.S., MCITP:EA, MCDBA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2009)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Monday, October 12, 2009 11:31 PM
    Moderator

All replies

  • > The server sits in a main office and pushes out updates

    Just because I always do -- let's clarify here that the WSUS server does not push anything. The Windows Update Agent on each individual client system queries, downloads, and initiates the installation of the updates. The WSUS Server is a *PASSIVE* device in the updating process.


    > One of these offices is 100+ users and it really saturates our T1 connection to that office when updates are pushed out.

    One hundred clients on a T-1 (1.544mb/sec) connection should not saturate that connection when you approve updates unless you've significantly misconfigured the default detection interval for that site. With 100 clients (and the default detection interval of 22 hours), you should be seeing a client load of about 4.5 to 5.7 clients PER HOUR initiating downloads of updates. That's one client every 10-13 minutes. In 10 minutes of download time a client on a T-1 connection should be able to download around 70 megabytes (1.544mb/sec / 8 bits/byte * 60 seconds * 10 minutes = 70.193 MB) -- unless you're pushing Service Packs, or an entire year's worth of updates, saturating the link is unlikely.

    On the other hand, if you had 100 clients with a 2 hour detection, which is 50-60 clients per hour (one client every minute), it would be a piece of cake to saturate a T-1 link!

    My conventional wisdom is that if a site that has > 5kb/sec of bandwidth per PC it should be able to update from a central server across that WAN connection; a site with < 5kb/sec of bandwidth needs a locally-installed replica server. With 100 clients and 1.544mb/sec of bandwidth, you have at least >15kb/sec of bandwidth available to each client, even if every client is downloading simultaneously -- the key here is to time the update approvals (or implement bandwidth restriction policies), so that those downloads do not occur during normal working hours. (Note: In 24 hours, 100 computers on a T-1 connection can still download over 160 Megabytes PER PC -- so even if you are saturating that line, the typical monthly update distribution is measured in mere tens of megabytes -- even on a busy month -- and that saturation won't last for more than a couple of hours.)

    Note also that there's an interrelationship between how frequent the detection interval is and how long it takes to download the content on a fixed-bandwidth link. Using the example above -- with 22 hour detections, it'll take 23-24 hours for all clients to get updated, but only one client at a time will be using bandwidth, and the actual bandwidth consumption will be directly proportional to the bandwidth needed to transfer one set of update files. If you have detections at a much higher rate, all of the clients will know about the updates -- but 100 clients contending for a megabit of bandwidth will take *days* to get the content downloaded -- and saturate the link for the duration.

    So, three considerations here:

    1. Ensure that your detection interval is configured appropriately for the number of clients, bandwidth availability, and actual need of those clients to get updates in a specified time frame. Unless you're distributing FCS updates and need to have them updated within hours of their release, I'd say use the standard default 22 hour detection interval.

    2. If necessary, implement BITS throttling (via Group Policy) to restrict the bandwidth that each of those clients can use so they don't download update content during working hours.

    3. Alternately, approve the update(s) for that site at the end of the day so that the updates are downloaded during overnight hours.


    > My best idea so far for what I'm trying to do is to stop applying this policy at the domain level and set it up individually for each of our OUs (therefore each office).

    Yes, you *should* have policies set up at the OU level, as that would allow you to set up SITE-SPECIFIC Target Groups, and thus approve updates BY SITE, rather than the entire organization at one time. Furthermore, this will allow you to configure a site-appropriate detection interval, as described previously. So, where every 3-4 hours might be practical for a couple hundred clients on a 100mb/sec corporate LAN; it's probably not practical for 100+ clients on a T-1 connection.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2009)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Monday, October 12, 2009 8:57 PM
    Moderator
  • Wow, excellent information Lawrence, thank you.

    Poor use of words on my part using the term push.

    As far as saturating the T1 line, Windows Updates are far from being the only thing going across this pipe. I've got email, voice, file shares, web filtering logs and other various other data going over this pipe as well (even the occasional video conference). It's already fairly saturated as it is, but Windows Updates push it over the top depending on how many patches/what size was released in any given month. I've already got a fairly underutilized Server 2008 box in that office that the WSUS role fits nicely on so I figured it would be an easy solution to this problem as opposed to trying to get more budget for a fatter pipe.

    I have my clients set to check for updates every 4 hours. I have some various reasons for doing this - all of which could be mitigated, but I feel the best solution here is to use a downstream server at that office.

    Wow, apparently I have a huge hole in my WSUS knowledge. I thought WSUS clients used BITS by default? Interesting, I will have to look into this further.

    A decent amount of our users will shut down their computers at night - meaning they wouldn't get the updates. Management pretty much never backs IT at my shop, so enforcing policies proves to be extremely difficult for IT. I am working on a wake on LAN solution for a separate project that may help me out with WSUS, but it's still several months away from implementation.

    Glad to hear my idea about the policies was not far fetched. I'm going to start testing tomorrow. Thanks for the great info.
    Monday, October 12, 2009 9:42 PM
  • > I thought WSUS clients used BITS by default?

    They do! But BITS is somewhat of a misleading entity, as it determines bandwidth availability based on the =LAN= connection of the machine, not the slowest pipe in the entire download path. That's where using Group Policy to configure bandwidth availability (either by throughput, or by time of day) becomes essential. If there's more than a megabit of available bandwidth on the LAN connection (and there always is these days), then BITS will try to use that bandwidth on the WAN connection.

    > A decent amount of our users will shut down their computers at night - meaning they wouldn't get the updates.
    > Management pretty much never backs IT at my shop, so enforcing policies proves to be extremely difficult for
    > IT. I am working on a wake on LAN solution for a separate project that may help me out with WSUS, but it's still
    > several months away from implementation.

    The default configuration of the WUAgent can actually be of some help to you here. If the scheduled installation event is missed overnight (because the PC is powered off), the WUAgent will initiate the installation of those scheduled updates at one minute after the Automatic Updates service restarts at boot time. (This value can be extended to up to 60 minutes, via Group Policy.) You let those users get annoyed enough by those power-on installation/reboot scenarios, and then point out that all they need to do to avoid that inconvenience is leave their machine powered on overnight, and the problem will solve itself. (You can help the scenario by sending a notification when you approve updates for deployment to a particular site.)

    ALSO... note that Windows XP SP2 and later systems support the installation of updates at the SHUTDOWN event, and if the natural practice is to power off machines at the end of the day, then also encourage your users to use the "Install Updates and Shutdown" feature to avoid the inconvenience of installations at power on.

    As for "Management"... I learned a long time ago -- The best way to get Management to support something I wanted, if I couldn't achieve it by simple intelligent logic, was to make "not supporting it" as unpleasant as possible for them. In other words -- your biggest cheerleader for leaving machines powered on, or using "Install Updates and Shutdown" will be inconveniencing the CIO, or staff members who whine and cry to the CIO, when he/they have to sit through morning restarts in order to install updates at power on. Your Excuse: "Uhh... Sorry. That's the behavior of the WUAgent. I can't change it." (They'll never check the documentation to find out that's not entirey true. >;-D


    Lawrence Garvin, M.S., MCITP:EA, MCDBA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2009)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Monday, October 12, 2009 11:31 PM
    Moderator