Welcome to MSDN Blogs Sign in | Join | Help

MSMQ is asynchronous on the inside too

There is a new Knowledgebase article out - although I use the term "new" with some reservation. The article refers to a hotfix that has since been included in service pack 2 which gives you an idea how old the content really is.

FIX: Message Queuing 3.0 still accepts incoming messages from the network after you successfully call the MSMQApplication.Disconnect method on a Windows Server 2003-based computer

So I'm not mentioning the KB article because you may need the fix as you will already have service pack 2 in place so would be a moot point (or not a moot point, depending how you use the English language).

What is instead interesting is why there is a problem. MSMQ is designed to shift messages as fast as possible between locations and everything else is a secondary function. So, in this article's case, a call is made to disconnect MSMQ. The application making the call immediately gets a "success" back as the queue manager accepts the request. Unfortunately that request will not necessarily be acted upon right away, depending on how busy the server is with incoming messages at the time.

An analogy would be with switching off a hose - it takes a while to turn the tap and stop the flow of water. In most cases that's not a problem but if we are talking about a fire hose then a lot of water can still pass through before the flow finally stops.

If, in the message queuing world, you are monitoring the health of the MSMQ server and are calling Disconnect to stop the volume of incoming messages reaching a particular level then that delay before disconnecting may be critical. There could be so many messages arriving per second that the server fills up and stops working (See this insufficient resources post for more detail on why) before the disconnection completes.

The resolutions are:

  1. Call Disconnect earlier than you need (although this is a bit hit and miss)
  2. Add the FastDisconnect registry value introduced in the KB article

Note that FastDisconnect is still not immediate (to allow any outstanding acknowledgements to arrive) but it is an improvement.

Posted by JohnBrea | 0 Comments
Filed under: ,

ComputerWeekly.com IT Blog Awards

Thanks for everyone that voted for me in the ComputerWeekly.com IT Blog Awards this year.
Unfortunately I was in a tough category - the winner was not only the best in the Company category but chosen as best blog overall. So congratulations to Steve Clayton. 
Check out Steve's blog "Geek In Disguise" to see what the fuss is all about.
Posted by JohnBrea | 2 Comments
Filed under:

0x800288c5 trying to install MSMQ on Windows Vista

Not specifically an MSMQ problem but one encountered mainly by people installing Message Queuing anyway.

The symptoms are as follows:

While installing MSMQ on Windows Vista, the component setup churns away for 30-40 minutes before coming back with an error. A message box titles "Windows Optional Component Setup" appears complaining "The component setup program encountered an error: 0x800288c5. Size may not exceed 64K"

This forum link describes the problem and discussed the number of files in the %windir%\WinSxS\Manifests directory:

"Using Process Explorer, I noticed that what is happening is TrustedInstaller is parsing manifests from the C:\Windows\WinSxS\Manifests the entire time. What caught my eye is that it is *actually* leaving the file handle open for each manifest it opens, reaching an open handle count well over the theoretical limit of 65,536 handles by the time it fails. For the record, there are 80,449 manifests in my C:\Windows\WinSxS\Manifests folder."

I have tried to reproduce the problem (although not extensively) and noticed the total handle count on my test machine rise from 31,086 to 51,994 during the setup operation (which was successful) and then dropped to 32,784, for a difference of roughly 20,000(!) handles (TrustedInstaller is the source of all the handles). My 64-bit laptop has 15,000 entries in the C:\Windows\WinSxS\Manifests folder taking up 300+ MB which is much less than for those people with the problem.

Those people affected have had many language packs installed for testing and development - removing a number of these has allowed component setup to complete.

Posted by JohnBrea | 2 Comments
Filed under: ,

Understanding How You Use This Blog

Greetings Blog Readers,

 

My name is Ed Jolly, and I am a director in the Commercial Technical Support (CTS) organization at Microsoft. I am here to request a few minutes of your time.

 

We would like to learn more about blog readership through a brief survey. This is an opportunity for us to better understand what is valuable to you and what you would like to see in the future.

 

