A lot has been said regarding the MSMQT adapter for BizTalk 2004 already, but below are a few recent observations that may be of help to you. 

When people ask me what MSMQT is, my short answer goes something like this: "MSMQT is the name of the BizTalk 2004 adapter that implements the MSMQ network protocol directly within BizTalk.  It allows BizTalk 2004 to send/receive MSMQ messages directly, and move messages to/from the MessageBox very quickly - without external (DTC) transaction coordination.  Only private queues are supported for receives."

Using the MSMQT adapter you can:

• Use Send Ports to send to public or private queues on remote machines - but the queues must be transactional.
• Use Send Ports to send to local queues, which will be private since that is all MSMQT supports.
• Use Receive Locations to receive from locally defined queues, which will be private since that is all MSMQT supports.  These queues can be either transactional or non-transactional.  You cannot monitor remote queues (i.e. receive locations can't reference remote queues.)

You cannot using the System.Messaging MSMQ APIs/COM MSMQ APIs/MSMQ C Libraries or the MSMQ MMC console on a BizTalk 2004 machine that is running the MSMQT adapter!  This is because these all rely on the native MSMQ Service running.

You can use the aforementioned APIs (though not the MMC console) from remote machines (that are not running the MSMQT adapter) to put messages in MSMQT-defined queues.

To test MSMQT queues on the BizTalk 2004 server where they are defined, you can:

1. Create a Receive Port and a File Receive Location that will monitor a particular directory...
2. Create a static one-way Send Port that specifies MSMQT & the queue you want to test as the destination.  In the "Filters" portion of the Send Port configuration, define BTS.ReceivePortName = ReceivePortNameFromStep1

Now, when we you drop a file on your directory, it will be routed to your queue.  The receive location could also use HTTP posts, in which case the WFETCH tool from the IIS Resource Kit (or a similar tool) will let you easily get test messages to the queue.

Note: If you have existing applications that used to send to public MSMQ queues, but will now be sending to MSMQT queues, the most common problem is that they are referencing those queues via the PathName property, rather than the FormatName property (with 'DIRECT=OS:machine\private$\qname' syntax.)  This is only a problem for users of the COM/C-Library APIs - the System.Messaging.MessageQueue class actually allows format names to be used with the Path property.

See this Microsoft Support discussion for lots of additional insight into MSMQT.