Nine times out of ten this will not be the correct question. Whoever is asking REALLY means “How do I send MSMQ messages between forests?”
MSMQ will happily send messages between domains in the same forest. All you need is a Global Catalogue (GC) in every domain and the whole forest is enabled for enterprise-wide message transfer. The GC will be able to:
- authenticate users from domains different to that of the receiving machine
- resolve queue information for queues on machines in different domains
Remember the GC is a single point of failure in a domain so make global catalogues of multiple DCs just to be on the safe side. To see what MSMQ attributes are stored on a GC, look here:
Sending messages between domains in different forests, though, is a completely different situation. Even though you set up as many trusts as you like, the sender has no access to the remote forest’s Active Directory so is unable to perform any kind of lookup or object querying.
From Cross-Enterprise Support:
- Queues in the other enterprise can be referenced only by using direct format names. For example, when opening a queue you must specify the queue using a direct format name.
- You cannot make any function or method call that requires access to the directory service on the other enterprise. You can access the directory service only on your own enterprise.
- When requesting message authentication, you must provide an external certificate. Internal certificates cannot be used.
- To send encrypted messages, your application must obtain the public key of the receiving computer and encrypt the message itself. (The destination queue manager will still decrypt the message for you.)
- When you send messages within a transaction, the IP address of the sending computer must remain constant. Message Queuing uses the IP address to return a confirmation notice when the message has been retrieved from the target queue.
There can also be a problem receiving messages from a remote forest but that is for a different reason – the tightening up of MSMQ’s use of RPC as documented in the Message Queuing security overview. The “Secured remote read” feature will need to be tweaked if you plan to work across forest boundaries – even if you don’t, this problem can appear in development where the test machines are in different forests to the production servers. As the overview article says:
Message Queuing 3.0 cross-forest clients on Windows Server 2003 family computers in non-trusted domains will use the secure remote read interface. By default, the Message Queuing 3.0 server requires domain clients to establish an encrypted channel, and such a channel cannot be established between non-trusted domains. Thus remote read requests from such clients will be rejected. To modify this default behavior and allow the Message Queuing server to accept domain clients that do not establish an encrypted channel, create a DWORD value SecurityNewRemoteReadServerAllowNoneSecurityClient in the registry and set it to 1.