Below is a link that will take you to another website to complete the survey. Based on what we learn, we may request more feedback in future surveys like this.  When you open the survey, you will see a list of blogs that CTS engineers contribute to across many different products. We have not posted a listing of these blogs in the past, and I hope it helps you find other blogs that are helpful to you.

 

The blog survey is completely anonymous.

 

The survey period has now ended.

 

 

Thank you in advance for your time, participation and assistance.

Ed Jolly (edjolly@microsoft.com)

 

Posted by JohnBrea | 0 Comments

MSMQ and IPv6

As IPv6 becomes more prevalent in your environments, you'll need to make sure that you are running MSMQ systems that can actually cope with the new IP addresses.

There are (at least) three issues to watch out for.

  1. The addressing of messages is not as simple.
    For example, an old school address of

          DIRECT=TCP:10.32.55.123\PRIVATE$\queuename

    would become

          DIRECT=TCP:[2001:4898:2a:1005:230:48ff:fe73:989d]\PRIVATE$\queuename

    Notice the use of square brackets.
  2. Not all operating systems can work with IPv6 out of the box. Windows Vista and Windows Server 2008 are both fine but Windows Server 2003 has IPv6 disabled by default. Although you can enable IPv6, MSMQ 3.0 (that comes with Windows Server 2003) will still only be listening on the IPv4 IP address. In that situation, any MSMQ 4.0 machines will not be able to send messages to an MSMQ 3.0 destination using IPv6 addresses.

  3. On a Windows Server 2008 cluster you may find MSMQ is only listening on an IPv6 address even though there is an additional IPv4 address configured. This is down to the slightly different times taken for each IP address to become registered in DNS. MSMQ will only listen on the IP addresses that are returned when it queries DNS for the network name being used. IPv6 addresses are slightly faster than IPv4 addresses to initialise and so are more likely to be in DNS when MSMQ comes looking.

    Workarounds:

    • Don't use IPv6 addresses if you don't need them yet

    • Recycle the MSMQ resource to force DNS to be queried (all addresses will have been registered in DNS by then)

    • Change the Dependencies for the Network Name used by MSMQ from "<IPv6 address> OR <IPv4 address>" to "<IPv6 address> AND <IPv4 address>". The "OR" logic means the network name resource - and therefore MSMQ - comes on line when either of the addresses has initialised; the "AND" logic requires both addresses to be ready before the network name resource can come on line, giving more time for the DNS updates to complete.

Do check the event log first, though, as there may be some other explanation:

    • MSMQ Event 2197 "Message Queuing failed to listen on the IPv6 protocol. Messages will not be accepted on IPv6. <error code>"

    • MSMQ Event 2198 "Message Queuing failed to listen on the IPv4 protocol. Messages will not be accepted on IPv4. <error code>"

Reference

Windows Server 2003 IPv6

Posted by JohnBrea | 0 Comments

Checking if MSMQ queues exist is hard work so should you bother?

Frank Boyne, 5 star MVP, posted a great response to a question on the MSMQ newsgroups which I felt was worth reiterating. 

Basically someone wanted to check if a private queue on a remote machine existed before they sent a message to it. The problem was that they couldn't call the MessageQueue.Exists() method without getting InvalidOperationException.

As Frank explained, this method call isn't available for remote computers, as documented in MSDN.

Exception

Condition

ArgumentException

The path syntax is not valid.

MessageQueueException

An error occurred when accessing a Message Queuing method.

-or-

The Exists(String) method is being called on a remote private queue

InvalidOperationException

The application used format name syntax when verifying queue existence.


As you can see, an exception will be thrown for checking remote private queues.

The interesting part of Frank's response is what to do about it. Basically, checking that a remote queue exists before you send is no guarantee that the destination will still be there when the message arrives. Or, vice versa, someone could create the queue just after you've found it didn't exist.

Frank's alternative approach is to make use of other features that MSMQ provides, such as negative acknowledgements messages with administration queues.

What should happen is that either:

  • the message will be delivered successfully to the destination queue
    or
  • a negative acknowledgement (NACK) will be returned to the administration queue with a class of  "The destination queue does not exist." (MQMSG_CLASS_NACK_BAD_DST_Q)

