SCOM Patching blues – part 2

In my previous post on the theme I pointed out two issues with KB 956689 and KB 958490. For the former I stated several files are updated by the fix even if they’re not cited in the KB article and without changing the version number. Daniele Muscetta (msft) correctly addressed me to this msdn article that states that by default:

1) versioned files are changed just when a new version is present in the msp file

2) unversioned files are changed based on checksum

Now, I gave a quick answer to Daniele in the comment section, but I understand I need to articulate further my statement. On one side the keyword here is “by default” that means if no special parameters are passed to msiexec, on the other the article explains other cases when a versioned file can be substituted with a different file with the same version. So, once the file is in the msp, the exact behavior depends on the way msiexec is called. Adhering to Murphy’s law here’s a screenshot from a system where I applied the fix:


Taking a closer look to MOMModules.dll we can see it’s still at version 6.0.6278.0 but it’s not the SP1 RTM binary and the change date is the same of MOMNetworkModules.dll version .41 (the dll changed by our very own fix). So the fix changes more files than documented. There can be valid reasons to add more files than the one meant to be patched in a msp, for example dependency relationships with specific modules the dev wants to be sure are maintained, but, immo, there are no valid reasons to have different versions of the same file with the same version number. And this is exactly what happens in this fix. Anyway supposing the only file that needs to be updated by the fix is MOMNetworkModules now the fix is obsoleted, so just do not apply it.

On the case of KB 958490, that caused in my environment a huge increase in CPU utilization agent side, I want to add some information:

  • probably this behavior is not a rule, it depends on the mix of MPs implemented
  • on a customer of ours we tried the fix and immediately we had an increase on DCs but apparently not on other servers, we were in production and kept the fix just a few hours before uninstalling it
  • I know the MOM team is working hard on a repro without any luck as of today
  • So if you have the dependency rollup issue solved by the fix (and you have it, trust me :-)) you can probably give it a try and check the HealthService CPU utilization on your agents. If you have any experience to share I’m interested in listening.

– Daniele

This posting is provided "AS IS" with no warranties, and confers no rights.

Technorati Tags: ,
  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: