Contents

MSMQT Adapter................................................................................................................3

Overview......................................................................................................................... 3

Deprecation of the MSMQT Adapter in BizTalk Server 2006..........................................4

Migrating from the MSMQT Adapter to the MSMQ Adapter............................................5

End-to-End Ordered Delivery......................................................................................5

Transaction Usage When Processing Messages with the MSMQT Adapter vs. the

MSMQ Adapter........................................................................................................6

High Availability (Transactional, in Order)....................................................................7

High Availability (Non-transactional, Not in Order)......................................................8

Scalability (Non-transactional, Not in Order)...............................................................8

Scalability (Transactional, Not in Order)......................................................................9

Scalability (Transactional, in Order)............................................................................9

Architecture Summary....................................................................................................9

Why Migrate to the MSMQT Adapter?..........................................................................10

Common MSMQT Problems and Solutions..................................................................11

Why isn't the MSMQT adapter installed by default?..................................................11

How do I uninstall/delete/deactivate the MSMQT adapter?.......................................11

How can I view messages in MSMQT?.....................................................................12

How can I get the retry count value or the retry interval value to work with MSMQT?

............................................................................................................................... 12

Can I set up MSMQT to receive messages from public queues?..............................12

Does MSMQT support the HTTP protocol?...............................................................12

MSMQT does not seem to start, and I receive the following error in the event log....12

Messages appear to disappear when sending messages to a remote private queue.

............................................................................................................................... 13

Can I use System.Messaging on the BizTalk Server computer where MSMQT is

installed?................................................................................................................13

Which ports are used by MSMQT?...........................................................................13

Can I write programmatically to the MSMQT queue?................................................14

Can I send a message that is larger than 4 MB from MSMQ to MSMQT?................14

Can I install MSMQT and Message Queuing side-by-side?......................................14

What is required to set up MSMQT to use multiple computers in the same BizTalk

group?.................................................................................................................... 15

Can I use Network Address Translation (NAT) with MSMQT?...................................15

Can I use hardware load balancing with MSMQT?...................................................15

MSMQT messages are not flowing...........................................................................16

Performance issues with MSMQT.............................................................................17

Troubleshooting Tips....................................................................................................19

Recommended Hotfixes and Service Packs for MSMQT.............................................19

Resources....................................................................................................................20

Copyright...................................................................................................................... 20

MSMQT Adapter

Microsoft Corporation

April 21, 2006

Applies to: BizTalk Server 2004, with references to BizTalk Server 2006

Summary: This document provides an overview of the BizTalk Message Queuing

(commonly referred to as MSMQT) adapter. Its primary focus is to build a fundamental

understanding of the adapter and to outline the most common problems encountered

when using the adapter and how to address these problems. It also provides

comparisons between the MSMQT adapter and the Message Queuing (also known as

MSMQ) adapter. (13 printed pages)

Prerequisite knowledge: MSMQ 2.0, BizTalk Server 2004

OverviewBizTalk Message Queuing (commonly referred to as MSMQT) is the message queuing

transport component in Microsoft® BizTalk® Server. It is shipped as a core internal

component of the BizTalk Server product and is one of many adapter components in

BizTalk Server.

From a network perspective, BizTalk Message Queuing works the same as Message

Queuing (also known as MSMQ). The main difference between the two components is

that MSMQT sends messages to a receive location instead of sending messages directly

to a queue. This receive location, which is tied directly to the BizTalk Server MessageBox

database, is a virtual representation of a Message Queuing queue.

Note

Receive locations and send ports can be accessed in the BizTalk Server

Administration console or in BizTalk Explorer.

The MSMQT adapter allows for the integration of its message store with the MessageBox

database, a database designed to scale out on multiple servers and serve as a central

repository for all user data. The MSMQT adapter also provides the following subset of

Message Queuing functionality:

Binary protocol. Support for the native (MSMQ 1.0) wire protocol.

3

Private queues. Because messages in BizTalk Server are stored in the MessageBox

database, a queue in MSMQT is a virtual entity. However, the support queues in the

programming interface and remote servers cannot distinguish a Message Queuing

server from an MSMQT server. The MSMQT adapter supports sending messages to

and receiving messages from private queues (queues that are not published as

Active Directory® service objects), as well as sending messages to remote private

queues, but does not support receiving messages from local public queues. This

private queue support extends to send port groups as well. Note that send port

groups cannot have public queues.

Workgroup mode. MSMQT supports direct messaging to private queues without

integration or dependency on Active Directory.

Active Directory mode. MSMQT supports DIRECT addresses. With Active

Directory, it also supports PRIVATE (send/receive) and PUBLIC (send-only)

addressing.

Transactional and best-effort quality of service. MSMQT supports guaranteed

delivery, which is end-to-end reliability, exactly once and in-order delivery.

Note

Ordered delivery only works if MSMQT is the primary transport. If the primary

transport fails, the adapter does not preserve the end-to-end order, even if

the secondary transport is MSMQT.

Just as Message Queuing supports only one body part in a message, MSMQT supports

only one body part in a message.

For more details about MSMQT, review the BizTalk Server 2006 documentation.

Deprecation of the MSMQT Adapter in BizTalk Server 2006The MSMQT adapter is deprecated in BizTalk Server 2006 and is provided for backward

compatibility with existing solutions developed with BizTalk Server 2004. Because the

MSMQT adapter is unchanged from BizTalk Server 2004 to BizTalk Server 2006, it does

not use new functionality that is available to other integrated adapters. For a list of

features in BizTalk Server 2006 that do not apply to the MSMQT adapter, review BizTalk

Server 2006 Help.

4

Migrating from the MSMQT Adapter to the MSMQ AdapterThere is no requirement to migrate existing solutions from the MSMQT adapter to the

MSMQ adapter. The MSMQT adapter is present and fully supported in BizTalk

Server 2006. The MSMQT adapter is deprecated, but that only means that it might not be

available in subsequent versions of BizTalk Server.

The following sections discuss considerations for using the MSMQT adapter and the

MSMQ adapter.

End-to-End Ordered Delivery

The MSMQT adapter ensures end-to-end ordered delivery of messages. This means that

if an MSMQ application sends messages 1, 2, and 3 to a receive location bound to the

MSMQT adapter, then these messages are delivered to an orchestration or send port in

BizTalk Server in the same order: 1, 2, 3. One use of this functionality might include stock

market trades that must be submitted and executed in the same order that they are

received.

End-to-end ordered delivery with the MSMQT adapter requires many components to work

together. The following sequence of events illustrates how this is done with the MSMQT

adapter:

1. The MSMQ API on a remote computer receives messages 1, 2, and 3 in order and

pushes them into a transactional, local queue in the same order: 1, 2, 3.

2. An MSMQ client on the remote computer takes the messages from the queue and

sends them to the MSMQT queue in order: 1, 2, 3.

3. The MSMQT adapter receives the messages in order 1, 2, 3 and hands them to the

BizTalk MessageAgent component in the same order: 1, 2, 3.

Note

The BizTalk MessageAgent is the low-level API that the BizTalk Server 2004

and 2006 engine uses to interact with the MessageBox database.

4. The BizTalk MessageAgent component ensures that the messages are sent to the

MessageBox database in order: 1, 2, 3.

Note

This step provides the storage medium and the primary logic to maintain the

state of a subscription.

5

5. The MessageBox database routes the messages and ensures that if they are routed

to the same instance of an orchestration or a send port, they are delivered to this

instance in the same order: 1, 2, 3.

In BizTalk Server 2004, the MSMQT adapter is the only adapter capable of guaranteeing

end-to end ordered delivery. All other integrated BizTalk adapters can potentially change

the order of the messages in steps 3 through 5 in the preceding list. Most other integrated

adapters complete step 3 by using a component known as the End Point Manager, which

is inherently multithreaded and therefore does not preserve order. The End Point

Manager is the service responsible for managing send and receive ports, and acts as the

intermediary between the ports and the MessageBox database.

The MSMQ adapter for BizTalk Server 2004 can use a "serial processing" feature that

preserves order for step 3, but it does not ask the MessageAgent to preserve order going

forward, so the messages may be routed out of order to an orchestration or send port.

Note

For in-order delivery to work correctly with an orchestration, the received

messages must be delivered to the same instance of the orchestration. This

means the messages that the MSMQT adapter receives will be delivered in order

to the MessageBox database, but a subscribing orchestration must be either a

singleton or using a convoy set.

If these inbound messages result in the creation of multiple instances of either an

orchestration or a send port, there will be no ordering of messages. A send port must

have the "Order Delivery" feature enabled. This feature differs in BizTalk Server versions

as follows:

In BizTalk Server 2004, the "Order Delivery" feature is available only for MSMQT

send ports.

In BizTalk Server 2006, the "Order Delivery" feature is available for all send ports.

Ordered delivery is guaranteed only if the MSMQ queues monitored by BizTalk Server

receive locations are serviced by only one computer. This can present problems for

scalability, as described in the following sections.

Transaction Usage When Processing Messages with the MSMQT Adapter vs. the MSMQ Adapter

With regard to transaction usage, there is a key difference between how the MSMQT and

MSMQ adapters process messages.

6

When using the MSMQT adapter, the processes of receiving a message from the network

and processing it with BizTalk Server are handled under a single transaction. When using

the MSMQT adapter, ACK messages generated for the sender indicate that the message

has been received and has been successfully processed by BizTalk Server.

Note

An acknowledgment (or "ACK") is a type of message sent to indicate that a block

of data arrived at its destination without error.

When using the MSMQ adapter, the processes of receiving a message from the network

and processing it with BizTalk Server are handled under two separate transactions: one

for receiving the message from the network and one for processing it with BizTalk Server.

When using the MSMQ adapter, ACK messages generated for the sender indicate only

that the message has been successfully received from the network, and not that the

message has been successfully processed by BizTalk Server.

The sender receives an ACK from the Message Queuing server when the message is

received from the network and stored in the local MSMQ queue regardless of whether

BizTalk Server is installed. After the message has been stored in the MSMQ queue, the

MSMQ adapter picks it up, processes it, and publishes it to the MessageBox database. If

this process fails, the message is either sent to the BizTalk Server Suspended queue or

left in the local MSMQ queue (when using transactional processing), and the sender has

no indication that the message failed processing in BizTalk Server.

If your architecture requires that you receive ACKs when BizTalk Server successfully

processes your messages, then you must add application-level ACKs if you are migrating

from the MSMQT adapter to the MSMQ adapter. You will need to update your

orchestration and sending application to implement application-level ACKs.

High Availability (Transactional, in Order)

To provide high availability for the MSMQT adapter, you can either add multiple

computers to the receive host and configure Network Load Balancing (NLB) for fault

tolerance or, in BizTalk Server 2006, you can cluster the default BizTalk Host.

If you are running the MSMQT adapter in conjunction with NLB, if one server goes down,

the other servers handle the load. If you are running the MSMQT adapter handlers on a

clustered host in BizTalk Server 2006, if one host node fails, cluster software fails over

the clustered host to the other node.

When using the MSMQ adapter, NLB does not work if you need transactional processing

with no data loss, because the MSMQ adapter uses local MSMQ queues for intermediate

7

storage. In this scenario, if a message has been delivered to the local MSMQ queue but

has not been consumed by the MSMQ adapter, the message is lost if the computer fails.

To provide high availability and transactional consistency with the MSMQ adapter on

BizTalk Server 2006, you should do the following:

Configure Message Queuing (MSMQ) as a clustered resource in a Windows Server®

cluster group on your BizTalk servers.

Configure the MSMQ adapter receive handler in a BizTalk Host instance that has

been configured as a cluster resource in the same cluster group as the clustered

MSMQ resource.

Configure the cluster resource for the BizTalk Host instance so that it maintains a

dependency on the clustered MSMQ resource.

Important

BizTalk Server 2004 does not provide the ability to cluster a BizTalk Host; this

functionality is available only in BizTalk Server 2006.

To implement End-to-End ordered delivery with this architecture, follow the steps

presented earlier in "End-to-End Ordered Delivery."

High Availability (Non-transactional, Not in Order)

If you need high availability but do not need transactional processing, you can achieve

this with the MSMQ adapter by implementing NLB and running instances of a host

configured with the MSMQ send and receive handlers on multiple BizTalk Servers behind

NLB.

When implementing NLB with MSMQ you should follow best practices as documented in

Microsoft Knowledge Base article 899611, "How Message Queuing can function over

