MSMQ 1.0

Building on my ‘has anyone ever used’ this feature of the NT 4.0 option pack‘, I thought it’d be interesting to build a simple MSMQ deployment.  MSMQ is another technology I never saw deployed, as everyone was instead far more interested in MTS.  So I thought I’d take a stab at MSMQ.

The only deployment guide I can find is here.

And I have to say, that it looks and feels a *LOT* of what became Active Directory.

So let’s look at a few things through the guide.

Top features of MSMQ are:

  • Connectionless messaging. With store-and-forward message queuing, applications are not affected by network fluctuations and do not have to establish sessions. Because MSMQ uses a sessionless model at the application level, the sender and receiver do not need to support the same protocol. MSMQ supports Internet Protocol (IP) and Internet Packet eXchange (IPX).
  • Network traffic prioritization. Message prioritization allows urgent or important traffic to preempt less important traffic so you can guarantee adequate response time for critical applications at the expense of less important applications.
  • Guaranteed delivery. Messages can be logged to a disk-based queue to provide guaranteed delivery.

Which for 1997 technology sounds pretty great!  But obviously what is the cost?  To deploy MSMQ you *NEED* the following:

  • Install a PEC (Primary Enterprise Controller).
  • Install a PSC (Primary Site Controller) at each additional site
  • Define site links and costs
  • Install MSMQ dependent clients and independent clients

Optionally you can install for greater redundancy and speed..

  • Install a BSC (Backup Site Controller) at each site, if required
  • Install MSMQ routing servers, if required
  • Install the connectors and transports, if required

As you may guess MSMQ needs a server infrastructure of it’s own.  I thought for my limited experiment, I would use a simple two site network, comprising of a Windows NT 4.0 PDC, a Windows NT 4.0 BDC and two Windows NT 4.0 workstations.

As MSMQ stores it’s topology database in SQL Server 6.5 service pack 3, I found out the hard way that It will not install correctly with SQL Server 7.  Nor will it work with sp1, and it’ll bomb with 2.  It must be SP3.  I’ve also found it works best with the ‘restricted’ cut down version specifically for MSMQ.  Which is on CD2 of the Enterprise edition of Windows NT 4.0 (I stuck a copy here).  Basically it’s 6.5 slip-streamed to SP3, with no books (don’t’ try to install the books!).  However I found it works best on the PDC, and installing it on a BDC you should set the SQL services to login as local system for the installation, then set them for a domain account.  I also had to change the security model to “Windows NT Integrated”.  I’m not sure if that is 100% a requirement, but the installer demanded it.

xx

Setting SQL’s security to Integrated mode

With that out of the way, I ran setup from the option pack, selecting MSMQ.

Select MSMQ

Select MSMQ

And the install proceeds as normal installing the base components of IIS 4.0.

Select a MSMQ type

Select a MSMQ type

Then we get to decide what kind of Server this Server will become.  The first server I installed this on was the PDC, so I made it the PEC.  It installed without any further incident.

I installed the option pack on the BDC, which was located in a different network, and set it up as the PSC.  I then installed the workstation option pack on both of my workstations making them independent clients, and assigning them to their closest PEC/PSC.

MSMQ Enterprise

MSMQ Enterprise

As you can see the Enterprise view of MSMQ looks a LOT like the AD Sites and Computers view.  No doubt MSMQ was on the way to Cairo.. Although I’ve always thought Exchange would have been better served by SQL, having directory services being hosted on SQL would have made life a bit easier for doing backups and restores, making it less of a black box.  However the prospect of managing all those SQL servers.. I guess there is always trade offs.

MSMQ in action

MSMQ in action

This is a small ‘demo’ application where MSMQ can pass messages between a shared paintbrush application.  Very cool stuff.  And no doubt a missed opportunity to run something fun and subversive.  Although I was always the network admin so I never had to hide my traffic.

I’ve setup MSMQ in 2000 & 2003 networks, and it is not only far more simpler to deploy, but it relies on Active Directory to figure out it’s topology, and nominated MSMQ servers to forward traffic between sites.  I’m more surprised that AD doesn’t rely on MSMQ, but rather it seems it uses common technology.

This entry was posted in Windows NT 4.0 by neozeed. Bookmark the permalink.
avatar

About neozeed

What is there to tell? I’ve loved UNIX like things since I was first exposed to QNX in highschool (we had the Unisys ICONS!), and spent the better time of my teenage years trying to get my own UNIX… I should have bought Coherent in retrospect.. Anyways latched onto Linux in 1992, and then got some old BSD admin books and have been hooked on the VAX BSD & other big/ancient things since…!

7 thoughts on “MSMQ 1.0

  1. There was at least one commercial grade application of MSMQ over the Internet. An organization called Critical Reach used it for their alert messaging system.

    Deployment on end user machines was a PITA. Installing the MSMQ client required quite a bit of fiddling with firewalls, and the client machine needed SQL Server installed to handle the message store! A great way to slow a system down to a crawl!

    It worked great once it was setup though.

    • The independent clients in 1.0 can just log to disk, although the local site and enterprise servers need SQL. The SQL requirement was removed in 2.0 and higher, and 3.0 should work with HTTP (no doubt another RCP over HTTP, much like the killer feature of Exchange 2003).

      Alert messaging is a good fit for MSMQ, as I’m amazed people rely on 1970’s syslog.. Especially people that have absolutely insane volumes of syslog messages in their network.

  2. now that I think about it, this would have been perfect for SQLite!

    and you should really write about Cairo and the what the hell it would have been-ness of it!

    • well sqlilte didn’t exist back in 1997… And Watcom’s SQL offering eventually became the reason why Powersoft/Sybase bought them out, and killed off the excellent C/Fortran compilers.

      The rise and fall of Watcom alone is pretty sad. Not to mention it’s impossible to find Watcom Basic for the mainframe (or it’s other languages) or any of the other non PC stuff they did.

      Oh and I recently came across some NT 5.0 beta’s so I probably will do something about Cairo…

      • they sure had access… and the jet red/blue thing was happening at that time wasn’t it jet red with exchange 4, and jet blue with exchange 5 onwards? I really forget now. No doubt further investigation is needed.

Leave a Reply

Your email address will not be published.

Notify me of followup comments via e-mail. You can also subscribe without commenting.