INFO: Using the MSMQ Service on a Windows 2000-Based Cluster (310775)

SUMMARY

If you install Microsoft Message Queuing 2.0 on a cluster, this does not automatically provide access to Active Directory even though the local nodes of the cluster are Active Directory servers. You cannot configure Active Directory to run on a cluster, only on the local nodes of the cluster. In a clustered environment, the Message Queuing service on the local nodes are set to manual startup. Because of Microsoft Distributed Transaction Coordinator (MSDTC) dependencies, you cannot set the local node Message Queuing service to automatic startup. MSDTC on a Windows 2000-based cluster is set up as a clustered resource and it cannot be online when a node of the cluster is started. Changing the properties of the local Message Queuing service to automatic can result in unpredictable issues.

There are various application configurations that may require the local node Message Queuing service to start automatically, such as:

Applications that run as a Microsoft Windows NT service that are not cluster-aware.
Applications that run on the local node.
Cluster resource dynamic link libraries (DLLs) that invoke Message Queuing services.
ASP pages, even when the Web server is running as a cluster resource.

This list is not comprehensive, but it is an example of the types of applications that run in the context of the local node, and that require the local Message Queuing service to be running to successfully use Message Queuing services.

MORE INFORMATION

A common method that is used to work around this issue is to add a batch file to the virtual group that hosts Message Queuing 2.0 and to make it a generic application that depends on the Message Queuing resource (the batch file runs the net start msmq command). However, you need to be aware that this batch file completes and exits the process and causes the generic application resource to have an offline status. Unless you set this resource to not affect the group, this can cause the group to fail between the nodes repeatedly. Even with this option set, this may still confuse users and monitoring software in particular. To make the confusion less of an issue, add something that is like a "sleep" implementation to the batch file so that it does not exit but idles and appears online to the cluster.

A better solution is to use a combination of the same batch file and Srvany.exe from the Windows Resource Kit. Configure a Windows NT service for an instance of Srvany.exe (use a manual startup type) that launches the batch file, and then configure a generic service on the cluster to start it, which allows the batch file to start and exit while Srvany stays active. Make the generic service dependent on the clustered Message Queuing service to satisfy the cluster service that the generic service is still online, even though the batch file exits. In either case, the local node service does not stop if the cluster resource is taken offline or if it fails over to the other node. If the local Message Queuing service is already running, the batch file command is ignored.