Cant send to MSMQ with 2 DNS names

Question

We're Having an issue with sending an MSMQ message to the second DNS name on a server. If we send the IP for that same server, we're fine, but thats not where we are going architecturally. Any ideas as to why MSMQ would care about which name it receives?

Server Information:

The physical server load-int-01, has a second IP and DNS name associated with it.

• First IP/DNS: load-int-01, with IP 10.0.10.10
• Second IP/DNS: load-intv, with IP 10.0.10.20

Queue Path Formats Used:

• FormatName:DIRECT=OS:load-int-01\private$\MyQueue → Works Fine
• FormatName:DIRECT=OS:load-intv\private$\MyQueue → Returns the error…

  The queue does not exist or you do not have sufficient permissions to perform this operation

We have also tried using the IP addresses instead, and both sets of IPs work fine.

• FormatName:DIRECT=TCP:10.0.10.10\private$\MyQueue → Works Fine
• FormatName:DIRECT=TCP:10.0.10.20\private$\MyQueue → Works Fine

Partisan

Are you using transactional queues? – Strategy

Nope, but we set up a test app and tried both transactional and non-transactional. Same results. Currently by combining the IgnoreOSNameValidation (from your answer below) registry setting with another that sets up aliasing (the Optional Names key in HKEY_Local_Machine\System\CurrentControlSet\Services\LanmanServer\Parameters), we can SEND to these queues with our naming convention, but we cannot RECEIVE on them. Without these two reg settings we cant even send. – Partisan

Answer 1

We just got off the phone with Microsoft. This is a limitation of MSMQ. You can not receive on queues with a DNS name different than the server NETBIOS name. You can SEND to queues with an alternate DNS name provided you use the two registry keys mentioned above, OptionalNames and IgnoreOSNameValidation.

Back to virtual ip's for us, or we might keep the virtual name for the sending connection strings (with the reg settings) and use .\ for the receiving servername...that works.

Thanks for the help.

Partisan

Answer 2

From:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;899611

By default, Message Queuing verifies the message that it receives to determine whether the message is intended for the local computer. If the message is not intended for the local computer, the message is rejected.

So follow the section on "IgnoreOSNameValidation" in this article and I hope it will help.

Strategy

good find. We recently tried that already however. :( This one really stinks. – Partisan

New link to the KB article: learn.microsoft.com/en-us/previous-versions/troubleshoot/msmq/… – Nestling

Answer 3

Very frustrating. I'm trying to migrate some MSMQ targets (web services) and I guess I will have to configure them to use virtual IPs, and migrate the virtual IPs, since migrating the NetBIOS name will be a mission.

MSMQ should be re-christened MSMQ-1982, since it appears to predate the invention of a cunning and useful abstraction layer called "DNS" in 1983.

Tahr

Answer 4

I had the same issue and got it working. The trick for me was after setting the IgnoreOSNameValidation registry key, you have to restart the Message Queuing service.

I know this is an old post, but it comes up in Google when searching for a solution to this issue.

Jarid

Answer 5

This did work for me:

FormatName:DIRECT=TCP:HOST.TLD\PRIVATE$\MyQueue 

Note that uses TCP instead of OS. This is the relevant documentation:

Non-transactional messaging by using Direct=TCP This configuration

functions without any particular configuration changes.

Bleeding