And third for the day from Guatam is a problem managing MSMQ on a cluster.
MSMQ Management console on Win2k8 & WIn2k8 R2 Cluster not Visible
Seems that the MSMQ service on the physical node needs to run under Network Service.
Must set up a virtual cluster to test that out…
Another blog post from Guatam highlights the need to scale up some MSMQ parameters when there are many clients.
MSMQ 4 & 5 not receiving messages from Large Number of Clients
To improve performance, MSMQ caches user account information to reduce the overhead from checking if the sender of a message has adequate permissions to access a queue.
As with most caches, the size is fixed and old data is purged when there is no room left. Unfortunately, there is a potential situation where the clean-up process fails which prevents new clients from delivering messages.
To get round this blocker, make sure the cache is large enough to accommodate all possible users of the MSMQ system without needed to clean up.
This is done through the HKLM\SOFTWARE\Microsoft\MSMQ\Parameters\UserCacheSize registry value (default is 253; maximum is 4 billion).
It’s good to see my ex-colleague Guatam putting out some MSMQ content after a 10 month hiatus.
MSMQ Performance degrades over time & MSMQ LQS folder is 100s of MB.
The files in the %windir%\system32\msmq\storage\lqs folder are configuration files for the machine’s queues, or cached configuration information in the case of public queues.
Inside these text files is a collection of parameters, such as “Label”, “QueueName” and “PrivLevel”. The largest value is the “Security” parameter which contains the access permissions on the queue.
Guatam reports that sometimes this value can get out of hand, leading to larger and larger configuration files that are too big to be easily read.
One workaround is to delete and recreate the affected queues. Also disable inheritance and apply security permissions directly.