On paper patching can seem quite straight forward.  You have a system running that needs a patch so you just need to install the patch and job done.  Unfortunately in the Enterprise environment it’s never that simple and there are a lot of obstacles that will be put in your path.

 

As I mentioned in my previous blog there is never a "one solution fits all" for Enterprises and it’s important that you understand your own environment and tailor your patch management to meet your own specific setup.

 

In my experience there are a few key areas that I believe are important to any Enterprise patch process.

 

1) Having a complete Asset Inventory

Before you can start patching you really need to know your Enterprise setup and what systems you have.  The mix of Operating Systems you are covering and what applications you are responsible for keeping up to date is important.  You may have common applications, for example Adobe Flash Player, which you have installed on all your machines.  There are many patching and software delivery tools that will collect an inventory as well.  You can then use this inventory data to build groups of machines with an affected application or component so you can see how many affected machines you need to patch.

 

2) Ensure that your patch has been through Testing

Any patch that you look to roll out will need testing as the last thing you want is to create an issue when you roll out a patch.  Not testing patches can have a negative effect on your patch management process so it’s important that you have a good range of systems that you can test on, either in a lab or nominated users in your enterprise who are happy to test patches, and if something goes wrong are able to remove or re-install them.

 

3) Plan how the Deployment of the patch is going to be done

Once you are ready to deploy you need to decide how aggressive to be with the deployment.  If it’s a critical patch you may want to target all machines within a few days whereas a less critical patch may be split into batches and deployed over the period of a week. In my experience a pilot of between 200-500 machines before the main deployment always helps to build confidence with your Service Managers that a patch is deploying successfully.

 

4) Dealing with any Exceptions

There are always going to be one or more machines in your Enterprise that are either too critical to patch, have issues with a particular patch or who have a specific maintenance window.  In these cases you need to make sure that you have these exceptions not only documented but also reviewed on an on-going basis. It's quite easy in a large Enterprise to lose sight of your exceptions if they are not documented and these may end up posing the biggest risk to your enterprise if not reviewed on a regular basis.

 

5) Produce reports that show progress

Now that the patch has been deployed the process shouldn't stop at that.  Have you checked that the deployment is actually working as it should and that the patch you are deploying is being applied successfully?  Many Enterprises will ask for progress reports of any patch deployment so it’s important that you produce these to show not only the progress of the deployment but also how many machines have actually been patched.  This builds confidence that you have successfully patched the system and the risk reduced.

 

That's just a few areas that you need to consider when looking at best practices for your patch process and you will need to make tweaks and additions to meet your own specific setup within your enterprise, I never said it was easy.