It’s here — that time to patch your endpoints. Maybe it’s something you enjoy, but my guess is probably not. Patching can be a brutal task, and with many organizations still doing it manually, they’re spending more time and resources on patching than anyone really wants to think about.

Now, given the fact that you are going to spend all that time and resources on patching, you want to make sure it goes smoothly. No one wants to expend all that energy on patch management, only to find themselves in a tangled web of confusion and failures.

So, let’s make sure you don’t fall into these top two most common monthly patch problems:

  1. Do your patches work?
  2. Have you tested the patches in your environment?

Patch problem #1: Do your patches work?

It’s not uncommon for security patches and updates to simply fail. Sometimes, it’s because of a unique environmental issue. Other times, the patch itself is just bad. 

It’s a good thing you decided to check that patch before deploying it blindly, isn’t it? But now that it’s failing, what can you do about that? Well, it depends.

Solution 1: Contact your third-party patch management company

If you use a third-party patching company to manage your patch updates, then they’re the first ones you’ll want to reach out to. 

Although companies who manage third-party patching vigorously test the content they push out to their customers, they can’t test every use case scenario. You might have an edge-case set up — or your endpoint is handling the patch differently than the third-party patch company expected. 

Whatever the reason, your vendor should always be your first action. It’s not only important to report the failure so you can get it fixed, but it’s helpful to that third-party patching company, too.

You might have found a systemic issue. You’re now the hero that alerted the company about a bigger issue they can rally around and fix quickly!

Maybe it's not systemic, but it’s enough of a common problem that you’ve now helped that company be better prepared for future calls from other customers. Not to mention, you’ve now given them a potential new use case scenario that can be added into their default testing protocols!

Solution 2: Check with your broader online community for possible patch problems

But what if you’re not using a third-party patching company? Let’s say that your organization manually sifts through these patches.

There are some great online resources to see if other organizations are having the same issues, too, including:

Regardless of which avenue you decide to take, there are many options to pick from when it comes to identifying what went wrong with the failed patch.

Patch problem #2: Have you tested the patches in your environment? 

Alright, you’ve decided to test every patch that comes through — excellent! You’re in the clear, right? 

Nope! 

You also can’t forget to test the patches you’re going to push out on pilot devices from across your organization. 

Why, you may ask? It’s just a simple Chrome update after all. But is it really? 

Introducing a new patch to your systems is no different than introducing a new pet into your home. Even if you have had a pet before and are confident you know how to take care of it, each will have its own reactions to rooms or people that your previous pet didn’t have.

Similarly, each patch has its own nuance of changes and updates. These can often contradict what your systems or programs are designed to do, breaking the environment or the patch’s efficacy, even if it passed your earlier testing.

Software companies don’t patch products with your systems in mind, after all. They focus on updating and patching their own applications, and they can’t focus on all use case scenarios.

Resolving the domino effect of patch problems

Having a dedicated pilot group of endpoints to test these updates on can ensure you aren't breaking systems, programs or even processes your company depends on. The domino effect of one small patch update can be detrimental to a company’s operations. 

For example, in early April, Chrome rolled out a patch to address some bugs. But it also introduced new bugs, one of them affecting the printing capability out of Chrome. 

What if your organization works in a print-heavy environment, where being able to print through Chrome is a must-have option for your operations? 

In this way, testing out all patches — even small insignificant ones — can help you avoid catastrophe. 

Remember, when something goes wrong, errors ripple through the initially impacted department or user. Most users and organizations don’t think about the downstream impacts a small patch can take if it’s not fully tested. After all, it’s often IT who cleans up the effects of a failure or outage.

So, when it’s time to patch, we want to set ourselves up for success. To do that, we find a solid variety of endpoints to test our patches on — to ensure we’re not setting up an avoidable downstream impact – and we're also ready with our community resources in case the patches end up failing. 

You can also check out:

Sometimes, the best patch management strategy is just simple good ol’ preparation. Good luck!