Direct Format Names

Applies To: Windows 10, Windows 7, Windows 8, Windows 8.1, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server Technical Preview, Windows Vista

Direct format names are used to reference public or private queues without accessing the directory service. Direct format names are used when performing the following operations:

• Sending messages directly to a computer.

• Sending messages to computers over the Internet.

• Sending messages across forest boundaries.

• Sending messages to any queue while operating in domain, workgroup, or offline mode.

• Reading messages while operating in domain, workgroup, or offline mode.

Direct format names should be used to send messages whenever routing, authentication, and encryption by Message Queuing are not needed.

When Message Queuing detects a direct format name for a remote public queue or for a local or remote private queue, it does not contact the directory service. Message Queuing uses the information provided by the format name to send messages directly to their destination.

Direct Format Name Syntax

Direct format names specify the location of the queue and the name of the queue.

The following is the general form of direct format names.

DIRECT=AddressSpecification\QueueName  (For public queues)  
DIRECT=AddressSpecification\PRIVATE$\QueueName  (For private queues)  
DIRECT=AddressSpecification\QueueName;JOURNAL  (For public queue journals)  
DIRECT=AddressSpecification\PRIVATE$\QueueName;JOURNAL  (For private queue journals)  
DIRECT=AddressSpecification\SYSTEM$;computersystemqueue  (Introduced in MSMQ 2.0 for the computer journal and dead-letter queues.)  
DIRECT=URLAddressSpecification/QueueName  (Introduced in MSMQ 3.0)  

The maximum length allowed for the computer name in the address specification is 256 Unicode characters. Also, queue names longer than 124 Unicode characters are not supported. Using names longer than 64 Unicode characters for public queue names may cause a slight reduction in performance. Furthermore, they are not easily displayed in the directory service.

For public queues  
LPWSTR wsz = L"DIRECT=IPX: 00000012:00a0234f7500\MyQueue";  // Supported only on Windows NT 4.0 and Windows 2000  
LPWSTR wsz = L"DIRECT=TCP:157.18.3.1\MyQueue";  
LPWSTR wsz = L"DIRECT=OS:Mike01.msn.com\MyQueue";  
LPWSTR wsz = L"DIRECT=OS:Mike01\MyQueue";  
LPWSTR wsz = L"DIRECT=OS:.\MyQueue";  

For private queues  
LPWSTR wsz = L"DIRECT=IPX: 00000012:00a0234f7500\PRIVATE$\MyQueue";  // Supported only on Windows NT 4.0 and Windows 2000  
LPWSTR wsz = L"DIRECT=TCP:157.18.3.1\PRIVATE$\MyQueue";  
LPWSTR wsz = L"DIRECT=OS:Mike01.msn.com\PRIVATE$\MyQueue";  
LPWSTR wsz = L"DIRECT=OS:Mike02\PRIVATE$\MyQueue";  
LPWSTR wsz = L"DIRECT=OS:.\PRIVATE$\MyQueue";  

For public queue journals  
LPWSTR wsz = L"DIRECT=IPX: 00000012:00a0234f7500\MyQueue;JOURNAL";  // Supported only on Windows NT 4.0 and Windows 2000  
LPWSTR wsz = L"DIRECT=TCP:157.18.3.1\MyQueue;JOURNAL";  
LPWSTR wsz = L"DIRECT=OS:Mike01.msn.com\MyQueue;JOURNAL";  
LPWSTR wsz = L"DIRECT=OS:Mike01\MyQueue;JOURNAL";  
LPWSTR wsz = L"DIRECT=OS:.\MyQueue;JOURNAL";  

