Patching is like oatmeal, it’s good for you, but no one cares except your mom. If you’ve been in the sysadmin trenches for any length of time, you understand that patching is necessary, and “no news is good news.” Good patching should go unnoticed.
We patch primarily for three main reasons:
Security - Keep out bad guys
Features - New things that help users
Consistency - Supporting one software version is easier than 30
In this blog we’ll learn how to:
Take inventory of the patching status of an application.
Identify/create Dynamic Groups that target the computers needing the patch.
Download/create the package to deploy.
Create a schedule and identify triggers, targets, and packages.
Create a report for Compliance Status.
Create an Auto-Report to email patch status at regular intervals.
You don’t need to fix what isn’t there. The first step is knowing what software packages you have. PDQ Inventory can help answer these questions:
I can search for NotePad++ using the default Application Counts Report and find:
I see that I’ve got 134 installations of the software and both 32Bit and 64Bit versions. For me, if it’s over ten installs, then I choose to set up a baseline for it. Your threshold may be different. Now, I want to see the distribution of versions I need to work with. Using the default Applications Report I can search for NotePad++ and find:
I have quite a few different versions. So we need a baseline to keep this software up-to-date!
Good targeting is the key to a successful baseline. Use the built-in applications count report to search for what you’re trying to target. For NotePad++ we will use the built-in group, but you could also make your own group as well:
Notice the different groups as they relate to versions. PDQ publishes new variables for these versions that are updated as a new package comes out. Keep in mind that you also have the option to create custom variables to support custom packages.
Navigate to the Package Library in PDQ Deploy and download the NotePad++ package as an auto download.
I prefer to let the rest of the world test new software before it hits my client machines, so I like to wait three days before I automatically download it.
Click on All Schedules in PDQ Deploy and create a new schedule:
I like to name my baselines with a prefix of BASELINE simply for organization and to differentiate from temporary schedules. I also like to use a combination of daily and heartbeat triggers as a catch all. The idea is that I can deploy to all desktops (or laptops if they’re there) at 7:00PM at night or whatever is appropriate after-hours for your company. Then, I use a heartbeat trigger a half hour later that is active to deploy to laptops that start checking in the next morning.
On to Targets: Choose PDQ Inventory / Collection
This is an important decision point. Do you only want to patch existing versions of the software?
Choose OLD Groups ONLY ( Custom groups I’ll often Name VERSION LOW).
Or is it really important and you want it on every system as a corporate standard?
Choose OLD and MISSING Groups.
In my example, I want to enforce this on all machines. On the packages tab attach the NotePad++ package you downloaded.
It’s Monday morning and I’m called into an emergency security meeting. The IT director and the security guy want to have a “friendly chat” and do their job of making sure I’m doing my job. I know I have everything set, but I need a way to show it...
In PDQ inventory, create a report then link it to an Auto Report on the current state of an application.
Under Columns, I just chose Computer Name. You can add more if that’s applicable to your situation. Under filters, I added our four groups that are flagged for being out of compliance. Now, create an Auto Report and attach the report you just created and email it every Monday at 8:00 am or weekly, whatever is appropriate.
These reports accomplish two things:
I have an email letting me know specifically what has not been patched yet and if a deployment requires my intervention.
The emergency meetings stop when I start sending regular reports to the IT Director and the security guy. It shows them that I’m organized and proactive toward security.
For the simplicity of this article, we used a pre-built package. You can do this with custom packages as well with software unique to your business. The additional requirements include building and maintaining your own packages and setting up dynamic groups for specific software. I recommend checking out this short video on custom variables to use with your dynamic group.
This will be a future blog with more detail, but I want to encourage you to think about integrating a test group into your patch cycle. The basic concept is creating a cross-section of computers in your organization and making a pilot group. A pilot group can be identified by:
Logged on User (careful of Conference/Lab/Kiosk computers with this strategy)
Consider having two auto-download packages, one for the pilot group for immediate download and the other three to seven days later.
It seems like a lot of work upfront, but when there’s a critical patch released you can go home and forget about it until the nextmorning. You get the evening back with your family and can walk in the next day to tell your boss that you’re testing machines and the updates are scheduled for deployment in two days.
Happy family, happy boss, and more time to automate other things. So go be awesome!