What is Patch Management?

OK...I admit: I've done this a little backwards. I've been writing a lot about the benefits of patch management solutions (see ) and patch management best practices (see ), but I haven't really discussed the basics of patch management. So, in this post, I'll outline a few key concepts of patch management, and define some basic terms.

Patch Management - The Basics

First, let's answer the main question posed by the title of this post. Patch management is the process by which SysAdmins keep the software on the servers and workstations they manage up to date. This involves applying updates - or patches - to managed systems in an effort to maintain the highest levels of security, functionality, and consistency. A lot of this can be done by the end-users; however, the patch management process ensures the updates that get applied within a managed environment actually work with the rest of the software on those systems, and that critical updates are applied in a timely fashion.

That's where the SysAdmin comes in. Admit it: As end-users, it's easy for us to ignore the little popups from Adobe or even Microsoft telling us our software's out of date. Even the polite restart-Chrome-and-we'll-update-it-for-you icon gets ignored by users that don't regularly restart their applications, much less their computers. SysAdmins - by way of a patch management process - reduce this unpredictability by automating the updates they want applied, and systematically disregarding the ones they don't.

To make such a process work, several components come into play. The following are the basic components you're likely to find in any Windows patching environment.

The Update Server

The update server serves two purposes:

  1. It collects updates from one or more software vendors. In a standard Windows patching environment, the update server collects the updates directly from Microsoft.
  2. It distributes updates to managed clients. This part of the process is scheduled on a per-client basis, and is facilitated in part by the Windows Update Agent on each client.

Generally, the update server is either a Windows Server Update Services (WSUS) server, or a System Center Configuration Manager (ConfigMgr) server. In a future post, I'll outline some of the differences between these two options.

The Update Agents

The update agents accept updates from the update server, and then install them on a pre-defined schedule. For Windows systems, this is the Windows Update Agent (WUAgent). If the system is not configured to participate in some kind of patch management process, the WUAgent collects updates directly from Microsoft Windows Update, and then notifies the end-user with that all-too-familiar popup in the task bar. With a patch management process in place, you can decide whether or not to require/allow this level of user intervention.

The Management Console

The management console is where the SysAdmin makes the rest of the process work. This is where you approve and decline updates, and define how you want the WUAgent to handle the updates you approve. Furthermore, the management console lets you define groups of servers and workstations to streamline the approval process and impose a high level of consistency across similar systems.

What About Third-party Patching?

Third-party patching is something that is notably missing from the standard Windows patching environment. Microsoft Windows Update helps you keep your operating systems and Microsoft applications up to date, but it doesn't help you when it comes to patching Firefox, Adobe products, or Sun Java. That said, the WUAgent is particularly well-suited to handle updates from these and other third-party vendors. So, if you publish updates from these vendors to your update server (WSUS or ConfigMgr), the WUAgent on your clients will "see" those updates and apply them when they're approved and applicable for the client.

This is not a simple as it might sound, however. In order to publish a third-party update to a Windows update server, you have to also publish some metadata along with it. This metadata includes rules that define the type of clients to test for applicability, and then specify what constitutes whether or not the update is actually applicable. Furthermore, the metadata defines how the WUAgent should handle the installer for the update: Should it reboot the client before or after installing the update? Does it need to stop any processes before it can start the installer? and so on. Configuring these update packages can equate to a lot of work for you, especially if you're working with several third-party updates, or even just one or two that require a lot of work from the WUAgent (patching Java is a good example).

Bridging the Gaps

A good patch management tool is an efficient patch management software that can help bridge the gaps inherent in the shortcomings - some discussed here, others not - in the standard Windows patching environment. For example, SolarWinds Patch Manager, your very own patch management solution, can help bridge the third-party-update gap by providing a collection of pre-built, pre-tested packages from tens of popular third-party vendors. Patch Manager also provides deployment flexibility beyond what WSUS or ConfigMgr provide natively. Namely, with Patch Manager, you can deploy updates on demand - you no longer have to wait for your clients to check in with the update server, you just tell Patch Manager to push the update. In a similar fashion, Patch Manager can even deploy full-installer software packages to clients that don't even have the software yet.

To see how Patch Manager, the efficient patch manager software can help you implement a powerful, yet flexible patch management process, check out our interactive demo or download a free trial.

  • NCM - Network Configuration Manager (Cirrus) - My mistake.

  • I spoke with Andrew, and he suggested the following reboot order for your servers:

    1. SQL Server
    2. NPM
    3. NCM (assuming that's what you meant by "NPC")
    4. NPM Addl Web Servers
    5. Failover Engines
  • Also, regarding how to automatically apply the WSUS updates and restart the servers, you might want to check out our Patch Manager product, referenced in my post. Andrew can comment upon how frequently you should update/restart your NPM server, and in what order; but if you're looking for a way to automate patching your servers (NPM or not), Patch Manager's a good solution for that. Plus, we just added a Patch Manager view to the Orion web console, so you'll be able to integrate Patch Manager with your existing NPM deployment.

  • Thanks for commenting. This is a good question for one of our NPM writers, so I'll pass it along. In the meantime, you might want to check for help and suggestions from the NPM community here: .

  • I have inherited Orion and just getting started using it. I was told this morning our servers are handled manually by the sys admin (me) to install server updates and reboot when required. I was also told that the Orion Servers must be restarted in sequence. I could really use some help with "best practices" on this. We have individual VM servers, for NPM, NCM, SQL Server, 2 failover engines, & NPM additonal Web Server. My thought is to write a small script to apply the wsus updates, and restart the servers at different times over 45 minutes. Appreciate your feedback.