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
The PDQ ecosystem
By combining PDQ Deploy and PDQ Inventory we can create an automated package “baseline” that requires minimal to no user interaction. In this example, we’ll use NotePad++ and create a baseline.
Taking inventory of patching statuses of applications
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!
Creating the dynamic inventory group
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.
Download the auto-update package
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.
Setting up a patching schedule
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.
Set it, trust it, and verify everything
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...
Send yourself auto report emails
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.
Additional considerations
Custom packages:
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.
Test 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:
Static List
AD group
Logged on users (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.
Now it’s your turn!
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 next morning. 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.
