Simple answer - you don't.

Outgoing queues are dynamically created by the MSMQ queue manager when your application is sending messages. This is MSMQ's built-in store-and-forward mechanism in operation. The messages are stored in the local outgoing queue and then forwarded to the destination queue when the remote MSMQ machine is available. You won't see an outgoing queue when sending to a queue on the same machine - MSMQ just cheats and writes the message straight to the destination.

Normally outgoing queues don't hang around for long - once the message has been delivered and processed at the destination then it has served its purpose. As the cost of creating a network connection is high (in computing terms), MSMQ keeps the queue alive (even if it is empty) for a few minutes just in case you are going to send another message. This saves the queue manager the effort of making the network connection again. This cleanup delay is controlled by the CleanupInterval registry value - 5 minutes for clients and 2 minutes for servers.

You may see outgoing queues remain for a lot longer if you are using transactional messages. This is because a copy of the message is hidden in the queue waiting for the transaction to commit or abort. During this time, the copy can be resent as part of the retry mechanism. Should the transaction abort then the message will be moved to the transactional dead letter queue.

Looking at the underlying mechanism:

  1. An application wants to send a transactional message to a remote queue.
  2. This message is first put into an outgoing queue
  3. The queue manager connects to the remote machine
  4. A copy of the message is sent to the remote machine
  5. The remote machine responds with an acknowledgement to confirm the message reached the queue safely
  6. The original message is now hidden as MSMQ knows it has been delivered - the message can only be visible in one place at a time
  7. The remote machine later sends a final acknowledgement confirming that the message has been successfully processed by an application
  8. The original message can be deleted as the transaction has committed.

Here is Computer Management during step 6:

The outgoing queue above contains no visible messages but the columns below show 10 messages unprocessed:

Additionally, performance monitor shows 10 real messages still taking up space:

 Here is the outgoing queue on the destination sending acknowledgements back to the original machine:

Note - all this only happens when you send messages with dead lettering (or negative source journaling) enabled. If you don't request this then MSMQ won't bother to keep copies of the messages after delivery - there would be no point as they would never be moved to the transactional dead letter queue.

The use of negative source journaling is a best practice - properly implemented, it takes away some of the mystery when things go wrong and messages seem to get lost.