MSMQ’s internal ping mechanism over port 3527

If you are using Network Monitor or Wire Shark to view MSMQ traffic, you will see that there is a small packet sent over port 3527. This ping mechanism is used to optimise connection time to computers that are online.

There is a change in MSMQ 4.0 (and above) where the MSMQ service no longer listens for this mechanism to reduce the number of ports exposed by Windows, as documented here:

Security Enhancements that Affect the Default Behaviour of Message Queuing

Message Queuing 4.0 does not listen for ping message on UDP port 3527

Previous versions of Message Queuing send a ping message to a remote computer over UDP port 3527 to verify that the remote computer is available before attempting to send messages to it. Message Queuing 4.0 does not initiate a ping message before connecting to a remote computer and also does not listen for ping messages on UDP port 3527.

To revert Message Queuing behaviour to listen for ping message on UDP port 3527, create the DWORD registry entry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters\Security\EnablePingService and set to a value of 1.

The result of not listening is that any MSMQ client using the ping mechanism will experience a small delay as it waits for a ping response before trying to establish a TCP connection. MSMQ will still try to connect with the remote machine even if there is no ping response and messages will be sent (if possible). Once connected, there are no further delays due to this functionality, or lack of it.

Note - To prevent MSMQ 3.0 machines experiencing this delay when talking to MSMQ 4.0 machines, switch off the ping mechanism on the sender by setting the UsePing registry value to 0.