Deploying Superseded Down Level Windows Updates with Microsoft Configuration Manager 2007

UPDATE 12/5/2016: In November 2016, the Security Monthly Quality Rollups were released as superseding the Security Only Quality updates. This resulted in an impact to customers deploying the Security Only Quality updates, using tools that cannot easily deploy superseded updates such as System Center Configuration Manager 2007. Based on customer feedback, this supersedence has been changed in December 2016. If you’re using Configuration Manager 2007, you do not need to leverage the workarounds noted in the post below after December’s patch Tuesday.


As you are probably aware, Microsoft previously announced Windows servicing changes on down level operating systems aiming to have a more consistent and simplified servicing experience to down level operating systems. As part of this simplified servicing model, the 2nd Tuesday of each month will see the release a new Security Monthly Quality Rollup and a new Security Only Quality Update. As the Security Monthly Quality Rollup contains the same security fixes as the Security Only Quality Update, as well as all fixes from previous monthly rollups and Security Only Quality Updates, there is a supersedence relationship between these updates. This supersedence allows installers of the Security Monthly Quality Rollup to see that fixes in earlier Rollups and Security Only updates are included, and allows for machine disk space to be managed appropriately when updates are superseded. See More on Windows 7 and Windows 8.1 servicing changes for more information about the servicing changes and supersedence rules.

Cross-Month and Intra-Month Supersedence Relationships

In Configuration Manager 2007 (ConfigMgr 2007), superseded updates are automatically expired and can no longer be deployed using the built-in software updates management (SUM) feature. As noted above, there is a cross-month supersedence relationship as well as an intra-month supersedence relationship between Security Only Quality Updates and Security Monthly Quality Rollups. For example, the Security Monthly Quality Rollup released in November will supersede the Security Only Quality Update also released in November as well as the updates (Security Monthly Quality Rollup and Security Only Quality Update) released in October.

Operational Impact (Security Monthly Quality Rollup Deployments)

Configuration Manager 2007 customers have roughly a month (from the 2nd Tuesday of each month to the following 2nd Tuesday) to test and fully deploy a new Security Monthly Quality Rollup for a given month using the SUM feature. If this deployment does not complete before the next superseding rollup is released, there are two primary options to continue:

1. Choose to switch to testing and deploying the latest superseding Security Monthly Quality Rollup using the SUM feature.


2. Choose to deploy the superseded Security Monthly Quality Rollup using an alternate deployment method (outside of SUM), such as general software distribution.

Operational Impact (Security Only Quality Update Deployments)

Given that new Security Only Quality Updates are superseded by the new Security Monthly Quality Rollup for the same month, they will be marked as expired and unavailable for deployment each month via the SUM feature. Customers that desire to install Security Only Quality Updates will need to do so using an alternate deployment method (outside of SUM), such as general software distribution.

Alternate Deployment Methods using Software Distribution

Using the software distribution feature to deploy superseded updates, which you may have done previously in the past, will entail manually downloading the desired update content from the online Microsoft Update Catalog site. The update content will be .MSU based. Wusa.exe is the command line installer that can be used to install the updates. See Description of the Windows Update Standalone Installer in Windows for more information about using Wusa.exe.

Important Notes:

1. There will be update content packages per down level OS and per platform. Multiple packages and programs may be needed, as applicable.

2. You may need to create specific collections for targeting. It could be as simple as ‘All Windows 8.1 Computers’ or as complex as ‘All Windows 8.1 Computers that Require October’s Security-only Quality Update’.

3. You may need to test and define recurring advertisements designed to reinstall updates that are removed by end users.

4. Configuration Manager (current branch) and Configuration Manager 2012 have a Supersedence Rules feature that allows customers to define the expiration behavior for superseded updates. For example, instead of superseded updates being expired immediately, you can define that there is a three (3) month wait, allowing additional deployment time.

Deleting Superseding Updates

By deleting the superseding update, the superseded update will be unexpired and available for deployment in ConfigMgr 2007. See the Deleting updates using the WSUS API section below for more information, including how it affects Configuration Manager 2007.

Publish Superseded Updates Separately Using SCUP

