Reactive patching has some important disadvantages as compared with proactive patching. The process of identifying a problem fix can be made more difficult as your system falls further behind the most recent patch levels available. In addition, the required patch will likely contain much more new content than if you had performed frequent proactive updates. You might also find it difficult to perform adequate testing in reactive patching situations, and this could lead to the introduction of additional problems.

Acquiring patches for reactive patching

The easiest way to identify your required patch is to call the HP Response Center. This works only if you have the appropriate support contract. Alternatively, you can carefully research the problem using resources such as the ITRC. The ITRC's self-solve tools, such as the search knowledge base link, can help with that query. For more information, see Chapter 6: “Using the IT Resource Center” (page 55).

Next, using the ITRC Patch Database, you must identify the patches needed to resolve the problem. For reactive patch management, patch acquisition and installation should be strictly limited to the smallest set of patches believed to provide a solution to a current system problem. Do not use the unplanned down time as an opportunity to make unrelated changes. This is especially true for mission-critical systems.

Once you know what patches are needed to solve the problem, you must determine when to patch your system. In making this decision, you should consider the following factors:

Severity of the problem

Frequency of occurrence

Availability of system down time for patching

Follow these steps to patch your system reactively:

1.Isolate the problem and identify the patches with the highest HP rating that represent a potential fix.

2.Acquire the needed patches and any patches needed to satisfy dependencies.

3.If you have a patch depot, add these patches to it and use this as a test base.

4.Test the patch. In some cases the problem is so serious (such as a when a critical system is down) that you might need to omit the test step. This is especially true if it takes a long time to replicate the problem, or if the configuration is difficult to replicate. If you choose to omit testing, do so only with the knowledge of the risks you might incur.

5.Determine a suitable time to install the patches.

6.Install the patches.

If you have multiple, similarly configured systems and you need to patch one of them reactively, consider patching the remaining systems as soon as it is reasonably possible. This is because it is likely that your other systems will suffer the same problems at some future point. Additionally, there are benefits to maintain the same patch level on similar systems.

Advanced topic: security patching strategy

Security patching requires both urgency and a need to be proactive. It does not fit neatly into the proactive or reactive patching strategies. At times, you might need to apply security patches proactively prior to the next scheduled patch installation maintenance window.

When you use the ITRC to acquire patches, it is safe practice to obtain patches listed as recommended. Because of the urgency associated with security fixes, there are many instances when a security patch is too new to have this rating. However, many customers give a new security fix priority over an older patch recommended by the ITRC. Because most patches that fix a security problem fix only a single problem, this practice is not as risky as it might seem.

50 Patch management overview