Recently I discovered the limitations of WMI when it comes to monitoring MSMQ running in a cluster. I researched the solutions and didn't like the mess I found. One of my MSMQ savvy colleagues wrote me a VBScript utility to connect to queues count the number of messages. His solution was great because it guaranteed that we would have accurate message count data back from the queues and simultaneously tested the queue's up-time. Unfortunately, we discovered that this isn't perfect. The problem is that in order to get the message count we had to create a MSMQ.MSMQManagement COM object (YUCK!).
Since we're performance minded folks, we monitored cscript.exe while it ran our script. We were shocked to find that although it ran for less than 2 seconds, it used ~160 MB of RAM and 99% of the CPU. This was totally unacceptable. We have over a hundred queues to monitor, and it would crater our monitoring environment. So then we moved on to plan B. I blew the dust off of a Powershell book someone let me borrow that I had been aggressively ignoring.
At first I found Powershell confusing, it was familiar in many ways, but unfamiliar in just as many. Fortunately, the book and with the encouragement of my book's owner I was able to throw down a script to mimic the work of the VBscript but using .NET's System.Messaging's Message Queue class. The trick was making the script reliable so that if it failed, our monitoring tool (PRTG) could send the operator a friendly message. It turns out that it was much easier than I expected. Without further ado, I give you the PRTG MSMQ Monitoring Powershell