I have more of an approach-like question on BizTalk (integration) monitoring. We use SCOM 2007 to monitor the integration platform. Among other things, SCOM is good in monitoring the events (system generated or application generated) and alert as appropriate. But, often we find that there are some custom monitoring needed, that SCOM is not fully capable of handling – for example, Long Running orchestration instances, that stays in an “ACTIVE” state longer than needed It appeared that we needed to write a detailed WMI script to query the message box – instance status, which appeared that SCOM was not the right fit (and we wrote a custom .NET code to supplement SCOM monitoring). My question is, is it normal? Do you use supplemental monitoring in addition to SCOM in your company? I think part of it may be that the above example is not a platform monitoring we are trying to achieve, rather a functionality or correct utilization of resources.

Hi! Generally speaking, you should think hard before using OpsMgr to fix problems that really should be fixed in the applications themselves. That said, in real life, it's not that easy to get an app fixed. The scenario you are speaking of should lend itself admirably to a monitor. Even if you have to write .net code, OpsMgr can run that code with a monitor. A long running orchestration could be labeled as a performance issue (a threshold is passed). The monitor changes state to warning/critical, possibly triggering a recovery. /Roger This posting is provided "AS IS" with no warranties, and confers no rights.

I agree, if you can get it in the right scripts you can implement those as a monitor and feed back data into a property bag en use that to determine state and alert. Mostly the first hard part is getting a piece of code/script to get to exactly what you want to do. Next would be to use that one to make it a SCOM script basically and use it. It is normal to augment scom with additional monitoring. This could be management packs or third party add-ons onto scom. But also custom scripts and stuff to run inside scom. Creating your own management packs if nothing is available out there in the community of in third party vendor solutions/mps. There is always something extra that somebody wants to monitor and check that is not in the product (or any product). The cool thing is that scom lets you do that.Bob Cornelissen - BICTT (My BICTT Blog)