none
Best Practice to clean up WSUS content no longer needed

    Question

  • I have been researching this for days and probably have about 10 hours invested in trying to come to a conclusion and now want some feedback from this group. Below you will find everything I think you might need about my current configuration. I originally installed my first WSUS server in 2006.Over the years I added new products as needed, changed to express files (seems to have been a bad decision), unselected products no longer needed, and when version 3 came out began running the cleanup wizard monthly. I have never declined any updates myself and only approved those showing as needed. I watched my content grow to about 65 GB then decided to migrate to a new server. I followed this procedure which worked very well:

    http://exchangeserverpro.com/how-to-move-wsus-30-to-a-new-server

    After the migration I tested a round of updates and everything was working fine. Then I added Windows Server 2008 (only have one server with this OS) and SQL Server 2008 R2 (only have one server with this OS) products and was amazed when my content went up to over 100 GB. I decided to remove those two products since only one server needs them and I could update it direct from MS instead thinking it would be easy to recover the space. Was I in for a surprise. No real easy way to do that. From my research these seem to be the options to do a good clean up on all unneeded content. What do you suggest as the best way for me to proceed?

    Option 1: uninstall and re-install fresh

    Option 2: reset the content following this procedure:

    http://blogs.technet.com/b/gborger/archive/2009/02/27/what-to-do-when-your-wsuscontent-folder-grows-too-large.aspx

    Option 3: reset the content following this procedure: (I tested this on my old server and steps 1-4 took about 90 minutes)

    1. Decline all previously approved updates. (Yes, all of them. Even the ones you want.)
    2. Run the cleanup wizard -- this will remove files in the WsusContent folder.
    3. Change the approval of all DECLINED updates from declined to "Not Approved" (and apply inheritance).
    4. Run the cleanup wizard again -- this will decline all expired updates.
    5. Re-approve needed updates. Content will be re-downloaded.

    I do plan to remove the express files option first to reduce the amount of space needed for storage. If you see anything else in my config that should be tweaked please let me know. Thanks for any and all feedback. I appreciate you taking the time to read this and respond.

    My configuration follows:

    1 Gbps switched network infrastructure with 10/10 fiber internet access

    WSUS – current environment – 1 physical server also used as a file share server for user files

    Windows Server 2008 Enterprise (x86)

    Dual Intel Xeon 2.8 Ghz

    2 GB Ram

    1 Gbps Nic

    136 GB hard drive for DB and WSUS Content files (currently DB=1.5 GB, Content = 108 GB)

    WSUS Server version: 3.2.7600.226

    Using the Windows Internal Database (I do have a SQL Server 2008 R2 server available now)

    128 Computers in 13 groups manually assigned but computers are directed to this server via GP

    (all Servers and 90% of workstations are current on updates through last month)

    3189 Updates installed/NA

    139 Updates needed

    919 Updates with no status

    Configuration options:

    Update source – Microsoft

    Products – Office 2003, Office 2010, Windows 7, Windows Defender, Windows Server 2003, Windows Server 2008 R2, Windows XP (previously selected but no longer needed: Office 2002/XP, SQL Server 2008 R2, Windows 2000, Windows Server 2008)

    Classifications – critical, definition, security, service packs, update rollups, updates

    Update files and languages – store locally, download only when approved, download express installation files, English

    Automatic approvals – above classifications for test group which includes one computer with each of the following OS’s: Windows 7, Windows Server 2003, Windows Server 2008 R2, Windows XP

    After those machines are tested then I approve and install needed updates for the server group (8 machines total) which include Windows Server 2003, Windows Server 2003 R2, Windows Server 2008 R2, Windows XP

    After those machines are tested then I approve needed updates for all computers and let the users install them


    Monday, October 17, 2011 6:47 PM

