Alexey - I try to keep this "important hotfixes" list as small as I can... only including the hotfixes that I or my peers seem to run into the most.  I absolutely do add hotfixes to the list based on feedback.  However - I have not personally run into a customer that needed this.  It did make it into a KB - so obviously - there is a need... but do you see this in MOST OpsMgr environments you support/work in?  Most of my customers dont even utilize SNMP in any way.

Thanks for the feedback Paul.  However - I want to respond to some of your comments:

First - in my opinion, my list is not "missing" anything.  This is not a list of "all released hotfixes" and was never intended to be that.  This is a list of the most common issues, and the hotfixes for those issues, that I encounter to be needed in the field.

Second - on the superseded points:

954049 is NOT superseded by  958490+970533.  958490 takes a very special custom action, which resets the state of ALL the monitors on the system, which can have a serious impact on any large enterprise customer.  This is not just a simple DLL update, and therefore must be considered on it's own merits.  It is already listed in my list - however I dont recommend it unless the user if affected by that issue, and understands what will happen.  

On 957135 -> 958490 - same issue as above.  EVERYONE I have worked with was impacted by 957135, but not necessarily 958490.  958490 also includes DLL's in addition to the two in 957135.

On 956423 -> 962082 - I will assume you meant 968082.  However - that is a very, very specific hotfix, that 99% of the customer bas will not be affected by. (a numeric digit at the beginning of the domain name)

Overall - I am *VERY* careful when recommending or listing any hotfix.  A hotfix = expense and adds to TCO of an application.  My large enterprise customers can equate this to real $$$, in overtime, off shift pay, downtime, or costs incurred by their service provider to apply these patches.  I spent the last decade working for one of the largest IT service providers, and know all too well the cost and impact of updating systems.  For those reasons, I only recommend or list the most common issues and hotfixes, and dont recommend a new hotfix just because it came out or supersedes an existing one.  

And - this list isn't official... it is more my personal list of recommendations than anything else.  But I do take a lot of feedback from the field, if there is an issue seen by a large number of consultants, that I have not seen myself.

Unless something really critical comes out soon, I will be adding anything to the post-SP1 hotfix list, until the SP1 hotfix rollup ships... in which I will be recommending that to all customers.  Applying one bigger fix is generally cheaper than applying multiple smaller fixes.

@Techiedude - kb968967 clearly does not apply to Windows 2008R2 - as stated in the KB.  A hotfix will only apply to those OS versions specifically state din the KB article.  You confirmed this.  :-)

As to the "Operations Manager agent processes are using too much processor time" on Windows 2008R2 systems.  I too have seen this.  I really think (but havent confirmed) that there is no problem at all.

When that script runs to collect the agent CPU - it USES a lot of CPU to collect it.  It was using so much CPU originally, that it was triggering and really hammering the agents, when it was originally set to a 300second interval.  This was found during testing and so it was set to an interval less likely to coincide with other monitoring intervals - 321 seconds.  However, I still see this alerting, randomly, and mostly on Windows 2008 R2 systems, which are virtualized and dont have many CPU's.  Especially on single CPU VM's which are running on a very busy host CPU.

Is that your case?

Start a detailed perfmon capture on one of these systems - collect Processor\%processor time for _total, and then Process\% cpu time for all processes.  Collect this every 1 seconds, for a few hours.  Then analyze that perfmon.  Is the primary CPU spike happening every 321 seconds?  If so - it is the collection script using too much CPU, or the host CPU not having enough resources that is the root cause.

@Techiedude -

I would do the exact same, as I would with ANY monitor that is alerting:

1.  Consider if the alert is actionable/wanted.  Disabled the workflow if it isnt actionable.

2.  Assuming it is desired/actionable.... consider if when the monitor alerts, is there really an actionable response?  If not - TUNE the workflow until the monitor becomes prepresentative of a serious condition.

In this case - I would consider if I want to be alerted when agents are consuming too much CPU.  If so - I would devise an override that makes the monitor useful to me.  If you determine the CPU is not all that high, except when the script runs to inspect it - then that tells me it is highly likely your virtualization hosts are oversubscribed to CPU resources.  Not a big deal, you just have to take that into account.  Perhaps make a group of virtual machines, or machines with only a single CPU, and override the monitor for those machines to a much higher setting.

@odnap -

I would make your plan - and follow the guides for each step.

I would upgrade from SP1 to R2 fully (except agents).  Then - I would upgrade to the latest CU available that you have tested.  Then - update all the agents from SP1 to R2 CU(x).