To ensure a predictable rollout once a patch is deployed across your network, you should test it in a non-production...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
environment. Tests are likely to detect any conflicts with existing configurations unique to the systems in which the patch will be installed.
First, identify which security issues and software updates are relevant to your environment, and determine whether the risk of not installing the patch mitigates the cost of installing it. Prioritize which patches are urgent, and schedule and deploy them before those less critical. Develop a business application profile. This helps assess system importance, allowable downtime periods and vulnerability risk levels. You should also consider vendor-reported criticality when calculating a patch's significance.
Once you have obtained a patch, verify its source and integrity. A digital signature is typically used to complete validity check. Once a patch has been validated, it is usually placed in a test environment. Ideally, you should create a test system that is identical to your production system. This allows you to verify that applying the patches will not result in unexpected or undesirable system behavior.
Virtualization can be a valuable part of your patch testing strategy because you can replicate various production environments on one computer, preferably using the same hardware. Running several operating systems "virtually" can save you time, money and space. Two leading products within the virtualization market include VMware GSX Server and Microsoft Virtual Server 2005.
It is important to expose the patch to as many scenarios of system usage as possible. Look closely for unanticipated changes within the test environment, such as:
- Program failures
- Changes in permissions
- Newly disabled services
- Newly enabled services
- Disrupted services
- Negatively affected code
- Any other application failures
If testing produces an unsatisfactory result, you must identify the root cause of the problem before going any further.
Production rollouts can be considered an additional part of the testing process if they are done in stages. The initial rollout should be to less critical systems, and if they perform as expected you can continue with the rollout until all systems are updated. The testing process can be considered finished when the full rollout is complete and there are no reported issues within a week.
Even with a thorough testing program, it is wise to have a contingency and back out plan in case something goes wrong during, or as a result of, the application of a patch or update. Change management is vital to every stage of the patch management process and updates must be performed and tracked through the change management system. Your Change Management Policy should describe the processes that will be used to identify and deploy patches, and the ownership of each step in the workflow.
Dig Deeper on Microsoft Patch Tuesday and patch management
Related Q&A from Michael Cobb
Microsoft collects data using Windows 10 telemetry features. Expert Michael Cobb explains what type of data is collected, and whether enterprises ...continue reading
Some malicious apps can hijack smartphones and expose those devices with open ports. Expert Michael Cobb explains how this happens and how users can ...continue reading
Smartphone users could be at risk of memory corruption attacks because of a baseband vulnerability. Expert Michael Cobb explains the attack and how ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.