Answers

  • Thanks for your feedback Lawrence. Both answers were expected. The reason I have never declined updates is I have had a hard time coming up with a good procedure. Even after reading the online documentation it still seems fuzzy to me. Is there any Best Practice Procedure available that documents how to do this step by step?


    I've discussed this process many times in this forum and in webcasts.

    From the All Updates view, filter on Approval=Approved and Status=Installed/NotApplicable. Enable the Superseded column and the Installed/NotApplicable Percentage column. Sort on the Superseded column, focusing on updates with the blue icon at the bottom and in the middle. Select those updates with Installed/NotApplicable Percentage = 100% that are superseded. Decline them. Performed monthly this exercise should take no more than 10 minutes.

    Run the Server Cleanup Wizard.


    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
    Tuesday, October 18, 2011 7:29 PM
    Moderator
  • Once an update is declined will it ever show as needed again
    Not unless you set it's approval back to NotApproved. The WUAgent cannot see, or report status on, updates that are Declined or Expired.
    It seems straightforward to decline previous service packs after pushing out later ones using a service pack update view.
    Correct. There is no reason I can think of to keep a downlevel service pack in the list of approved updates, except while the recently-released service pack is still being evaluated and tested for wide-scale deployment -- although by that point, the previous service pack should, arguably, already be at 100% installed.
    It seems straightforward to decline all previous product updates when that product is no longer needed using a product view.
    Correct. For example Windows 2000, Office XP, SQL Server 2000, Exchange Server 2003. If you were synchronizing those products, and those products are now permanently retired from your enterprise, there is no value in retaining that content as a notDeclined update.
    Regular monthly maintenance of declining superceeded updates as above and yearly maintenance of declining old service packs and old products should keep content a lot more tidy. Is there anything else that should be considered?
    I would treat Service Packs just as any other superseded update. When the downlevel service pack reaches 100% NotApplicable -- decline it.
    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
    • Marked as answer by mikegalbicka Wednesday, October 19, 2011 9:10 PM
    Wednesday, October 19, 2011 8:38 PM
    Moderator
  • Option 1: uninstall and re-install fresh

    This one.


    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, October 17, 2011 8:24 PM
    Moderator
  • I have never declined any updates myself
    btw.. not doing this is what has contributed most significantly to your ever-growing content store. You must perform regular maintenance on old approvals -- at a minimum this must include removing approvals for updates that no longer are being actively deployed. (e.g. superseded updates with NotApplicable Percentage=100%). Ideally, since it's exactly the same number of keystrokes, you should Decline those updates.
    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
    • Marked as answer by mikegalbicka Thursday, October 20, 2011 11:41 AM
    Monday, October 17, 2011 8:27 PM
    Moderator