Network Load Balancing (NLB)" available at http://go.microsoft.com/fwlink/?

LinkId=57510. In this scenario, if one of the BizTalk servers fails, the messages that are

running in the host instance on that BizTalk server will be unavailable until the BizTalk

server is recovered. This configuration provides high availability because if one of the

BizTalk servers is not available, NLB routes requests to the other BizTalk server.

Scalability (Non-transactional, Not in Order)

You can achieve scalability by following the guidelines for high availability (non-

transactional) and adding additional host instances. This architecture provides fast

delivery as well as scalability, but does not provide ordered delivery.

8

Scalability (Transactional, Not in Order)

For transactional delivery of messages without ordered delivery, you can combine the use

of NLB with MSMQ and Windows® Clustering. This architecture requires that you

configure at least two cluster groups on two separate Windows cluster environments

following the steps under "High Availability (Transactional, in Order)" for each Windows

cluster. You then implement NLB to distribute load between the cluster groups. Because

NLB is not supported running on a Windows cluster, this scenario requires a hardware

NLB solution.

Note

This architecture does not provide ordered delivery.

Scalability (Transactional, in Order)

Because the MSMQ API does not support remote transactional reads, scaling out an

architecture that provides high availability, transactional consistency, and ordered delivery

is problematic. To scale out, multiple local MSMQ queues must be used. If the TCP/IP

connection for the MSMQ session to NLB is broken, it may subsequently be restored by

NLB to a different computer, which can cause out-of-order delivery.

One possible workaround to this limitation is to manually load balance message delivery

by allocating destination queues to different computers. You can accomplish this by tying

specific BizTalk Host instances to specific MSMQ queues. For example, if you receive a

large number of documents from one particular trading partner, create a separate host

and receive queue on a particular BizTalk server for only that trading partner.

Architecture SummaryThe following table summarizes the architectures that you can implement with the MSMQ

adapter to accommodate specific functionality.

Functionality Neither NLB nor

cluster

NLB Cluster

(BizTalk 2006

only)

NLB and cluster

End-to-end

ordered delivery

Yes No Yes Possible with

manual

configuration

9

Functionality Neither NLB nor

cluster

NLB Cluster

(BizTalk 2006

only)

NLB and cluster

Transactional

consistency

No (messages

can be lost or

duplicated if

service failure

occurs)

No Yes Yes

Highly available No Yes Yes Yes

Scalable No Yes No Yes

Why Migrate to the MSMQT Adapter?Microsoft is deprecating MSMQT. This means that in future versions of BizTalk Server, it

is possible that MSMQT will not be available.

MSMQT is present and fully supported in BizTalk Server 2006. You may prefer to

continue to use the MSMQT adapter and avoid migrating to the MSMQ adapter.

If you are considering alternatives to the MSMQT adapter, then the MSMQ adapter may

be a great choice.

For those of you that are familiar with the MSMQ AIC for BizTalk Server 2002, the MSMQ

adapter for BizTalk Server 2004 has the same advantages and the same problems, but it

provides much richer functionality. The biggest difference is that it supports large

messages by using MQRTLarge.dll. The MSMQ Adapter for BizTalk Server 2004 has the

same limitations as MQRTLarge.dll.

The MSMQ Adapter for BizTalk Server 2004 is the recommended way to use the MSMQ

transport with BizTalk Server 2004.

Advantages of using the MSMQ adapter instead of the MSMQT adapter are as follows:

Standard Windows Message Queuing is used with all features of MSMQ 3.0.

Other applications using MSMQ will run on the same computer concurrently with

BizTalk Server.

MSMQ administration and troubleshooting tools are available.

Most operations are essentially local, and hence much faster. The adapter drops a

message to or gets a message from a local queue. For remote read the Windows

10

Message Queuing API uses remote procedure call (RPC) without all of the

complexities and delays of the MSMQ protocol. It still takes time to deliver the

message, but message delivery happens asynchronously to BizTalk Server, while the

visible processing time is comparable to a File adapter.

The adapter is compact, lightweight, and functionally rich.

Keep the following points in mind when selecting the MSMQ adapter for your project:

High availability requires a Windows NT® cluster. This means that you need BizTalk

Server 2006 to use the adapter.

