Microsoft KB Archive/237431

{|
 * width="100%"|

INFO: MSMQ Site Controller Availability and MSCS

 * }

Q237431

-

The information in this article applies to:


 * Microsoft Windows NT Server version 4.0
 * Microsoft Windows NT Workstation version 4.0
 * Microsoft Cluster Server
 * Microsoft Message Queue Server (MSMQ) version 1.0

-

SUMMARY
In many cases, installing a Microsoft Message Queue (MSMQ) Site Controller on a Cluster is not the optimal solution for providing High Availability for MSMQ applications. Instead, installing an Independent Client (IC) or a Routing Server (RS) may be better for a number of reasons.

MORE INFORMATION
NOTE: For the purpose of this article a Primary Site Controller (PSC) can also be read to mean a Primary Enterprise Controller (PEC). A Site Controller (SC) is a PEC, PSC, or a Backup Site Controller (BSC).

It may be a better idea to install either an Independent Client or a Routing Server on a Cluster rather than a Site Controller. The following list are the four main reasons for this.

 PSC/BSC combination on stand-alone computers provide inherent redundancy and higher availability than a clustered PSC. If a PSC fails the BSC takes over within seconds as the MSMQ service, because it is running concurrently on the two stand-alone computers. If a PSC fails on a cluster the fail over may take a few minutes or longer to complete. The fail over time will take longer than an IC or RS fail over because of the MSMQ dependency on Microsoft SQL Server (MSMQ 1.0 is limited to an Active/Passive mode). The PSC will be blocked from going online while the Microsoft SQL Server goes offline on the first node and comes back online on the second node. Startup time for all flavors of MSMQ, clustered or not, will be effected by the number of remaining messages in the queues as all of these messages will need to be processed upon startup.  There is little to be gained in functionality. A PSC primarily performs three tasks that an IC or RS cannot perform:

 Client installation (requires a PEC or a PSC). MQIS object lookups (queue lookups, queue enumeration, computer permissions, etc.). Sending using a direct format name and modifying private queues are two actions that don't require MQIS access. MQIS object modification (queue creation/deletion, setting computer permissions, and so forth.). Only a PEC or a PSC can modify the MQIS database.

Of these, high availability typically isn't a requirement for installation clients. The other two points involve accessing the MQIS database. If the application is written for offline operations then these two issues can be avoided. For additional information about on how to write applications for offline operations, please click the article number below to view the article in the Microsoft Knowledge Base: "Q172688 INFO: Writing an MSMQ Application for Offline Operation" A BSC can perform MQIS object lookups in the case of a PSC failure.  Installing a Site Controller is more involved and has a greater chance of failure on a cluster. Microsoft SQL Server 6.5 (either the retail Enterprise Edition or the Limited version that is located on the Component CD under \MSMQ\MSMQ\SQL) must be installed and clustered with the Limited SQL Server Wizard that ships with MSMQ on the Component CD (under \MSMQ\sql.wiz). This wizard clusters SQL Server as "local" which means that it will be limited to Active and Passive mode. In this scenario, there are more dependencies between the cluster resources and more things that could break or fail and thus your MSMQ service is more at risk of a failure. There is a design limitation between MSMQ and Microsoft SQL Server 7.0. The design limitation is that Microsoft SQL Server 7.0 cannot be used to host the MQIS database for MSMQ Site Controllers in an MSCS Cluster. This limits the upgrade options on a Cluster with an MSMQ Site Controller. This limitation is only present on MSCS Clusters with MSMQ 1.0 Site Controllers.</li></ol>