Advanced Microsoft BizTalk Server 2004 and Microsoft Operations Manager 2005 Scenarios

Published: May 1, 2005

Author: Scott Colestock

Technical Contributors: Harold Perry, Kris Shankar, Cristian Salvan, Dale Koetke

Applies to: Microsoft® BizTalk® Server 2004 and Microsoft Operations Manager (MOM)

Summary: Building application-specific management packs for BizTalk Server 2004 applications to better leverage MOM 2005 for both infrastructure and application-level monitoring. (45 pages)

Applies to: Microsoft BizTalk Server 2004

On This Page

Brief MOM 2005 Architecture Overview
What Else Will You Need?
Why Application-Specific Management Packs?
Appendix A
Appendix B


Microsoft® BizTalk® Server 2004 Management Pack for MOM (BizTalk MP) was released October 2004. Like all management packs released by Microsoft, it contains the core rules, alerting, computer group definitions, and knowledge base content to monitor the availability and performance of the targeted product, in this case BizTalk Server 2004, as a part of your company infrastructure.

BizTalk MP is able to monitor the availability of critical services such as BizTalk Host instances and Enterprise Single Sign-On (SSO). It monitors connectivity to core BizTalk Server databases such as the MessageBox database, the Configuration database, and the Single Sign-On database (SSODB). Moreover, BizTalk MP can look for basic errors that occur in transport adapters and pipelines, and capture Windows Management Instrumentation (WMI) events related to suspended message and service instances.

Add to the monitoring capability the rules that are included for collecting performance counter data and you can see that BizTalk MP provides a good foundation for monitoring activities.

This white paper describes the specifics of what BizTalk MP provides, how you can use it, and how its contents can aid you in the equally important task of creating an application-specific management pack for your BizTalk Server 2004–based solution. An application-specific management pack will significantly extend the value of MOM 2005 in your environment, enabling you to meet application service level agreements (SLAs) more effectively.

If you are already familiar with MOM 2005 and BizTalk MP, you may wish to skip ahead to the section, "Why Application-Specific Management Packs?”.

Brief MOM 2005 Architecture Overview

Many other materials are available on this subject, but to provide the new user with background information this paper briefly covers the MOM 2005 architecture. For a deeper, yet still brief, overview, see "Monitor Your .NET Applications with Microsoft Operations Manager 2005" in the MSDN Library, found at

Figure 1 - MOM architecture diagram

Figure 1 - MOM architecture diagram

As pictured, the MOM architecture consists of Management Agents, a Management Server, a MOM Database, various consoles, the MOM Connector Framework, and MOM Reporting.

  • MOM Agents run on servers managed by MOM 2005. The agent collects information about the environment, such as installed software, and collects operational data from the event log, performance counters, and WMI events. The agent can also execute actions, such as scripts, executables, or .NET code, on the managed server.

  • Management Servers manage the deployment and health of agents, and the deployment of monitoring configuration to the agents. The Management Server also consumes operational data from the agents, storing it in the MOM database, processes alerts, and executes alert responses, such as scripts, executables, or .NET code, on the Management Server.

  • Operator Console and Web Consoles provide operations staff with tools for day-to-day systems monitoring. The staff can view events, respond to alerts, see health/system state, and carry out trend analysis on performance data.

Management Packs

Management Packs represent a collection of configuration settings and MOM artifacts that you can deploy to a given MOM environment. A Management Pack has items used for directly defining monitoring parameters, as well as items used to facilitate operations staff interaction with what is being managed. The figure below shows the contents of a Management Pack.

 Figure 2 - Management Pack Contents

Figure 2 - Management Pack Contents

You can divide Management Pack contents conceptually into content targeted for MOM agents and associated managed servers, and content targeted for operator consoles. The pack supplies the following for managed servers:

  • Rules. Determine what data is collected to generate events, what responses will occur, what alerts will be raised, and what performance statistics will be gathered. Rule groups combine related rules together for targeting as a single unit. Rules reference Provider Instances.

  • Provider Instances. Refer to a particular type of event source, such as the event log, performance counter, time-based, or WMI query.

  • Scripts. Execute for custom events or alert responses, or other tasks needed for administration.

  • Computer Groups. Describe the essence of a particular set of servers. Rules groups, in turn, apply to the computer groups they reference. You can manually assign servers to a computer group, which is a static assignment, or assign them based on a common criteria such as registry key, IP address range, and others, which is a dynamic assignment.

  • Notification Groups. Represent roles that are responsible for a particular aspect of monitoring, such as IIS Administrators. They are part of a Management Pack to represent what the author believed were potential divisions of responsibility. The responses established for rules can reference Notification Groups if the response is "Send a notification..."

The pack supplies the following relating to operators and console functionality:

  • Tasks. Represent Management Pack-specific scripts. An operator uses these scripts to gather additional information or perform specific tasks that relate directly to the area the management pack is managing. An example is a connectivity check to ensure a service is still listening on the appropriate port.

  • Views. Provide customized views of the operational data gathered by the pack. An example is a filter that displays all of the "Database free space" alerts raised in the last seven days by the SQL MP.

  • Diagrams. Provide customized graphical views of the state or health of what the pack is managing. An example is a graphical overview of the health of all SQL Agent services in an environment.

  • Schemas and Relationships. Define how one subsystem relates to another in order to leverage the state monitoring functionality of MOM. An example is the logic that would indicate whether a subcomponent of Microsoft SQL Server™, such as the Agent, should have its health status roll up to the health of the server or the associated computer group. This allows for at-a-glance views at an aggregate level.

  • Reports. Build on SQL Reporting Services to provide custom views of operational data relevant to the pack.

  • Knowledge Base content (for rules and other artifacts). Provides a key way for Management Pack authors to further capture their knowledge of the system and make it visible to operations staff. An example is a detailed problem resolution path to follow when a rule raises an alert in response to long-running SQL Agent jobs.

Installing BizTalk Server 2004 Management Pack

Note   If you are already quite familiar with BizTalk Server 2004 Management Pack (BizTalk MP), you may want to pass over this section and the next section.

If you have not yet deployed BizTalk MP, you can download it from After you have extracted the download, you are ready to import the management pack.

In the MOM Administrator console, select Microsoft Operations Manager to view a task pane on the right side that includes a link for importing management packs. This will launch a wizard that will guide you through the process, as shown in figures 3 and 4.


Figure 3 - Importing a Management Pack

 Figure 4 - Management Pack Import Wizard

Figure 4 - Management Pack Import Wizard

