none
Find size of a WSUS synchronization RRS feed

  • Question

  • Hi,

    One of my clients is running WSUS 3.2 on Windows Server 2003. They had a large download increase last month which I suspect was caused by one of the WSUS synchronizations however I can't see anywhere that shows the size of a sync.

    Is there anyway to find out the size of a WSUS sync? So, for example, if on the 14th Feb one synchronization shows 90 updates can I find out the total size of all the updates for that synchronization? Obviously I can see the updates that were downloaded but I can't find out how big the sync was unless I go through the 100+ updates and try and add them all up (not going to happen).

    Thanks,

    Wednesday, May 4, 2011 1:13 AM

Answers

  • Is there anyway to find out the size of a WSUS sync? So, for example, if on the 14th Feb one synchronization shows 90 updates can I find out the total size of all the updates for that synchronization? Obviously I can see the updates that were downloaded but I can't find out how big the sync was unless I go through the 100+ updates and try and add them all up (not going to happen).

    First, the synchronization event does not download update files, only metadata -- except for updates that are configured with automatic approval rules.

    The list of updates for a synchronization event can be obtained from a Synchronization Results report.

    The file sizes associated with a particular event can be found on a per-update basis from the Updates View. Right click the update, select File Information from the content menu. The only updates that are relevant are those updates that were Auto-Approved during the synchronization event. If the client is auto-approving all Critical and Security updates -- then they should plan for these type of events twice per month (2nd and 4th Tuesday), and perhaps schedule their server synchronization at a time that will minimize the impact of that activity.

    Detailed information on synchronization and download activity can be found in the SoftwareDistribution.Log which is found in %ProgramFiles%\Update Services\Logfiles on the WSUS server.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com

    Wednesday, May 4, 2011 4:18 PM
    Moderator
  • The issue is for Hughesnet Satellite ISP: it is (very) limited for 19 hours/day, but from 2-7am Eastern time there are no limits. So the goal is to limit Downloads to the 2-7am period.

    Aha! This is a piece of cake. :-)

    BITS is expressly designed to do exactly this.

    In Group Policy (or in Local Policy on the WSUS Server), navigate to Computer Configuration | Administrative Templates | Network | Background Intelligent Transfer Service and configure the settings to restrict/allow utilization at the desired times.

    There are two ways you can approach this. You can disable all usage from 7am to 2am, and then use all available bandwidth from 2am to 7am; or you could even place a limit on the utilization from 2am to 7am, and block all utilization at any other time.

     


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Monday, December 19, 2011 12:42 AM
    Moderator

