One plan for the summer is to sit in the garden sipping cool beer whilst writing a book on MSMQ. We'll see how that pans out. If you have any suggestions for what to include then by all means drop me a line.

I won't be disappearing, though, and still plan to maintain a presence on the Internet somewhere.

If you found this blog useful then hopefully the new content at Blog.PlumbersMate.EU will be equally well received. (Thanks to the cybersquatters for taking up most of the available domain names...)

Don't forget the new MSMQ forum which recently replaced the various newsgroups.

And anything on Twitter with a #MSMQ tag is bound to attract my attention.

Thanks to Microsoft for providing me with this blogging platform and, of course, to you all out there for reading, commenting and emailing over the last 3-4 years.

Cheers
John Breakwell

Windows Phone is a Silverlight/XNA platform, as discussed here:

Silverlight for Windows Phone

Silverlight is the application development platform for Windows Phone 7 Series.
High performance gaming is also supported through the XNA Framework.

This means that any existing Windows Mobile applications will need to be recoded (or re-written from scratch) to make use of Silverlight.

As discussed back in November, MSMQ isn't part of Silverlight for various reasons (such as cross-platform issues and client size). So if there is a requirement for messaging functionality then an alternative approach would be needed.

If this limitation affects you - either because you have a Windows Mobile application that uses messaging or you want MSMQ in Silverlight - could you please drop me an email or post a comment that describes the scenario you are developing for?

Additionally, if you have any suggestions on alternatives to providing messaging on the Windows Phone, please share.

• MSMQ - confusingly the protocol name is the same as the product name (although Microsoft Message Queuing is the preferred alternative. Not as snappy, mind). This protocol is for sending messages to remote destinations.
• RPC - used for pulling data from another queue manager. This information could be whole messages or just properties about messages, queues, services and so on.
• LDAP - required for querying Active Directory about the properties of the various MSMQ objects stored there

This blog post will focus on the main obstacles to using remote operations and RPC.

Over the years, Windows security has been beefed up and this means a lot of unsecured ways to interact with MSMQ have been disabled by default. The three that come to mind are:

• Secured remote read interface enabled

By default, an encrypted channel is required which is not possible with machines in a different forest, running in workgroup or using local (not domain) accounts. This is covered in my MSMQ 3.0 too secure for you? blog post.

• Windows Firewall blocks RPC port 135

To reduce the number of ports exposed to attack, port 135 is blocked by default. Without this port, clients cannot determine what port the server's MSMQ service is listening on. This is covered in my Getting MSMQ messages out of Windows Server 2008 remotely blog post.

• Un-authenticated RPC calls disabled 

This is part of the changes made with Windows 2003 sp1. Remote anonymous access to RPC interfaces on the system was disabled and now the authentication of callers is required which reduces the risk of being attacked by means of buffer overruns invoked anonymously and remotely.The user interface for changing this just for MSMQ is covered in my MSMQ 4.0 - what's new in Computer Management? blog post.

References

• RPC Interface Restriction

Following is list of key capabilities that have been added to BizTalk Server 2010.

1. Enhanced trading partner management that will enable our customers to manage complex B2B relationships with ease
2. Increase productivity through enhanced BizTalk Mapper. These enhancements are critical in increasing productivity in both EAI and B2B solutions; and a favorite feature of our customers.
3. Enable secure data transfer across business partners with FTPS adapter
4. Updated adapters for SAP 7, Oracle eBusiness Suite 12.1, SharePoint 2010 and SQL Server 2008 R2
5. Improved and simplified management with updated System Center management pack
6. Simplified management through single dashboard which enables IT Pros to backup and restore BizTalk configuration
7. Enhanced performance tuning capabilities at Host and Host Instance level
8. Continued innovation in RFID Space with out of box event filtering and delivery of RFID events

One interesting result of the renaming is that the lifecycle clock resets. For BizTalk 2009 R2, the 5 and 10 year support bands would have started with the release of BizTalk Server 2009 "R1" so you would effectively lose a year. For BizTalk 2010, the support bands start from its release ... some time in 2010.

Hello all,

Today we are announcing that we have opened a new MSDN Forum for all topics of MSMQ. 

The new Forum is located at https://social.msdn.microsoft.com/Forums/en-US/msmq. 

We have migrated the last 90 days worth of posts from all of the MSMQ newsgroups into the Forums for your convenience.

Regards,
The MSMQ Team

