I had an update on my system in a partially installed state. Our vulnerability scanner determined one file, MSO.dll, was still out of date. It recommended a patch to apply. Running it gave me an error message. Here’s what to do when Windows says the update is already installed on this system and refuses to let you do anything but click OK.
Because hey, from a security analyst’s point of view, this is anything but OK. I get questions about patches in a partially deployed state all the time, so I figured I’d write about it. Here’s what I do when security updates fail to apply with this error.
Is the system still vulnerable?
Usually when people ask me this question, they just want me to assure them the system isn’t vulnerable, call it a false positive, and move on with life.
I could do that, but I would be wrong. That’s called malpractice. If the vulnerable component is still on the system, then the system is still vulnerable. You can test it against an exploit. Or you can just fix the problem. It’s faster to just fix the problem. Actually we usually end up spending more time talking about the problem than it takes to fix the problem. Here’s how.
The first step is to just download and install the update by hand, directly on the affected system. Sometimes that just works. Other times, especially with Microsoft Office updates, it doesn’t. You may be able to find some clues by digging through ETL files. But here’s a trick I use to get through the error, and it’s always worked for me.
Sometimes it’s best to patch like a caveman, and sometimes you have to patch like a brain surgeon. This is an example of patching like a brain surgeon.
What not to do
Don’t mess with redeploying the patch from the Windows server that deploys updates. You’re going to have to work directly on the system.Sometimes going into the control panel and uninstalling and reinstalling the patch works. But sometimes you’ll find the patch isn’t in the control panel and you’re still getting the error that it’s installed.
There are some tricks you can do with the Windows Softwaredistribution folder. But there’s a faster way.
The update is already installed on this system error in Windows
The first step is always to run the update by hand and look for error messages to see what you’re working with. You’ve probably already done that and that’s why you’re reading this.
When I ran the update, I got an error message that said the update is already installed on the system. My go-to fix, rebooting the system a couple of times and then running it again didn’t help in this case. Sometimes the problem is that the file is in use and can only update during a reboot. You can look in the registry, but there are 16 places to check, so my natural inclination is to reboot a time or two, see if that fixes it, then dig deeper.
And in this case, I ended up having to dig deeper. We still had a missing file, and no pending reboots on the system.
I had executives asking about the update in question due to ransomware scares, so I pulled a rabbit out of my old bag of tricks to get the patch down. A decade ago I was a patching whiz and most of my old tricks still work. Having executive attention and not having a solution is a bad thing. So it’s a good thing I had a solution.
Extracting the MSP from the update’s EXE manually
The answer was to run the command to extract the MSP file from the update. To do that, you run the executable from the command prompt with the switch /extract and the name of a subdirectory to extract to.
In my case, I did this:
The patch then extracted the contents into the directory I created. It’s pretty quick. Inside the directory, I found an MSP file, an XML file, and a text file. You need all three files, but the MSP file is the key.
Installing the MSP file by hand
I opened the MSP file from Windows Explorer. It ran, and the update installed without any hassle. If anything, it was a bit faster than using the EXE file. It wouldn’t surprise me if some of the better patch deployment tools use this trick by default.
We rescanned the system and it was up to date. Some vulnerability scanners take the operating system’s word that a patch is deployed. The two most common, Qualys and Tenable, do not. This is why. Sometimes the operating system is wrong.
Who should do the work?
Another question that comes up from time to time is who should do the work when onesie-twosie patches come up in partially installed state and it takes manual application to get them right. In the case of workstations, I think it should be the local desktop support person. With servers, it’s murkier. But anyone with admin rights on the server ought to be a candidate. I don’t think the administrator of the centralized patching system ought to shoulder full responsibility. Security is a shared responsibility. It affects everyone in the company, so a team of people ought to help out when stamping out a critical vulnerability if it requires manual intervention to apply correctly.
Why “the update is already installed on this system” happens
I don’t know exactly why the “the update is already installed on this system” error happens, but I’ll share a couple of observations. It happens more frequently on things like Office and .NET updates than on Windows updates. And it happens more often on systems that had an older version of Office on them and then got upgraded to a newer one. The same is probably also true of .NET.
When I’ve mentioned this to other security professionals, they tend to pause for a second, then chuckle, then say, “That makes sense.” I can’t guarantee you’ll avoid this error by uninstalling Office completely, then reinstalling it fresh and patching it. But I’ll bet it reduces it.
Of course that’s not always practical. When you can’t do that, you can extract the MSP and install the MSP directly. And there’s a repair tool for .NET that may help you with that whole family of update problems.
I fixed 200,000 vulnerabilities a year with a success rate of 100 percent and an MTTR of around 30 days when I was a sysadmin. There are analysts who will tell you that’s impossible, but I did it. Using a deployment tool got me anywhere from 80 to 98 percent of the way there, but every month I had at least one update fail on one system. This trick was one of the ways I closed that gap and reached 100 percent.
I’ve brought up this solution at various times in my career. Usually the reaction is a thank you when it works. Occasionally someone will come up with various reasons why they don’t want to extract and run an MSP file. I suppose they could rebuild the system if that’s really what they’d rather do.