All replies

  • Is there anyway to find out the size of a WSUS sync? So, for example, if on the 14th Feb one synchronization shows 90 updates can I find out the total size of all the updates for that synchronization? Obviously I can see the updates that were downloaded but I can't find out how big the sync was unless I go through the 100+ updates and try and add them all up (not going to happen).

    First, the synchronization event does not download update files, only metadata -- except for updates that are configured with automatic approval rules.

    The list of updates for a synchronization event can be obtained from a Synchronization Results report.

    The file sizes associated with a particular event can be found on a per-update basis from the Updates View. Right click the update, select File Information from the content menu. The only updates that are relevant are those updates that were Auto-Approved during the synchronization event. If the client is auto-approving all Critical and Security updates -- then they should plan for these type of events twice per month (2nd and 4th Tuesday), and perhaps schedule their server synchronization at a time that will minimize the impact of that activity.

    Detailed information on synchronization and download activity can be found in the SoftwareDistribution.Log which is found in %ProgramFiles%\Update Services\Logfiles on the WSUS server.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com

    Wednesday, May 4, 2011 4:18 PM
    Moderator
  • The OP didn't comment so I feel compelled to.

    >The file sizes associated with a particular event can be found on a per-update basis

    If one of the key benefits to WSUS is to be able to control bandwidth used with your ISP, then it would REALLY, REALLY be useful to be able to know in advance how large a Sync Event you have scheduled. Then one can guage not only the size of the download but also the time it might take given whatever ones Mbps is.

    Until MS improves on this, if you Lawrence or anyone knows of a 3rd party method to determine full Synchronization size ("Select All" then "Properties" or some such) I'd like to know about it.

    Saturday, December 17, 2011 5:41 PM
  • if anyone knows of a 3rd party method to determine full Synchronization size ("Select All" then "Properties" or some such) I'd like to know about it.

    the logging/reporting of your proxy or firewall should be able to tell you this (after the fact).
    if you don't have one, you could implement one, there are many options including squid (free).

    also, whilst MS do mention that WSUS...control...bandwidth...., it's the usual carefully-phrased statement which you or I might interpret as "gives me control/flexibility" but it really means "we made it so you only download everything once".. and, that also means "you will download everything that you approve and it will only be downloaded once"

    it isn't "you can predict/forecast/report/manipulate-in-great-detail......"

    FWIW, ConfigMgr doesn't do what you want either. And ConfigMgr is neither cheap nor easy.


    Don
    Saturday, December 17, 2011 9:06 PM
  • If one of the key benefits to WSUS is to be able to control bandwidth used with your ISP, then it would REALLY, REALLY be useful to be able to know in advance how large a Sync Event you have scheduled. Then one can guage not only the size of the download but also the time it might take given whatever ones Mbps is.

    I think you've missed the point.

    The synchronization event does not transfer files. It only transfers metadata. The total volume of data transferred during a synchronization event is measured in kilobytes.

    The download event transfers files. A download event is created in response to the administrators active choice to Approve for Installation one or more selected updates. The file sizes are available in the console for each and every update prior to their approval, thus merely reading the information available in the console should be more than sufficient to determine what the bandwidth utilization will be.

    As for the time it will take -- that cannot be calculated in any circumstance. The amount of time it takes to download an update file is dependent upon the available bandwidth on the Internet link, and the available bandwidth on the network interface of the WSUS server, and how BITS is configured to manage that bandwidth utilization.

    Now, if truly you need to limit the bandwidth utilization on a circuit for a given period of time, the best way to do that is to configure the Background Intelligent Transfer Service (BITS) to only have that bandwidth available for use -- based on kb/sec and hours per day -- and approve the most important updates first, and the lesser important updates if you still have bandwidth available.

    Ultimately, this a fundamental cost of doing business, so I'm having a bit of difficulty grasping the significance of what it takes. Updates are released, you need to install them, you need to download them to do the installation -- it takes what it takes and you cannot control what it will take to get the updates downloaded so that they can be installed. If you don't have enough bandwidth with your ISP to run a WSUS server.... well.... I'm not really sure what to say. :-//


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com

    Saturday, December 17, 2011 10:20 PM
    Moderator
  • >If you don't have enough bandwidth with your ISP to run a WSUS server.... well.... I'm not really sure what to say. :-//

    Lawrence thank you for your comments. The issue is for Hughesnet Satellite ISP: it is (very) limited for 19 hours/day, but from 2-7am Eastern time there are no limits. So the goal is to limit Downloads to the 2-7am period. BTW I know Houston is a big city, but here in the Hill Country west of you some of us have ONLY HN as an ISP option!

    I've misunderstood Synchronizations and managed to blow our bandwidth allotment. When my first Sync occurred after 2am, it only downloaded metadata, no doubt because I have "Download update files to this server only when updates are approved" checked under Update Files and Languages. But when I approved a body of updates yesterday morning, unbeknownst to me WSUS downloaded all the approved updates immediately (and blew our Fair Access Policy bandwidth limitation). I had expected that the download would occur at the next scheduled Sync event--obviously I didn't know how WSUS works.

    Is it correct that if I leave "download only when approved" checked, and then have an Automatic Approval rule in place, that the downloads will occur (only) during the Sync Schedule period? If I assert the Auto-Approval rule, will it begin immediately to download the rest of my updates or will it do so at the next Sync Schedule time?

    The MS worldview appears to assume unlimited bandwidth 24/7 (there is NO way to schedule-restrict MS updates on individual computers) but this is not the case sir!

    Sunday, December 18, 2011 3:03 PM
  • The issue is for Hughesnet Satellite ISP: it is (very) limited for 19 hours/day, but from 2-7am Eastern time there are no limits. So the goal is to limit Downloads to the 2-7am period.

    Aha! This is a piece of cake. :-)

    BITS is expressly designed to do exactly this.

    In Group Policy (or in Local Policy on the WSUS Server), navigate to Computer Configuration | Administrative Templates | Network | Background Intelligent Transfer Service and configure the settings to restrict/allow utilization at the desired times.

    There are two ways you can approach this. You can disable all usage from 7am to 2am, and then use all available bandwidth from 2am to 7am; or you could even place a limit on the utilization from 2am to 7am, and block all utilization at any other time.

     


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Monday, December 19, 2011 12:42 AM
    Moderator
  • Is it correct that if I leave "download only when approved" checked, and then have an Automatic Approval rule in place, that the downloads will occur (only) during the Sync Schedule period?

    The files for those auto-approved updates will be immediately queued for download, but there's no guarantee that they'll complete before the end of your free-use period; on the other hand, it's highly unlikely that regular monthly updates would take more than an hour, with unlimited bandwidth, even on a satellite connection.

    However, combining that with the BITS policy described in the previous post will suspend any pending downloads at 7am, and resume them automatically at 2am the next morning.

    If I assert the Auto-Approval rule, will it begin immediately to download the rest of my updates or will it do so at the next Sync Schedule time?

    When you configure an Auto-Approval rule, the automatic approvals are only applied to subsequently synchronized updates, they are not applied to existing updates. If you invoke the "Run Rule" option, the downloads will be queued and initiated immediately -- unless you have a BITS policy in place that blocks those downloads until 2am.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Monday, December 19, 2011 12:47 AM
    Moderator
  • Thanks Lawrence for the tip about BITS--I've not seen any discussions about this before so your post is welcome indeed.

    As for my "Auto-Approval" question, I already have some 1200 updates' worth of metadata downloaded (not the updates themselves), with only a very small subset that I Approved (though still they blew my daytime bandwidth). So I'm not clear from your response whether the non-approved ones still awaiting download are "already synchronized" or not...I will cogitate on it some more tomorrow and maybe just try & see what happens. I might be too tired tonight to be thinking straight about this.

    Yeah I thought about the "complete before the end of the free-use period" question which is sorta where we started. I have a pretty good handle on download rates so if I knew how big the downloads were going to be, I'd have had at least a prayer of avoiding an over-run by being selective about which/how many downloads to approve.

    OK, you've now given me some ammo and good ideas and I thank you again for that!

    EDIT: Well your posts got me wired-up a bit, so I set-up BITS for 1a-6aCST downloads and approved a few large updates for installation. Since the downloads did NOT appear to start right away, it looks like the assigned limitation is working. Looking forward to seeing the result in the morning! BITS, er, ah, Lawrence where-have-you-been all my life! ;-)
    • Edited by maxblack Monday, December 19, 2011 3:05 AM
    Monday, December 19, 2011 2:25 AM
  • Well it does seem that "bandwidth limiting" worked for me overnight. The log (App/Services--Bits-Client) is sorta ugly--it includes Warnings for every new update that I'd approved ie.

    Started the transfer job...

    Stopped transferring...

    every 10 minutes from the time I'd Approved them for download. But then sometime after 100am the transfers continued and completed without any trouble.

    Thanks again Lawrence for your patience and your feedback. I think I can now leave this thread as "answered" with a clear conscience! :D

    Monday, December 19, 2011 1:19 PM
  • Thanks Lawrence for the tip about BITS--I've not seen any discussions about this before so your post is welcome indeed.

    For future reference -- it used to be in the WSUS Deployment Guide in a much more primitive form, but now it is found in the WSUS Technical Reference Guide, and has been expanded a bit to talk about the differences between the versions of BITS as well as the methodologies for configuring BITS.

    Improve WSUS Download Performance with BITS


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2011)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Monday, December 19, 2011 10:08 PM
    Moderator
  • Well the hits just keep on comin' don't they. The para on Peer Caching has me thinking maybe building this server expressly for WSUS might not have been necessary (though I needed to do it anyway for the learning experience of WS/WSUS).

    Another reason I guess that when you need something done right, you hire a professional (not a lot of those out here in the extreme country so yours truly does often get the call, but I have no letters after my name :-) ).

    Many thanks LG.

    Tuesday, December 20, 2011 11:52 AM
  • If one of the key benefits to WSUS is to be able to control bandwidth used with your ISP

    I'm not sure I agree with the premise. The primary purpose of WSUS was to allow organizations to have choice and control over what updates were installed on organizational systems, and to a lesser extent when those updates get installed. What gets downloaded over the ISP connection is a function of the updates that are needed in order to meet the criteria for "what updates will be installed". There's not a lot of choice here -- except to NOT approve updates that are not needed (e.g. XP SP2, WS2003 SP1, Itanium, etc.)

    The other way to control bandwidth consumption via the ISP is to NOT auto-approve an entire classification of updates (e.g. Security, Critical). For starters, I can demonstrate that for the typical organization, auto-approving Security Updates is already downloading at least TWICE what the organization actually needs, and maybe even more.

    Consider this scenario. Organization has WS2003 x86 servers, WS2008 x86 servers, and WS2008R2 x64 servers. Three platforms. To get updates for those three platforms requires the enabling of three product categories: WS2003, WS2008, and WS2008R2. But in those three product categories you get updates for the following platforms:

    • Windows Server 2003 x86
    • Windows Server 2003 x64
    • Windows Server 2008 ia64
    • Windows Server 2008 x86
    • Windows Server 2008 x64
    • Windows Server 2008 ia64
    • Windows Server 2008 R2 x64
    • Windows Server 2008 R2 ia64

    That's EIGHT platforms worth of updates for only THREE actual platforms in operation. At least TWICE as many updates approved and downloaded each month than will be actually deployed, and probably closer to THREE times as many.

    Incidentally, a similar, but slightly less significant issue also occurs for Desktop OS updates. Less significant only in that there aren't any ia64 desktop platforms, and the XP x64 updates are in a separate product category. For an organization that has Win7 x64 systems, then this is probably completely insignificant.


    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, May 29, 2013 7:23 PM
    Moderator