Next, you can confirm a successful installation by selecting Management Packs, followed by Rule Groups. You should see a rule group for Microsoft BizTalk Server 2004, with child groups for BizTalk Server 2004 Core and Enterprise Single Sign-On.

To make sure the import Management Pack artifacts are propagated quickly, right-click Management Packs and select Commit Configuration Change, as shown in figure 5.

Figure 5 - Completing the Management Pack Installation

Figure 5 - Completing the Management Pack Installation

Contents of the BizTalk Server 2004 Management Pack

At a high level, you can divide BizTalk Server 2004 Management Pack (BizTalk MP) into three general areas:

  • Availability Monitoring

  • Health Monitoring

  • Utilization / Performance Tracking

Let us examine what BizTalk MP provides for each of these three areas, providing a sense for the infrastructure nature of the monitoring provided, as opposed to the monitoring that might be required for your specific BizTalk Server 2004-based application. Note that we focus here on the BizTalk Server 2004 Core rule group, as that is our primary focus in the discussion regarding custom management packs. Appendix A, shown at the end of this paper, covers the rules in BizTalk MP for the Enterprise Single Sign-On service.

Note that the ReadMe.rtf file for BizTalk MP indicates that there are partially configured template rules and MOM views included in the management pack. This information is incorrect.

This section ends with a brief look at some sample scenarios to illustrate which alerts MOM would raise in various cases.

Availability Monitoring

The BizTalk Server 2004 Core rule group contains the following rules to address availability monitoring, that is, monitoring related to whether BizTalk Server is currently operable and able to process work. All of the rules are configured to suppress duplicate alerts for identical event content, which means a repeat count will be incremented for a single alert rather than seeing multiple alert instances in the MOM Console. This is key to avoiding a flood of console alerts that an administrator must deal with; too much information can be as problematic as too little. None of the rules contain automated responses, such as email/pager notifications, though operations staff can easily add these.

Rule Name



Alert Severity

A BizTalk Host instance has stopped and is not processing information.

Indicates an instance of the BTSNTSvc.exe service (a host instance) has stopped, and is not processing any additional work. Restart the host and examine the event log for related errors.

Event ID 5429

Service Unavailable

A BizTalk Server subservice has failed while executing a service request.

Indicates one of the host sub-services such as BizTalk Message Queuing (MSMQT), Tracking Data Decode Service (TDDS), Endpoint Manager or messaging subservice (EPM) failed to start. Examine the event log for related errors.

Event ID 5434

Critical Error

A File Receive location is invalid.

Indicates that the configured directory is invalid, that is, it does not exist. Examine the Receive location properties using the BizTalk Admin MMC or VS.NET.

Event ID 7176


A Receive location is shutting down.

Indicates than an adapter-specific error has caused the Receive location to shut down.

Event ID 5649

Service Unavailable

A stored procedure call failed.

Often indicates that SQL Server is not functioning properly. Consider having a database administrator (DBA) examine SQL traces.

Event ID 6912

Critical Error

An adapter was added to this host application after the service started.

Indicates that Receive locations specific to an adapter are not functioning within a given Host instance, and that Host instance must be recycled.

Event ID 5780

Critical Error

An attempt to connect to the MessageBox database failed.

Indicates connectivity problems with the SQL Server database. Check network status and permissions.

Event ID 6913

Service Unavailable

The Host instance failed to connect to the BizTalk Configuration database.

Indicates connectivity or permissions issues with the SQL Server database. Check network status and permissions.

Event ID 5439


The Messaging Engine could not contact the SSO server.

Indicates that the Enterprise Single Sign-On (SSO) service is unavailable, and could not be contacted to retrieve configuration data. Check the running state of the SSO service.

Event ID 5777

Service Unavailable

The Messaging Engine encountered an error initializing a Receive adapter.

Indicates that a Receive adapter was unable to initialize for reasons indicated by the reported HRESULT.

Event ID 5697

Critical Error

The Messaging Engine failed to initialize a transport adapter.

Indicates that a Transport adapter was unable to initialize for reasons indicated in the event detail.

Event ID 5652

Critical Error

The Messaging Engine failed to initialize the Receive Manager.

Indicates that this particular subsystem within the Messaging Engine is potentially having low system resource issues, connectivity issues with SSO, or Receive location configuration errors. No messages will be received.

Event ID 5640

Critical Error

The Messaging Engine failed to initialize.

Indicates that a component within the Endpoint Manager (EPM) failed, often because of connectivity issues with the SSO or adapter component failures. Check network status and permissions.

Event ID 5632

Critical Error

The Messaging Engine failed to register an adapter.

Indicates that multiple adapters have been registered to operate within the same isolated Host process, such as HTTP and SOAP attempting to use the same Application Pool. Isolate adapter usage to unique application pools.

Event ID 5787

Critical Error

The Messaging Engine failed to retrieve the configuration from the database.

Indicates connectivity issues with either the SSO or Configuration databases. Check network status and permissions.

Event ID 5641

Critical Error


  • You may wish to add a rule with a Service Unavailable alert for Event ID 5741/Source="BizTalk Server 2004" which states, “The receive location filespec is shutting down. The adapter did not provide any error description.”

  • You may wish to add a rule with a Service Unavailable alert  for Event ID 5644/Source="BizTalk Server 2004" which states, “The Messaging Engine failed to add a receive URL url to the adapter adapterName. Reason: reason.

Health Monitoring

The BizTalk Server 2004 Core rule group contains the following rules to address health monitoring, that is, monitoring related to various non-fatal failure modes. Typically, the situation may be isolated to individual interchanges or may possibly resolve itself. The BizTalk Server service is still, in some capacity, able to process work. The primary intent of these rules is to provide operations staff with information relating to messages that are stuck in the system and that require manual intervention of some sort, and to give them the information required to rectify the root problem.

All of these rules are configured to suppress duplicate alerts for identical event content, which means a repeat count will be incremented for a single alert rather than seeing multiple alert instances in the MOM Console. None of the rules contain automated responses, but such responses could easily be added by operations staff.

Rule Name



Alert Severity

A Message Instance has been suspended - WMI.

Indicates that a message instance has been suspended. This is almost always MSMQT, as other transports raise a "Service Instance Suspended" event. Use HAT to research further.

SELECT * FROM MSBTS_MessageInstanceSuspendedEvent


A Service Instance has been suspended - WMI.

Indicates that a message that has been received and assigned to a service instance, such as a pipeline, transport, orchestration, and so on, has been suspended. Use HAT to research further.

SELECT * FROM MSBTS_MessageInstanceSuspendedEvent


All Receive locations are being temporarily disabled because either the MessageBox or Configuration database is not available.

