Patches? We don’t need no stinkin’ patches! … Wait, yes we do.
However, it’s important to tread carefully when applying them.
Patching and updating and service packs and firmware
There are lots of terms that define the incremental software and hardware updates that our systems need. What systems are we talking about? End-user devices (desktop PCs, laptops, tablets, smartphones) and also anything that touches your network (servers, storage arrays, switches, firewalls, routers, Wi-Fi access points to name a few).
Patches and updates can generally be broken down into these three categories:
- Firmware updates (permanent software on the device or component, system BIOS updates for example)
- Operating Systems (Windows updates for example, iOS updates)
- Application updates
Major vs. minor updates
Software and firmware are generally versioned with a major release number (Ver 1.0) and a minor update number (Ver 1.1). A minor or “point release”/”dot release” increases the number after the decimal point. Minor releases tend to be less risky to apply, although that is not always the case.
Major releases might impact related software and require updates on those platforms as well (i.e updating VMware vSphere from version 5.0 to version 6 might require Veeam Backup to be upgraded to a later version to remain compatible.) Read the release notes before updating to be sure.
Why patch at all?
Like fabric patches used to mend holes in your favorite jeans, computer system patches often repair flaws or bugs in computer system code as well as to enable new features. Patching and updating on a regular basis helps to avoid exposure to malware and increase system stability and performance.
Tips for before you patch
Read the release notes before you even decide to apply the patches/updates and then do some research. The release notes will detail bug fixes and spell out compatibility. In your research, you’ll come across articles if there’s some sort of issue with the software that may make you think twice about it.
Test the patches/updates in a dev environment first. Take note of these things: if it worked or not, how the update process went, and how long it took (helps you plan your maintenance window for production). We can show you how to set up a dev environment to do this with if you’d like.
Make sure you have good and recent backups. If something goes awry, you’ll have them to roll back to.
First is not always best: sometimes patches and updates are not fully regression tested and can cause additional problems.