subject: Points To Consider While Patching Your Operating System [print this page] Unfortunately, no code that is millions of lines long is perfect, and security holes will always exist. One of the best ways to protect yourself is to make sure your system has the most recent patch levels installed. Rarely does a virus or worm attack a brand new vulnerability; rather, they attack known vulnerabilities for which patches exist. Typically, people who discover vulnerabilities will report them to Microsoft, and a patch is created and released along with the announcement of the vulnerability.
Administering the Patching Process
When you are administering a production environment with business-critical functions, its extremely important that you use a controlled process to manage your patching. Here are some ideas to get you started on a patching procedure.
Implement Change Control
First and foremost, you should implement a change control process for your system. A change control process has
Defined owners for the system, patch, and any applications
Communication to all parties involved in the patch
A waiting period, so that the interested and affected parties can raise objections or questions; its often a good idea to get approval from each of the owners before applying a patch
An audit trail and back-out plan
A scheduled time for installation and a defined outage window
Be Consistent
When applying patches, make sure the same patch level is applied to each server-unless you have a good reason not to do this. Consistent installation is especially true for domain controllers, since out-of-sync patches could mess with replication or authentication between DCs.
Read the Documentation Always
Completely read the documentation for a patch before you install it, so you can understand thoroughly whats involved. That way, you can determine whether applying the patch is going to disable some needed functionality or cause issues with a certain piece of hardware or software on your system. Reading the documentation will also educate you on which patches are necessary and which ones are not critical.
Test It Out
It is a good idea to have a test lab in your organization that tests any new patches before theyre installed systemwide. When you are completely satisfied that the patch performs appropriately and have appropriate sign-off from everyone involved, target noncritical systems first for patching. If you are not comfortable patching, dont do it, especially if the patch is a feature enhancement rather than a security patch.
Be Able to Uninstall the Patch
If you can, install patches so that you can uninstall them if you need to later on. That way, you can back out of a patch if it causes problems on your system. You can usually find switches that allow for this. Also, keep a backup of the system state data on hand, plus a full backup of the system, just in case.
Make Sure the Patch Is Relevant
Always make sure that you can or should apply a patch to a system. Applying a WS03 Post SP1 patch before applying SP1 probably isnt a great idea. Also, keep in mind that you may not need to apply client patches, such as Internet Explorer patches, to a server, since Internet Explorer wont be used on the server. In addition, applying a whole service pack is usually better than applying lots of individual patches within the service pack.
