다음을 통해 공유

How to delete upgrades in WSUS

  • 아티클

(Alternative title: "Help, I synched Upgrades before installing the patch!"  

This applies to anyone who missed KB 3095113 when it was offered as a hotfix, and subsequently enabled synching of Upgrades in their environment. The upgrades that were downloaded happen to be from the Windows 10 1511 feature upgrade, but these steps could be modified to suit a similar purpose for a different set of content.)

In this scenario, WSUS has downloaded content that it cannot use. Because parsing only happens once, and WSUS does not know what “Upgrades” are without having installed KB 3095113, it incorrectly identifies the upgrade as a regular update and saves it to the SUSDB as such. In order to remedy this, you must perform the following sequence of steps on the WSUS servers as specified in the table below (where "USS" represents "upstream server"):

Action

Where to perform

1.       Disable the “Upgrades” classification

USS or Standalone WSUS

2.       Delete the previously synched upgrades

All WSUS (start with topmost server)

3.       Enable the “Upgrades” classification

USS or Standalone WSUS

4.       Perform full sync

USS or Standalone WSUS

Some workarounds propose that you delete these entries from the SUSDB via SQL queries, but we do not recommend directly modifying database content. The supported way to remove update content is with PowerShell commands [from an elevated session] as described below. Again, be sure that you perform the deletion step on the WSUS server that is highest in your hierarchy first, and then work your way down; otherwise, your deletions may be replaced by the USS on the next sync attempt. 

// disable Upgrades classification on local WSUS server

Get-WsusClassification | Where-Object -FilterScript {$_.Classification.Title -Eq “Upgrades”} | Set-WsusClassification -Disable  

// delete all update content on the current server belonging to the 1511 release

$s = Get-WsusServer

$s.SearchUpdates(“version 1511, 10586”) | foreach { $s.DeleteUpdate($_.Id.UpdateId) } 

// enable Upgrades classification

Get-WsusClassification | Where-Object -FilterScript {$_.Classification.Title -Eq “Upgrades”} | Set-WsusClassification 

// perform full sync

$sub = $s.GetSubscription()

$sub.StartSynchronization()