Indicates that the BizTalk Server service is experiencing connectivity issues with the MessageBox or Management/Configuration databases. Check network status and permissions.

Event ID 5773


An adapter raised an error during message processing.

Indicates a problem with a specific adapter identified in the DETAILS section.

Event ID 5740


An inbound message is being suspending by the adapter. [Rule is misspelled in MP]

Indicates that Transport Receive adapter is suspending the message arriving on the Source URL defined in the message. Use HAT to research further.

Event ID 5753

No Alert raised

An outbound message is being suspended by the adapter.

Indicates that Transport Transmit adapter is suspending the message attempting to send on the Destination URL defined in the message. Use HAT to research further.

Event ID 5754

No Alert raised

The Messaging Engine has suspended one or more inbound message(s).

Indicates one or more messages were suspended from a particular Receive adapter, identified in the message. Use HAT to research further.

Event ID 5752

No Alert raised

The Messaging Engine has suspended one or more outbound message(s).

Indicates one or more messages were suspended from a particular Transmit adapter, identified in the message. Use HAT to research further.

Event ID 5680

No Alert raised

The Messaging Engine could not find a matching subscription for the incoming message.

Indicates that the Messaging Engine failed to process a message submitted by an adapter, typically because a send port or orchestration has not been started, or appropriate properties on the message have not been promoted, or the message is simply not subscribed to by what has been currently deployed.

Event ID 5778

No Alert raised

The Messaging Engine encountered an error publishing a batch of messages.

Indicates that one or more messages were not published, often because of incorrect endpoint bindings. Check binding (port properties) and look for related transport errors in the event log.

Event ID 5755

No Alert raised

The Messaging Engine is dropping the message due to an authentication failure.

Indicates that a failure is occurring with a Receive port that requires authentication. Check port properties to see if authentication options are configured correctly, and look at what identity the sender is using.

Event ID 5724


The MSMQT subservice failed to start because Windows MSMQ service is running on the computer.

Indicates that MSMQ service is not running in accordance with side-by-side installation procedures (or should be turned off.)

Event ID 7425


The processed file is either read-only or a system file.

Indicates that the received file is potentially marked read-only.

Event ID 7175


There was a failure executing a Receive pipeline.

Indicates that a pipeline failure occurred as described in the message (which includes Receive pipeline, Receive location and reason codes.)

Event ID 5719


There was a failure executing a send pipeline.

Indicates that a pipeline failure occurred as described in the message (which includes send pipeline and reason codes.)

Event ID 5720


There was an error executing a pipeline component.

Indicates that pipeline component failed, such as Assemblers/Disassemblers, Encoders/Decoders, Parsers/Serializers, as well as any custom component. Examine the stack trace and consult the component author.

Event ID 5709


Performance Monitoring

There are two types of Performance Rules you can create within MOM: Measurement rules and Comparison Rules. Measurement rules gather data from Microsoft Windows® performance counters, or other data sources, with a specified sampling rate and store the data for historical analysis. Comparison rules allow actions to be taken and alerts to be raised when a given performance value varies by a specified threshold from expected values, which can include averages of past samples.

All of the Performance Rules provided by BizTalk MP are Measurement rules, because establishing Comparison rules, or thresholds, outside the context of a particular application would be problematic.

The table below shows the Performance Rules for the BizTalk Server 2004 Core rule group.


  • All of the counter values for the BizTalk Tracking Data Decode Service (TDDS), otherwise known as the BAM Event Bus Service, performance object are stored with 15 minute samples.

  • Within the BizTalk:Messaging performance object, all counter values except the following are stored, with 15 minutes samples: Active Receive Locations, Active Receive Threads, Active Send Messages, Active Send Threads, Documents Resubmitted, Pending Receive Batches, Pending Transmitted Batches, Request/Response timeouts, and Throttled Receive Batches. These counters were all added in Service Pack 1, and you should add these manually if you find historic analysis useful.

  • Within the XLANG/s Orchestrations performance object, all counters except the following are stored, with 15 minutes samples: Megabytes Allocated Private Memory, Dehydration Threshold, Orchestrations Created, Orchestrations Created/Sec.

Rule Name

Provider Name

BizTalk:TDDS - Batches being processed

BizTalk:TDDS-Batches being processed-15.0-minutes

BizTalk:TDDS-Batches Committed

BizTalk:TDDS-Batches Committed-15.0-minutes

BizTalk:TDDS-Events being processed

BizTalk:TDDS-Events being processed-15.0-minutes

BizTalk:TDDS-Events Committed

BizTalk:TDDS-Events Committed-15.0-minutes

BizTalk:TDDS-Records being processed

BizTalk:TDDS-Records being processed-15.0-minutes

BizTalk:TDDS-Records Committed

BizTalk:TDDS-Records Committed-15.0-minutes

BizTalk:TDDS-Total Batches

BizTalk:TDDS-Total Batches-15.0-minutes

BizTalk:TDDS-Total Events

BizTalk:TDDS-Total Events-15.0-minutes

BizTalk:TDDS-Total Failed Batches

BizTalk:TDDS-Total Failed Batches-15.0-minutes

BizTalk:TDDS-Total Failed Events

BizTalk:TDDS-Total Failed Events-15.0-minutes

BizTalk:TDDS-Total Records

BizTalk:TDDS-Total Records-15.0-minutes

Documents processed

BizTalk:Messaging-Documents processed-<All>-15.0-minutes

Documents processed/sec

BizTalk:Messaging-Documents processed/Sec-<All>-15.0-minutes

Documents received

BizTalk:Messaging-Documents received-<All>-15.0-minutes

Documents received/sec

BizTalk:Messaging-Documents received/Sec-<All>-15.0-minutes

Documents suspended

BizTalk:Messaging-Documents suspended-<All>-15.0-minutes

Documents suspended/sec

BizTalk:Messaging-Documents suspended/Sec-<All>-15.0-minutes

ID Process

BizTalk:Messaging-ID Process-<All>-15.0-minutes

MessageBox databases connection failures

XLANG/s Orchestrations-MessageBox databases connection failures-<All>-15.0-minutes

Online MessageBox databases

XLANG/s Orchestrations-Online MessageBox databases-<All>-15.0-minutes

Orchestrations completed

XLANG/s Orchestrations-Orchestrations completed-<All>-15.0-minutes

Orchestrations completed/sec

XLANG/s Orchestrations-Orchestrations completed/sec-<All>-15.0-minutes

Orchestrations dehydrated

XLANG/s Orchestrations-Orchestrations dehydrated-<All>-15.0-minutes

Orchestrations dehydrated/sec

XLANG/s Orchestrations-Orchestrations dehydrated/sec-<All>-15.0-minutes

