SCCM vs WSUS

Since I work for a vulnerability management company, I get tons and tons of questions about patch management. I don’t speak for my employer, and they probably don’t have an opinion since neither product comes close to meeting their needs. But I’m glad to share what I know. Recently, someone asked me which is better, SCCM or WSUS. My answer probably was not what they were expecting me to say.

Advantages of SCCM

The advantage of SCCM is that it can do more than push updates, and it can push a wider variety of updates.

It is a million miles away from being the easy button that all of my former IT managers’ golf buddies told them it was way back in 2003. But what it lacks in ease of use it tries to make up for in power.

It’s also extensible. It is beyond lousy for pushing updates to non Microsoft software, but third party add-on-ons do exist to extend its capabilities to make it better for pushing third party software. Having somebody else’s tested scripts is very much worth it. Otherwise, it is way too easy to deploy your update right next to the vulnerable software that you intended to replace.

Advantages of WSUS

The upside to WSUS is it’s cheap. It costs about a thousand bucks. But wait Dave, I hear you saying, WSUS is free! WSUS itself doesn’t cost anything, but it requires a Windows server license. The Windows server license costs about $1,000. Make sure you buy as early as possible in the Microsoft Life cycle to maximize your investment.

That’s all it has to offer. It’s cheap. It gives you a central place to deploy Windows updates from, and provides basic scheduling and deployment functionality beyond what you can get by enabling Windows Update for Business on all your machines. There’s nothing great about it, but if it’s all you can afford, it is much better than logging in to each machine remotely and running MSI files to apply updates.

Disadvantages of SCCM and WSUS

I’m going to lump these together because both SCCM and WSUS share common weaknesses. When all goes well, either of them can push Microsoft updates at a success rate slightly north of 90%. That sounds pretty good, but remember, IT organizations define success as five nines uptime, or 99.999 percent. And my employer’s true positive rate is a little bit better than that, with six sigma accuracy, or approximately 99.9997%.

People find that .00003 percent, and they don’t give a crap about the five nines and change. But here is Microsoft, celebrating 20 years of one nine.

I know I just offended a bunch of people by saying that, because SCCM was good for a lot of people’s careers. The people who became SCCM administrators circa 2003 escaped much worse jobs and gained 20 years of job security. I refused to become an SCCM administrator in 2003, and my then employer couldn’t get rid of me fast enough. Then they came for my teammate, and he quit.

No one wants to hear that they made the wrong career choice, but I didn’t say that choosing the SCCM road in 2003 was the wrong idea. All I’m saying is there are other options today, and it doesn’t have to be either or. Especially since Microsoft tends to bundle SCCM with something else you want, so in essence, you’re paying for SCCM whether you use it or not.

WSUS has approximately the same success rate, but has exactly zero capability to deploy third-party updates, and you need that capability in a modern enterprise. You’ve got Chrome running on your corporate systems whether it’s allowed or not, so you need to be updating it.

Why not both?

Years ago, a former co-worker called me and wanted my opinion on his science experiment. I don’t know exactly how he did it, because SCCM uses WSUS. But he was using both. Presumably, he set up SCCM with its own WSUS instance and used the SCCM agents to deploy updates through SCCM. And then he stood up a second independent WSUS instance and pointed the Windows update agents at WSUS.

Then he played them off each other. If Mom says no, ask a grandma. Or, if SCCM falls flat on its face, trot out WSUS.

He told me that if he tried to deploy an update with one of them, and it failed, the other one didn’t always fail. The tandem fell short of getting him to 99% reliability, but in his estimation, it improved his success rates enough to be worth the cost of dedicating an extra server to his arsenal.

Better yet, why not three?

But then what he did next was really clever. He bought a non Microsoft patching solution. Specifically, he bought a KACE appliance, but I think the main benefit is buying something that uses a different technology stack.

What he found was that doing a pass with all three did get him above 99% success rates.

RFP your patching tool!

I’ll let you in on a secret. Your security teams conduct due diligence on their vulnerability scanners on a regular basis. For some organizations, that’s every year. For others, it may be every 3 years. And you can bet that anytime the director of vulnerability management quits and they get a new one, the new manager conducts due diligence.

At the very least, it means getting a quote and a demo from Tenable and at least two competitors and finding out what improvements they have made since the last time they talked. And for the right combination of price and improved functionality, they will make a change.

I’m telling you this because I rarely hear of anyone doing this for patch deployment software. And I think everyone should.

What patching tool does Tenable use?

Another question that I get is what patch deployment software my employer uses. The answer is I don’t know. What I do know is that we change them at least occasionally, so if I did know and I told you, it might not be the best advice by the time you acted on it.

How to test patch management software

I’ll tell you how I evaluate patch management software. I think I’m qualified to do these evaluations, because I had clean Nessus scans on 30 day intervals between 2005 and 2009. The product I used and liked doesn’t exist anymore. They gave me WSUS in 2008 to save money. I had to make up the difference in failure rate by logging in to each server and installing updates by hand. When management told me they weren’t going to buy a proper deployment tool and I could work Saturdays uncompensated to make up the difference, I quit.

They missed me when I was gone.

Test on old and tired systems

There was definitely a pattern to which systems were more difficult to update. New systems were generally not a problem, and now that most updates are cumulative, they are even less of a problem. Deploy a service pack and the current month’s updates, and they will probably be good to go.

It was the old and tired systems that gave me trouble. Systems that had been around a long time, seen a few upgrade, but never a clean reinstall. The more of a story they had, the harder they were ot update.

So when you go to evaluate patching solutions, don’t build new systems in your lab. Take a handtruck down to where you keep decommissioned systems and fill up. Take an image of each system, and then apply the image back to each system. You are going to reimage each system in between evaluations, so to make it fair, reimage before evaluating the first one. That makes the evaluation fair because sometimes imaging the system corrects disk errors.

But outside of not having disk errors, you still have old and tired systems, with bloated registries, orphaned DLLs, and all kinds of other random things that can gum up the works.

You will notice that some patching solutions do a much better job than others at handling this toxic mess. It may or may not be the most expensive one. But if it is, it’s probably worth paying the extra money for.

And then, since WSUS is cheap, and you may be paying for SCCM anyway, now you have a second and a third string to try to get another nine or two.