Your company has made decision to use Microsoft System Center as your systems management solution. You have spent months and precious dollars getting all of the moving parts to work together. Congratulations, you are now a fearless, SCCM user!
Now it’s working well for most things, but one question keeps nagging at you, “What about third-party application patching?”
You realize that most vulnerabilities exploited in the wild are found in third-party applications and not in Microsoft software, and of course, you want to secure your network from this threat. You’ve been talking to a number of third-party patch add-on vendors, and it’s becoming clear that you have a tough choice to make.
Let’s look at the various factors SCCM users should take into account when selecting a third-party patch add-on for SCCM.
The foundation of a third-party patch decision is built upon one simple question, “Do you want to add this capability by extending your existing, SCCM infrastructure or by investing in a new architecture?”
Let’s review some of the advantages of “extending” over “investing.”
|No additional cost of hardware||Cost of server and database, deploying agents|
|No Scalability Concerns||Acquire new hardware to scale with business|
|No additional training cost||Administrators must learn new console|
|No new workflows||Must deploy using a new way of doing things – error prone|
|No “new” report||Dashboards and Custom Reports|
|Single “pane of glass”||Dashboards, consoles, tools – many user interfaces to learn|
There are clear advantages to extending, but it comes down to what problem a user is trying to solve. Some people are looking for additional functionality beyond patching. They may need to invest in new infrastructure to accomplish this. Usually, this involves use of an agent that must be installed on every machine, which then feeds data to a proprietary application server. This allows the vendor to do more analysis and to offer more features, but these features come at a cost.
Other companies are looking to address just the third-party patch problem in the most efficient manner possible. For them investing in new architecture is a costly and redundant solution. They are better served by an add-on that fully integrates with SCCM’s user interface, its database, and its process workflows. Add-on’s like this allow administrators to perform and to report on third-party patching in the exact same manner as Microsoft patching.
Heck, some of these add-on’s, like Shavlik Patch for Microsoft System Center, even allow administrators to fully automate the third-party patching process. This “set and forget” capability means that the third-party patching problem is solved.
Third-party patch management is something that has to be done. It’s not sexy or fun, but it doesn’t have to be difficult.
Going back to the original question, “Do you want to add this capability by extending your existing, SCCM infrastructure or by investing in a new architecture?”
If your answer is to extend, check out our free trial of Shavlik Patch, and you can be patching third-party applications from within SCCM later today.