Orchestrations discarded

XLANG/s Orchestrations-Orchestrations discarded-<All>-15.0-minutes

Orchestrations discarded/sec

XLANG/s Orchestrations-Orchestrations discarded/sec-<All>-15.0-minutes

Orchestrations rehydrated

XLANG/s Orchestrations-Orchestrations rehydrated-<All>-15.0-minutes

Orchestrations rehydrated/sec

XLANG/s Orchestrations-Orchestrations rehydrated/sec-<All>-15.0-minutes

Orchestrations resident in-memory

XLANG/s Orchestrations-Orchestrations resident in-memory-<All>-15.0-minutes

Orchestrations scheduled for dehydration

XLANG/s Orchestrations-Orchestrations scheduled for dehydration-<All>-15.0-minutes

Orchestrations suspended

XLANG/s Orchestrations-Orchestrations suspended-<All>-15.0-minutes

Orchestrations suspended/sec

XLANG/s Orchestrations-Orchestrations suspended/sec-<All>-15.0-minutes

Orchestrations-% allocated private memory

XLANG/s Orchestrations-% allocated private memory-<All>-15.0-minutes

Orchestrations-% used physical memory

XLANG/s Orchestrations-% used physical memory-<All>-15.0-minutes

Orchestrations-Active application domains

XLANG/s Orchestrations-Active application domains-<All>-15.0-minutes

Orchestrations-Average batch factor

XLANG/s Orchestrations-Average batch factor-<All>-15.0-minutes

Orchestrations-Database transactions

XLANG/s Orchestrations-Database transactions-<All>-15.0-minutes

Orchestrations-Database transactions/sec

XLANG/s Orchestrations-Database transactions/sec-<All>-15.0-minutes

Orchestrations-Dehydratable orchestrations

XLANG/s Orchestrations-Dehydratable orchestrations-<All>-15.0-minutes

Orchestrations-Dehydrating orchestrations

XLANG/s Orchestrations-Dehydrating orchestrations-<All>-15.0-minutes

Orchestrations-Dehydration cycle in progress

XLANG/s Orchestrations-Dehydration cycle in progress-<All>-15.0-minutes

Orchestrations-Dehydration cycles

XLANG/s Orchestrations-Dehydration cycles-<All>-15.0-minutes

Orchestrations-Idle orchestrations

XLANG/s Orchestrations-Idle orchestrations-<All>-15.0-minutes

Orchestrations-Megabytes allocated virtual memory

XLANG/s Orchestrations-Megabytes allocated virtual memory-<All>-15.0-minutes

Orchestrations-Pending messages

XLANG/s Orchestrations-Pending messages-<All>-15.0-minutes

Orchestrations-Pending work items

XLANG/s Orchestrations-Pending work items-<All>-15.0-minutes

Orchestrations-Persistence points

XLANG/s Orchestrations-Persistence points-<All>-15.0-minutes

Orchestrations-Persistence points/sec

XLANG/s Orchestrations-Persistence points/sec-<All>-15.0-minutes

Orchestrations-Transactional scopes aborted

XLANG/s Orchestrations-Transactional scopes aborted-<All>-15.0-minutes

Orchestrations-Transactional scopes aborted/sec

XLANG/s Orchestrations-Transactional scopes aborted/sec-<All>-15.0-minutes

Orchestrations-Transactional scopes committed

XLANG/s Orchestrations-Transactional scopes committed-<All>-15.0-minutes

Orchestrations-Transactional scopes committed/sec

XLANG/s Orchestrations-Transactional scopes committed/sec-<All>-15.0-minutes

Orchestrations-Transactional scopes compensated

XLANG/s Orchestrations-Transactional scopes compensated-<All>-15.0-minutes

Orchestrations-Transactional scopes compensated/sec

XLANG/s Orchestrations-Transactional scopes compensated/sec-<All>-15.0-minutes

Runnable orchestrations

XLANG/s Orchestrations-Runnable orchestrations-<All>-15.0-minutes

Running orchestrations

XLANG/s Orchestrations-Running orchestrations-<All>-15.0-minutes

What Else Will You Need?

To monitor your BizTalk Server infrastructure comprehensively, we recommend that you also install the management packs for Microsoft Windows Server™ Base Operating System, Microsoft SQL Server, and Microsoft Windows Internet Information Services. Depending on your environment, you might also find the Microsoft Message Queue (MSMQ) and Microsoft .NET Framework Management Packs useful. All of these are available as downloads from (using the name of the management pack and "management pack" as keywords.)

If you install Microsoft SQL Server Management Pack, you will want to designate as critical the BizTalk Server databases, typically named BAMArchive, BAMPrimaryImport, BAMStarSchema, BizTalkDTADb, BizTalkEDIDb, BizTalkHwsDb, BizTalkMgmtDb, BizTalkMsgBoxDb, BizTalkRuleEngineDb, TPM and SSODB.

The following steps are require to mark databases as critical:

  1. From the State Monitoring and Service Discovery rule group for Microsoft SQL Server select Event Rules.

  2. Edit SQL Server Database Health. You may wish to rename it to indicate that it has been customized.

  3. Click the Responses tab and edit the response script.

  4. Edit the HighSevDatabases parameter to the script.

  5. Add to the value of the parameter by providing a comma-separated list of the BizTalk Server databases. Note that this will work regardless of how you physically distribute your BizTalk Server databases across servers, as long as they are all members of the Microsoft SQL Server 2000 computer group.


Figure 6 - Marking BizTalk Server databases as critical in SQL Server Management Pack

Sample Scenarios

Following are a set of error-producing scenarios and a discussion of what the corresponding error message activity and console view look like. This is not an exhaustive look at BizTalk MP functionality, but rather a glimpse into how typical problems will cause rules to occur and alerts to flow to the MOM Console. The MOM Console is where you can act upon alerts and move through various resolution states by operations staff.

Providing Non-XML File to XMLReceive Pipeline

If an non-XML file were to be fed to a Receive location that was using an XML disassembler in the associated pipeline (such as Microsoft.BizTalk.DefaultPipelines.XMLReceive), two rules from the BizTalk Server 2004 Core rule group will occur, as illustrated in the MOM Console view below. The first is the “There was a failure executing a receive pipeline,” and the second is “A Service Instance has been suspended – WMI.” Both alerts generate, presumably because there are pipeline execution failures that would not result in a suspended message depending on in what pipeline stage the failure occurred. The suspended message alert indicates that there is at least a message, with associated context and message flow, available to view in Health and Activity Tracking (HAT) even if the transaction cannot be resumed.


