In System Center 2012 Configuration Manager, we’ve added the capability to automatically remove software update content from distribution points when that content is related to expired updates. This process helps manage drive space on your distribution points by removing any content you no longer need. It’s particularly helpful for Endpoint Protection definition updates, given their frequency of release, deployment, and expiration. In this blog, I’m going to walk you through exactly how the process works, and I’m also going to provide a script you can use to clean up source locations related to obsolete updates, as our out-of-box process does not manage source content.

Expired Updates and Deployments

The first part of the process for managing content related to expired updates is getting expired updates out of any deployed update groups. First, we never delete any expired update associated with an active deployment, as we don’t want to remove anything associated with your deployments. It could be disconcerting if updates simply disappeared from your deployments and you had no idea why, so we just don’t do it. The step to make expired updates removable, however, is straightforward, and it should be part of a monthly process. To remove expired updates from all deployments in only a couple of clicks, do the following. Note: When using Auto Deployment Rules to deliver definition updates, where you should be re-using the same update group each time the rule runs, expired updates are automatically removed from the update group each time the rule runs.

Navigate to the All Software Updates node under Software Library, and search for all expired updates.

Add the value for expired updates to search, leave the default value as “Yes”, and click search.

The search results will include all of your expired updates, so simply select all updates in the list view (CTRL+A), right-click, and choose Edit Membership.

You will then see a list of all Update Groups where any of the selected updates from the list view are members. Simply uncheck the selected check boxes.

Click OK to remove all of the expired updates from the selected Update Groups, and they’ll be ready for deletion through the process outlined in the next step.

The Delete-Expired-Updates Process

Next, there are four phases to removing expired updates and its related content, and those are: the expiration action, tomb-stoning, deletion, and then source cleanup, which is a scripted action. At a high level, updates that have been expired and that aren’t part of an active deployment will be deleted 7 days after they are expired. There is no specific or configurable maintenance task to do this—it’s an automated process that crosses multiple ConfigMgr components. Let’s walk through the process at a detailed level so you understand how it works.

When a full software update point synchronization runs, updates are expired. A full software update point synchronization is a scheduled synchronization, not one initiated through the console, which is a delta synchronization. Only full/scheduled synchronizations expire updates.

Full synchronizations expire updates for the following reasons:

Updates expired by the publisher.

Updates superseded by the publisher (and outside of the “keep superseded updates” time that you configured for the software update point).

Updates declined or missing from WSUS.

You can see expiration activity in logs, through wsyncmgr.log. Look for a line in the log that looks like the following:Removed 106 unreferenced updates SMS_WSUS_SYNC_MANAGER 3/30/2012 12:06:15 AM

Expired updates still show up in the console, but they are marked as expired, and have the following icon showing this state: They will remain in the console for 7 days following expiration, where the next process around cleanup starts.

After 7 days, expired updates that are not associated with active deployments, are tomb-stoned. This means they are no longer visible in the UI. Again, use wsyncmgr.log to view the removal of these updates:Deleting old expired updates… SMS_WSUS_SYNC_MANAGER 3/30/2012 12:06:16 AM Deleted 80 expired updates SMS_WSUS_SYNC_MANAGER 3/30/2012 12:06:20 AM Deleted 80 expired updates total SMS_WSUS_SYNC_MANAGER 3/30/2012 12:06:20 AM

Finally, distribution manager checks every hour, and removes any Distribution Point content associated with update CIs that have been deleted by objreplmgr.

Now that both metadata and distributed content for expired updates has been removed, we need to go ahead and cleanup the source directory, which can be done with the script at the end of this blog.

Simply create a VBS script from what’s provided below, and run it on the top-level site server (CAS or standalone Primary Site). Because of formatting issues, line breaks were inserted at the locations indicated by [CR]. Please remove them before executing the script. Some notes on the script:

Make sure you have rights to the content source (from the site server you are running the script on).

The script deletes source content for any update that no longer has an associated CI.

The source directory cleanup will not necessarily map to date-time stamps in the source directory. Some binaries are chained to other binaries, for which there may still be a CI reference in the database. In other words, if you cleanup Endpoint Protection definitions, yet the source directory still has files and folders older than 7 days, then those files still have active CIs and are needed (don’t delete them manually).

Finally, the script looks for source content that is definitively not needed by a referencing CI, and it removes just that source content.

Wrapping Up

Expired update and associated content cleanup in Configuration Manager 2012 is a built-in mechanism to help keep your console, database, distribution points and (with the script) source directories as clean as possible. Hopefully, you better understand the manual steps required to do this, as well as how all of the automated pieces work together to manage expired updates and content.

for each i in WMI.ExecQuery(“select pc.* from SMS_PackageToContent pc left join [CR]SMS_CIToContent cc on cc.ContentID=pc.ContentID where pc.PackageID=””” & Pkg.PackageID & “”” and [CR]cc.ContentID is null”)

For the installation of SCCM 2012 SP1 the following components are required:

Deployment Tools

Windows Preinstallation Environment

User State Migration Tool

After resolving all errors it’s time to kick of the installation. However, before starting, make sure you’ve created a fresh backup of all site servers, packages and other settings.

In the Setup wizard pick the option to ‘Upgrade this Configuration Manager site’

Enter your license key on the next page, accept the licens terms for SCCM and the additional software prerequisites and provide a (UNC) path to download additional setup files. If you’re planning to upgrade multiple site serves it’s highly recommended to download these files to a central location in your network that is accessible by all site servers. This way there’s no need to download these installation files for other site servers.

When the extra files are downloaded just click through the rest of the installation wizard and start the update. By pressing the “View Log” button on the setup wizard windows you can follow the log file during the upgrade.

The Service Pack can be applied to an existing SCCM 2012 installation. To kick of the installation start the prerequisite checker that is included with the new install source on all site servers. This will verify your current settings with the prerequisites for SCCM 2012 SP1.