Manage Learn to apply best practices and optimize your operations.

Pros and cons of third-party patch management tools

Struggling with patch deployment every month? Considering a third-party product? Contributor Serdar Yegulalp offers 10 things to think about before making the jump from Microsoft utilities to a third-party product.

I've heard a number of arguments both for and against using third-party patch management tools over Microsoft tools -- some of them well-reasoned, some not -- and, over time, I've compiled the most consistent and intelligent ones. People who are looking for detailed assessments of why it might make sense to go with a third-party tool in their organization can start here, and there might also be compelling reasons in these lists for people to change their minds, either pro or con.

More on patch management
 Third-party patches: IT pros debate their worth 

Four patch management myths

Five reasons to use a third-party tool:

  1. Additional features: Third-party patch management systems often have additional features that aren't present in the standard Microsoft way of doing things. For instance, Service Pack Manager 2000 allows the administrator to create multiple arbitrary groups of computers to better govern who gets what updates.

  2. Automation: Some third-party applications have automated functions that are above and beyond what's available by default, and they don't require scripting to be effective.

  3. Additional coverage and information: Many of these tools have detailed reporting and research functions -- for instance, the ability to automatically generate a summary of what's installed on a given machine and relevant details from Microsoft Knowledge Base articles that apply to each fix.

  4. Better feedback: The aforementioned Service Pack Manager, for instance, logs detailed results about each deployment, including how long it takes for the target machine to reboot.

  5. A more comfortable paradigm: Some people are just happier with the way a given third-party product works to roll out fixes, whether because of the workflow or even just the interface.

Five reasons not to use a third-party tool:

  1. Internal consistency:If you have one department that's using a third-party tool and another that's using the standard Microsoft deployment methods, it can become confusing for people trying to maintain standards across organizations -- and it might not be convenient or politically possible to get everyone to use the same tools. In such a case it might be best to fall back on Microsoft standards.

  2. Retraining: When people come in from another company or department where no such third-party tools are in use, you'll need to retrain them. If this happens often, it can be a drain on time and energy.

  3. Unneeded additional features: Not every organization needs the advanced features offered by third-party products. Sometimes the defaults work just fine.

  4. Troubleshooting: If something goes wrong, it's best to have as few variables as possible to figure out the source of a problem. This includes the presence of third-party products, so if you are a believer in running clean and lean, you may want to work without third-party tools.

  5. Cost: Sometimes you just can't afford anything more, and that can be the most compelling reason of all. Granted, many third-party tools have free trial versions, but you'll have to shell out money for them at some point if you intend to do more than just see how they work.

About the author: Serdar Yegulalp is editor of the Windows Power Users Newsletter. Check it out for the latest advice and musings on the world of Windows network administrators -- and please share your thoughts as well!

This tip originally appeared on

Dig Deeper on Small-business IT strategy