Figure 7 -Non-XML file to XmlReceive pipeline

Unexpected Termination of SQL Server

If the SQL Server service process were to terminate unexpectedly, the set of alerts generated would vary according to how long it took the process to restart. There are many rules that are candidates raise if SQL Server is unavailable. In the lab environment, where installation of multiple management packs in in place, the following rules occurred prior to SQL Server restart:

  • Microsoft Windows Servers Base Operating System\Windows 2003\Core System Components and Services - The service terminated unexpectedly (for the BizTalk Server service)

  • Microsoft BizTalk Server 2004\Enterprise Single Sign-On - An error occurred while attempting to access the SSO database.

  • Microsoft SQL Server\SQL Server 2000\SQL Server 2000 Event Collection\SQL Server General - The MSSQLServer service terminated unexpectedly

  • Microsoft BizTalk Server 2004\Enterprise Single Sign-On - An error occurred while attempting to access the SSO database.

As a result, the MOM Console looked as shown in in Figure 8.


Figure 8 - Unexpected SQL Server process termination

Exception within an Orchestration

If an exception is thrown, and not caught, within an orchestration, the "A Service Instance has been suspended – WMI" rule would occur. As is seen in the Console view below, an InstanceID property within the WMI event is available, and this can be tied to the Service Instance ID column within HAT, specifically, the Operations:Service Instances view. HAT will then provide additional detail about exactly which orchestration and exception was involved. If you right-click on the service instance and select Orchestration Debugger, you can see progress within the workflow, as well as see the stack trace associated with the exception. This if found under the Debug menu.

Note: To avoid the need to use HAT to track down which orchestration was involved, and to get a stack trace, you may wish to add a rule with an Error alert for Event ID 10034/Source="XLANG/s", which is “Uncaught exception terminated service orchestrationName”. The description of this event will contain many details that the corresponding WMI event does not, though the event structur is purely as text.


Figure 9 - Uncaught exception in orchestration

Why Application-Specific Management Packs?

Having just discussed the extensive monitoring available in the standard BizTalk MP, why focus on application-specific management packs?

All of the server products that Microsoft offers, which serve as a development platform, will introduce two layers of monitoring needs into the deployed environment.

  • An infrastructure layer. In an infrastructure layer the primary concern is health and availability of the core service and the subsystems that it must rely on. This is essentially answering whether the vendor-supplied components are currently functioning properly. Note that Microsoft Internet Information Services, Commerce Server, .NET Framework, Host Integration Server, BizTalk Server, Microsoft Message Queuing, SharePoint® Sevices, and SQL Server are all components of the server development stack that have a Microsoft Operations Manager (MOM) Management Pack that functions in this manner.

  • An application layer. In an application layer,the primary concern is the health and availability of what you have assembled on top of the platform provided. As an application grows richer and more complex, you can often find the greater monitoring complexity in the application, not in the infrastructure.

Often, two different Information Technology (IT) groups will be responsible for these two different layers of monitoring. The TechNet IT Showcase article titled “Deploying Microsoft Operations Manager 2005 at Microsoft” describes the division of responsibility within the Microsoft IT organization. An Infrastructure Services (IS) group manages Microsoft Active Directory® directory services, DNS, DHCP, WINS, and other dial tone services, whereas a Centralized Business Unit IT (Central BUIT) group manages production line-of-business applications.

It is this second layer that can be more challenging, precisely because the specific monitoring needs will be as varied as the applications themselves. In an IT shop setting, communicating application-specific monitoring needs between the development team and an operations staff has traditionally been notoriously difficult. Development teams may often invest in instrumenting their applications, but several issues complicate the operational handoff:

  • Do all fatal error scenarios in the application result in an event log entry or WMI event? Are event log entries from the application made with a common event source?

  • Are there a set of event log Event IDs generated by the application that you should examine for specialized operations handling?

  • Is there a single event for each actual application problem, or several? What conditions allow for the consolidation of several events for purposes of alerting?

  • Is there an over-reliance on diagnostic-level tracing upon which only the application development team can interpret and act?

  • At the point where the application intersects with the platform, what failure scenarios should receive attention that is more specific? A concrete exampleis that the BizTalk MP can tell you “an outbound message is being suspended by the adapter,” and provide some generalized knowledge base help. However, what if this means you are not interacting with a crucial trading partner in a crucial business process? This should receive custom alerting, response, and knowledge base content.

In general, the application often has an ill-defined instrumentation surface area, that is, you cannot suffiently understand the event log entries it writes, the custom performance counter data it generates, and diagnostic-level tracing enough to create an actionable operations plan. Thus, the operations group that is responsible for application-level monitoring must learn by trial and error what the appropriate response is to any given application event. This process inevitably causes lengthy problem resolution times while it reaches steady state, and usually involves the creation of many custom scripts, or the adoption of custom applications written by the development team.

A development team can achieve a much better outcome if it gets quite clear on the instrumentation surface area of the application, and captures that knowledge, as well as appropriate responses and knowledge base content, in the form of a custom MOM Management Pack. This will far exceed what written documentation such as static operations guides or other similar hand-off materials can provide.

Developing Your Application-Specific Management Pack

You could take many approaches to developing an application-specific management pack. In this section, we discuss one such approach. Learning more about MOM 2005 from the provided online documentation is required to be successful, but the benefits will be substantial.

At a high level, the overall approach consists of the following steps:

  1. Put the MOM Administrator Console in “Authoring Mode.”

  2. Create a new computer group that will be specific to those servers that have your application installed.

  3. Create a new rule group that will be specific to your application, and that targets the application-specific computer group.

  4. For rules that are in BizTalk MP that appear to be good candidates for application-specific customization, copy-and-paste rules. This will be discussed later in greater detail

  5. For rules that are in BizTalk MP that you have copied, supply “rule-disable overrides” on the original rules to avoid double alerts.

  6. Create new rules not covered by BizTalk MP that your application requires.

  7. Create alerting rules for your application-specific management pack that can cause the notifications appropriate to this application to flow out to operations staff, perhaps specific to various tiers of support.

  8. Export your management pack,and  import into a development server and test. Treat it as another deliverable for the application.

We discuss each of these steps in turn, though space does not permit us to describe the creation of a complete sample management pack.

Authoring Mode

Authoring mode activates user interface features in the MOM Administrator Console that enable you to create and edit vendor-specific knowledge. Developers of an application should always interpret themselves to be the vendor when dealing with MOM. Operations staff may add company knowledge to rules over time. Authoring mode also enables advanced properties on rules, groups, and other items that are read-only or disabled by default. To enable authoring mode, from the Administrator console click Management Packs, right-click Rule Groups, and then click Authoring Mode.