Ordered delivery in BizTalk Server 2004 is not achievable with the MSMQ adapter,

and it is a standard feature in MSMQT. Ordered delivery is available in BizTalk Server

2006 with some configuration work.

Common MSMQT Problems and Solutions

Why isn't the MSMQT adapter installed by default?

By default, when a BizTalk group is configured, the MSMQT adapter is not automatically

set up. The MSMQT adapter has to be manually configured so that there are no conflicts

with the native Windows MSMQ service (if already installed and configured).

The MSMQT adapter listens on two ports: TCP port 1801 and UDP port 3527. If you do

not need to use the adapter, having these ports open can pose a security threat.

Therefore the best option is to install this adapter only when it is needed.

How do I uninstall/delete/deactivate the MSMQT adapter?

Perform the following steps to remove the MSMQT.

To remove the MSMQT adapter

1. Stop all BizTalk service instances (BTSNTSVC).

2. Open Health and Activity Tracking (HAT), and then terminate all MSMQT-related

messages and service instances.

3. In the BizTalk Management database (BizTalkMgmtDB), in the adm_adapter table,

change the "capabilities" column to "11".

4. In the BizTalk Server Administration console, delete the MSMQT adapter.

11

How can I view messages in MSMQT?

You cannot view messages in MSMQT, because MSMQT has no message store.

MSMQT queues are only logical queues—the physical storage is provided by BizTalk

Server internal queues (stored in SQL Server™). Because there is no physical

representation of the queue, it is not possible for a client to query an MSMQT queue.

Messages that MSMQT receives are written to the same tables as every other received

message. Therefore, you cannot distinguish MSMQT messages from other messages.

How can I get the retry count value or the retry interval value to work with MSMQT?

The MSMQT adapter does not support the retry count value or the retry interval value.

Although you can set these values, they are ignored. MSMQT is implemented on top of

the MSMQ protocol and the retry logic is built into the MSMQ protocol.

Can I set up MSMQT to receive messages from public queues?

MSMQT does not support receiving messages from public queues. MSMQT does support

sending to and receiving from private queues, and also supports sending messages to

remote public queues.

Does MSMQT support the HTTP protocol?

MSMQT does not support the HTTP protocol; however, the HTTP protocol is supported

by MSMQ 3.0.

If there is a requirement to use the HTTP protocol, you can send a message from

MSMQT to an MSMQ 3.0 queue, and then have the message sent from MSMQ 3.0 using

the HTTP 3.0 protocol.

MSMQT does not seem to start, and I receive the following error in the event log.

"The MSMQT subservice encountered an error executing initialization of the networking

component. The binding IP address may be invalid, or another application may be

holding the IP port."

12

This problem may occur if TCP/IP "Port 1801" is not available to the BizTalk Server 2004

host instance under which MSMQT is configured.

Messages appear to disappear when sending messages to a remote private queue.

When you use the MSMQT adapter to send a message to a remote private queue that

does not exist, and the send port has the Retry Count property set to 0 (retry count=0),

the message appears to disappear and there is no indication that anything has gone

wrong.

The Retry Count property does not apply to MSMQT. By default, a message must reach

a queue within four days (96 hours). If you do not specify a time by which your message

must reach a queue, MSMQT suspends the message and then passes the message to

the backup transport after four days.

Can I use System.Messaging on the BizTalk Server computer where MSMQT is installed?

Using System.Messaging on the BizTalk Server computer does not work. This is

because System.Messaging needs MSMQ; that is, you need to install the MSMQ client

for System.Messaging to work.

Which ports are used by MSMQT?

MSMQT only uses the following ports:

TCP 1801

UDP 3527

MSMQ uses the following ports:

TCP: 1801

RPC: 135, 2101*, 2103*, 2105*

UDP: 3527, 1801

* These port numbers may be incremented by 11 if the initial choice of RPC port is being

used when Message Queuing initializes. A connecting QM queries port 135 to discover

the 2xxx ports. For more information, see the "More Info" section of the Knowledge Base

article "TCP ports, UDP ports, and RPC ports that are used by Message Queuing"

available at http://go.microsoft.com/fwlink/?LinkId=65214.

13

Can I write programmatically to the MSMQT queue?

