System Management Compendium

At my company my latest project was to completely revise the Windows updates process within SCCM. The architecture was in place, the process was in place, but both were far from managable.  In this post I’ll describe both the old and motivation to changes I’ve made.

Bad, ugly and all that’s negative

When it comes to managing Windows updates, one of the most essentials questions you need to be able to answer is ‘ What’s the overall compliancy for 2009 security updates?’ and ’Are we distributing update KBxxxxxx? But also a very simple question as ‘What update languages are we deploying to our servers?’ In our old situation we weren’t able to answer any of these questions.

When I said there was a process in place, people didn’t even knew what process. Some people were working on the Windows update deployments some random times during a month and the end result would be an environment that had been provisioned with some Windows updates, most of them weren’t even tested.

Some day during a month, mostly the third thursday of the month, during evening hours people would gather and install Windows updates to server machines. However, when an update caused problems, many bad decisions were made in such a situation by the wrong people, resulting in even more trouble or even sometimes a server needing an OS reinstallation. In other words, there was no escalation process.

This all came down to a faulty software update architecture within SCCM, WSUS was set up properly, so I’ll leave that out of the discussion.

Changes

After much deliberation I decided it would be best to completely redo the configuration for Windows updates, starting off with deleting everything in SCCM under the ‘Software Updates’ node.

The second major change was to set up a number of Update Lists (UL). These UL’s could to quickly determine whether or not an update is being distributed by us, plus UL’s can be used in some reports to determine compliancy of the containted updates. UL’s would be ordened in a yearly order for security updates and critical updates would be stored together. Aside of that, monthly updates would be placed together for the ease of administration.

Next were the introduction of Deployment Templates. Why should you use them?  Well, it’s pretty obvious, with deployment tamplates you eliminate the change of human errors. I chose to create two templates, one for servers and one for clients. Templates are linked to specific collections and since we have multiple staging collections, we need to divide servers from workstations. Aside of that the reboot settings, scheduled installation and deadline settings differ for servers and workstations. So many differing settings that pose potential errors, all eliminated by the use of templates.

Then it was time to revise the way updates are stored on the local disk. In the old situation, all updates that were caught up in a deployment were stored in a separately created deployment package. So all deployments had their own deployment package in their own folders on the disk. Talking about easy management, this is not it! As with the UL’s, I made 5 deployment packages. Security for each year (2006-2009) and criticals all together in a single package. Reason for this division is the limitation of 255 updates per deployment.

Finally, the deployments. I’ve created quite a large number of deployments, but that’s basically because of the same reasons as the deployment template separation. It comes down to separate deployments for 2006-2009 security updates and monthly updates. All in duplicate, because of the different settings for workstations and servers.

So?

Basically what’s created is as follows :

Software Update Hierarchy

How to use this? well check this post