Create Application-Specific Computer Group

The MOM Management Server deploys monitoring configuration, for example rules associated with management packs, based on to which computer groups a given server belongs. It is useful to identify the servers your application will reside on as a distinct group.

The most flexible way to accomplish this is to create first a new "Computer Attribute." You can find Computer Attributes as a child node of Management Packs in the MOM Administrator console. A computer attribute can be either a registry key or registry value that your application installation creates indicating by its presence the current installation status of the application. For example, the presence of SOFTWARE\MyAppName might be a good indication of the installation of your application if there is key creation when you install the application and removed when uninstalled.

To create the application-specific computer group, from Management Packs, right-click Computer Groups, and click Create Computer Group.

In the wizard that appears, you can populate a static list of the currently installed servers for your application in the Included Computers step. However, if you have created an appropriate Computer Attribute, advance to the Formula step and choose Specify a formula... option. Click Attribute and choose the attribute you created, as shown in Figure 10.

Note: You can also use the naming patterns for your servers or other criteria to define group membership.


Figure 10 - Create computer group based on computer attribute

Note that if your application consists of multiple types of servers, such as BizTalk Server servers and Web servers, you may wish to create two different types of computer groups to represent these, perhaps under a common parent.

Create a New Rule Group

Rule Groups are used to group rules, just as the name implies. You can organize them in hierarchies, so if your application consists of logically independent pieces or if it consists of different types of servers, such as BizTalk Server and Web Server, you may wish to create multiple rules groups with a common parent.

To create a rule group in the MOM Administrator console, right-click Rule Groups and click New Rule Group. In the wizard that appears, provide a name and description and accept the default of Enabled. Company knowledge can be left blank. Remember, the application author is the Vendor.

In the third wizard step, select Export as a vendor produced rule. If the rule is disabled, then do not export. This will allow you to keep particular rules from being included in your management pack export by simply disabling them. This is convenient when authoring.

Figure 11 - Advanced rule group properties

Figure 11 - Advanced rule group properties

Finally, the wizard will ask you to enter information about your application, also known as vendor knowledge. Populate this box with the purpose, features, and configuration of this rule group, or the management pack as a whole. Right-clicking Rule Group from the Administrator console and selecting Regenerate Knowledge from the menu can generate the HTML-formatted version of knowledge information.

Figure 12 – Populating vendor knowledge

Figure 12 – Populating vendor knowledge

After finishing the wizard, there is a prompt to deploy the rules in the new rule group to a group of computers. Click Yes, and the Rule Group properties shown in Figure 13 displays, letting you add or remove references to the computer group created previously.

Figure 13 - Target a rule group to a computer group

Figure 13 - Target a rule group to a computer group

Note that if you have chosen to create multiple rule groups, with a common parent, in order to correspond to the different types of servers present in your application, you will likely not want to target the top level rule group to a computer group at all. Instead, you can target the child rule groups to the corresponding computer groups.

Copy Desired Rules from BizTalk MP

Many of the rules in BizTalk MP might be useful to your application, but with some customization could provide additional diagnostic information.

As an example, assume that we have a BizTalk Server solution that contains multiple Receive locations with associated custom pipelines. Suppose one or more of these Receive locations have a failure mode that you can describe in a rule knowledge base entry, and has a well-defined response. The rule in the BizTalk Server 2004 Core rule group titled “There was a failure executing a Receive pipeline” could be improved upon in this case.

First, in this rule group, you can locate this rule, right-click and copy. Then, in the newly created rule group for your application, you can paste the rule. You are prompted as to how to handle the associated knowledge for the rule, Select Leave the knowledge authoring entry of the new rule empty. You may wish to remove the “Copy of...” prefix that adds to this rule.

Figure 14 - Copying a rule

Figure 14 - Copying a rule

Paste the rule twice – once for the special case handling just described, and once for the default case.

Now, assume that the Receive location that would benefit from the special case handling has a Receive location using the FILE adapter, and that it picks up purchase orders from an UNC path: \\PROD011\POPickup\*.xml

In this case, we edit the first copy of the rule we just pasted, and change the name to reflect the special case such as, “PO Pickup problems.” Click the Criteria tab, click Advanced..., and add the Description field with a contains substring condition. The value would be set equal to \\PROD011\POPickup\*.xml. Then click Add to list..

Figure 15 - Customizing criteria for special-case handling

Figure 15 - Customizing criteria for special-case handling

Moreover, in the Knowledge Authoring tab, you can add a description such as “This error often occurs because one of our vendors is sending us documents that conform to a new version of the PO schema that we have not yet adopted.” This would cause the alert details view to look as shown in Figure 16. In the Responses tab, you can click Send a notification to a notification group to ensure that an e-mail reaches someone who manages vendor relationships.


Figure 16 - Alert details showing custom knowledge base content

This example may or may not be realistic in your environment, but the point is clear: We can take a particular failure mode of our application and of BizTalk Server 2004, and customize the knowledge base content, alert severity, response, notification, and so forth, all to match a particular situation. This is a very efficient way of communicating the specifics of how an operations staff should handle such a failure mode in production.

For default case handling, such as pipeline failures that don't involve purchase orders, we can edit the second copy of the rule we made, and set the Advanced Criteria to reflect “Description doesn't contain substring \\PROD011\POPickup\*.xml”. This could also be set to reflect that the description does not contain regular expression, and so forth, if the issues became more complex. This ensures raising only a single alert for the purchase order case.

Other examples of cases where it may be desirable to create custom versions of existing rules include:

  • Any case where the rule itself is sufficient, but additional vendor (developer-supplied) knowledge will be helpful because the failure mode can be better described in the context of the application

  • Cases where you should handle failures for send ports in a way that is specific to the Send port, so that you can take action with a particular external service provider, perhaps a credit agency or other vendor.

  • Cases where you can route failures involving a particular specialized adapter to a specific team, for example, an application adapter, like SAP.

  • Cases where failures for particular deployed orchestrations need special treatment. One such example would be a different level for alert consolidation, for instance, suppressing extra alerts that would arise from a rule that was watching for event log entries pertaining to a particular application-defined exception. In the normal case, alert suppression would only happen if the event description was identical, which will not be the case if the exception occurs in different locations within the orchestration, given that the stack trace will be different. This case can be accommodated by building event rules that use criteria that look for a substring, or regular expression, in the event description rather than insisting on a complete match in description in order to get alert suppression.

Apply Rule-Disable Overrides