Yes, you can write programmatically to the MSMQT queue by using one of the following

methods:

You can install MSMQ on a remote computer, and then use the MSMQ APIs to send

messages to the BizTalk Server 2004 MSMQT receive location.

- OR -

You can create a file receive location that picks up files from a folder and an MSMQT

send port that subscribes to the file receive port by using a filter expression.

Can I send a message that is larger than 4 MB from MSMQ to MSMQT?

MSMQ by itself does not support large messages (larger than 4 MB). If you have BizTalk

Server 2004, you can use MQRTLarge.dll to send large messages from MSMQ to

MSMQT. For an SDK example that demonstrates how to use MQRTLarge.dll, see

http://go.microsoft.com/fwlink/?LinkId=65215.

Can I install MSMQT and Message Queuing side-by-side?

Yes, you can install MSMQT and Message Queuing side-by-side. This requires a special

configuration, and we highly recommend that you consider using the MSMQ adapter as

opposed to using MSMQT and MSMQ side-by-side. MSMQT is a deprecated technology

starting with BizTalk Server 2006.

However, it is possible to have both the native Windows MSMQ service and the BizTalk

Server MSMQT subservice run side-by-side. You can do this by setting up at least two IP

addresses for the same computer. Then bind the native MSMQ service to the first IP

address and bind the BizTalk Server MSMQT subservice to the second IP address. You

can then use all format names to send messages to queues on remote computers.

However, there is a limitation: It is not possible to use the DIRECT format name to send

messages to the local MSMQ queues.

If you must create such a configuration, follow the instructions in BizTalk Server 2004

Help located at http://go.microsoft.com/fwlink/?LinkId=65216.

14

What is required to set up MSMQT to use multiple computers in the same BizTalk group?

When configuring MSMQT to use multiple computers in the same BizTalk group, you

should first configure Network Load Balancing (NLB) for load-balancing MSMQT. Use the

Virtual NLB Cluster Name as the Computer Name in the Configuration Wizard on all

computers when setting up MSMQT.

For more information about Network Load Balancing, see Knowledge Base Article

323437, "How To Configure Network Load Balancing Parameters in Windows Server

2003" located at http://go.microsoft.com/fwlink/?LinkId=65217.

Can I use Network Address Translation (NAT) with MSMQT?

Network Address Translation (NAT) is primarily used to convert a public IP address into a

private IP address. NAT devices can be routers, firewalls, or proxy servers. NAT services

can be provided by software or by hardware devices. You can implement NAT in many

different configurations. Because testing and troubleshooting these many different

configurations is complex, using client NAT or server NAT together with MSMQT is not

supported.

For more information, see the article " Network Address Translation (NAT) support in

Message Queue Server 1.0, in Message Queuing 2.0, in Message Queuing 3.0, and in

BizTalk Message Queuing" available at http://go.microsoft.com/fwlink/?LinkId=65218.

Can I use hardware load balancing with MSMQT?

Using hardware load balancing with MSMQT is not officially supported. Microsoft only

supports load balancing using Network Load Balancing. Some customers have reported

that they have been able to successfully configure hardware load balancing with MSMQT.

Some customers have reported that disabling NAT (Network Address Translation) and

"Sticky IP" in their environment seem to provide a stable configuration.

Disclaimer:

The following example is provided as a basis for how you might go about setting up

MSMQT to work with a hardware load balancer. This example is for illustration purposes

only and should be used only as an example. Microsoft makes no warranties, expressed

or implied, regarding the reliability of this example.

Example:

15

Suppose that you want to configure a BizTalk Server MSMQT solution to use two BizTalk

Server 2004 SP1 servers (running Microsoft Windows Server 2003) and a hardware load

balancer from F5 Networks.

You have declared a virtual IP address (VIP) and a logical name of EBizTest.Sample.En

(EBizTest) in the DNS.

Which parameter should be used during the BizTalk Server setup to configure

MSMQT—the VIP if you want to use it or the logical name?

You need to configure the following properties during setup:

In the address field, enter the physical IP address.

In the computer name field, enter the virtual name.

Which form is more appropriate: DIRECT=OS or DIRECT=TCP ?

Both forms are supported.

Do you have to use the BizTalk group name in the address of send ports (for

example, DIRECT=OS:<BizTalk Group>\private$\<queueName>)?