For private queue journals  
LPWSTR wsz = L"DIRECT=IPX: 00000012:00a0234f7500\PRIVATE$\MyQueue;JOURNAL";  // Supported only on Windows NT 4.0 and Windows 2000  
LPWSTR wsz = L"DIRECT=TCP:157.18.3.1\PRIVATE$\MyQueue;JOURNAL";  
LPWSTR wsz = L"DIRECT=OS:Mike01.msn.com\PRIVATE$\MyQueue;JOURNAL";  
LPWSTR wsz = L"DIRECT=OS:Mike01\PRIVATE$\MyPrivateQueue;JOURNAL";  
LPWSTR wsz = L"DIRECT=OS:.\PRIVATE$\MyPrivateQueue;JOURNAL";  

For the computer journal and dead-letter queues (Introduced in MSMQ 2.0)  
LPWSTR wsz = L"DIRECT=OS:Mike01\SYSTEM$;JOURNAL";  
LPWSTR wsz = L"DIRECT=OS:Mike01\SYSTEM$;DEADLETTER";  
LPWSTR wsz = L"DIRECT=OS:Mike01\SYSTEM$;DEADXACT";  

For URL-named queues (Introduced in MSMQ 3.0)  
DIRECT=HTTP://157.18.3.1/msmq/MyQueue                 // Single computer or cluster  
DIRECT=HTTP://Mike01/msmq/MyQueue                     // Within the enterprise  
DIRECT=HTTPS://Mike01/msmq/MyQueue                    // Within the enterprise  
DIRECT=HTTP://www.northwindtraders.com/msmq/MyQueue   // Over the Internet  
DIRECT=HTTPS://www.northwindtraders.com/msmq/MyQueue  // Over the Internet  

Address specification

The address specification of the computer can be specified in three forms:

• As the network protocol followed by the network address of the target computer. Message Queuing supports TCP and, only on Windows NT® 4.0 and Windows 2000, SPX.

• As any string that is supported natively by the underlying operating system to identify the target computer (OS is used as the protocol to indicate that the computer's native protocol should be used to interpret computer names).

• As the Internet transport protocol (HTTP or HTTPS) followed by the IP address or full DNS name of the host computer (or the computer name within an enterprise) and then by the virtual directory name separated by slashes (introduced in MSMQ 3.0). The default virtual directory name is msmq, but Message Queuing can be configured by IIS to use a different virtual directory.

Security Limitations

Opening a remote queue for sending messages with a direct format name signals Message Queuing not to query the directory service when it opens the queue. This enables Message Queuing to send messages in workgroup and offline mode and to transmit messages across forest boundaries, but it eliminates the possibility of using some of the security functionality provided by Message Queuing for access control, authentication, and encryption. When security services performed by Message Queuing are unavailable, it is the responsibility of your application to implement the missing functionality.

Authentication

Message Queuing authentication refers to two operations:

• Verifying that no tampering occurred while the message was in transit from the sender to the receiver.

• Verifying the sender's identity by comparing the SID of the user who registered the certificate attached to the message with the sender identifier (the sender's SID) attached to the message.

Message Queuing can perform the first task for messages sent with direct format names, even when the default internal certificate is used, by generating a digital signature of the message on the sender side and verifying the digital signature on the receiver side before placing the message in the destination queue. However, if the receiver needs to authenticate the sender's identity in situations where the sender's SID is meaningless, the sender must use an external certificate issued by a Certification Authority that is trusted by both the sender and the receiver. In this case, the destination queue manager verifies that the message content was not changed, but does not attempt to verify the sender's identity, and only the receiving application can analyze the certificate attached to the message and decide whether to trust the sender. When using a direct format name to send messages across trust boundaries (for example, across untrusted domains), set the PROPID_M_SENDERID_TYPE property of the message to MQMSG_SENDERID_TYPE_NONE, because the SID is meaningless when crossing trust boundaries. For more information on how Message Queuing authenticates messages, see Message Authentication.

Encryption

Message Queuing cannot encrypt messages sent with a direct format name. If Message Queuing is in domain mode on the receiving computer, then you can encrypt messages in your application and the destination Queue Manager will decrypt the messages. For more information, see the sample "DirEncrypt" at Message Queuing Sample Applications. For more information on sending encrypted messages, see Message Encryption.