Suppose you created a custom version of a rule, as just described in the previous section. Since servers in your application-specific computer group will be members of the BizTalk Server computer group as well, all rules from BizTalk MP will apply. For those rules in BizTalk MP that you replace or enhance with custom rules, you should supply rule-disable overrides, on the original rule, that reference your application-specific computer group as criteria. Otherwise, two alerts raise for the same issue. You are specifying that the situation is under control and that you are opting out of default BizTalk MP handling.

This is straightforward to accomplish. Locate and edit the original rule from which you copied. You find this in BizTalk MP. In the General tab, select Enable rule-disable overrides for this rule. In the Set Criteria... dialog box, add the name of the computer group that corresponds to your application.

Figure 17 - Applying rule-disable override

Figure 17 - Applying rule-disable override
Create New Rules

Examples of new rules you may wish to add to your application-specific management pack are endless. Any case where the code or orchestrations deployed with a BizTalk Server solution log to the event log directly, presumably with a custom source and specific event Ids, will require new rules if MOM alerting is to take place.

Adding Comparison Performance Rules would potentially be a huge additional value. Within the context of a particular application that is running within dedicated hosts it will likely be possible to identify threshold values for such counters as documents processed/sec, orchestrations resident in-memory, orchestrations % allocated private memory, running orchestrations, and so forth. All of the counters added in Service Pack 1 would be good candidates for threshold rules as well. Refer to Performance Monitoring, which you can find earlier in this paper.

Another powerful example of a new rule would be to take advantage of the queries outlined in the document titled "BizTalk Server 2004 Advanced MessageBox Queries", such as the query that checks for current length of the work queue for a given processing host. This begins to reach true health monitoring in a way that other rules might not.

To start, create an event rule with the Provider corresponding to a timed event, such as “Schedule every 10 minutes”. This type of rule occurs at the timing interval, and allows a response to be associated with it. The response in this case is a script that runs the host queue length query. If this query returns a number that is beyond a threshold, the script could raise an event that another rule responded to and created an alert. See Appendix A at the end of this paper for sample stored procedure and script to enable this scenario.

Figure 18 -Creating a rule that runs on a timed interval

Figure 18 -Creating a rule that runs on a timed interval


Figure 19 - Specifying a response script for timed interval rule
Create Alerting Rules

Alerting rules are distinct from event rules, and deal with the handling of alerts themselves as the name implies. When you create alerting rules targeted to your computer group, you can define, for instance, how to handle notifications for all alerts raised by all rules executing on your servers.

This can be quite powerful, because it enables the operations staff that is responsible for a particular application to ensure they are able to deal with alerts in the way that best suits that team. You can find alert rules in Event Rules.


The last step required when creating an application-specific management pack is to export it, import it on a separate test server environment, and test.

The default file format for MOM Management Packs is a binary format with the extension AKM. You can convert management packs to an XML format using a conversion tool included with the MOM 2005 Resource Kit, and then compare with another XML rendering using a resource kit tool named MPDiff. You cannont import these XML files, however.

To export your management pack, right-click the Management Packs folder in the Administrator console, and click Import/Export Management Pack to start the Management Pack Import/Export wizard. Click Export, choose your top-level rule group, and chose any tasks or views that you may have created for MP. Finally, choose a location for your AKM file.

Note that if you have customized the native BizTalk MP with rule-disable overrides, and have done so outside your production MOM environment, you will need to deploy those changes as well.

Management Pack Enhancements

You can enhance your management pack even further with event consolidation rules, custom tasks for doing such things as clearing caches or resetting specific host instances, custom reports on performance data, and others. We have only looked at just a few aspects of management pack development.

If you are taking advantage of BAM as part of your solution, you should look at the MOM 2005 Resource Kit, which contains a wizard that creates a management pack to monitor business processes. By leveraging the BAM components of BizTalk Server, the wizard allows you to build a management pack using BAM Key Performance Indicators (KPIs) and raise alerts when these KPIs deviate from normal operating conditions.

Appendix A

Enterprise Single Sign-On Event Rules

Rule Name


Alert Severity

The SSO service failed to start.

Indicates that the Enterprise Single Sign-On (SSO) service failed to start and contains the error code for the failure.

Critical Error

The SSO ticket could not be decrypted.

Indicates that the ticket supplied could not be decrypted because it is either invalid or has expired.

Security Breach

An SSO mapping could not be created because the specified user is not valid for this application.

Indicates that during the manual operation of creating a mapping for the user, the mapping could not be created because the user is not a member of the Application User account.


Tickets are not enabled for this SSO application.

Indicates that tickets are not allowed for this particular application. Examine the creation parameters for the application.


A user operation failed the SSO audit.

Indicates that something went wrong with a user application.


The SSO service is running as a local Administrator.

Indicates that the SSO service is running as an administrative user, which is not a recommended configuration.


Failed to retrieve master secrets.

Indicates that a server was attempting to communicate with the master secret server and failed. 


SSO is going offline.

Indicates that the Enterprise Single Sign-On service is halting.

Service Unavailable

The SSO service must be disabled before changing the SSO Admin account..

Indicates that a user tried to change the SSO Administrators account without first disabling the SSO system.

Security Breach

The SSO ticket has expired.

Indicates that the ticket received has expired. 


SSO Lookup server access denied.

Indicates that an unauthorized attempt to access the mapping server was made. 

Security Breach

The SSO master secret server must be backed up.

Indicates that the master secret server which contains all of the secret information has not been backed up. Use the ssobackup utility.


Failed to back up the SSO master secrets.

Indicates that an attempt to back up the Secrets in the SSO server was made and failed.


The SSO client could not be impersonated.

Indicates that the SSO service did not recognize or could not impersonate the client. Check the credentials that are configured for use.


A request to get a master secret failed.

Indicates that an attempt to get a master secret failed.

Security Breach

The SSO credential cache has been disabled.

Indicates that the credential cache is currently disabled. 


The SSO ticket does not have the correct format.

Indicates that the ticket supplied could not be used because it does not have the correct format.

Security Breach

The SSO service could not access the SSO database.

Indicates that there was a problem connecting to the database. Check network status and permissions.


Failed to update the external credentials in the SSO database during re-encryption.

Indicates that the credentials were not updated in the SSO database.


External credentials cannot be returned because the mapping is disabled.

Indicates that the external credentials could not be returned because the mapping is disabled.


The SSO service could not start because its service account is not a member of the SSO Admin Group.

Indicates that the SSO service could not start because the service account it is running under is not a member of the SSO Administrators group.

Critical Error

SSO Config store access denied.

Indicates that the account accessing the configuration store does not have authorization to do so. 

Security Breach

SSO Secret server access denied.

