Enabling tests and tracking in the "Diagnostics" tab for the "Message Queueing" node in Computer Management on Windows

Thanks to a coworker, I finally know how to enable the Diagnostics for MSMQ in Computer Management on Windows so that I can better diagnose and track issues for working with MSMQ.

See this. To find it on Google, search for this: "site:msdn.microsoft.com Enable Route Tracking and Test Messages" and also see this post from the MSMQ Mighty Hero, John Breakwell.

Solving "The signature is invalid." errors on MSMQ messages in the "MSMQ, WCF and IIS: Getting them to play nice (Part 3)" series by Tom Hollander

My company has recently had need for an MSMQ-backed queueing solution, that happened to match the topology described in Tom Hollander's "MSMQ, WCF and IIS: Getting them to play nice (Part 3)" blog post. I went a first round with that piece, trying to get it to work on our network. It cost me about a week's worth of time before I had to show that I couldn't get it to work and negotiate a deferral of the last phase of the work: enabling Transactions in addition to the security on the queue. Well, this issue reared its ugly head again and I was forced back to it. This time, I was able to get it to work with much less time and effort.

The error that I kept encountering was all my messages would go straight to the System Transactional Dead Letter Queue, with the error on them "The signature was invalid".

TL;WR: There's several steps that were unique to our setup that weren't mentioned in Tom Hollander's blog post.

The extra steps that I had to implement that weren't in the blog post were (at a high level) as follows:
1) Configure MSDTC to enable XA transactions, mutual authentication, and allowing remote clients.
2) Configure both the MSMQ Server and queues to grant Full Control to the principal that was running the service.
3) Ensure that the principal that was making the request to the server had full control over its respective queues.
4) Install MSMQTriggers and MSDTC in addition to the MSMQ service, because these pieces were apparently necessary for transactions to work in the setup in the Blog post from Tom Hollander. He never explicitly states in the Blog post series that these items have to be installed. They do.

I'll publish a follow up post with steps to automate setup of all of this if I have the time.

Solving the dreaded MQ_ERROR_CORRUPTED_SECURITY_DATA (0xC00E0030) MSMQ error

I recently started getting a the error MQ_ERROR_CORRUPTED_SECURITY_DATA (0xC00E0030) when trying to execute tests on my development box while publishing to MSMQ queues. As indicated by the error, the cause was corrupted security data. I had recently changed my development machine from one directory over to another. Going into the MSMQ Server properties in compmgmt.msc (Computer Management) and clearing out all the certifticates for my user, renewing them and reregistering the certificates with Active Directory fixed the issue.

Solving "Binding validation failed because the binding's MsmqAuthenticationMode property is set to WindowsDomain but MSMQ is installed with Active Directory integration disabled"

I've been trying to set up remote reads from an MSMQ queue to a WCF service hosted on another machine. I seem to have all my application settings correct, but I'm being screwed over by machine-level configuration on the service machine: the service machine won't run in Active Directory mode, no matter what I do.

After searching for the problem, I found this page on John Breakwell's MSDN blog. It describes the problem: essentially there's a legacy msmq object left around when you install MSMQ Server and Active Directory Integration features together in the same transaction. Here's how you **actually** fix the problem:

