Joseph Hinkle at MyITForum.com

I spent most of the day today finalizing our patch management policy/strategy. It has been an interesting evolution for me, since I've watched the process grow from the basic patch management I was doing in SMS 2.0 to the well-tunes process I outlined for my staff today. While the tools have gotten better - and much more reliable - the process has not changed that much in my organization.

Our users, like most, have little tolerance for much of anything. I work for a manufacturing company, so spending money on a wake-on-LAN solution was never an option. We've experimented with different timings, patch groupings, and other mind tricks to help with the process. Today, I finally realized what I didn't like about our existing process.

Essentially, the process was unmanageable. Clients got advertisements they didn't need, resulting in unnecessary inventories. Patches weren't grouped into appropriate sets that made it easier to transition to a maintenance mode for that group. Clients rebooted multiple times, depending on different configuration items. In other words, it was bad. I was never really challenged on it because of some extenuating circumstances - the same ones that pulled me away from posting here for a year and a half - but that's all better now and I have time to focus on process improvement.

Tomorrow, I'll post a sanitized version of the result of my work, along with some queries that I'm using to build the collections that we're distributing to. I'm sure that someone is doing something better and, if so, I'd love to hear ideas for improving the process. If nothing else, I hope that it can serve as a starting point for a patch management policy and procedure for another needy admin.