See Deploying Custom .MSU Updates with SCCM (and SCUP) and read it thoroughly. One thing to avoid using this method is that you must not put in the Vendor/Publisher “Microsoft” or “Microsoft Corp” – this will break reporting in Configuration Manager.

Deleting Updates Using WSUS API

Delete the update in question directly using the PowerShell script below, or by calling the IUpdateServer.DeleteUpdate method from your own script/application. Run the PowerShell script to delete a specific Monthly Quality Rollup by using the KB article number:

$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer();
$updates = $wsus.getupdates() | Where {$_.KnowledgebaseArticles -eq '1234567'}
foreach ($upd in $updates){
Write-Host $upd.Title removed

To delete all Monthly Quality Rollups at once, replace the third line above with the following:

$updates = $wsus.getupdates() | Where {$_.Title -like '*Security Monthly Quality Rollup for Windows*'}

Save the script as a .PS1 file and run it from an administrative PowerShell command prompt on the WSUS server in question.

If the above script times out, you can delete the updates directly by ID. The ID for an update can be found by querying for KB number in the Microsoft Update Catalog or in the WSUS console. For example, if you wanted to find the ID for October, 2016 Security Monthly Quality Rollup for Windows 7 for x64-based Systems, you could search for "security monthly quality rollup for windows" in the Microsoft Update Catalog:

Then find and click the entry of interest – that will open it in a new window. If you look at the properties of the window, the update ID is embedded in the URL:

As we can see, the update ID for October, 2016 Security Monthly Quality Rollup for Windows 7 for x64-based Systems (KB3185330) is 4a7c98c1-098e-46ca-af01-1b80eee5f48c.

You can also find it in the WSUS console:


Therefore, if the update ID is 4a7c98c1-098e-46ca-af01-1b80eee5f48c, you can replace line 3 in the script above with the line below:


This avoids the search against all updates until the WSUS has been cleaned. To fix the general issue with the timeout error, implement the actions described in the blog below:

IMPORTANT: If you have a WSUS/SUP hierarchy, run the script on every WSUS server, including replicas. It is strongly recommended that you start on the lower-most, downstream/replica WSUS server first, then move up the hierarchy. The upstream server should be the last one on which the script is run. See the Important/Warning notes in this Use the Server Cleanup Wizard article for more details.

Triggering a manual sync in Configuration Manager 2007 will only run a delta sync with WSUS and nothing will be updated. You must wait until ConfigMgr 2007 does a full sync (scheduled sync) or you can schedule a custom schedule for the next few minutes to see the changes immediately:


You can monitor the sync in the wsyncmgr.log file. It should look something like this:


In the Configuration Manager console you will also see the Security Only Updates being available and deployable (green arrow) and the deleted Monthly Quality Rollup undeployable (grey arrow):


Reimporting deleted updates

If at any point you require the deleted updates again, you can import them back from the WSUS console:


This option will open the Microsoft Update Catalog (now working from every browser), where you can search and select the updates you want to import:




Each individual action discussed above is supported, however the end-to-end process has not been tested by the WSUS/ConfigMgr product groups and is therefore not officially supported. The Microsoft CSS organization will assist in any case delivering best-effort support (meaning no guaranteed solution). As always, be sure to test and verify this in a lab environment first, and be sure to complete a backup before making any major changes.

Microsoft System Center Configuration Manager 2007 System Center 2012 Configuration Manager ConfigMgr 2012 R2

Comments (12)
  1. JKHemker says:

    > Customers that desire to install Security Only Quality Updates will need to do so using an alternate deployment method
    Honestly, as an answer to enterprise customers this seems to be bizarre.
    Q1: What about the following suggestion:
    Use WSUS API to .Delete the “offending” superseding cumulative updates. This deletes the superseding relationships as well. Works here. Cumulative updates could be re-imported later if needed.
    Q2: What concerns me even more is (obviously based on same data): Latest turns out to be completely unable to scan for / report on November security-only updates. This is at least consistent because of the intra-month supersedence relationship. Will you tell us again that this is by design?

  2. gaz_11 says:

    Why have MS done this knowing it prevents the security only update being deployed using the SUM. Saying use a software deployment is ridiculous. The whole methodology of patching has been changed and why did they only notify us of this 5 days ago. This is shocking from MS

  3. Alex Line says:

    Can I suggest a possible change which I think might help address this for us and other SCCM 2007 users out there?

    At present both the “Security Monthly Quality Rollups” and the “Security Only Quality Updates” have the same Update Classification – “Security Updates”. I’m thinking a new Update Classification just for the “Security Monthly Quality Rollups” (e.g. “Security Update Rollups”) might possibly help with this?

    That way we could de-select this classification in the SUP configuration, and would therefore not download the catalogue information or I think the supersedence information for these Rollup patches… This way I think the monthly “Security Only Quality Updates” patches would not then become superseded and expired – which would be exactly what we want: Every monthly “Security Only Quality Update” patch to remain unexpired and therefore deployable if a system needs it, until a subsequent monthly “Security Only Quality Update” patch supersedes it.

    This would allow us to retain our process for a baseline set of patches, and also to not deploy the functional patches embedded in the Rollups which we know break things in our environment.. Obviously those people who do want to deploy the rollups would just select the new classification in their SUP configuration, and for them it would work as it is now..

  4. Bluehand says:

    I thought this blog post was a joke to start off with. Then I checked out our SCCM 2007 implementation managing tens of thousands of Windows 7 clients and found it to be true. Really? A change of this magnitude with only a few days notice? This effectively breaks software updates in SCCM 2007 forcing us to use the monthly cumulative update, when we have been told for months now that we would be able use the security only update. We even had a meeting with someone from the product group who told us that there would be no further changes to Windows 7 servicing and we would not be forced into using cumulative updates. This change needs to be rolled back, now…

  5. Ray says:

    This behavior can be avoided by setting the Supersedence options in Config Manager (on the SUP) to not expire superseded updates for a period of time. I have used 6 months for this setting for years, as not all updates can be applied (without breaking things) in an Enterprise Environment, as quickly as we like.

  6. JKHemker says:

    @Alex: IMHO you are right, and my suggestion under Q1 could be regarded as being merely a replacement for this. But remember that once you got the stuff into SUSDB – which most of us already did – you must find a way to remove it, which is why .Delete comes into play. I verified that it would even be sufficient to merely kick the “bad” supersedence relationships out of SUSDB, but of course this is unsupported.

    @Ray: at best, this is a (SCCM2012++) workaround for well-managed enterprises; but think of outsourcers getting in servers with completely unknown patch states: Clearly even 6 months would not be sufficient. So this only looks like a solution.

    @gaz_11, Bluehand: >”…only a few days notice”: IMHO this is false: MS informed us August 15th, and the supersedence relationships were “questionable” in October already, but now the new intra-month supersedence relationships added in November made the problems more visible to everyone. In fact I very much appreciate the new serving model – the only thing that kills us is the handling of the supersedence relationships in a world where supersedence relationships are by new design not that trivial to handle as they were before.

    @Microsoft: Please, handle supersedence relationships in a way that allow enterprises to adopt cumulative rollups *at there own pace* – without having to abandon SUM.

  7. Alex Line says:

    @JKHemker: Thanks for your post – we’re still looking at this and of course you’re right – even if MS were to take up the suggestion of the new classification, this wouldn’t immediately help with the entries that are already there.. So – with some assistance from MS we tried your approach and deleted the November rollups from WSUS. This produced some interesting results –
    a) SCCM did not show the November Security Only patches in its database until after it had done a FULL synchronisation. At first we triggered a synchronisation manually, but found that this actually only runs a delta sync from WSUS, and this didn’t pull in the November Security Only patches. However, we also had a custom sync schedule set to run overnight, and this apparently forces a FULL synchronisation. After this was run we could see the November Security Only patches in SCCM, and they aren’t superseded or expired.
    b) The November Rollup patches which we removed from WSUS are still showing in the SCCM console, but now have the grey icon as if they have been expired.
    c) The October Security Only patches are in the SCCM database, and are showing as superseded – but not expired (2 days so far). We think this was because they were previously in the database from last month, and then the insertion of the November Rollup made them superseded. Despite the removal of this superseding November Rollup patch in WSUS, these October Security Only patches are still showing as being superseded by it. However, as they don’t seem to be expiring (so far), and still have the yellow icon, so I think we’d still be able to deploy them which is what we want going forward for new builds etc. I do suspect however that the supersedence information for the November rollup is still within the WSUS database despite the fact that the patch itself has been deleted – and therefore if the supersedence information could also be deleted then after another FULL sync the October Security only patches would then show as not superseded (green icon). At present we don’t know the API call we’d run to WSUS to delete the supersedence information for the November Rollup…
    d) Finally and most importantly – we are not seeing any clients requiring the November Security Only update after successfully doing their scan. This seems to mirror what you saw, and still leaves us in the position where we still can’t actually get the November Security Only update installed on any clients. We’d be very interested if you have found an answer to this.. We also have a (test) SCCM 2012 environment where we have superseded patches set not to expire for 3 months, and in this case the clients are scanning and reporting their requirement for the Security Only updates correctly.
    We’d appreciate any suggestion of further comments on this subject…

  8. JKHemker says:

    @Alex My “Q1” suggestion was admittedly not that detailed. While the following worked for me, don’t trust me but test it.
    Preliminary note: Actually we must address 2 alternative scenarios: One for the green field – e.g. December patchday- , and one for “when it seems to be too late”, which is why I try to describe them as A and B.

    PROCEDURE A: New patchday (how to prevent unwanted updates to arrive in SCCM2007 at all)
    1. Disable SCCM SUP-controlled sync schedule temporarily
    2. Backup SUSDB (head WSUS)
    3. On patch tuesday: In “head WSUS”, synchronize with MS (from within WSUS console, yes this is usually not recommended)
    4. Use SQL or PS1 to identify new *unwanted* cumulative rollups (e.g. “DefaultTitle like ‘November%Rollup%'”)
    “unwanted” means: a) you do not currently want to deploy these and b) you do not want their supersedence relationships prevent you from deploying security-only stuff.
    5. Use PS1 to remove the identified unwanted updates from head WSUS; e.g.
    Carefully check for success!
    6. In SCCM console, re-enable SUP controlled sync and do a full sync now.
    7. Verify that
    7a – updates in SCCM do not include those deleted from WSUS in step 5
    7b – updates originally superseded merely by those removed in step 5 are now shown as a) not being superseded and b) not expired. Update icons should be green.

    PROCEDURE B: After patchday (how to prevent unwanted updates *already arrived in SCCM* from doing harm / “what to do if it seems to be too late”)
    1. Disable SCCM SUP-controlled sync schedule temporarily
    2. Backup SUSDBs (throughout your hierarchy)
    3. nop
    4. Use SQL or PS1 to identify new “unwanted” cumulative rollups (e.g. “DefaultTitle like ‘November%Rollup%'”)
    5. Use PS1 to remove the identified unwanted updates *from all downlevel WSUS servers* as in procedure A. Proceed bottom-up.
    Use PS1 to remove the identified unwanted updates from head WSUS as in procedure A.
    6. In SCCM console, re-enable SUP controlled sync and do a full sync now.
    7. Verify that
    7a – updates in SCCM that have been removed from WSUS in step 5 are now Expired=Yes and Superseded=No
    7b – updates originally superseded merely by those removed in step 5 are now shown as being Superseded=Yes (!) but Expired=No. Update icons in SCCM central site console are shown in yellow now. Updates are scanned for and deployable again. Supersedence infos replicated once from SUSDB are still available *in SCCM* but will no longer prevent us from scanning/deploying/reporting.

    Some remarks:
    – Main difference between A and B is that in B you need to drill down and remove the unwanted updates from each and every WSUS in step 5, so that scanning agents are not affected by them.
    – Alex noted that after procedure B the once-superseded updates are Expired=No (good for us) and Superseded=Yes (strange). This seems to be due to the fact that SCCM DB has it’s own database table (CI_ConfigurationItemRelations /w RelationType=6) which obviously is not cleaned when we clean SUSDB. This may look strange in the SCCM console but does no harm, in that agents scan against WSUS, not against SCCM.
    – While it is tempting to simply take some PS1 snippets to .Delete() unwanted updates, care should be taken to really check for success: .Delete() may raise an exception like
    “spDeleteRevision: cannot delete revisionid: NNNNNN because it is still deployed to a Non DSS Target Group”
    In that case use PS1 or WSUS console to first *remove the approval* of the unwanted update, then retry deletion.
    – Should we once decide that we need to deploy the now-unwanted updates, these could be re-imported into WSUS or even implemented using SCUP – thus completely preventing supersedence relationships to be restored again.
    – Note that these procedures do NOT address the problems of those doing full cumulative updates and complaining about deployment windows being limited to ~1 month, i.e. to the time until next patchday’s cumulative updates arrive.

    1. Andreiz says:

      Stefan’s script:
      Cleanup Security Monthly Quality Rollups out of SUSDB

  9. JKHemker says:

    W.r.t. to the first paragraph (“UPDATE 12/5/2016”): Thank you so much for having fixed this – at least for OS updates – in December!
    However, your conclusion (“you do not need to leverage the workarounds noted in the post below”) is technically not correct. The belowmentioned .Delete workarounds may still be necessary for at least the following 2 reasons:

    a) While you fixed the intra-month and cross-month supersedence relationships _between the *2016* updates_, the metadata of the cumulative updates still includes many more unwanted supersedence relationships that prevent us from properly handling older security updates (i.e. published before October). Using latest SUSDB data I compiled a list of those older pre-October OS security updates that are now superseded _only_ by one of the new optional cumulative “*2016 Security Monthly Quality Rollup*” updates. I found
    – 12 old server OS security updates that are now unmanageable (SCCM 2007/WSUS context as well as offline context)
    As an example, “Security Update for Windows Server 2008 R2 x64 Edition (KB3185911)” is ONLY superseded by “December, 2016 Security Monthly Quality Rollup for Windows Server 2008 R2 for x64-based Systems (KB3207752)”
    IMHO deleting the cumulative rollups is still the only option to properly handle these older security updates.

    b) While your promised change has been properly implemented in December for OS updates, the same is unfortunately not true for DotNet updates: We still see 2 supersedence relationships (server only):
    – “October, 2016 Security Only Update for .NET Framework 3.5 on Windows Server 2012 for x64 (KB3188731)” is still superseded by “December, 2016 Security and Quality Rollup for .NET Framework 3.5, 4.5.2, 4.6, 4.6.1, 4.6.2 on Windows Server 2012 for x64 (KB3205403)”
    – “October, 2016 Security Only Update for .NET Framework 3.5 on Windows 8.1 and Windows Server 2012 R2 for x64 (KB3188732)” is still superseded by “December, 2016 Security and Quality Rollup for .NET Framework 3.5, 4.5.2, 4.6, 4.6.1, 4.6.2 on Windows 8.1 and Windows
    Server 2012 R2 for x64 (KB3205404)”
    IMHO deleting the 2 superseding cumulative “December, 2016 Security and Quality Rollup for .NET Framework*” updates is still the only option to properly handle the “October, 2016 Security Only Update for .NET Framework*” updates.

  10. Jane McLeish says:

    I did this procedure last month to deploy November’s security only patches. And was about to deploy Decembers when i saw the update to this article and can conform that i can still see the expired December security only updates in the console (Once i modified the search criteria 🙂 )

    So can i deploy expired updates to my deployments and if so will the clients install them if they are expired?
    Because when i ran the above procedure previously it appeared to remove all the rollups and therefore the security only updates did not then show as expired because the rollups were not there to superceed them. So just wondering if clients will actually install the expired updates.

    – Reading this- below i was wondering if i could actually add them into my deployments without them breaking (Thats why i always removed my expired updates from my depoyments each month before adding new ones in.

    Expired software updates were previously deployable to client computers, but once a software update is expired, new deployments can no longer be created for the updates. Existing deployments that contain an expired update continues to work.

    (Almost at SCCM CB migration stage! 😉 )

Comments are closed.

Skip to main content