Hello, Im playing with SCOM 2012 RC but Im having problems with high CPU usage on three of my physical servers where the 2012 RC agents are running. I have read quite a few blog & forum posts on here regarding high CPU usage on SCOM agent machines but I have not read anything that helps me so thought I would try again. I have three HP DL385 servers with 2x 12core AMD Opteron 6174 CPU's (so 24 cores). I'm finding that for about 15 seconds every 2-3 minutes all the cores spike at 100% then drop down to 2-3% (which is where they normally are). If I stop the 'HealthService' service on the machine this does not happen and also if I stop it while its spiking it drops straight away so I'm sure its the SCOM agent causing the problem. This is only happening on these three physical servers I have other physical (and virtual) servers running the agent with no problem. These three servers are all from the same build. The three servers are running Windows Server 2008 R2 SP1 with Hyper-V and all the Windows updates. The agent version is 7.0.8560.0 (is that the latest 2012 agent available?) and they are showing as healthy in the SCOM console. I have seen this KB >> http://support.microsoft.com/kb/968967 but not sure if it is applicable to SCOM 2012 or Server 2008 R2. I have disabled the AV (temporarily) but the problem still remains and I can't see any problems in the Windows event logs. If anyone has any ideas on where to look next I would very much appreciate it! Thanks, Joe

Hi SCOM 2012 RTM was released some weeks back. I'd strongly suggest testing that to see if that resolves it. If nothing else, it will get you on to the latest version. I suspect to be honest that RTM won't actually resolve this though. Perhaps take a look a Kevins article which explains the KB article you have looked at. http://blogs.technet.com/b/kevinholman/archive/2009/07/20/do-you-randomly-see-a-monitoringhost-exe-process-consuming-lots-of-cpu.aspx But first up, I'd get onto the RTM version and apply the lastest rollup: http://blogs.technet.com/b/kevinholman/archive/2012/05/08/opsmgr-2012-cumulative-update-release-1-ur1-ships-and-my-experience-installing-it.aspx Cheers GrahamRegards Graham New System Center 2012 Blog! - http://www.systemcentersolutions.co.uk View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/

Hi SCOM 2012 RTM was released some weeks back. I'd strongly suggest testing that to see if that resolves it. If nothing else, it will get you on to the latest version. I suspect to be honest that RTM won't actually resolve this though. Perhaps take a look a Kevins article which explains the KB article you have looked at. http://blogs.technet.com/b/kevinholman/archive/2009/07/20/do-you-randomly-see-a-monitoringhost-exe-process-consuming-lots-of-cpu.aspx But first up, I'd get onto the RTM version and apply the lastest rollup: http://blogs.technet.com/b/kevinholman/archive/2012/05/08/opsmgr-2012-cumulative-update-release-1-ur1-ships-and-my-experience-installing-it.aspx Cheers GrahamRegards Graham New System Center 2012 Blog! - http://www.systemcentersolutions.co.uk View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/

7.0.8560.0 is RTM - not RC. I'd apply UR1 as Graham suggests.... but I'd also take a good look at this: http://blogs.technet.com/b/kevinholman/archive/2011/12/12/opsmgr-network-utilization-scripts-in-baseos-mp-version-6-0-6958-0-may-cause-high-cpu-utilization.aspx Do you have any other management packs in place that might be related? Also - make sure your SCOM healthservice isn't restarting all the time by looking at the SCOM event logs.Kevin Holman http://blogs.technet.com/b/kevinholman

7.0.8560.0 is RTM - not RC. I'd apply UR1 as Graham suggests.... but I'd also take a good look at this: http://blogs.technet.com/b/kevinholman/archive/2011/12/12/opsmgr-network-utilization-scripts-in-baseos-mp-version-6-0-6958-0-may-cause-high-cpu-utilization.aspx Do you have any other management packs in place that might be related? Also - make sure your SCOM healthservice isn't restarting all the time by looking at the SCOM event logs.Kevin Holman http://blogs.technet.com/b/kevinholman