MSMQ on Windows 2008 Discards Messages

Posted on 2009-12-16
Last Modified: 2013-11-29
Our message queuing software utilizes MSMQ private queues.  It has always worked fine on Windows 2003 Server.  On Windows 2008 Server, however, messages originating across the network do not populate the private queue.  Messages originating from the same server as the destination server arrive in the private queue.  I have the "server" software down so I can see if messages stack up in the queue.  With End2End logging enabled, I can see "Message came over network" when I send to the private queue from a network client.  The message never shows up in "Queue Messages" list in Computer Management, however.  I've noticed that the End2End log entry for the messages that don't work have empty EventData fields.  The locally sent and received messages cause EventData to be populated in the End2End log entry.

Either the message isn't being directed to the private queue or some other piece of software is consuming the message.  Anyone have any troubleshooting ideas?  Thanks.
Question by:tpk193
    LVL 41

    Expert Comment


    Author Comment

    The message queuing application software consists of a client program and a server program.  The client program may run on the same machine as the server program or the client program may run on other machines on the network.  A locally injected client message is accurately consumed by the server program.  There are no firewalls between the networked client machines and the server 2008 machine.  The Windows Firewall service is actually disabled on the Windows Server 2008 machine.
    To confirm that MSMQ will negotiate transferring a message between the client and server machine, I have stopped the server program and the Message Queuing service on the Windows 2008 Server.  When I run the client program from a remote machine, I can see the message in the "Outgoing Queues" with Name "DIRECT=OS:mailin1\PRIVATE$\cgsmqrequest".  When I start the Message Queuing service on the Windows Server 2008 machine, the message disappears from the client machine.  However, even thought the server program is not running, the message is not viewable in the private queue.  There is an entry in the End2End MSMQ log stating "Message came over network",  
    Why isn't Message Queuing on Windows Server 2008 compatible with Message Queuing on Windows 2000, Windows XP, and Windows Server 2003?  What needs to be changed?  Thanks.
    LVL 1

    Expert Comment

    It took me weeks to find the solution. Because there is no monitoring tool to trace the massage.
    Finally I sent every message three times in one: DIRECT=OS:\machinename\private$\test
    Message came over network and disappears.
    DIRECT=HTTP:// nothing happend, because the sending application didn't support this.\private$\test and the massage was received and processed.

    I have a firewall between both servers and opened port 1801, 2101, 2103, 2105, 2107 and UPD 3527 for the ping.
    The ping is discarded by W2K8, because it's not longer necessary. To  enable it again add the follwing registry key (but make sure, you have backup of your registry!):
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters\Security\EnablePingService and set to a value of 1.

    Unfortunately using the DIRECT:OS format name in addition to the pinging of the sending server forces the receiving server to open an OUTGOING queue with the same name. That's were your message disappears. It's send to its message to its own queue.

    Hust use the DIRECT=TCP... it worked in my case.


    Author Comment

    So far I've only had a chance to confirm the code is using "DIRECT=OS".  I need to read up on what needs to be changed to use "DIRECT=TCP", then change the code and perform a test.  I'll re-post what transpires.  Thanks.

    Author Comment

    I changed the client program to use "DIRECT=TCP".  Here is the sequence of events for the test I ran.
    1) Shutdown the server program on the Windows 2008 server
    2) Stopped the "Message Queuing" service on the Windows 2008 Server
    3) Ran the new client program on another machine with a destination of the Windows 2008 server, which placed a message in the client machine's Outgoing queue.
    4)  Confirmed the message in the client machine's Outgoing queue was in "\PRIVATE$\QueueName" format.
    5) Started "Message Queuing" service on the Windows 2008 Server
    6) Looked for the message on the Windows 2008 Server but it wasn't there
    7) Confirmed the message was detected by the Windows 2008 server by checking the End2End log for MSMQ.  It states "Message came over network".
    8) Confirmed new client program can still successfully send messages to server program running on NON-Windows 2008 Server.

    Based on my original tests and today's tests "Message Queuing" on Windows 2008 Server is broken.  Both styles ("DIRECT=OS" and "DIRECT=TCP") remotely originated messages are detected by Windows 2008 Server, but never placed in the private queue.  MSMQ is supposed to be guaranteed delivery.  Why are the messages being discarded?
    When I started this thread back on 12/16/09, I only had the 64-bit version of Windows 2008 Server to test with.  Today, I also tested against the 32-bit version of Windows 2008 Server.  The same problem exists with both versions.    Does anyone have MSMQ working on Windows 2008 Server?
    LVL 1

    Expert Comment

    The messages are not discarted. If the W2K8 opens an outgoing queue on the private queue to that one you want deliver the message, the message is sent FROM the W2K8 to somewhere else.
    It's not stored in the private queue.
    You can check that when you send a message to the private queue. If the server which should receive the massage, opens an outgoing queue to itself, so to its private queue, the message is not stored, but sent to Nirwana.

    Author Comment

    By my tests and your description, MSMQ is broken in W2K8.  If I can't send a message from a remote client program to the private queue on a W2K8 machine and see the message in the private queue then Microsoft changed the behavior in W2K8.  Anyone know where the documentation is stating what changed and how to code and implement a pair of client/server programs to process messages with guaranteed delivery?  The pair of client/server programs I wrote have been working fine for years on OSs prior to Windows 2008.  If I shut down the server program on a non-W2K8 machine, I can send  messages to the private queue from remote machines and see them in the private queue on the local server.  When I launch the server program, the messages are processed.  The messages associate with this pair of programs survive reboots of the server machine.  The messages either wait in the remote client queue until the server comes back up or in the server queue until the server program is initiated.  

    Accepted Solution

    I found a thread elsewhere on the Internet started 5/7/2008 ( which describes the same problem I have.  Even though the thread doesn't show a resolution, there was enough information to point me in the right direction to solve the problem I was having.  The suggestion was made to do "negative source journaling" by setting System.Message.message.UseDeadLetterQueue to true on the message.  It says the message will end up in the sender's Dead Letter Queue, but in my case, the message ended up in the receiver's (Windows 2008) Dead Letter Queue.  As stated, the Class column indicated the problem, which in my case was "Access is denied".  So Microsoft changed the permissions on private queues in Windows 2008.  On the Security tab of private queues, the 'Everyone' entity doesn't have the Send Message permission by default.  My client/server application has its own security mechanism, so the resolution to my problem was to grant the Send Message permission to Everyone on the Windows 2008 servers.

    Featured Post

    Enabling OSINT in Activity Based Intelligence

    Activity based intelligence (ABI) requires access to all available sources of data. Recorded Future allows analysts to observe structured data on the open, deep, and dark web.

    Join & Write a Comment

    Storage devices are generally used to save the data or sometime transfer the data from one computer system to another system. However, sometimes user accidentally erased their important data from the Storage devices. Users have to know how data reco…
    Recently Microsoft released a brand new function called CONCAT. It's supposed to replace its predecessor CONCATENATE. But how does it work? And what's new? In this article, we take a closer look at all of this - we even included an exercise file for…
    Windows 8 comes with a dramatically different user interface known as Metro. Notably missing from the new interface is a Start button and Start Menu. Many users do not like it, much preferring the interface of earlier versions — Windows 7, Windows X…
    With the advent of Windows 10, Microsoft is pushing a Get Windows 10 icon into the notification area (system tray) of qualifying computers. There are many reasons for wanting to remove this icon. This two-part Experts Exchange video Micro Tutorial s…

    733 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    21 Experts available now in Live!

    Get 1:1 Help Now