If you want to send messages to BizTalk Server on NLB, use:

DIRECT=OS:NLBVirtualName\private$\<queueName>

If you use the MSMQT adapter to send messages out, use:

DIRECT=OS:DestinationComputerName\private$\<queueName>

How can this name be changed during the BizTalk Server installation?

For BizTalk Server 2004, MSMQT adapter reconfiguration is not supported.

MSMQT messages are not flowing.

Here are a few symptoms of this problem:

MSMQT messages appear in the HAT "Queries-Messages Sent in Past Day" report,

but they do not actually arrive in the destination queue.

The HAT "Operations-Messages" view seems to display strange behavior, but

nothing that indicates an error condition. Retry count will increment on the original

service instance.

No error condition is reported in the event log. OK, Premier Support indicates in a

phone conversation you might see something after 5 days have elapsed, when an

exponential backoff algorithm has run its course.

16

To troubleshoot this issue, try the following:

Verify that none of your send ports have the Use MSMQ Authentication check box

selected. This option should be used only if MSMQT is installed in Active Directory

integrated mode.

Double-check any binding files that might be used to set up MSMQT send ports, or

any scripting code that you use to set up such ports.

Note

There are similar options for receive ports that also should be checked.

Performance issues with MSMQT

MSMQT is by design transactional and guarantees in-order delivery. This design

inherently has some side effects, which are discussed in the following paragraphs.

Impact on throughput

To guarantee in-order delivery, only one thread can service a specific receive location

(input queue). This is necessary to avoid receiving multiple messages arriving

concurrently at the same receive location. Using only a single thread for a single receive

location limits the amount of data that can flow through the system. This is because the

same blocking thread has to serially service all incoming requests to its input queue.

One workaround to this problem is to architect a scenario in which multiple receive

locations (input queues) are created and data is routed to these multiple input queues

such that the system can concurrently receive input documents, thereby improving

system throughput. If this workaround is not an option and if in-order delivery is not a

requirement, the other solution is to create a custom multithreaded adapter for the

MSMQT transport that can receive messages concurrently on multiple threads for the

same receive location. The BizTalk Adapter Framework can be used to create such a

custom MSMQ adapter.

Impact on scalability

By design, to scale out the receiving tier it is recommended to add multiple host instances

(BizTalk Server service processes) to a particular host (logical container) and to then map

this host to the handler (for example, receive handler) for a particular adapter (for

example, the MSMQT adapter). Thus, it is possible to scale out and improve throughput

by having multiple servers concurrently share the workload of servicing the same receive

location. Further, specific to the MSMQT adapter, it is necessary to set up the

infrastructure such that clients (outgoing queues) can send messages to a single virtual

17

receiving queue. This can be accomplished by using the NLB approach outlined in the

previous section.

Due to the in-order delivery design of the MSMQT adapter, it is not possible to have more

than one BizTalk server service a single receive location. Even if a host is mapped to a

receive handler and multiple host instances are added to this host, only one host instance

can service the single receive location. Thus, the other host instances (BizTalk Server

service processes) are unable to share the workload. The way around this is to have

multiple receive locations, and have multiple BizTalk servers servicing those receive

locations.

Non-deterministic design

Multiple receive locations (input queues) and multiple host instances (BizTalk Server

service processes) can be set up so that the system can handle concurrent load and

provide improved throughput. However, based on the scalability design in the preceding

paragraphs, BizTalk Server automatically sets affinity in a non-deterministic manner to a

particular receive location. For example, if a host instance servicing a particular receive

location fails, another host instance takes over the responsibility of servicing the receive

location. After this happens, the new host instance has affinity to the receive location and

the original host instance (which relinquished affinity to the receive location) is unable to

reacquire affinity to the receive location.

Impact on high availability

Even if multiple receive locations are created so that multiple BizTalk servers can share

the workload, one and only one BizTalk server can service a single receive location at

any given time. After a BizTalk server services a particular receive location, that server

will continue to service the receive location for the lifetime of that BizTalk Server service

process. However, this design (only one server having affinity to a particular receive

location) does not impact high availability. If this host instance (servicing a particular

receive location) is unavailable either due to hardware/software failure or for

