How to tell if MSMQ is actually in use on a server

  • Article

Let's say MSMQ is part of your company's standard server build but you have been given the objective of removing the MSMQ service from those machines that do not require it. If you are handed responsibility for servers where there is no documentation and the previous support staff have moved on to other jobs then this job is going to be tricky. Just checking a server for running applications will not be enough as any local queues can be accessed from anywhere in your network, not just the hosting machine. There are no reports in the event logs that describe message activity, for example, so you may need to get imaginative. Also, the search for MSMQ activity can take a while as there is no reason to believe that all applications within the company will want to send or receive messages 24 hours a day. Some applications could be used for monthly reports which may take weeks to identify if you are unlucky in when you start looking.

Journaling

You can enable journaling on a queue to check if messages have been read from it. Each time a message is processed, a copy will be created in the corresponding journal queue. After a while, check the journal queue for messages with Computer Management; alternatively, write a small app to monitor the queue or set up a trigger. As a safety measure, set a low quota on the journal queue to ensure the message copies don't get out of hand and fill the system. Don't forget to purge the journal queue when you've finished.

You cannot enable journaling as easily on a machine that could be sending messages - source journaling is enabled in the code so you would need to deploy an update to all those machines running this particular application. Without such a code change, journaling is not possible for successfully sent messages.

 

Network Monitor 

MSMQ uses a number of ports for message transfer so a long-running a sniff for traffic on these will highlight the machines involved.

 

Auditing

Just like for files and folders, an MSMQ queue can be audited to show who/what accessed it.
[[Note to self - must experiment with this feature more...]]

 

Performance Monitoring

There are two objects of use here - MSMQ Service and MSMQ Queue. The following counters will help highlight activity:

  • MSMQ Service\MSMQ Incoming Messages
  • MSMQ Service\MSMQ Outgoing Messages
  • MSMQ Service\Sessions
  • MSMQ Service\Total messages in all queues

The Incoming/Outgoing Messages counters are a cumulative total for messages received or sent over the network. These are useful for showing that the machine interacts with others on the network, as will be the Sessions counter.

Use the "Total messages in all queues" counter to look for local activity where messages are created and consumed all on the same machine (and so doesn't appear in the Incoming/Outgoing Messages counters).

If you do detect activity then the MSMQ Queue counters can provide data on which queues are being used and so hopefully lead you to identify the applications generating the messages.

 

Checking the Storage directory

Messages are written to files in the %windir%\System32\msmq\storage directory. Checking the timestamps on the *.MQ files here may provide some useful information. Note that care should be taken here as the "Accessed" date and time does not show the last occasion a message was written to storage but rather when the storage file, or its properties, was last read.

 

Disable the service

Primitive but can provide good data - switch off the service and listen out for people complaining that their applications have stopped working. Be prepared to react quickly to re-enable services on machines you do need to be running MSMQ!