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. An exploit for the vulnerability might need more than one component, but it probably doesn’t. You can test it in the lab, but your exploit may not be as good as the exploits the bad guys have. So that doesn’t reassure me, as an experienced vulnerability management professional. 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. Don’t mess with the control panel, or the Windows Softwaredistribution folder. There’s a faster way.
The update is already installed on this system error
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, didn’t help. And redeploying the patch from our automated deployment system didn’t help either. You should always try the easiest fixes first, of course.
I had executives asking about this update 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 some of those old tricks still work.
Extracting the update manually
The answer was to run the command to extract the update so I could bypass the check. 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, since it’s not a lot of work. Inside the directory, I found an MSP file, an XML file, and a text file.
Installing the MSP file by hand
I opened the MSP file from Windows Explorer. It ran, and the update installed without any hassle. It didn’t check anything, it just followed orders and replaced every file and updated every registry key.
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 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.
I’ve manually installed patches to get around this error dozens of times and it continues to work. It will work for you too.