maintenance, the other host instances (not servicing this receive location) will detect that

this receive location (input queue) is not being serviced and will take over servicing this

receive location. This process is seamless and should happen within 60 seconds. After

this happens, this new host instance locks the receive location and will continue to have

affinity to this receive location for the lifetime of this BizTalk Server service process.

Note that NLB does not help improve throughput by balancing the load; it does, however,

provide availability. The passive server takes precedence for receiving incoming

messages after the BizTalk Server service on the active server is stopped. If multiple

queues are used the load is indeed balanced. Thus by design only one BizTalk server

can provide service to one receiving queue and only one BizTalk server can provide

service to one sending queue.

18

Static MSMQT host

Unlike other native transport adapters it is not possible to change the receive and send

handlers (default: BizTalkServerApplication) for the MSMQT adapter. Thus all

functionality (receive/send) runs on one host. Adding multiple servers to this host does

provide failover and high availability. However, it is not possible to split functionality

across isolated computers dedicated for receiving or transmitting. Due to this design it is

not possible to set up the receiving host and transmitting host to run under different user

credentials. Because MSMQT exclusively needs the well-known port, there cannot be

more than one host with MSMQT (otherwise more than one instance with MSMQT might

come to the single server).

Troubleshooting TipsThe following tips may help you to get more information about errors:

Install the BizTalk Adapter Trace utility, available at http://go.microsoft.com/fwlink/?

LinkId=65220.

This utility enables you to capture the details of what BizTalk Server code is doing

when a problem occurs. The format of the file is binary and the file must be sent to

Microsoft for review.

Can the problem be reproduced by taking BizTalk Server out of the equation? If so,

this is a general MSMQ problem, and not specific to BizTalk Server.

For information about using MSMQ tracing, see the article "Tracing Messages"

available at http://go.microsoft.com/fwlink/?LinkId=65222.

Recommended Hotfixes and Service Packs for MSMQTThe following fixes and service packs are highly recommended if you are using MSMQT:

BizTalk Server 2004 Service Pack 1, available at http://go.microsoft.com/fwlink/?

LinkId=65223.

Knowledge Base Article 890530 - FIX: You receive a "The root element is missing"

error message when you try to process a message by using a Message Queuing

transport adapter send port in BizTalk Server 2004, available at

http://go.microsoft.com/fwlink/?LinkId=65225.

19

Knowledge Base Article 914018 - FIX: A memory leak may occur in the BizTalk

service when a receive location uses the MSMQT adapter in BizTalk Server 2004,

available at http://go.microsoft.com/fwlink/?LinkId=65226.

Knowledge Base Article 829977 - A memory leak condition occurs when you run

COM+ 1.0 on a computer that is running Windows 2000 SP4, available at

http://go.microsoft.com/fwlink/?LinkId=65227.

Knowledge Base Article 329492 - A cluster node with two network cards does not

receive messages, available at http://go.microsoft.com/fwlink/?LinkId=65228.

Knowledge Base Article 898618 - FIX: Transactional messages that are addressed to

a nonexistent queue remain in the outgoing queue in Message Queuing 3.0,

available at http://go.microsoft.com/fwlink/?LinkId=65229.

Resourceshttp://blogs.msdn.com/eldarm

Messaging Engine Overview

CopyrightThe information contained in this document represents the current view of Microsoft

Corporation on the issues discussed as of the date of publication. Because Microsoft

must respond to changing market conditions, it should not be interpreted to be a

commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any

information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO

WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN

THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without

limiting the rights under copyright, no part of this document may be reproduced, stored in

or introduced into a retrieval system, or transmitted in any form or by any means

(electronic, mechanical, photocopying, recording, or otherwise), or for any purpose,

without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other

intellectual property rights covering subject matter in this document. Except as expressly

provided in any written license agreement from Microsoft, the furnishing of this document

20

does not give you any license to these patents, trademarks, copyrights, or other

intellectual property.

© 2006 Microsoft Corporation. All rights reserved.

Microsoft, MS-DOS, Windows, Windows Server, Windows Vista, Active Directory, BizTalk,

and Windows NT are either registered trademarks or trademarks of Microsoft Corporation

in the United States and/or other countries.

All other trademarks are property of their respective owners.

21