When configuring SCCM as a Software Update Point (SUP) there is one particular setting you should pay attention to:
So what happens when the SUP is configured like this?
I’m glad you asked!
This settings tab is designed to help you keep SCCM/WSUS cleaned out. When these settings are configured in SCCM, upon seeing a new superseding update, it will remove from its catalog any update that has been superseded completely from your view. The particular problem this introduces is two-fold.
- The patches have been removed from SCCM, so you cannot search for them in the Software Updates node, making it impossible to quickly determine if an update was previously deployed and compliant through the All Software Updates node.
- Some environments deploy patches one month behind due to Microsoft’s known QC issues. In this scenario this configuration will keep those all-important monthly security rollups from deploying.
Why does scenario #2 happen, you ask?
You obviously know how to ask great questions!
Let’s say your ADR runs late on Patch Tuesday in month 1 to create the deployments and said deployments are made available roughly three weeks out. No problem so far. Let’s say you patch on the first and second Sunday of the month and that month 2 begins on a Monday. This means that Patch Tuesday will fall in between your deployments that were made the previous month.
If SCCM is configured as it is in the above picture, your first patch deployment targets will receive the monthly security rollups from the previous month. But, because Patch Tuesday occurred in the middle, it now sees the current month’s security rollups that typically supersede the previous month’s security rollup patches. SCCM then goes and removes the superseded patches from its catalogs and deployments and your second group can no longer download and install them. This means your second group will show compliant against the deployment, but the SUG was changed after Patch Tuesday and is now unreliable.
Why does this setting exist?
As I mentioned above this setting is designed to help keep the SCCM database and console clean and if you managed updates in SCCM 2007 you know how much work this setting saves you. So what should it be set to? Usually 3 months is good, but here comes the standard *YMMV disclaimer* and you should evaluate the needs of the environment being managed and set it accordingly.
With this setting change an update will expire and clear out after it has been superseded for three months, but will give you a window in which you can view historical compliance easily without having to resort to running tons of reports.
P.S. Yes, a superseded update will still install as long as the client cannot see the superseding update.