Comments

  • Anonymous
    February 01, 2016
    What if you have enabled the Upgrades classification on WSUS 3.2? The powershell commands wont work with this version. Can I just run them after migrating the DB to a newer WSUS server?
  • Anonymous
    February 12, 2016
    fr: WSUS 3.2 does not support Upgrades, so it should not have this classification enabled. You can disable this classification through the WSUS UI, and then decline the upgrades, after which you can run Server Cleanup Wizard to remove them from your SUSDB. If you're planning to migrate to a new WSUS, then we recommend completing that migration before attempting to clean up your SUSDB, since these upgrades won't cause any issues if they show up in the new SUSDB. After the migration, you can use the PowerShell commands as described in this post.
  • Anonymous
    February 18, 2016
    This worked a treat on our server. Previously the downloads were getting to the client but then failing to install.
  • Anonymous
    February 25, 2016
    Almost worked like a charm.
    Only got 1 error on the deleting action but the error message was informational enough that it indicates that the update was still applied.
    First I put it to NA for all computer groups.
    Then the deletion went fine.
  • Anonymous
    March 12, 2016
    When running then uninstall scripts the curser just returns to "PS C:".
    I assume that all the processing has occurred without error or you would see such?
    • Anonymous
      May 30, 2016
      Greg P: none of the commands have the -Verbose switch, so indeed they will be silent, and errors/warnings will only appear if something went wrong.
  • Anonymous
    June 10, 2016
    The comment has been removed
    • Anonymous
      August 03, 2016
      You must uninstall that update from all machines reporting to that WSUS before deleting it; otherwise, the SUSDB does not contain updates that its clients have installed, which is an inconsistent state.
  • Anonymous
    June 13, 2016
    HiI am running the commands how long should the delete all update content take to complete on average ? My power shell has been sat for 10 minutes and still hasn't gone back to PS command prompt indicating it has finished the task.
    • Anonymous
      August 03, 2016
      Deleting all content can take a while, but just the Upgrades shouldn't take much time at all. How long did it end up taking you?
      • Anonymous
        August 13, 2016
        Hi I am having the same issue. When I run the command it has not finished and it has been running for over 12 hours and i can see CPU is using 25% with the cmd. Would you please provide how to make the cmd write to the Powershell window with Verbose. I have a feeling although I am using the cmd -verbose i may be using the syntax wrong.
  • Anonymous
    June 29, 2016
    It seems to me that there could be another workaround to this issue. Consider the following scenario: Someone builds a new Server 2012 R2 downstream WSUS server. This new server completes its first sync before rebooting for KB3095113 installation. This results in this particular downstream server having the unusable feature upgrade content that we are concerned about. For the proposed workaround, why could you not uninstall and reinstall WSUS from the newly built problematic downstream server? When uninstalling WSUS, leave the WsusContent behind but delete the SUSDB. When reinstalling WSUS, use the same WsusContent as before. But this time, make sure we reboot the server after installing KB3095113 but before completing the first sync. This proposed 'workaround' only affects the problematic server rather than having to touch every single WSUS server in the environment as the article suggests.
    • Anonymous
      August 03, 2016
      Every SUSDB that contains the unusable content will need to delete that content to make room for the correct update content. How you do that is up to you, but I think deleting updates via PowerShell on several servers is easier than reinstalling a single WSUS.
      • Anonymous
        August 04, 2016
        Thanks for your feedback, Steve! When one has over 200+ downstream WSUS servers in their environment and not all are accessible at any given time, the uninstalling and reinstalling WSUS on a single server becomes a more desirable scenario.
  • Anonymous
    July 18, 2016
    My company environment has an upstream server (server 2012) which was patched and 13 downstream replica servers (server 2012 R2)that were unpatched. Despite this we have enable the sync of Windows 10 updates/upgrades on the upstream server as we are running test on our Windows 10 SOE machines. Do we need to clean up WSUS now on the replica servers? or can we upgrade them with the hotfix and this should fix the problem?
    • Anonymous
      July 27, 2016
      This has been rectified by installing some updates. The update view did not sync to the replica server but manually setup.
    • Anonymous
      August 03, 2016
      Anywhere that received metadata that could not be parsed at the time needs to be cleaned up. If the replicas all copied this update, then my recommendation would be to delete it everywhere, and then sync it again at your top-level server.
  • Anonymous
    August 20, 2016
    The comment has been removed
  • Anonymous
    August 29, 2016
    Update to fix script-I wanted to provide some additional scripting to help with this process. If you run this there is no type of logging to find out how long it will take.Get-WsusClassification | Where-Object -FilterScript {$.Classification.Title -Eq “Upgrades”} | Set-WsusClassification -Disable # delete all update content on the current server belonging to the 1511 release$wsus = Get-WsusServer($wsus.SearchUpdates(“Windows 10 Education, version 1511, 10586”)).Count$wsus.SearchUpdates(“Windows 10 Education, version 1511, 10586”) | foreach { Write-Host "Deleting $($.Title)" -ForegroundColor Yellow; $wsus.DeleteUpdate($.Id.UpdateId) }($wsus.SearchUpdates(“Windows 10 Pro, version 1511, 10586”)).Count$wsus.SearchUpdates(“Windows 10 Pro, version 1511, 10586”) | foreach { Write-Host "Deleting $($.Title)" -ForegroundColor Cyan; $wsus.DeleteUpdate($.Id.UpdateId) }($wsus.SearchUpdates(“Windows 10 Enterprise, version 1511, 10586”)).Count$wsus.SearchUpdates(“Windows 10 Enterprise, version 1511, 10586”) | foreach { Write-Host "Deleting $($.Title)" -ForegroundColor Green; $wsus.DeleteUpdate($.Id.UpdateId) }# delete all update content on the current server belonging to the 1607 release($wsus.SearchUpdates(“Windows 10 Pro, version 1607”)).Count$wsus.SearchUpdates(“Windows 10 Pro, version 1607”) | foreach { Write-Host "Deleting $($.Title)" -ForegroundColor Yellow; $wsus.DeleteUpdate($.Id.UpdateId) }($wsus.SearchUpdates(“Windows 10 Education, version 1607”)).Count$wsus.SearchUpdates(“Windows 10 Education, version 1607”) | foreach { Write-Host "Deleting $($.Title)" -ForegroundColor Cyan; $wsus.DeleteUpdate($.Id.UpdateId) }($wsus.SearchUpdates(“Windows 10 Enterprise, version 1607”)).Count$wsus.SearchUpdates(“Windows 10 Enterprise, version 1607”) | foreach { Write-Host "Deleting $($.Title) NON EN-US" -ForegroundColor Green; $wsus.DeleteUpdate($.Id.UpdateId) }#($wsus.SearchUpdates(“Windows 10 Enterprise, version 1607”) | ? {$.title -notlike "en-us"}).Count#$wsus.SearchUpdates(“Windows 10 Enterprise, version 1607”) | ? {$.title -notlike "en-us"} | foreach { Write-Host "Deleting $($.Title) NON EN-US" -ForegroundColor Green; $wsus.DeleteUpdate($.Id.UpdateId) }# enable Upgrades classificationGet-WsusClassification | Where-Object -FilterScript {$.Classification.Title -Eq “Upgrades”} | Set-WsusClassification # perform full sync $sub = $s.GetSubscription()$sub.StartSynchronization()Good Luck and Keep PS Scripting -Gregory Hindman
    • Anonymous
      September 07, 2016
      You absolute star, GOLFUSMC :)
  • Anonymous
    September 01, 2016
    The comment has been removed
  • Anonymous
    September 07, 2016
    One additional point. If you're using SCCM, make sure to disable upgrades via SCCM rather than the the powershell above. If you don't, SCCM will re-enable it on its next sync and might put them all back again before the job to delete all the content has completed.
    • Anonymous
      September 20, 2016
      Thanks for pointing this out, OffColour.
  • Anonymous
    September 16, 2016
    The comment has been removed
    • Anonymous
      September 16, 2016
      Additional infoI've also tried the Get-WsusServer command using SSL and the 8531 port number.The connection is closed because the trust relationship could not be established.
      • Anonymous
        September 21, 2016
        Is your WSUS part of a different forest, perhaps an untrusted one? What does your topology look like?
    • Anonymous
      September 21, 2016
      If you need to delete 1607 Upgrades, then please refer to this guidance: https://blogs.technet.microsoft.com/wsus/2016/09/21/resolving-error-0xc1800118/
  • Anonymous
    July 20, 2017
    Does this problem exist for SCCM / WSUS installed on Windows 2016 servers? I don't see an applicable hotfix for WSUS installed on 2016, but I DO get the following warning when selecting 'Upgrades' under the Software Update Point Classifications tab."Before you enable the Upgrades classification, you must install WSUS hotfix 3095113 on all software update points in your hierarchy."While I haven't seen a related hotfix for 2016, I also haven't found anything that says the issue has been resolved in the new OS either.Thanks!
    • Anonymous
      July 26, 2017
      Windows Server 2016 does not have the decryption problem because the RTM version contained the changes that were shipped in KB3095113 and KB3159706. If your SUPs are all WS16, then you should have no issues of this nature.