Testing patches before deploying them to all of your production machines can be a tedious task that few want to do, but it is a crucial part of keeping your network as secure and bug free as possible. While no company releases patches to break their product it does happen from time to time. There are several methods for testing patches; one method requires you to look at each individual patch and approve it for deployment after careful research, another method is to have a test group of computers that get deployed patches before the rest of your environment does.
The first method is fairly straight forward, what you will want to do is have a manual patch label, created under “Label Management”. This manual label can have patches manually added to it on the Patch Listing page, the Patch Listing is located under the Security Tab. This will show you all available patches that you can choose from to add to this label. What you do next is simply click the check box to the far left of the appropriate patch(es), then click the Choose Action drop down box and select Apply Label and viola your label is now updated. This allows you to have a great degree of control over what patches are applied to the machines in your environment.
The second method is a bit more hands off, for those that don’t have the time to go through all the patches one by one you can set up a patch smart label for testing and another for production machine deployment. The way this works is you create a Patch smart label, targeting the appropriate patches you wish to deploy for testing. Next you create another patch label with the same criteria with one extra item, select “Release Date” “>” “DATE_SUB(now(), INTERVAL 30 DAY)” and create the label, name it ex. OS Patches Greater than 30 days Old. Next you will need to edit this label, to go the Home – > Label – > Smart Labels and select the label you just created by clicking on it. Once you’ve clicked on it, locate the ’DATE_SUB(now(), INTERVAL 30 DAY)’) and remove the quotation marks before Date and between the last to parenthesis. This greater than 30 days old will be your production patches because it will allow you to deploy the first label that includes all patches regardless of age to a test group of machines and if there is an issue you can catch it before it goes company wide. What you can now do is take the standard label and deploy it to a group of computers in various departments for testing (or use a labels that includes your standard testing machines), if your other deployment labels are also including a variation of this for GREATER than 30 days- your automated testing of the patches has 30 days before it goes live for deployment to the rest of your network, so you have 30 days to catch any issues that are caused by a particular patch. Adjust INTERVAL 30 DAY to INTERVAL 10 DAY or any other number that you wish to set your release cycle to.
These are just two methods of testing patches before they are deployed to your environment, they vary in the amount of automation for the deployment and both offer better flexibility and security than just simply deploying patches and hoping for the best. In many environments we see that “testing” amounts to deploying the patches to the IT staff to see if it breaks anything. If not, it just rolls out to the rest of the world. The challenge with that and similar methods is that you’ve forgotten that you use your machines differently than the end users; if I update office and open Word and Excel and say it’s all good, then roll it out to a group of Publisher and Access users and there’s an important feature that’s broken… we might well create more work for ourselves to undo the patch, and worse- we’ve impacted the users. Testing across multiple departments and business functions is ideal if possible. Many companies are taking a tiered approach based on our Label automation noted above- IT First for 1-3 days, Testing Label including various hardware types/OSes/Departments/Etc. for 10-14 days, then all deployed machines within 30 days.