All replies

  • Option 1: uninstall and re-install fresh

    This one.


    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, October 17, 2011 8:24 PM
    Moderator
  • I have never declined any updates myself
    btw.. not doing this is what has contributed most significantly to your ever-growing content store. You must perform regular maintenance on old approvals -- at a minimum this must include removing approvals for updates that no longer are being actively deployed. (e.g. superseded updates with NotApplicable Percentage=100%). Ideally, since it's exactly the same number of keystrokes, you should Decline those updates.
    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
    • Marked as answer by mikegalbicka Thursday, October 20, 2011 11:41 AM
    Monday, October 17, 2011 8:27 PM
    Moderator
  • Thanks for your feedback Lawrence. Both answers were expected. The reason I have never declined updates is I have had a hard time coming up with a good procedure. Even after reading the online documentation it still seems fuzzy to me. Is there any Best Practice Procedure available that documents how to do this step by step?
    Tuesday, October 18, 2011 12:05 PM
  • Thanks for your feedback Lawrence. Both answers were expected. The reason I have never declined updates is I have had a hard time coming up with a good procedure. Even after reading the online documentation it still seems fuzzy to me. Is there any Best Practice Procedure available that documents how to do this step by step?


    I've discussed this process many times in this forum and in webcasts.

    From the All Updates view, filter on Approval=Approved and Status=Installed/NotApplicable. Enable the Superseded column and the Installed/NotApplicable Percentage column. Sort on the Superseded column, focusing on updates with the blue icon at the bottom and in the middle. Select those updates with Installed/NotApplicable Percentage = 100% that are superseded. Decline them. Performed monthly this exercise should take no more than 10 minutes.

    Run the Server Cleanup Wizard.


    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
    Tuesday, October 18, 2011 7:29 PM
    Moderator
  • Thanks Lawrence. This is very useful information. To be clear - after setting up the all updates view as noted it displays 3172 updates of 4636 total in this order:

    icon represents an update that supersedes an older one – 431 updates

    icon represents an update that supersedes an older one, AND is superseded by a newer one -  1101 updates

    icon represents an update that is superseded by a new one – 703 updates

    No icon – 937 updates

    All updates in the list show 100% installed/na status.

    I would select the 1101 and 703 groups together and decline them then the server cleanup wizard will delete the content.

    Wednesday, October 19, 2011 2:06 PM
  • icon represents an update that supersedes an older one, AND is superseded by a newer one -  1101 updates

    icon represents an update that is superseded by a new one – 703 updates

    All updates in the list show 100% installed/na status.

    I would select the 1101 and 703 groups together and decline them then the server cleanup wizard will delete the content.

    Correct.

    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, October 19, 2011 3:46 PM
    Moderator
  • Great, that should indeed help a lot. A few more questions come to mind before I put this topic to rest.

    Once an update is declined will it ever show as needed again (say by a newly added system that might be way behind in updates) or does it disappear from update checks unless the status is changed back to not approved?

    It seems straightforward to decline previous service packs after pushing out later ones using a service pack update view. Any gotchas?

    It seems straightforward to decline all previous product updates when that product is no longer needed using a product view. Any gotchas?

    Regular monthly maintenance of declining superceeded updates as above and yearly maintenance of declining old service packs and old products should keep content a lot more tidy. Is there anything else that should be considered?

    Wednesday, October 19, 2011 6:48 PM
  • Once an update is declined will it ever show as needed again
    Not unless you set it's approval back to NotApproved. The WUAgent cannot see, or report status on, updates that are Declined or Expired.
    It seems straightforward to decline previous service packs after pushing out later ones using a service pack update view.
    Correct. There is no reason I can think of to keep a downlevel service pack in the list of approved updates, except while the recently-released service pack is still being evaluated and tested for wide-scale deployment -- although by that point, the previous service pack should, arguably, already be at 100% installed.
    It seems straightforward to decline all previous product updates when that product is no longer needed using a product view.
    Correct. For example Windows 2000, Office XP, SQL Server 2000, Exchange Server 2003. If you were synchronizing those products, and those products are now permanently retired from your enterprise, there is no value in retaining that content as a notDeclined update.
    Regular monthly maintenance of declining superceeded updates as above and yearly maintenance of declining old service packs and old products should keep content a lot more tidy. Is there anything else that should be considered?
    I would treat Service Packs just as any other superseded update. When the downlevel service pack reaches 100% NotApplicable -- decline it.
    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
    • Marked as answer by mikegalbicka Wednesday, October 19, 2011 9:10 PM
    Wednesday, October 19, 2011 8:38 PM
    Moderator
  • Thanks for all your clear answers Lawrence. You have been a big help. If you could stick this info to the top of the board or put it in the FAQ's it might help keep you from having to repeat it so much. I did a lot of searching before asking so your previous answers weren't easily found. Just a thought.
    Wednesday, October 19, 2011 9:08 PM
  • Thanks for all your clear answers Lawrence. You have been a big help. If you could stick this info to the top of the board or put it in the FAQ's
    I am, in fact, working on a FAQ for the forum, which will be sticky posted to the top of the mesage list.
    it might help keep you from having to repeat it so much.
    One can only hope.
    I did a lot of searching before asking so your previous answers weren't easily found.
    A reflection on the less-than-optimal search engine used in these forums. Shucks, I have troubles finding my own threads/posts and I know the specific keywords that should bring them to the top of the list. No such luck.
    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
    Thursday, October 20, 2011 5:17 PM
    Moderator
  • Hi Lawrence,

    How did you go with creating the FAQ? I know this is a rather old thread, but as far as WSUS 3 is concerned, it's still current.

    It seems that finding definitive information on doing "proper" maintenance on WSUS is still hard to find and conflicting.

    Here in Australia the majority of businesses are on download limits with ISPs, so we have to be very careful about what we do with cleaning up WSUS, as it can lead to expensive excess data charges! Welcome to the world of Australian telecommunications! First world infrastructure with third world aspirations!

    If you decline the updates that are no longer needed in your environment, isn't there a risk that, should somebody join or re-join an old computer to the network, the computer will never be identified as needing potentially critical updates? Would it be a better option to change approved updates, that are no longer needed, to unapproved? Surely this would mean the update will still be cleared out after running the clean-up wizard, but, should somebody attach or reattach an old computer to the network it will still be identified and targeted for the correct updates?

    Cheers,

    David.

    Friday, June 27, 2014 1:48 AM
  • Hi Lawrence,

    How did you go with creating the FAQ?

    Shortly after this thread was last active, I was acquired by SolarWinds, and shortly after that we created PatchZone.org. I've published a lot of this "FAQ" information as blog posts to that site. If you know of anything that's missing, please let me know.

    It seems that finding definitive information on doing "proper" maintenance on WSUS is still hard to find and conflicting.

    I don't know about "conflicting"; the process is pretty straight forward. But it has been hard to find. Truth is, until a couple of years ago it wasn't even required, but the voluminous number of updates now published in the catalog make it necessary. I posted a series of blog articles at patchzone.org addressing this very issue.

    Here in Australia the majority of businesses are on download limits with ISPs, so we have to be very careful about what we do with cleaning up WSUS, as it can lead to expensive excess data charges!

    Cleaning up WSUS will **NEVER** lead to excessive data charges; failing to properly administer and manage the server absolutely will do that!

    If you decline the updates that are no longer needed in your environment, isn't there a risk that, should somebody join or re-join an old computer to the network, the computer will never be identified as needing potentially critical updates? Would it be a better option to change approved updates, that are no longer needed, to unapproved?

    Absolutely! A critical observation, in fact. This is why only updates that are superseded should ever be declined. Updates that are NOT superseded should not be declined, but merely left in a NotApproved state so that if a computer is introduced to the network that requires one of those updates, you would be able to readily determine that fact.

    Surely this would mean the update will still be cleared out after running the clean-up wizard, but, should somebody attach or reattach an old computer to the network it will still be identified and targeted for the correct updates?

    Actually, no. Only if you explicitly decline an update, or if the Server Cleanup Wizard declines an update, will the files associated with that update be physically removed from the filesystem. If you merely remove the approvals, the files previously downloaded will remain. This, then, brings attention to the conditions under which the Server Cleanup Wizard will DECLINE an update. In order for the Server Cleanup Wizard to decline an update it must either be expired or superseded. Furthermore, superseded updates must be NotApproved, the replacement update must be Approved, and the superseded update must have been 100% Installed/NotApplicable for at least 30 days.

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

    Sunday, June 29, 2014 11:42 PM
    Moderator
  • These instructions are applicable for the server that is directly connected to the clients being managed. However, this cannot be employed for a server that retrieves updates for a disconnected WSUS installation.  The retrieving server will always show Installed/NotApplicable = 0%.
    Thursday, August 20, 2015 9:01 PM
  • Lawrence

    I will say thanks for your contribution, I had made this clean up on my WSUS and is working fine.

    Regards.

    David Iraheta - from El Salvador

    Tuesday, May 30, 2017 9:50 PM
  • Lawrence

    I will say thanks for your contribution, I had made this clean up on my WSUS and is working fine.

    Regards.

    David Iraheta - from El Salvador

    Unfortunately Lawrence passed away suddenly a couple of years ago.

    I also want to extend my script as a set-and-forget maintenance plan for WSUS. It automates generally what Lawrence says to do in many of his posts, and works very well to clean up and keep WSUS working at its best performance. I have users of my script that use it and can't believe how well WSUS works now.

    Have a peek at my Adamj Clean-WSUS script. It is the last WSUS Script you will ever need.

    http://community.spiceworks.com/scripts/show/2998-adamj-clean-wsus

    What it does:

    1. Remove all Drivers from the WSUS Database.
    2. Shrink your WSUSContent folder's size by declining superseded updates.
    3. Remove declined updates from the WSUS Database.
    4. Clean out all the synchronization logs that have built up over time (configurable, with the default keeping the last 14 days of logs).
    5. Compress Update Revisions.
    6. Remove Obsolete Updates.
    7. Computer Object Cleanup (configurable, with the default of deleting computer objects that have not synced within 30 days).
    8. Application Pool Memory Configuration to display the current private memory limit and easily increase it by any configurable amount.
    9. Run the Recommended SQL database Maintenance script on the actual SQL database.
    10. Run the Server Cleanup Wizard.

    It will email the report out to you or save it to a file, or both.

    Although the script is lengthy, it has been made to be super easy to setup and use. There are some prerequisites and instructions at the top of the script. After installing the prerequisites and configuring the variables for your environment, simply run:

    .\Clean-WSUS.ps1 -FirstRun

    and then

    .\Clean-WSUS.ps1 -InstallTask

    If you wish to view or increase the Application Pool Memory Configuration, you must run it with the required switch. See Get-Help .\Clean-WSUS.ps1 -Examples

    If you're having trouble, there's also a -HelpMe option that will create a log so you can send it to me for support.


    Adam Marshall, MCSE: Security
    http://www.adamj.org


    • Edited by Adamj.org Wednesday, May 31, 2017 3:25 AM
    Wednesday, May 31, 2017 3:24 AM
  • Run this script in ps 32bits, later wsus clean up wizard :D

    # ===============================================
    # Script to decline superseeded updates in WSUS.
    # ===============================================
    # It's recommended to run the script with the -SkipDecline switch to see how many superseded updates are in WSUS and to TAKE A BACKUP OF THE SUSDB before declining the updates.
    # Parameters:

    # $UpdateServer             = Specify WSUS Server Name
    # $UseSSL                   = Specify whether WSUS Server is configured to use SSL
    # $Port                     = Specify WSUS Server Port
    # $SkipDecline              = Specify this to do a test run and get a summary of how many superseded updates we have
    # $DeclineLastLevelOnly     = Specify whether to decline all superseded updates or only last level superseded updates
    # $ExclusionPeriod          = Specify the number of days between today and the release date for which the superseded updates must not be declined. Eg, if you want to keep superseded updates published within the last 2 months, specify a value of 60 (days)


    # Supersedence chain could have multiple updates. 
    # For example, Update1 supersedes Update2. Update2 supersedes Update3. In this scenario, the Last Level in the supersedence chain is Update3. 
    # To decline only the last level updates in the supersedence chain, specify the DeclineLastLevelOnly switch

    # Usage:
    # =======

    # To do a test run against WSUS Server without SSL
    # Decline-SupersededUpdates.ps1 -UpdateServer SERVERNAME -Port 8530 -SkipDecline

    # To do a test run against WSUS Server using SSL
    # Decline-SupersededUpdates.ps1 -UpdateServer SERVERNAME -UseSSL -Port 8531 -SkipDecline

    # To decline all superseded updates on the WSUS Server using SSL
    # Decline-SupersededUpdates.ps1 -UpdateServer SERVERNAME -UseSSL -Port 8531

    # To decline only Last Level superseded updates on the WSUS Server using SSL
    # Decline-SupersededUpdates.ps1 -UpdateServer SERVERNAME -UseSSL -Port 8531 -DeclineLastLevelOnly

    # To decline all superseded updates on the WSUS Server using SSL but keep superseded updates published within the last 2 months (60 days)
    # Decline-SupersededUpdates.ps1 -UpdateServer SERVERNAME -UseSSL -Port 8531 -ExclusionPeriod 60


    [CmdletBinding()]
    Param(
    [Parameter(Mandatory=$True,Position=1)]
        [string] $UpdateServer,

    [Parameter(Mandatory=$False)]
        [switch] $UseSSL,

    [Parameter(Mandatory=$True, Position=2)]
        $Port,

        [switch] $SkipDecline,

        [switch] $DeclineLastLevelOnly,

        [Parameter(Mandatory=$False)]
        [int] $ExclusionPeriod = 0
    )

    Write-Host ""

    if ($SkipDecline -and $DeclineLastLevelOnly) {
        Write-Host "Using SkipDecline and DeclineLastLevelOnly switches together is not allowed."
    Write-Host ""
        return
    }

    $outPath = Split-Path $script:MyInvocation.MyCommand.Path
    $outSupersededList = Join-Path $outPath "SupersededUpdates.csv"
    $outSupersededListBackup = Join-Path $outPath "SupersededUpdatesBackup.csv"
    "UpdateID, RevisionNumber, Title, KBArticle, SecurityBulletin, LastLevel" | Out-File $outSupersededList

    try {
        
        if ($UseSSL) {
            Write-Host "Connecting to WSUS server $UpdateServer on Port $Port using SSL... " -NoNewLine
        } Else {
            Write-Host "Connecting to WSUS server $UpdateServer on Port $Port... " -NoNewLine
        }
        
        [reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration") | out-null
        $wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer($UpdateServer, $UseSSL, $Port);
    }
    catch [System.Exception] 
    {
        Write-Host "Failed to connect."
        Write-Host "Error:" $_.Exception.Message
        Write-Host "Please make sure that WSUS Admin Console is installed on this machine"
    Write-Host ""
        $wsus = $null
    }

    if ($wsus -eq $null) { return } 

    Write-Host "Connected."

    $countAllUpdates = 0
    $countSupersededAll = 0
    $countSupersededLastLevel = 0
    $countSupersededExclusionPeriod = 0
    $countSupersededLastLevelExclusionPeriod = 0
    $countDeclined = 0

    Write-Host "Getting a list of all updates... " -NoNewLine

    try {
    $allUpdates = $wsus.GetUpdates()
    }

    catch [System.Exception]
    {
    Write-Host "Failed to get updates."
    Write-Host "Error:" $_.Exception.Message
        Write-Host "If this operation timed out, please decline the superseded updates from the WSUS Console manually."
    Write-Host ""
    return
    }

    Write-Host "Done"

    Write-Host "Parsing the list of updates... " -NoNewLine
    foreach($update in $allUpdates) {
        
        $countAllUpdates++
        
        if ($update.IsDeclined) {
            $countDeclined++
        }
        
        if (!$update.IsDeclined -and $update.IsSuperseded) {
            $countSupersededAll++
            
            if (!$update.HasSupersededUpdates) {
                $countSupersededLastLevel++
            }

            if ($update.CreationDate -lt (get-date).AddDays(-$ExclusionPeriod))  {
       $countSupersededExclusionPeriod++
    if (!$update.HasSupersededUpdates) {
    $countSupersededLastLevelExclusionPeriod++
    }
            }
            
            "$($update.Id.UpdateId.Guid), $($update.Id.RevisionNumber), $($update.Title), $($update.KnowledgeBaseArticles), $($update.SecurityBulletins), $($update.HasSupersededUpdates)" | Out-File $outSupersededList -Append       
            
        }
    }

    Write-Host "Done."
    Write-Host "List of superseded updates: $outSupersededList"

    Write-Host ""
    Write-Host "Summary:"
    Write-Host "========"

    Write-Host "All Updates =" $countAllUpdates
    Write-Host "Any except Declined =" ($countAllUpdates - $countDeclined)
    Write-Host "All Superseded Updates =" $countSupersededAll
    Write-Host "    Superseded Updates (Intermediate) =" ($countSupersededAll - $countSupersededLastLevel)
    Write-Host "    Superseded Updates (Last Level) =" $countSupersededLastLevel
    Write-Host "    Superseded Updates (Older than $ExclusionPeriod days) =" $countSupersededExclusionPeriod
    Write-Host "    Superseded Updates (Last Level Older than $ExclusionPeriod days) =" $countSupersededLastLevelExclusionPeriod
    Write-Host ""

    $i = 0
    if (!$SkipDecline) {
        
        Write-Host "SkipDecline flag is set to $SkipDecline. Continuing with declining updates"
        $updatesDeclined = 0
        
        if ($DeclineLastLevelOnly) {
            Write-Host "  DeclineLastLevel is set to True. Only declining last level superseded updates." 
            
            foreach ($update in $allUpdates) {
                
                if (!$update.IsDeclined -and $update.IsSuperseded -and !$update.HasSupersededUpdates) {
                  if ($update.CreationDate -lt (get-date).AddDays(-$ExclusionPeriod))  {
       $i++
    $percentComplete = "{0:N2}" -f (($updatesDeclined/$countSupersededLastLevelExclusionPeriod) * 100)
    Write-Progress -Activity "Declining Updates" -Status "Declining update #$i/$countSupersededLastLevelExclusionPeriod - $($update.Id.UpdateId.Guid)" -PercentComplete $percentComplete -CurrentOperation "$($percentComplete)% complete"

                    try 
                    {
                        $update.Decline()                    
                        $updatesDeclined++
                    }
                    catch [System.Exception]
                    {
                        Write-Host "Failed to decline update $($update.Id.UpdateId.Guid). Error:" $_.Exception.Message
                    } 
                  }             
                }
            }        
        }
        else {
            Write-Host "  DeclineLastLevel is set to False. Declining all superseded updates."
            
            foreach ($update in $allUpdates) {
                
                if (!$update.IsDeclined -and $update.IsSuperseded) {
                  if ($update.CreationDate -lt (get-date).AddDays(-$ExclusionPeriod))  {   
     
    $i++
    $percentComplete = "{0:N2}" -f (($updatesDeclined/$countSupersededAll) * 100)
    Write-Progress -Activity "Declining Updates" -Status "Declining update #$i/$countSupersededAll - $($update.Id.UpdateId.Guid)" -PercentComplete $percentComplete -CurrentOperation "$($percentComplete)% complete"
                    try 
                    {
                        $update.Decline()
                        $updatesDeclined++
                    }
                    catch [System.Exception]
                    {
                        Write-Host "Failed to decline update $($update.Id.UpdateId.Guid). Error:" $_.Exception.Message
                    }
                  }              
                }
            }   
            
        }
        
        Write-Host "  Declined $updatesDeclined updates."
        if ($updatesDeclined -ne 0) {
            Copy-Item -Path $outSupersededList -Destination $outSupersededListBackup -Force
    Write-Host "  Backed up list of superseded updates to $outSupersededListBackup"
        }
        
    }
    else {
        Write-Host "SkipDecline flag is set to $SkipDecline. Skipped declining updates"
    }

    Write-Host ""
    Write-Host "Done"
    Write-Host ""

    Tuesday, September 19, 2017 3:30 PM
  • While that just declines superseded updates, it fails to do the rest of the WSUS Maintenance.

    My script has improved since this original post of mine. My script now has options of what to decline, and superseded is one of those options, but it includes more like beta updates, itanium updates, etc. I'm also now including SQL Indexing that speeds up WSUS Performance by about 1000-1500 times on database operations.

    Have a peek at my Adamj Clean-WSUS script. It is the last WSUS Script you will ever need!

    http://community.spiceworks.com/scripts/show/2998-adamj-clean-wsus

    What it does:

    1. Add WSUS Index Optimization to the database to increase the speed of many database operations in WSUS by approximately 1000-1500 times faster.
    2. Remove all Drivers from the WSUS Database (Default; Optional).
    3. Shrink your WSUSContent folder's size by declining multiple types of updates including by default any superseded updates, preview updates, expired updates, Itanium updates, and beta updates. Optional extras: Language Packs, IE7, IE8, IE9, IE10, Embedded, NonEnglishUpdates, ComputerUpdates32bit, WinXP.
    4. Remove declined updates from the WSUS Database.
    5. Clean out all the synchronization logs that have built up over time (configurable, with the default keeping the last 14 days of logs).
    6. Compress Update Revisions.
    7. Remove Obsolete Updates.
    8. Computer Object Cleanup (configurable, with the default of deleting computer objects that have not synced within 30 days).
    9. Application Pool Memory Configuration to display the current private memory limit and easily set it to any configurable amount including 0 for unlimited. This is a manual execution only.
    10. Checks to see if you have a dirty database, and if you do, fixes it. This is primarily for Server 2012 WSUS, and is a manual execution only.
    11. Run the Recommended SQL database Maintenance script on the actual SQL database.
    12. Run the Server Cleanup Wizard.

    It will email the report out to you or save it to a file, or both.

    Although the script is lengthy, it has been made to be super easy to setup and use so don't over think it. There are some prerequisites and instructions at the top of the script. After installing the prerequisites and configuring the variables for your environment (email settings only if you are accepting all the defaults), simply run:

    .\Clean-WSUS.ps1 -FirstRun

    If you wish to view or increase the Application Pool Memory Configuration, or run the Dirty Database Check, you must run it with the required switch. See Get-Help .\Clean-WSUS.ps1 -Examples

    If you're having trouble, there's also a -HelpMe option that will create a log so you can send it to me for support.


    Adam Marshall, MCSE: Security
    http://www.adamj.org

    Tuesday, September 19, 2017 4:04 PM