This is a new MP which will discover and monitor the MSMQ feature on Windows Server 2012 and later versions of the OS.
Quick Download: https://github.com/thekevinholman/MSMQ
Microsoft’s MSMQ MP’s don’t really work. Each release is a copy of the previous release, and are antiquated with disabled Self-tuning baseline monitors (because these don’t really work either). The scripts targeting the queues don’t cook down properly and can overload a computer with a lot of queues. Cluster queue performance monitoring didn’t really work either.
This MP is almost a complete re-write. Major changes:
- Re-wrote most workflows from VBScript to PowerShell.
- Clustered MSMQ discovery and monitoring actually works
- Discovering the Cluster Node as a MSMQ server is optional via override. By default only the clustered MSMQ instance is discovered by design.
- Cookdown works
- Simplified class structure
- Utilizes a SEED class and doesn’t run scripts on ALL Computers in the management group
- Most monitors utilize a shared script datasource
- Monitoring scripts log a single event, but provide for DebugLogging override if needed
- Removed the broken logical disk dependency which was in the MSFT MP.
This MP discovers:
IMPORTANT NOTE: The monitors and rules use shared script datasources – so care should be taken on overrides. If you change the interval on ANY of the monitors or rules, you must change it on ALL of them that share the datasource, or you will break cookdown. The default frequency is 15 minutes, and should be sufficient for most environments. You can set thresholds differently without impacting cookdown. Look for events 14120 and 14130 in the OpsMgr event log to know how often (and how many simultaneous runs) the scripts are running.
Rules:
Monitors:
On the thresholds – the default thresholds might be noisy, and were arbitrarily set. You need to adjust these for EACH setting if you want monitoring, because I have no way of knowing what is “normal” and “unhealthy” for your Queues.
There are also 92 event based Alert generating rules – ALL of which are disabled out of the box. These are likely important, but were disabled likely to reduce the out of the box noise experience. You should review these rules and determine if you want to alert on their events.
If you implement this MP – once you validate all monitoring scenarios are working, you should remove the following MP’s from your management group
- Microsoft.Windows.MSMQ.2012.mp
- Microsoft.Windows.MSMQ.2012.R2.mp
- Microsoft.Windows.MSMQ.2016.mp
I consider this a bit of a work in progress, so If there are features you’d like to see, or issues, please let me know in the comments.
Quick Download: https://github.com/thekevinholman/MSMQ
Excellent! One question, I see in the XML for the “MSMQ Journal Percent used Threshold Monitor”, you have the following; Journal Percent Used .
I would very much like to get the Journal Percent Used value in the alert to notify the support folks. Any chance of getting that?
Thanks again for all that you do!
Ok, 10.0.2.8 is released. I updated all the alert descriptions for all monitors to be MUCH more informational, and correct. Try it out, and any other feedback you have for initial settings is welcome.
sorry the copy/paste removed some info…..the XML has ” Journal Percent Used ” So basically where it says Journal Percent Used, you are dumping the Counter Name value.
Does this work for MSMQ 10/2019 server too? Does it make the log on as a service right for the runas account in the MSMQ profile unnecessary?
Yes, this covers MSMQ feature on WS2012 and later.
If you use a RunAs account, then SCOM 2019 will need the runas account to have the LogOnAsAService right, as all SCOM 2019 RunAs accounts require this. There is nothing special about this from my MP. I didnt do much testing with the RunAs profle, as I didnt find it necessary to use. However I believe tobe able to discover public Queues – it is needed. For private queues I have not found that to be the case.
I am constantly updating this MP based on feedback I get, it has been updated over 10 times since I released it, so keep checking back for updates if you use it.
Hello Kevin, Does it monitor System queues also ?
It should. However It requires a RunAs account for that, for some reason. I didnt change the discovery from the Microsoft MSMQ MP because it was quite complex VBscript. I am not sure why they designed it to require a runas account configured to discover system queues. If this doesn’t work or is too complex let me know and I can try to find time to re-write the discovery from scratch using PowerShell. The issue I was having – is there are many functions available in VBscript that do not exist in PowerShell, so I’d have to figure out a way to discover those properties, assuming they are actually necessary.
Any chance that a future version would include support for oldest message like the Microsoft ones? For me the age is more important than the number of messages on a queue. We might not have many messages at a given time, but it’s important that the are processed and if they pass the 15 minute mark something is most likely very wrong, but there might only be 15 messages. Could be a password reset message
Working on it
we have a number of Windows 10 machines that require monitoring of MSMQ. We have implemented this MP but noticed that the Windows 10 MSMQ were not discovered when the MSMQ Client discovery was enabled with an override. we also noticed once the override was in place we started receiving an error on the Windows 10 machines
Host reference in workflow “MSMQ.Client.Discovery”, running for instance “************” with id:”{***********}” cannot be resolved. Workflow will not be loaded. Management group
.
This is now fixed – in 10.0.3.2 release.
When monitoring Windows 10 – make sure you do NOT have “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PerfProc\Performance\Disable Performance Counters” registry DWORD value set to “1” as that will disable the ability to collect process information.