Alternatively you could use negative source journaling and, on failure to deliver, should see the same class of NACK in the corresponding "Dead-letter messages" system queue.

In summary, don't check if the queue exists but instead handle the non-delivery of the message should it turn out that the queue doesn't exist.

Posted by JohnBrea | 0 Comments
Filed under:

If you are looking for a BizTalk self-study plan...

... hop over to Chris Romp's blog where he has put together one for developers which he will try and keep up to date for you.
Posted by JohnBrea | 0 Comments
Filed under:

Installing MSMQ can be a SELF-ish act

There's one thing with the documentation/help for installing MSMQ that confuses me - it talks about the Active Directory permissions required for the logged in account but I've noticed setup doesn't really care. For an independent client at least, all you need is for the SELF special account to have "Create All Child Objects" on the corresponding Computer Object in Active Directory.

I tried a simple test arrangement - a Windows Vista independent client-to-be and a Windows 2003 domain controller, both in the same domain. The logged in account is a domain user added to the local administrator group (I have to make some concessions). I tweaked the permissions on the Windows Vista machine's computer object as follows:

Permissions for the domain user account

Permissions for the SELF special account

Result of installing MSMQ on Vista machine

None

None

Event 2116 – Access Denied 0xC00E0025

None

“Create all child objects”

Success

“Create all child objects”

None

Event 2116 – Access Denied 0xC00E0025

“Create all child objects”

“Create all child objects”

Success

I found that even an Enterprise admin will get Access Denied if SELF doesn't have the access it needs - I think SELF here resolves to the machine account you are installing MSMQ on.

I must dig further into this to find out what's really happening.

 

Reference

Well-known security identifiers in Windows operating systems

SID: S-1-5-10
Name: Principal Self
Description: A placeholder in an inheritable ACE on an account object or group object in Active Directory.
When the ACE is inherited, the system replaces this SID with the SID for the security principal who holds the account.

Posted by JohnBrea | 0 Comments
Filed under: ,

Does MSMQ 3.0 need the RMCAST (PGM) protocol driver?

I noticed in the newsgroups that someone wanted to know how they could remove the PGM protocol from their machines to reduce their exposure to attacks over the network.

In Windows 2003 and XP, this protocol is installed when Message Queuing is selected to provide support for multicasting. Unlike in Windows 2008 and Vista, there is no option to deselect this protocol when installing MSMQ.

MSMQ also has a dependency on the RMCAST (PGM) protocol driver so you can't simply remove the protocol.

If you don't require the ability to multicast MSMQ messages then the workaround for Windows 2003 and XP is as follows:

  1. Open up the Registry Editor
    • Navigate to HKLM\System\CurrentControlSet\Services\MSMQ
    • Edit the DependOnService value and CAREFULLY remove the RMCAST entry.
  2. Open up the Control Panel
    • In Network Connections, locate the Local Area Connection
    • In the connection's General properties, uninstall the "Reliable Multicast Protocol"
  3. Reboot the server to clean up the bindings and dependencies 

[[2nd September 2008]]

Note - this modification will not work for a clustered MSMQ resource because of the way the service is created. MSMQ on a standalone server uses the registry for all of it's settings and so editing the dependencies is simple. A clustered MSMQ resource, though, creates the corresponding service from scratch each time it is started and has a number of settings hard-coded - one of the settings is the service dependencies. So every time when the resource is brought offline/online, the service is re-registered with RMCAST in the dependency list.

This means that if RMCAST is uninstalled, the clustered MSMQ will be unable to start as the dependency list cannot be changed to exclude it. A partial workaround is to deselect "Reliable Multicast Protocol" from each network interface rather than uninstall it.

[[Thanks to Ruud Baars and Xin Chen for their invaluable input]]

Posted by JohnBrea | 0 Comments
Filed under: ,

BizTalk essentially

After a week of commuting to London and back, I've finally finished the Essential BizTalk Server course at developmentor. Definitely worth the time as my knowledge of the product has increased manyfold as a result - not quite a divide-by-zero increase but you get the idea. Thanks to Marvin Smit for delivering a top-notch course.
Posted by JohnBrea | 0 Comments
Filed under:

