Hello all - I tried to create monitor for this condition - but it doesn't work for me! I'm using SCOM 2007 R2 with CU2, I can see 90-100% CPU load on some Windows Server 2003 R2 SP1 and SP2 virtual machines from task manager (host is Virtual Server 2005 R2 SP2), but I can't see any alerts (new or closed) for monitoringhost.exe on SCOM console! It's very strange to me, because when I create similar monitor for perfomance counter _Total, it works and show alerts. So, my question is: where I was wrong? It makes me MAD why I cannot see alerts...
Mike Kulikov
30 Aug 2010 6:03 AM
30 Aug 2010 2:49 PM
Mike - dont get MAD. :-)
Using _total is fine as well.
One reason you might not be getting alerts - could be the counter you are using. I discussed this in the following article: blogs.technet.com/.../how-to-monitor-a-process-on-a-multi-cpu-agent-using-scaleby.aspx
You can always just use the process monitoring template if needed.
Mike Kulikov
31 Aug 2010 4:01 AM
Thanks for quick answer, Kevin - I already read your article and used "scaleby" and process monitoring template - without anу success results. No alerts and healthy proccess state view... I'll try again of course.
Mike Kulikov
20 Sep 2010 5:02 AM
This is perfomance view for instances of monitoringhosts (object - process, counter - %processor time) from one of our servers (process monitoring template is on): postimage.org/.../1gzdfjy84 - here you can see there is no graph for critical perfomance - when I connect to server at 8:00 a.m., monitoringhost perfomance changed between 90-100% until I kill process - and after this it appears (you can see it in the screenshot). Why SCOM cannot determine it when it is critical?
20 Sep 2010 3:42 PM
As you can see from the straight line - this means no monitoring data was available. The process that was in a spinlock was also the process that was collecting data... which appears to have died.
Suresh
14 Nov 2012 4:44 PM
Kevin, Is this hotfix applicable for Windows 2003 server also? I could see this is applicable for Windows 2008 and Vista; also I could see, it is applicable for "other systems that have MSXML 6.0 installed". So can I install KB 968967 on Windows 2003 server?
Naveed
1 Mar 2013 5:56 AM
Hi Kevin,
Can you please help me in thisregard,
i am facing cscript.exe running on my citrix server machine. and getting high CPU.
windows server 2008 R2 Sp1
XenApp 6.5
Sunil
30 Jan 2014 5:41 PM
Hi Kevin, As best I can determine, the Hotfix in KB968967 does not apply to Windows 2008 R2 SP1 which is the OS we are running on our print servers. The versions of msxml6.dll and msxml6r.dll that the hotfix installs: - msxml6.dll V6.20.5001.0 - msxml6r.dll V6.0.3883.0 The existing versions of these two files on the server: - msxml6.dll V6.30.7601.17988 - msxml6r.dll V6.30.7600.16385 Do we have any solution in this case - Monitoringhost.exe is spiking and is going to 100% and stays their till i restart the healthservice, Machines role is print server.
30 Jan 2014 5:50 PM
@Sunil - that condition is not normal. - that hotfix is for a VERY specific issue - spinlock - which isn't terribly common. For Server 2008R2 SP1, I'd say you have some other issue at hand, likely a poorly written MP that is doing something bad. I'd put certain classes into maintenance mode and see if you can identify. For instance - does it go to 100% immediately, or is it random? If you put the print server role into MM, does this not happen? You can use tools like ETL tracing when this occurs to try and determin root cause, or open a case with Microsoft.
Sunil
30 Jan 2014 7:30 PM
Hi Kavin, As you suggested, kept print server role in MM and its not happening.. server CPU performance is stable. but i cannot keep this role in MM as I need to monitor this. What could be the next course of action to fix this issue.
Sunil
30 Jan 2014 8:05 PM
Hi Kevin... Its Windows Server Print Server 2008 Management Pack
30 Jan 2014 9:12 PM
What version *specifically* Any issues in the OpsMgr event logs? Have you reviewed my recommendations here: http://blogs.technet.com/b/kevinholman/archive/2012/12/12/mp-update-printer-mp-6-0-7004-0-adds-support-for-ws2012-and-ws2008r2.aspx and here: http://blogs.technet.com/b/kevinholman/archive/2008/02/12/print-server-management-pack-fills-the-operational-db-with-tons-of-perf-data.aspx
Sunil
31 Jan 2014 3:06 PM
Yes Kevin the version is 6-0-7004-0.. We are having large print server with several hundred print queue and I have kept below three performance collection rule enabled Performance Measuring: Print Queue\Jobs Performance Measuring: Print Queue\Jobs Spooling Performance Measuring: Print Queue\Total Jobs Printed Performance Measuring: Print Queue\Total Pages Printed This may be the cause of high resource utilization.. We are using SCOM specially to monitor performance of print server so cannot disable this rules. Do we have any solution or workaround in this case.
31 Jan 2014 3:37 PM
@Sunil - If your monitoring solution can handle the load of what you wish, then you aren't getting the monitoring you desire. :-) I have not run across this before, but I'd anticipate the issue is with several hundred queues discovered as instances, with workflows attached. This can create a great load on the agent. First, I'd make sure you have set your healthservice limits very high - to keep the agents from restarting: http://blogs.technet.com/b/kevinholman/archive/2013/02/21/healthservice-restarts-still-a-challenge-in-opsmgr-2012.aspx Second - I'd disable ALL of the 16 rules, and the 13 monitors, that target the "Windows 2008 Print Services Printer Queue" class. Then - I'd see if the problem goes away. Next, I'd enable ONLY the performance collection rules that you deem critical, one by one, by deleting your custom overrides. After they are all enabled, bounce the healthservice and make sure it initializes and works fine. Next - do the same for the monitors dealing with performance - that you deem critical. There are several event based rules and monitors that I consider poorly written, as they utilize regular expressions unnecessarily, and they target a multi-instance object (printer queue) unnecessarily. Technically these should all cook down, but it is possible that they don't correctly. I would personally disable all the event based monitors and make simple event based alert rules - and target the print server role for these alerts.... if you are seeing a resource utilization issue..... IF you determine they are root cause.