The update is already installed on this system

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.

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 also might not. You can test it in the lab, 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 update is already installed on this system error

The update is already installed on this system
Many Microsoft updates will check to see if the update is already present, then give this error message.

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

Here’s how to extract the patch manually.

The answer was 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:

md mso2010
patchname.exe /extract:mso2010

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

Running the MSP file directly bypasses the checks.

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. Others, such as Qualys, 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.

Leave a Reply

%d bloggers like this:
WordPress Appliance - Powered by TurnKey Linux