Get ready for Tech Ed 2008 in Barcelona

The Super Early Bird offer ends July 31st so don't leave it too late.

See you at Tech Ed

Hopefully I'll be able to help out in the Ask The Experts booth like I did last year.

If so, please drop by and say hello - I'll even try and answer your question too!

Posted by JohnBrea | 0 Comments
Filed under:

Getting MSMQ messages out of Windows Server 2008 remotely

I'm now into full swing looking at MSMQ 4.0 on Windows Server 2008 using Virtual Server. I haven't got round to installing 2008 on my 64-bit laptop and desktop yet but maybe in the summer sometime when customers are on vacation I'll have the time.

Sending messages works fine but receiving them fails (0xC00E0069 Remote Machine Not Available). After a little while I realise that the security is tighter than I'm used to so the Windows Firewall must be blocking me. I check the Exceptions list for Windows Firewall (Control Panel) and Message Queuing is there.

This doesn't provide me with much detail, though, so I have a look at Server Manager where I can see two entries.

Checking the properties, I see that these are:

  • TCP - all ports - for %systemroot%\system32\mqsvc.exe
  • UDP - all ports - for %systemroot%\system32\mqsvc.exe

so basically the firewall will allow any incoming traffic to the ports that MSMQ is listening on. This is OK for sending messages to the server but not for receiving them as that uses RPC and the End Point Mapper (EPM). Luckily, in the list of Inbound Rules is "Remote Administration (RPC-EPMAP)". Enabling this exception allows my application to query the EPM and so determine the port MSMQ is listening on for remote receive requests. There's no need to add any other ports as the first two exceptions have those covered already. 
 
 
Now all my messages can be pulled out of their queues remotely.
 
For more information on ports required by MSMQ, check here.

Latest version (1.5) of the logging script for MSMQ 3.0

Microsoft PSS might ask you to change the logging level of MSMQ (in Windows XP, 2003) when helping you troubleshoot a support case.

The script for this is in the appendix of the MSMQ FAQ but sometimes copy/pasting the lines to a text file generates formatting errors that stop it working.

So I've attached it to this post to make it more easily available (and I get to test posting attachments too).

Note - The binary MSMQLOG.BIN files that are generated by MSMQ cannot be formatted to readable text without the assistance of a Microsoft support engineer. Even then you won't necessarily be able to see the output as the logging information can contain insights into the inner workings of the MSMQ services so the engineer may not be at liberty to share it with you.

Sub Note to Note - Support engineers don't make the rules  :-)

 

Posted by JohnBrea | 0 Comments
Attachment(s): mqtrace.cmd

MSMQ now able to listen to multiple IP addresses on a cluster

In the past, a clustered MSMQ service could only listen on one IP address. This was because MSMQ depended on the network name which in turn could only depend on a single address.

In Windows 2008 the address dependency has been changed and now you can have multiple IP addresses:

Description of what to consider when you deploy Windows Server 2008 failover cluster nodes on different, routed subnets

"One of the new features that Windows Server 2008 failover clusters introduce is the ability to locate cluster nodes on different, routed subnets. Therefore, Client Access Point (CAP) configurations have cluster network name resources that depend on multiple IP address resources."

This will allow you to use one clustered MSMQ service to handle messages from different subnets where in the past you may have had to use multiple services in different resource groups, one per subnet.

MSMQ Diagnostics "Send test messages" and "Tracking" are greyed out

So you want to test out the routing of MSMQ messages through your enterprise?

Sounds simple enough - go to the Properties of the machine to be tested and choose the Diagnostics tab.

Strange, the options to send test messages and track routing are greyed out:

 

even though I seem to have everything you would need

  • Routing services installed? ü
  • Multiple sites? ü
  • One DC per site? ü
  • Site links?  ü
  • Send test message? û 

Eventually I found after following various links in the online documentation for these diagnostics tools that they are DISABLED in the registry by default!

For instructions on enabling these features, see Enable route tracking and test messages and set EnableReportMessages.

Posted by JohnBrea | 3 Comments
More Posts Next page »
 
Page view tracker