System Management Compendium

In my previous article called “SCCM Software Update architecture guide” (check it out here), I described an architecture for software updates within SCCM. I mentioned the use of the update repository to retreive the updates, update lists to administer the updates, templates to take the cut out of potential human errors, deployment packages containing the actual updates and ofcourse the deployments itself. In the article I also described that the current amount of components won’t grow, aside of a single deployment (and package) a year. But how exactly does this cookie crumble?

Update lists & deployment package

Let’s start off by discussing the update lists in detail. The following update lists are available :

Only deploy updates that meet your company’s requirements and guidelines. Some company’s choose not to install Internet Explorer 8 because of potential compatibility issues with certain applications. Basically, the update list drill-down is as follows :

1. Microsoft releases updates at ‘Patch Tuesday’ (2nd tuesday of every month)
2. Updates are evaluated (does an update meet company requirements and guidelines, in other words; can it be distributed within your environment without causing trouble? If so, add them to the update list. If not, do not add them to the update list. By ‘the update list’, I mean the either critical or security monthly update list, depending on the classificaiton of the update
3. When adding updates to the update list, select the option to allow for downloading of the update. When doing so, add them to the relevant deployment package (for information, continue reading this article)

At this stage, you’re only adding updates to the monthly update lists.

Deployment templates

Deployment templates are ‘set and forget, but use them’. Once a deployment template has been set up and tested, it’s time to use them in production. The following deployment templates are used :

The monthly update list, being filled with current windows updates, is dragged and dropped onto a deployment template. By doing so, a wizard will start which will guide you into creating an actual deployment. Mind that no prompt is shown whether or not to download the updates, this is because you’ve already chosen to download the updates when they were added to the update list and there you already chosen the deployment package.

Deployment

When the deployment is created, you will need to verify everything has been set up correctly. You can do so by going into the deployment’s properties and go over all tabs. This deployment will be linked to the pilot collection, after that increment the collection and finally the entire production environment. The goal is to provide the updates to all machines. Once all machines have installed the updates, it’s time to enter the monthly update cycle. This process describes the method of moving the updates from the short-term deployments to the long-term deployments.

Note: In real life, you won’t get 100% coverage of any deployment. If one client is corrupted, it will never return a compliancy status, thus remaining “unknown”. At some point, you just have to decide to move the deployments to a long term deployment for ‘set and forget’-behaviour, knowing updates will remain enforced eternally.

Let’s Cycle!

Here comes the fun part, well ok it might not be fun, but it’s what will make update management easier :

1. Delete the monthly deployment (No serious, delete the deployment)
2. Drag and drop the monthly update lists to any of the long term deployments and go through wizard
3. Move updates from the monthly update lists to long term update lists

This will cause the deployments on machines where the short-term deployment haven’t been executed (completely) to be removed, thus removing any pending updates. However, by moving through the wizard in step 2, you’re ‘reproviding’ the updates to the clients again. This will actually update the deployment, causing a rescan of the machines and eventually being notified of the new (required) update(s). Like I said, this is a set-and-forget method, so no additional configuration is required.