Win 2003 High Availability Solutions, Message Queuing Page 2

To manage a clustered instance of MSMQ with Active Directory Users and Computers, you must ensure its Network Name resource has the “Enable Kerberos Authentication” setting (on the Parameters tab of its Properties dialog box) turned on. This will not only automatically create a computer account representing the virtual server in Active Directory, but it will also generate its msmq subnode as soon as the MSMQ resource is brought online. Although the Cluster Service automatically handles these activities, by default, its account is allowed (by virtue of having the right to “Add workstations to domain,” just like any regular domain user) to repeat them only 10 times. To eliminate this restriction, the account must be granted the privilege to “Create Computer Objects” as well as posses sufficient permissions in the Active Directory container where new objects are placed.

If you intend to implement an MSMQ Triggers component, start by installing it using the Add or Remove Programs Control Panel applet (described earlier) on every cluster node. Once this initial step is completed, the MSMQ Triggers resource type will automatically appear as a new resource type in the list of options of New Resource wizard. Launch the wizard within the context of the cluster group that hosts previously created MSMQ resource, select it from the list, and specify its name. Complete the creation by choosing the same possible owners as before and its dependencies, which include the MSMQ resource and its associated Network Name. This arrangement ensures that triggers will continue providing services to the MSMQ component running on the virtual server following a failover.

Unlike with the MSDTC, which is limited to a single instance per cluster, it is possible to have multiple, simultaneously running independent MSMQ resources on the same cluster. Each of them should reside in a separate group; however, if you decide to introduce such an arrangement, you might need to adjust the memory management mechanism on each node (to avoid problems described in the MS Knowledge Base article 940960), by increasing the system view space memory pool size (designating kernel memory dedicated for message queuing support). This involves creating SystemViewSize entry of DWORD data type under the

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerMemory Management

registry key, with the value derived by adding 16 (representing the default pool size of 16 MB) to the outcome of multiplying 4 (equivalent to 4 MB of the memory pool required by each MSMQ instance) by the total number of MSMQ cluster resources.

When working with MSMQ clustered resource, the same general principles that apply to its standard, non-virtual equivalent must be followed. For example, you can use the MSMQ node in our Generic Application-based Computer Management console to interact with existing system and application queues, create new public and private ones (referenced using the NetworkNameQueueName and NetworkNameprivate$QueueName notation, respectively), examine their content, and configure such parameters as routing or security.

This concludes our overview of various resource types available in Windows Server 2003 based clustering implementations. Next, we will discuss generic properties of cluster groups and their resources, which have significant impact on failover or failback behavior.