Indicates that an unauthorized attempt to access the secret server was made. 

Security Breach

The SSO system is currently disabled.

Indicates that the SSO system has been disabled.


An error occurred while attempting to access the SSO database.

Indicates that there was a problem accessing the SSO database. Check network status and permissions.


The SSO ticket could not be redeemed because the user is not a member of the Application Users Group.

Indicates that the ticket could not be redeemed because the user account that the ticket was issued to was not a member of the Application Users group.

Security Breach

Tickets are not enabled for the SSO system.

Indicates that tickets are not enabled for the SSO system.


Lost contact with the SSO database.

Indicates that the SSO service lost contact with the SSO database.


The SSO service must be disabled before updating the server name.

Indicates that a user tried to update the master secret server without first disabling the SSO system.

Security Breach

The SSO ticket could not be validated.

Indicates that the validation of the ticket failed because the sender name does not match the ticket issuer.


Tickets are not enabled for the SSO system.

Indicates that tickets are not enabled for the SSO system.


SSO Admin server access denied.

Indicates that an unauthorized attempt to access the mapping server was made.

Security Breach

SSO Mapping server access denied.

Indicates that an unauthorized attempt to access the mapping server was made.

Security Breach

An SSO ticket was redeemed after the ticket timeout period.

Indicates that a ticket was redeemed after the ticket timeout period expired.


The SSO master secret could not be loaded.

Indicates that the secrets could not be loaded from the registry because the service account may have changed.

Critical Error

The SSO credential cache size has been changed.

Indicates that the credential cache has been changed.


The SSO application is currently disabled.

Indicates that the application has been disabled.


Enterprise Single Sign-On Performance Rules

Rule Name

Provider Name

Enterprise SSO-Credential Cache Size

Enterprise SSO-Credential Cache Size-<All>-15.0-minutes

Enterprise SSO-# ValidateAndRedeemTicket

Enterprise SSO-# ValidateAndRedeemTicket-<All>-15.0-minutes

Enterprise SSO-GetConfigInfo/sec

Enterprise SSO-GetConfigInfo/sec-<All>-15.0-minutes

Enterprise SSO-IssueTicket/sec

Enterprise SSO-IssueTicket/sec-<All>-15.0-minutes

Enterprise SSO-# RedeemTicket

Enterprise SSO-# RedeemTicket-<All>-15.0-minutes

Enterprise SSO-ValidateAndRedeemTicket/sec

Enterprise SSO-ValidateAndRedeemTicket/sec-<All>-15.0-minutes

Enterprise SSO-# GetConfigInfo

Enterprise SSO-# GetConfigInfo-<All>-15.0-minutes

Enterprise SSO-# GetCredentials

Enterprise SSO-# GetCredentials-<All>-15.0-minutes

Enterprise SSO-RedeemTicket/sec

Enterprise SSO-RedeemTicket/sec-<All>-15.0-minutes

Enterprise SSO-GetCredentials/sec

Enterprise SSO-GetCredentials/sec-<All>-15.0-minutes

Enterprise SSO-# IssueTicket

Enterprise SSO-# IssueTicket-<All>-15.0-minutes

Appendix B

To monitor host work queue lengths, create a stored procedure on the MessageBox database like this:

CREATE PROCEDURE [dbo].[GetHostQueueLength]
@hostName nvarchar(128)
exec ('SELECT COUNT(*) 
FROM [BizTalkMsgBoxDb]..[' + @hostName +'Q] 

Then, within the scripts node of the MOM Administrator console, create a script like the one below, with parameters for HostName and ThresholdQLength. The Advanced MessageBox Queries white paper suggests a number of 100,000 for threshold queue length, but your application may vary. Finally, create two rules in your rule group, one which runs this script as the response to a timed event provider, supplying the appropriate parameters to the script, and one which responds to any events created that are created by the script and perhaps generates alerts. Note that the rule, which runs the script as the response to a timed event provider, should specify Management Server as the run location, since there is no need to run the script on every BizTalk server in a group.

Note: Some parts of the following code snippet have been displayed in multiple lines only for better readability. These should be entered in a single line.

' Script Name - CheckBizTalkHostQueueLength
' Assumptions - 
' Parameters - "HostName",”ThresholdQLength”

Option Explicit

'Event Constants
Const EVENT_TYPE_ERROR     = 1

'ADO constants
Const adVarChar = 200
Const adVarWChar = 202
Const adCmdStoredProc = &H0004
Const adParamInput = &H0001
Const adParamOutput = &H0002
Const adInteger = 3
Const adExecuteNoRecords = &H00000080

' Rules can respond to these events

Dim oEvent, oParams
Dim hostName, thresholdQLength, dbServer
Dim cmd, rs, message
Dim actualQLength

Set oEvent = ScriptContext.Event

'Get Parameters
Set oParams = ScriptContext.Parameters
hostName = oParams.get("HostName")
thresholdQLength = oParams.get("ThresholdQLength")
dbServer = oParams.get("dbServer")

Set cmd = CreateObject("ADODB.Command")

With cmd
  .ActiveConnection = "Provider=SQLOLEDB;database=BizTalkMsgBoxDB;
  Data Source=" & dbServer & ";Integrated Security=SSPI"
  .Commandtext = "GetHostQueueLength"
  .CommandType = adCmdStoredProc
  .Parameters.Append .CreateParameter 
  ("@hostName", adVarWChar, adParamInput, 128)
  .Parameters("@hostName") = hostName
End with

set rs = cmd.Execute
actualQLength = CInt(rs(0))

if actualQLength > CInt(thresholdQLength) then

  message = "Queue length for host " & hostname & " is " &
  rs(0) & "which exceeds threshold of " & thresholdQLength

end if

Sub CreateEvent(lngEventID, lngEventType, strMsg)

  Dim oNewEvent

  ' Create a new event
  Set oNewEvent = ScriptContext.CreateEvent

  ' Set event properties
  oNewEvent.Message   = Left(strMsg, MAX_EVENT_DESCRIPTION_LENGTH)
  oNewEvent.EventNumber = lngEventID
  oNewEvent.EventType  = lngEventType
  oNewEvent.EventSource = "CheckBizTalkHostQueueLength"

  ' Submit the event
  ScriptContext.Submit oNewEvent

  Set oNewEvent = Nothing

End Sub

About the author:

Scott Colestock ( has been writing, consulting, and developing for BizTalk Server 2004 since the beta timeframe. You can find Scott's deployment framework for automated BizTalk Server deployments, as well as other writing on all things BizTalk Server, at

For more information:

MOM 2005 Resource Kit

MOM 2005 Management Pack Development Guide