MSMQ Messages does not arrive in the destination queue

[jacobe]

Hi,
I have a problem when I send messages to a queue on a Windows Server 2008
server: They apparantly get sent - but I cannot find them afterwards in the
receiving queue...

Using the End-To-End monitoring option in the MSMQ application event log, I
have confirmed that the messages actually arrive on the server, but they
never show up in the queue.

All firewalls are turned off, and it doesn't matter if the queue is public
or private, transactional or not. When trying to send to a queue on my local
machine everything works just fine.

My team have used almost one whole day trying to find out what's wrong -
also on the Internet, but I cannot find any clue...

Jacob

[John Breakwell (MSFT)]

Hi Jacob,

First I must admit to not actually having yet used the end-to-end tracing
(http://technet2.microsoft.com/windowsserver2008/en/library/8d32ce1e-b156-4dc0-9367-c42b5eebaa1e1033.mspx?mfr=true).
My understanding is that E2E tracing monitors the reliability options
already enabled in the messages.
Enabling E2E in Computer Management doesn't then set these options within
the messages.
So if you don't create a message with Negative Source Journaling, for
example, then E2E tracing can't tell what happens to it when lost as there
is no NACK returned from the destination.
Therefore I can understand the lack of evidence you are seeing.
Can you please confirm what options you set on the message when you create
it?

Cheers
Joihn Breakwell (MSFT)

"jacobe" <jac...@discussions.microsoft.com> wrote in message
news:F25FEECC-BE89-48DD...@microsoft.com...

[jacobe]

It is correct that the E2E tracing does not give any detailed information
what is going on inside MSMQ, but at least I get messages like "Message
received" and "Message came over network"...

After some time (half an hour to an hour) i also get messages like "Message
with ID
CN=msmq,CN=SERVERNAME,OU=Virtual,OU=Servers,OU=City,DC=domainname,DC=local\6147
was put into queue PRIVATE=28f902fd-560d-477d-939a-954588b27011\00000002" - I
don't really understand this and the queue is still empty.

I do not set any tracing options or other special options on the messages I
create. Is there any common reason why messages disappear like that?

Thanks,
Jacob

[John Breakwell (MSFT)]

Hi Jacob,

You can decode PRIVATE=28f902fd-560d-477d-939a-954588b27011\00000002 as
follows:

28f902fd-560d-477d-939a-954588b27011 is the queue manager ID which should
match the registry value
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters\MachineCache\QMId.

00000002 is the local private admin queue.
If you look in the c:\windows\system32\msmq\storage\LQS directory, you will
find a file like 00000002.990736e8.
You can open this in Notepad and it should say
"QueueName=\private$\admin_queue$".

This sounds like an internal MSMQ acknowledgement being delivered for some
reason.
You won't see this message as the queues are not visible to you.

"Is there any common reason why messages disappear like that?"

Messages can be discarded for a number of reasons, such as:

1 Queue is transactional but message is not, and vice versa.
2 Queue requires encryption but message isn't encrypted
3 Queue requires authentication but message isn't authenticated
4 Etc

With negative source journaling enabled on the message, you could check what
happened.
The message would end up in the sender's dead letter queue with a class that
identified the problem.

Cheers
John Breakwell (MSFT)

"jacobe" <jac...@discussions.microsoft.com> wrote in message

news:E1B57C2F-64D9-493F...@microsoft.com...

[Frank Boyne]

"John Breakwell (MSFT)" <Green...@msn.com> wrote in message
news:345E1BDF-0090-41AD...@microsoft.com...

> With negative source journaling enabled on the message, you could
> check what happened.
> The message would end up in the sender's dead letter queue with a
> class that identified the problem.

Just to second John's suggestion, this is usually the quickest way to
figure out why a message isn't being delivered to a queue.

To use negative source jjournalling, do one of the following based on
the API you are using

C/C++ API: set PROPID_M_JOURNAL to MQMSG_DEADLETTER on the message
before you send it

COM API: set MSMQMessage.Journal to MQMSG_DEADLETTER on the message
before you send it

System.Messaging API: set System.Messaging.message.UseDeadletterQueue to
true on the message before you send it

To diagnose your problem run the Computer management snapin (from
administrative tools), expand Services and Applications, then expand
Message Queuing and finally expand System Queues. Select Dead-letter
messages (or Transactional dead-letter messages) to view all the
messages in the dead letter queue. Double click on a particular message
to view details. On the general tab of a particular message's details
the Class property should be shown as a text string explaining why the
message was diverted to the DLQ.