How to remove orphaned SCUP updates…


One of the most common questions I’ve been asked is, “How do I remove SCUP updates from Configuration Manager?”.  The answer is fairly easy, you expire the update in SCUP and the re-publish it into WSUS.  Then on the next scheduled ConfigMgr/WSUS synchronization the update will be marked as expired in the ConfigMgr UI.  Finally after a few weeks the update will be removed from the UI (unless the update is part of a deployment package).

Now this process becomes a little more work if you have deleted the update in SCUP and have no way of getting it back.  One thing to remember is that the flow of data is one way, meaning it flows from SCUP to WSUS (through publishing) and from WSUS to ConfigMgr (through synchronization).  If you publish an update to WSUS and then delete it from SCUP (before expiring/republishing) then the update will become orphaned in ConfigMgr and there is no easy way to remove it.  If you are in this situation the below steps should help remove those orphaned updates.

  1. The first thing you need to do is find the Update in the ConfigMgr UI that is orphaned as we need to find the Update ID. To display the Update ID in the UI you will need to add a new column for display.

    Orphaned1

    Add the “Update Classification” column to the Displayed columns list.

    Orphaned2

    Now find the orphaned update (probably by title) and note the Update ID

    Orphaned3

  2. Once you have the UpdateID you now need to find the InstallableItem ID.  To do this you can browse to your WSUS Server’s “UpdateServicesPackages” share. The path is \\<wsus server>\UpdateServicesPackagess\[Update GUID]\[InstallableItem ID GUID]

    Orphaned4

  3. Now that you have the UpdateID and InstallableItem ID you can re-create the update.  Open SCUP and create a new update with the same title and fill in the required fields.  For Installable/Installed Rules you can but in any rules as you are going to expire the update.  It does not really matter which rules you use.
  4. Export this newly created update. 
  5. Delete the new update from SCUP console, don’t worry we will re-import it in a few steps.
  6. Export/Save the XML file from inside the <catalogname>.cab file for editing.
  7. Open the XML file in an XML editor if you have one or notepad.  If you have an XML editor you can reformat the text for easier reading.
  8. Modify the PackageID with your orphaned UpdateID and modify the InstallableItem ID with your orphaned InstallableItem ID and save the file.

    Orphaned5

  9. CAB the file using the following command – “makecab <filename>.xml <filename>.cab”
  10. Re-Import the update into SCUP.
  11. Mark the update as Expired and flag the update for Publish.
  12. Publish the update.
  13. Verify in the %user%\updatespublisher.log that the update was expired.

    Orphaned6

There are a couple of things to remember with managing SCUP updates.  Before you delete an update in SCUP make sure you have no use for it in the future.  If the update was never published then deleting it is fine, however, if you have published it into WSUS/ConfigMgr then you will want to keep the update or expire it and re-publish before deleting it.

Comments (11)
  1. @Mike you have to do a full schedule sync, an on-demand sync will not pick up the changes.

    @vf1  & @Rich  I'm not aware of a way to remove updates once you have removed the package on WSUS. Sorry I couldn't be more help.

    Please note I have moved positions and no longer work on SCUP, thus the lack of responses – blogs.technet.com/…/moving-on.aspx.  I will see if I can get someone on the product team to look at comments in the future.

  2. Anonymous says:

    I spent ages trying to get rid of things from WSUS that had been orphaned. The above works fine as long as the original CAB files are still there.
    Here’s what I did to get rid of the ones where the CAB file had been lost. Hopefully helpful to someone.

    http://gsilt.blogspot.co.uk/2014/03/when-scup-2011-cleanup-wizard-wont.html

  3. I'm not aware of another way to remove the item.  Digging into the WSUS DB is unsupported and not recommended.  

  4. Anonymous says:

    Jason, what if the package was deleted from the "UpdateServicesPackage"?  You cannot create a new package with the installables without that.

    I have a package that I deleted by mistake (thought I was on a different server), now the SCUP will not update the "expired item" becuase it does not exist.

  5. mike says:

    Jason, you stated this:

    Finally after a few weeks the update will be removed from the UI

    Is there a way to make it happen quicker?  How can I manually force it!?

  6. Michael F. McKinnon says:

    Lot's to contemplate. I will secure these pages for an indepth review. Thank you  Michael

  7. Rich says:

    I have the exact same question as vf1. Any help, or are you going to be an absentee blogger like so many 'softees.

  8. Rich says:

    Thanks Jason,

    So there's no other way to discover the InstallableItem ID? There has to be some reference to it in the DB somewhere.

    Also, my update is listed as expired, however it never goes away, It has performed it's scheduled synchronizations several times. I even increased the frequency of the schedule to make sure.

    Thanks

  9. Rich says:

    Well, let me ask you this. Is the installableItemID, with the same uid as that cab file,  the same id number as the cab file referenced on the content information tab, where it has a path to download it? I know you don't have access to a SCCM lab any more, but… when I select an update, the lower part of the middle pane is populated with info about the update. On the content info tab it has an http link to download the cab file. That cab file is named differently than the unique ID. It's a long hexidecimal name. However, it has no dashes in it.

  10. Anders Johansson says:

    Hello Jason,
    I have a CM 2012 environment with SCUP 2011 implemented.
    I’m following your guide, to remove a “SCUP-update” in SCCM. But the thing is, even if I expire the update in SCUP, and publish it to the SCCM – and wait for the scheduled sync, it is not changing to “Expired” ..
    Do you have any idea of why?

  11. lee says:

    Top post and still relevant even today……Thanks.

Comments are closed.

Skip to main content