Patch management is a necessary evil for many system administrators. Software is not perfect; vendors find bugs, and hackers exploit security vulnerabilities, warranting a continuous cycle of new versions of software. It’s critical for systems administrators to continually keep tabs on the latest software updates installed on their servers and clients. And proper patch management practices get patches deployed as soon as possible to prevent production outages and security exploits.
But, there’s a catch. Deploying patches to endpoints is only half the battle. Admins must also pay attention to application compatibility concerns and other unexpected behavior when installing patches. These issues warrant rounds of testing to ensure that the latest patches don’t cause problems in a production environment.
Administrators have relied on many different tools over the years to get a handle on patch management. Two of the most common tools to manage the patch management lifecycle are standalone instances of Windows Server Update Services (WSUS) or System Center Configuration Manager (SCCM), which uses WSUS under the hood. These products work well enough, and you can’t beat the price of WSUS. But what do WSUS and SCCM actually cost you? You may be surprised at the answer.
Limitations of SCCM
As a former SCCM administrator of six years, I can tell you from firsthand experience that SCCM is not for everyone. I’d argue that the client I was working for at the time didn’t even need it. Why? Because this client only had a few hundred endpoints, and SCCM is definitely not designed for such a small footprint.
Complexity
Too often SCCM is thrown onto an eager administrator who realizes that deploying patches to endpoints isn’t quite as easy as it’s cracked up to be. Administrators soon find that managing SCCM properly requires full-time responsibilities.
If starting from scratch, an administrator’s first reaction to SCCM is always overwhelming. For something as simple as deploying patches at regular intervals, a complete architecture needs to be researched and designed (even for small endpoint numbers). SCCM can grow to be a large orchestration of multiple servers, with message buses flowing between them and many different processes running on client agents. Deploying a from-scratch SCCM infrastructure isn’t nearly as simple as an administrator initially thinks.
Also, due to SCCM’s bulky architecture, it can sometimes take many minutes to retrieve information about an endpoint. There was always a common joke in the SCCM community referencing “SCCM time.” Reality and “SCCM time” don’t always coincide due to the slow performance of many everyday activities, like pulling information from clients. It’s clear that SCCM wasn’t designed to be a real-time solution.
Focused on Microsoft Products
Being a Microsoft product itself, SCCM was bound to work great in Windows environments but is lacking when it comes to Linux, macOS, and mobile endpoints. For this very reason, clients can decide against SCCM and instead purchase a separate tool. The focus to move away from Linux support can’t be better explained than by Microsoft MVP Anoop Nair in his blog post Linux Unix SCCM Support is Dead. SCCM was simply never a contender for cross-platform support.
Although not as evident, but still pervasive, there is also SCCM’s lack of support for non-Microsoft patches. The issue becomes apparent when you look at the number of third-party tools that integrate with SCCM to fill this void. Simply Google “sccm third party patches,” and you’ll see many products that bolt onto SCCM for this feature.
Each software vendor seems to want to manage their software differently. Some have their own update mechanism, some send out emails to customers and post a link to the new installer on their website, and some have gone out of business altogether. Third-party patching is hard, and SCCM has only limited support.
Often, the security team that controls the desktop antivirus software will want to use that vendor’s update mechanism, while the software deployment team wants all updates under one umbrella through Microsoft SCCM. It can be a stalemate for a while, but the software deployment team eventually wins the argument. Situations like this come up all the time unless an organization has a clear protocol on patching all desktop apps the same way.
If you have many Linux endpoints and want a vendor-agnostic patch management solution, SCCM probably isn’t for you.
On-Prem Setup Required
The setup of a new SCCM infrastructure is not easy because it’s solely on-prem. You have to provide your own server(s) and maintain them. And just wait until you run into the chicken and the egg problem when your SCCM site servers need patching!
SCCM requires a full version of Microsoft SQL Server. If an administrator tasked with setting up SCCM wasn’t a database administrator before, he will be now! This is because there will be times when it’s necessary to understand SCCM’s database schema for reporting purposes or performance improvements.
However, it’s rare that an IT administrator’s role is as a full-time SCCM administrator, and this makes managing on-prem infrastructure another major challenge when rolling out patches.
Client Health
SCCM requires an agent installed on each endpoint. This usually isn’t a problem, but SCCM administrators inevitably find that there will always be a small percentage of clients that encounter an issue. There are many different roles a single client agent supports, from software and hardware inventorying to patch scanning and installation. The client agent itself is complicated enough–reflected by the dozens of log files typically required to troubleshoot a problem.
The term “client health” within SCCM refers to the overall well-being of a client agent. When working as an SCCM administrator, you may wonder why there is a specific term for this. One would think a specific term wouldn’t be needed to define something like “working.” But especially when you work in a large enterprise, overseeing the health of a client agent can become a full-time job, demanding continuous remediation, manually addressing clients that fail to report in, running patch scans at required times, etc.
Alternatives to SCCM
We’ve focused a lot in this article on some of the downsides of SCCM, but what other choices do you have? SCCM is so complicated because it does a lot of things. Patch management is only one spoke in the SCCM wheel. If you’re looking for a patch management solution, look for a product that’s vendor-agnostic and universal in terms of patch support. If you have a heterogeneous environment full of Microsoft, Linux, Adobe, AutoCAD, medical imaging software, old terminal emulation software, and any other kind of software, go with a product that has universal support for all of them.
Look for a solution that focuses on performance and simplicity. SCCM is complex. JetPatch, on the other hand, was designed for simplicity. If your team is strapped for people, and you need a solution to get patches deployed ASAP without any hassle, don’t go with SCCM. Go with a cloud solution that doesn’t require anything other than setting up a user account, deploying agents, and deploying patches. Cloud tools have a significant advantage over on-prem tools in terms of their speed of implementation and reduced management requirements.
Summary
SCCM is a product that does many things but no one thing spectacularly well. It’s a product that many organizations implement by default because it works, to some extent, and licenses for it come included with existing enterprise license agreements. Organizations fall victim to the lure of an inexpensive, does-everything solution when, in reality, that solution is susceptible to turning expensive in so many other ways.
As you’ve read in this article, SCCM is not a one-size-fits-all solution. If your organization’s goal is achieving painless 100% patch compliance across a heterogeneous environment with little oversight, look for a solution such as JetPatch that focuses on patch management alone. And I’m saying this as a former SCCM administrator.
