In the previous part of this blog series (PowerShell – The Patch Solution – Part 1) we introduced The Patch Solution. Simple, elegant, but yet empowering! In this post, I want to talk about some of the issues I’ve seen and heard about around patching. After you understand this, you’ll have a deeper understanding of The Patch Solution.

Headaches

It sounds sound simple. Microsoft releases patches on the 2nd Tuesday of every month. This has gone on for years. In the industry, it has the well-known name “Patch Tuesday”. New patches come out, download them, and install. Where is the headache in that? It’s predictable, it’s routing, it’s simple – Windows downloads and installs.

Simple questions that get asked:

  1. Which updates SHOULD I apply (Critical, Security, Drivers)
  2. Which updates DO YOU apply? Why?
  3. How long do I wait before installing them?
  4. Why deploy them into a DEV or QA environment if no one actually uses those environments?
  5. Which service should I use?
    1. Microsoft Windows Update
    2. Windows Update Service (WSUS)
    3. SCCM
    4. 3rd party
  6. How do I patch my cluster nodes?
  7. Do I know when I can update/patch/reboot computer x,y z?
  8. Will anyone object to automating patching?

After reading the questions above, you probably have some answers, or even all. But I’m willing to bet that you can find someone you work with that will argue with you! This is where the headaches come in. It’s not all cut and dry, especially when taking into account different environments, DEV, QA, Production and the role of each computer. Pretty simple to understand that you don’t reboot all the nodes in your IIS farm or all of your AD servers simultaneously.

Delivery Vehicle

This is exactly what Microsoft provides. They provide a simple and easy way to retrieve patches and install them. The patches are just there every Tuesday. Microsoft doesn’t know anything about the internal workings of your Windows infrastructure, your maintenance windows, change freeze periods, etc. All they can do is provide a simple way of publishing changes to the products you use. They also provide a mechanism within their OS software to apply these updates. When and how, well that’s completely up to you!

Push Back

As we know Microsoft releases updates and patches every Tuesday, what we need to think of and design next is our Update or Patching strategy. More often than not people are confused by my question #8 above, Will anyone object to automating patching? Oddly enough, there are people who love getting paid to work late over time hours and watch a ton of progress bars and rebooting computers. Can I get paid for that!? From my personal experience and helping organizations achieve their patching, I will say that automating patching has rarely become 100%. This means that there are some machines that will still need to be coddled and babysat for patching.

So why worry about automating patching? Well let’s look at it like this. If you have 100 machines, and you only end up patching and checking 30 machines every maintenance window, it could take you quite a while to get all 100 machines patched within that month. When we automate things, I like to strive for patching 75% or higher of server machines. This means that there are 25 machines that will require someone to work late and get paid overtime. People with hundreds or even thousands of servers, this is painful and very expensive. I hope most people are of the mindset of myself, let’s do something more productive with our time and most importantly, something more proactive for our company and career!