Sorry it has taken so long to reply... busy busy busy at work, little time to spare. Here's the documentation I have written so far. It's not 100% complete, and it doesn't detail the actual coding side, but at least it will give you an idea of how to use it.

Installation

1. Install ZenPacks.community.deviceAdvDetail and ZenPacks.community.MsmqMonitor via command line or ZenPackManager.
2. Navigate to /Devices/Server/Windows and open the "Flyout menu" => "More" => "Collector Plugins".
3. Click "Add fields" to show the hidden box, then drag the "community.msmq.MessageQueueMap" item into the box on the left.
4. Click "Save".

Usage

Adding Queues

Via Modeling

When modeling a device, the log screen will display an INFO-level message that indicates the number of queues the modeler discovered (i.e. “MSMQ: Found 15 queues.”). Ensure that this message appears before proceeding.

1. After modeling is complete, click on the device’s “OS” tab and uncheck the “Monitored” box in the “Message Queues” table. This will display all queues, including both manually-added and modeler-discovered.
2. Select the desired queues’ checkbox and click “Monitoring…” in the Message Queues table flyout menu
3. Click the “Enable” radio button and then “OK”.
4. Select the queues again and click “Lock/Unlock…” in the Message Queues table flyout menu.
5. Click the “Lock Queues From Deletion” button.

Manually

1. Navigate to the desired device’s OS tab.
2. Click the “Add queue…” entry in the Message Queues table flyout menu.
3. Enter the exact name of the queue and select the proper queue type.
4. Click “Add”.
5. In the breadcrumbs bar at the top of the screen, click “os”.
6. Select the checkbox for the queue you just added and click “Lock/Unlock…” in the Message Queues table flyout menu.
7. Click the “Lock Queues From Deletion” button.

Changing Thresholds

The default thresholds for MSMQ are Warning at 250 messages, Critical at 500 messages. These defaults can be adjusted globally, for sub-classes, or per-queue.

For All Queues

1. Navigate to /Devices/Server/Windows.
2. Click the “Templates” tab.
3. Click the “MessageQueue” template.
4. In the “Thresholds” table, make adjustments as desired.
   

For a Sub-class

Currently, defining a subclass is the only method of making threshold adjustments for specific servers without adjusting the global template.

1. Navigate to /Devices/Server/Windows.
2. Click the “Templates” tab.
3. Check the box next to “MessageQueue” and choose “Copy Templates…” from the flyout menu.
4. Select the target Device class. (It is suggested to use a subclass of /Server/Windows).
5. Zenoss will automatically navigate to the Templates tab of the subclass you chose. Verify that the definition path for “MessageQueue” matches the path of the subclass.
6. Click “MessageQueue”.
7. In the “Thresholds” table, make adjustments as desired.
   

For a Specific Queue

1. Navigate to the device and click on the desired queue name.
2. Click the “Template” tab.
3. In the “MessageQueue” row, click the “Create Local Copy” button.
4. Confirm that the definition path changed to the path to the queue.
5. Click “MessageQueue”.
6. In the “Thresholds” table, make adjustments as desired.

Known Issues

Queue Type Unused

The “Queue Type” field is not currently used by the ZenPack. This field was added to allow for greater specificity when monitoring queues (i.e. both a public and private queue with the same name). This was intended to be a "nice to have" feature when I originally wrote the code, but I never spent the time to finish it. If someone wants to finish fleshing it out, be my guest.

Queues Must Be Locked

After adding or configuring a queue, it must be locked to prevent the ZenModeler from deleting it (if the queue object drops out of the WMI Perfmon pool). I attempted to implement a sanity check in the modeler that would ignore any existing queues, but due to the limitations of modeler plugins I was unable to quickly overcome this problem and opted for the locking mechanism instead. Takeaway: if you don't lock your queues after setting them to be monitored, they *may* disappear the next time the device is modeled (automatically or manually).

I hope that helps. Again, I'm sorry about replying so late, hopefully you'll still be able to get some use out of this pack.

I just realized the version of the code that's posted here is not the most recent one I had (found and fixed some bugs). I'm rebuilding the egg now, will upload shortly.