Skip to content ↓ | Skip to navigation ↓

In my previous blog post, I mentioned that the one thing I’d change about my job would be Microsoft’s Patch Process. This is the first of several follow-up blog posts detailing how I would fix Microsoft Bulletins and Patches in order to change my answer.

I’m starting with the change that I feel would be easiest for Microsoft to implement… Error messages in updates.

Microsoft may have the vaguest error messages of any vendor. When you’re installing a security update, you should expect a working feedback system. If the patch doesn’t install, you should know why from the error message.

If the update won’t apply, you should know why it doesn’t apply. Clearly the update was able to determine why it didn’t apply, shouldn’t there be an easy way to communicate that detection logic to the end user?

Let’s take a look at a few of my favourite error messages:

  • This update has already been applied or is included in an update that has already been applied.
  • The expected version of the product was not found on the system.
  • The update does not apply to your system.

Now, before anyone says, “Run the update with logging”, I want to point out a few things:

  1. Logging doesn’t always capture the reasons for the decisions.
  2. Rerunning the patch to generate a log and reviewing said log is often outside the comfort zone of the end user.
  3. Taking a more complex approach to solve a simple problem is not a valid solution.

So, let’s take a look at these three error messages and how Microsoft could easily improve them.

This update has already been applied or is included in an update that has already been applied.

In many ways this is the easiest fix… include the line of detection logic that determined the update has already been applied. Is it a registry key? Display it. Is it a specific file version? Tell us which file and the version. Is there another indicator? Let us know.

The slightly harder part would be the removal of the ‘or’, depending on how the update’s applicability was determined. Either way, it’d be nice if an error message was accurate enough to tell us exactly what was going on, rather than giving us a few possibilities.

The expected version of the product was not found on the system.

This is the message that I find the most infuriating. There must be a dependency check that determines which versions of the application the update applies to, so tell me why the expected version was not found.

Does the update only apply to certain language packs? Do I have an older version of the product that is no longer supported? Am I missing a checkbox during the application install for a component that this update needs?

This could solve a lot of issues. The biggest one being that a person walks away thinking they aren’t vulnerable to a critical issue but in reality they are. If the error message simply said, “The expected version of Office 2010 was not found on the system. Please update to a supported version.” users would know to update their software.

The update does not apply to your system.

This is another error message that causes issues. Why doesn’t the update apply? I’ve got the software from the bulletin installed, so where’s the problem? This generally implies that a component is affected that you don’t have installed.

Again, this could be easily resolved by simply telling the user which component you are looking for. “The update does not apply to your system because you haven’t installed URL Lockdown for IIS”.

Not only would these changes make life easier for end users, help desks, and vendors… they’d also increase security. A lot of people walk away from a system when they get one of these errors and assume they are safe. T

his isn’t always the case.  Systems often end up more vulnerable due to the vague error messages and it seems like fixing them would be an easy step to improving the global security ecosystem.


Related Articles:

P.S. Have you met John Powers, supernatural CISO?


Title image courtesy of ShutterStock