I’m frequently impressed by the additions and changes to Windows as I spend more time on the Windows 8 Consumer Preview.
Here, for example, is how a the progress is now shown for a copy across my home network.
I think this is demonstrating to me how the destination is not able to keep up with the flow. I’m now intrigued to see if there is anything I need to do to improve performance.
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.
Thanks to Seif Attar for highlighting this problem.
It seems MSMQ doesn’t like sending to computers with names longer than 15 characters (which some may remember is the NetBIOS limitation).
To try it out, I created a queue on a Windows XP machine with a computer name of VeryLongMSMQServer and sent off some test messages to
DIRECT=os:verylongmsmqserver\private$\txqueue
I requested acknowledgements so I could see any errors and wasn’t disappointed:
As soon as I renamed the machine to ShortMSMQServer, restarted and sent new messages to
DIRECT=os:shortmsmqserver\private$\txqueue
the problem disappeared:
The messages are delivered to the destination’s queue manager in both cases but are rejected when the machine name is too long.
My suspicion is that this is a NetBIOS limitation. When I initially changed the machines computer name to one that was too long, Windows XP complained “The NetBIOS name of the computer is limited to 15 bytes. The NetBIOS name will be shortened to “VERYLONGMSMQSER”.:
I did try enabling the IgnoreOSNameValidation registry value in case that would help but no luck.
Udi Dahan briefly chats about MSMQ on his blog and provides a useful link:
Microsoft has put MSMQ in the Developer Preview of Server 8 (as Brian Buvinghausen has written here).
There’s good news on Brian’s blog:
“Finally! Microsoft added MSMQ to Server Core in Windows Server 8”
So it will be interesting to see how they got round the limitations of previous versions of Windows Server Core.
John Talarico shares a few lines of code to explain how he used TransactionScopeOption.Suppress to allow transaction messages to be sent within, but independent of, an ambient transaction.
Transactional logging outside of transactions
I’ve constructed a central logging system for a solution that involves routing and processing messages on multiple private queues (MSMQ) using WCF. Within a contract method of a WCF service, I do some logging.
Paul King explains how to use the DirectoryEntry object to manipulate MSMQ properties.
Our support website does a pretty good job for telling you how you can modify the MachineQuota setting for MSMQ. Unfortunately, if you need a way to do this programmatically and your installation happens to be in "Domain Mode", then there really isn't enough information here. Fortunately using the DirectoryEntry object makes this a pretty easy task.
Short and too the point. Too many people using MSMQ approach it with a workgroup mind-set and don’t always appreciate how much more there is to the product with Active Directory Integration.
This blog post sounds specific but most of the troubleshooting tips can be applied to other scenarios:
Troubleshooting Microsoft Message Queuing Issues on Microsoft Lync Server 2010
Microsoft Message Queuing (MSMQ) plays an important role in the Microsoft Lync Server 2010 Monitoring/Archiving server infrastructure: in a distributed network environment, MSMQ is used to transmit data from agents located on other servers (such as Front End Servers) to Monitoring/Archiving servers. The purpose of this article is to help you discover the root cause of any MSMQ problems that you might encounter, and to provide suggested ways to fix those problems.
Microsoft Lync Server is the new name for Microsoft Office Communications Server.
It’s good to see a major product make use of MSMQ – there aren’t many in the public eye (Symantec’s Enterprise Vault comes to mind).