MSMQ Set-Up

Some words of warning for those of you trying to install MSMQ for the first time.

After installing the PEC on one machine, it is definitely a good idea to read the section in the MSMQ Administrator’s Guide entitled ‘Permissions and Rights Required to Install MSMQ’. This covers who has rights to install Message Queue clients and servers and the SQL Server minimum install that is required to host the enterprise and site controllers.
Suppose, for example, that our Chicago office is setting up two MSMQ sites: One for Production and one for marketing. If one site contains the PEC and the other a PSC, then it should be noted that the PEC and PSC don't have to be in the same domain, but there has to be a trust relationship between the two. What happens is that applications trying to look at information on the PEC are doing so by attempting to establish an authenticated RPC connection to the PEC, which fails if the user in whose context the app is running is not trusted in the domain of the PEC. Incidentally, this restriction will likely be lifted with MSMQ 2.0 or perhaps even in NT Service Pack 4.

If you’ve got that, then here’s how I set up my Messaging System. For my PEC, I’ve chosen my machine dipsy, which is running Windows NT4 Enterprise Edition. I’ve specified the name of my enterprise to be OverTheHills, and my local site to be FarAway. By definition, dipsy is also the PSC for this site. I’ve added one connected network, called Windmill. I’ve also got one independent client called tinky-winky. Let’s take a look at this from the system administrator’s point of view.

The administration tool for MSMQ is called the MSMQ Explorer. At the time of writing, it hasn’t yet been incorporated into the Microsoft Management Console, but no doubt that will happen in time. If you start it up, you’ll see something like this:

If you look at my enterprise (OverTheHills), you can see the site (Faraway), containing the two hosts dipsy and tinky-winky. I’ve defined two queues for each of these: admin and smail. We’ll look at these queues in a little while, when we look at our first example.

You should also see three other queues: Dead Letter, Journal and Xact Dead Letter. These queues are set up automatically by MSMQ, and you can’t change any of their properties or delete them.

The Dead Letter queue is the place where messages go when they can’t be delivered. When you create a message, you have a number of choices about its lifetime. You can specify that it has infinite life — in other words, whatever happens to the enterprise, it will remain in the network until one way or other it manages to get delivered. Alternatively, you can specify that you’re only prepared to wait a specific period until either it reaches the target queue or is read. If this timeout (whose default is a staggering 90 days) expires, the message is put in a dead letter queue. The actual dead letter queue chosen is the one on the machine that the message had reached at the point when the timer expired. Depending on circumstances, this could be the machine that sent the message, the target machine, or a routing machine somewhere in between the two.

You can specify that a message is also copied to a Journal queue on your own machine when it is sent. This is a bit like the facility in most e-mail systems where you can keep a copy of everything you send out; you’ll notice a lot of e-mail analogies in MSMQ! We’ll look at the Transactional Dead Letter queue later on in the chapter when we see how MSMQ integrates with MTS.

I think we’re ready to try some MSMQ programming.