SCCM Software Update Point Configuration

The Scenario

When configuring SCCM as a Software Update Point (SUP) there is one particular setting you should pay attention to:

SUPConfig

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.

  1. 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.
  2. 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.

SUPConfig3Months

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.

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s