Patch management for the data center is approached in a different manner than for enduser systems. Typically for enduser systems we throw everything available at them. With a nominal amount of testing, it’s unlikely that any adverse results will be encountered; even if they are, the impact is typically restricted to a few users. Systems in the data center cannot afford such an approach. If a server in a data center experiences issues as a result of a dysfunctional patch, this could negatively impact business operations for several hours.
The first step is judicious selection of the updates to be deployed and which systems they are deployed to. While the idealists would have a clone of every production machine in a testing lab, realistically this is not practical. In some cases, risk mitigation involves a conversation between what a patch is supposed to fix vs. what happens if the patch is problematic due to unexpected results.
Newer operating systems have become much more granular with respect to the ability to install or not install and selected functionality, and as a result this has reduced the number of patches that need to be applied for functionality that’s not being used. But still, there are patches that can be completely ignored for server operating systems, and should be.
Perhaps a more practical consideration, that unfortunately does not follow the concept of granular installation, is the ubiquitous nature of the Microsoft .NET Framework on every server operating system. If you’re not using the .NET Framework on a given machine, is it necessary for you to patch it? This is a question that should be evaluated on a case-by-case basis for every machine, comparing the risk of the patch against the risk of not patching.
Testing the deployment of updates is an important part of a patch management strategy, but no matter how elaborate your testing strategy might be, at some point it will fail you despite your best efforts. Don’t get bogged down in the weeds when doing testing, and keep your ears open to trustworthy communities for others who may similar experience issues. Testing also provides feedback on how long it will take to install certain patches or sets of patches, and this information should be fed into your deployment operations plan.
Deployment: Scheduled or On-Demand
This is the question: Whether to let the machine patch itself using automated processes, or whether to supervise the patch installation using the IT team.
For small data centers it may be practical for one or two administrators to supervise these activities interactively via remote connectivity. For large data centers, interactive installation does not scale.
If you plan to schedule the patch installations, careful coordination of which systems are patched on what days, or at what times, may become the bulk of the effort in this process.
Monitoring to ensure that patches deployed are successfully installed, and stay installed, must exist. It’s also important to distinguish reporting between those updates that should be installed but are not, as opposed to those updates that should not be installed (and thus never will be). Reports should focus only on the former group. Cluttering up the report with information about updates that will never be installed may mask useful information that needs immediate attention.