Hope to see you all again on the forum.

Sajay's Blog

This isn't true - MSMQ has been supported on devices since Windows CE 3.0.

What is actually happening is that the vendor of the device is not supporting MSMQ.

Why this is the case is probably down to cost - the builds they provide to customers contain the components they are willing to support and maintain. Adding functionality to a build means an increased support overhead. Or maybe not enough customers are requesting MSMQ to make it worth adding to the builds. Maybe space available for MSMQ's message storage is an issue (although modern storage technology in devices should now be more than adequate).

If you need MSMQ on your Windows XP embedded devices then shop around - just because one vendor can't support MSMQ doesn't mean they are all in that situation.

References

• From the Embedded team's blog: Component Tales: Safe and Reliable Communication using Message Queuing
• Windows XP Embedded SP2 Feature Pack 2007: Message Queuing (MSMQ) Help
• Support:  QFE: MSMQ updates for Windows XP Embedded clients

When signing an outgoing message, MSMQ can use a number of algorithms depending on the version.

Algorithm	Available in	Default for
MAC	all versions	-
MD2	all versions	-
MD4	all versions	-
MD5	all versions	MSMQ 1.0 – 3.0
SHA-1	MSMQ 2.0 (Windows 2000 Service Pack 4) and above	MSMQ 4.0
SHA-2	MSMQ 4.0 and above	MSMQ 5.0

There is also a limitation if you are sending messages to HTTP/HTTPS or multicast addresses (MSMQ 3.0 and above) when only MD5/SHA-1 are available and SHA-1 is the default.

Although all the algorithms are still currently supported, the older ones are regarded as too weak and have been disabled in MSMQ 4.0 (MAC, MD2, MD4, MD5) and MSMQ 5.0 (SHA-1). These can be reinstated using the WeakHashAlgorithms registry key.

Here’re some definitions of the algorithms from the MSDN Security Glossary and Wikipedia:

Algorithm
MAC	“Message Authentication Code”
MD2 MD4 MD5	“Message Digest” Hashing algorithms that create a 128-bit hash value. MD2 was optimized for use with 8-bit computers and MD4/MD5 for 32-bit computers. Developed by RSA Data Security, Inc.
SHA-1 SHA-2	“Secure Hash Algorithm” Hashing algorithms that generate a message digest. SHA is used with the Digital Signature Algorithm (DSA) in the Digital Signature Standard (DSS), among other places. Developed by the National Institute of Standards and Technology (NIST) and by the National Security Agency (NSA). SHA-1 generates a 160-bit message digest. NIST published four additional hash functions in the SHA family, named after their digest lengths (in bits): SHA-224, SHA-256, SHA-384, and SHA-512. These algorithms are collectively known as SHA-2. SHA-256 and SHA-512 are computed with 32- and 64-bit words, respectively. SHA-224 and SHA-384 are simply truncated versions of the first two.

MSMQ 4.0

Overview of Message Queuing

Authentication

Message Queuing 4.0 supports Secure Hash Algorithm version 1.0 (SHA1) and all advanced hash algorithms that are supported in this version of Windows. The default is SHA1. Support for algorithms such as Message Digest version 2 (MD2), MD4, MD5, and Message Authentication Code (MAC) have been disabled by default in Message Queuing 4.0 because these algorithms are considered less secure.

MSMQ 5.0

What's New in Message Queuing 5.0

More Secure Authentication Algorithm

Message Queuing 5.0 supports Secure Hash Algorithm 2.0 (SHA2) and all advanced hash algorithms that are supported in this version of Windows. The default is SHA-2 with 512 bit digest length. Support for algorithms such as SHA1, Message Digest version 2 (MD2), MD4, MD5, and Message Authentication Code (MAC) have been disabled by default in Message Queuing 5.0 because these algorithms are considered less secure.

References

• MSMQ product group blog (Motley Queüe) - “Authentication and MSMQ4”
• MSDN Security Glossary
• MSDN documentation for PROPID_M_HASH_ALG
• Wikipedia – SHA hash functions

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.

Here's the page for Highlights & Top Issues.

Hmmm.... "Last Review : 30 July 2009" but the KB articles referenced are all at least 3 years old. I'd best find out who owns the page and get it refreshed for MSMQ 4.0 and 5.0.

[[Edited March 3rd, 2010]]

"Highlights & Top Issues" page was still viewable in error. It's now been archived/deleted.