1. Uninstall all of the MSMQ features.
2. Execute this PowerShell command (or one similar to it) to actually delete the Active Directory object described in the article (which doesn't go into nearly enough detail on this point):  get-adobject -filter “name -eq ‘msmq'” | Where { $_.DistinguishedName -eq ‘CN=msmq,CN=MyAffectedServerNameHere,OU=Web Servers,OU=Member Servers,DC=MyDomainNameHere,DC=Network,DC=ads’} | Remove-ADObject
3. Reinstall **just** MSMQ server, then reboot your machine.
4. Reinstall **just** MSMQ active directory integration, then reboot your machine.

You should now be good to go.

Solving "Binding validation failed because the binding's MsmqAuthenticationMode property is set to WindowsDomain but MSMQ is installed with Active Directory integration disabled"

I've been trying to set up remote reads from an MSMQ queue to a WCF service hosted on another machine. I seem to have all my application settings correct, but I'm being screwed over by machine-level configuration on the service machine: the service machine won't run in Active Directory mode, no matter what I do.

After searching for the problem, I found this page on John Breakwell's MSDN blog. It describes the problem: essentially there's a legacy msmq object left around when you install MSMQ Server and Active Directory Integration features together in the same transaction. Here's how you **actually** fix the problem:

1. Uninstall all of the MSMQ features.
2. Execute this PowerShell command (or one similar to it) to actually delete the Active Directory object described in the article (which doesn't go into nearly enough detail on this point):  get-adobject -filter “name -eq ‘msmq'” | Where { $_.DistinguishedName -eq ‘CN=msmq,CN=MyAffectedServerNameHere,OU=Web Servers,OU=Member Servers,DC=MyDomainNameHere,DC=Network,DC=ads’} | Remove-ADObject
3. Reinstall **just** MSMQ server, then reboot your machine.
4. Reinstall **just** MSMQ active directory integration, then reboot your machine.

You should now be good to go.

MSMQ, WCF and IIS: Getting them to play nice: The extras, Part I

I've recently been trying to set up queued publishing of data in my company within our internal applications so that we can publish that data out to other applications running in our hybrid cloud with Azure. To move the data around on-premise, I've been working off of the advice given to me by some very knowledgeable people in the IT space, and using architectural design patterns that have been proven to work (though not by me). To implement our new data-publishing architecture, I decided to leverage components I already had at my disposal and use WCF with MSMQ bindings to deal with unreliable connections from some of our remote sites. To help me get started, I began following the series of articles published here on MSDN by Tom Hollander. I was able to get past Part 1 of the tutorial without problem. I even needed the same architecture: a queued message client publishing to a service, via a queue hosted on a 3rd party system.

Part 2 however, securing the queue, proved to be a little bit harder, to the point where I needed to go to stackoverflow.com for help and posted this question. In the question, I kept running into an error when I tried to enable Transport security along with ActiveDirectory support. When I didn't enable ActiveDirectory support, I got a different error, with the code 0xC00E0030. Looking on the page for MSMQ queueing error codes on MSDN, I found that this error means that there was corrupted security data, somewhere. Here's what I had to do to resolve it:

1. In the EndpointAddress for my WCF binding, I had to add an extra parameter to the constructor for the EndpointIdentity of my binding: New EndpointAddress(queueUri, EndpointIdentity.CreateDnsIdentity(queueUri.Host))
2. I had to gain access to the server where I was hosting my MSMQ Server, and gain full access to the Server itself:  Computer Management -> Message Queueing -> Right-click -> Properties -> Security tab -> [my name] -> "Full Control"
3. I had to re-register my own Internal Certificate for MSMQ on the server: [previous steps] -> User Certificate tab -> Internal Certificate section -> Renew....

After cleaning up the certificate and adding the endpoint, I was good to go, and I could now authenticate and send messages to the MSMQ server.

To be fair to Tom Hollander, he did say that there would be some extra specifics to getting Authentication working, and I guess these were mine. I have to send him a lot of thanks for going through what he did AND recording and publishing the steps. People like him make the world a better place.

Managing MSMQ through PowerShell

There's a module for that!

Import-Module MSMQ

See the page on MSDN.

Creating an MSMQ queue administratively through the Windows Control Panel

To create a message queue

1. In the Control Panel, double-click Administrative Tools, and then double-click Computer Management.
2. Expand Services and Applications, and then expand Message Queuing. ...
3. Right-click Private Queues, and then click New.
4. Enter a name for the private queue, and then click OK.

See the link here on MSDN.

Enabling MSMQ in Windows via PowerShell

First, let's start off by seeing which Windows features for MSMQ are available in your installation:

Get-WindowsOptionalFeature -Online | ? { $_.FeatureName -like '*msmq*' }

If you see a message like "Failed to load program with incorrect format", double check that you're running a 64-bit version of PowerShell if your machine is running a 64-bit version of Windows.

Then, let's enable the ones we actually need:

$packageResults = @(Get-WindowsOptionalFeature -Online | ? { $_.FeatureName -like '*msmq*' -and $_.State -ne 'Enabled' } | Enable-WindowsOptionalFeature -Online -All -NoRestart)

$packagesRequiringRestart = @($packageResults | ? { $_.RestartNeeded })

if ($packagesRequiringRestart.Count -gt 0)
{
    Restart-Computer
}

This script takes the packages with MSMQ in the name, enables them along with any requisite parent features and prevents restart during installation. Once complete, we check the results to see if any installations require a restart. If there are any that require a restart, we restart the computer. As with anything else in PowerShell, and IT in general, use judgement and critical thinking.

IMPORTANT: The Get-WindowsOptionalFeature cmdlet and associated module are part of the DISM module. This module is available built-in with Windows Server 2012 and up. In Windows 7 / Windows Server 2008, it's available as part of the Windows Assessment and Deployment Kit available here. Even though the page says the installer is for Windows 8.1, it works on Windows 7 / Server 2008