MSMQ Diagnostics "Send test messages" and "Tracking" are greyed out

So you want to test out the routing of MSMQ messages through your enterprise?

Sounds simple enough - go to the Properties of the machine to be tested and choose the Diagnostics tab.

Strange, the options to send test messages and track routing are greyed out:


even though I seem to have everything you would need

  • Routing services installed? ü

  • Multiple sites? ü

  • One DC per site? ü

  • Site links?  ü

  • Send test message? û 

Eventually I found after following various links in the online documentation for these diagnostics tools that they are DISABLED in the registry by default!

For instructions on enabling these features, see Enable route tracking and test messages

and set EnableReportMessages.

Comments (5)

  1. Yoel Arnon says:

    Well, as the inventor of test messages and tracking I have to admit that it is not a bad idea to disable it 🙂

    The problem is that enabling test messages allows other computers to instruct your computer to send test messages, and enable tracking means that your computer will send a signature of every message received to a queue that may come from external computer. While this option is great for testing, it is also great for hackers and should be handled with care.

    John – thanks again for your excellent blog!

  2. MSDN Archive says:

    Hi Yoel,

    What you are saying is true – testing and tracking shouldn’t be on by default for good reasons but I’m commenting on the non-intuitive route to enabling them.

    For me 100% of all registry changes should be made through restricted interfaces and not regedit. There should be a fully documented check/tick box that enables testing and tracking by making the "EnableReportMessages" registry change for you.

    So this looks like a design change that was implemented AFTER all the user interface work was finalised, which explains why it is so difficult to find the required information.  



  3. Robke says:

    Hello guys,

    I tried to use your workaroufn to test soem message que, because we face problem with long "wait-to-cennect" status. But when I tried to add a queue to test. It tells it does nto support Private queues?

    Do you have any idea, how can I find where messages are lost on the way, that they do not arrive to remote destionation computer?



  4. MSDN Archive says:

    Hi Robert,

    The tools discussed in this blog post are for Active Directory-integrated clients and make use of public queues.

    How long do you see the "waiting to connect" status? You also mention lost messages. What are the actual problems you are seeing?


    John Breakwell (MSFT)

Skip to main content