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.
Five reasons to use third-party patch tools:
- 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.
- 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.
- 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.
- 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.
- 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 third-party tools:
- 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.
- 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.
- Unneeded additional features: Not every organization needs the advanced features offered by third-party products. Sometimes the defaults work just fine.
- 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.
- 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 wrote for Windows Magazine from 1994 through 2001, covering a wide range of technology topics. He now plies his expertise in Windows NT, Windows 2000 and Windows XP as publisher of The Windows 2000 Power Users Newsletter and writes technology columns for TechTarget.
This was first published in August 2006