Microsoft KB Archive/820985

= You cannot access Message Queuing from a clustered instance of IIS =

Article ID: 820985

Article Last Modified on 2/9/2006

-

APPLIES TO


 * Microsoft Message Queuing 2.0
 * Microsoft Message Queuing 3.0

-



SYMPTOMS
If you try to access Message Queuing from a Web application that is running on a clustered instance of Internet Information Services (IIS), you may receive one of the following error messages:

The Message Queuing service is not available

-or-

MQ_ERROR_SERVICE_NOT_AVAILABLE

-or-

0xc00e000b

You do not receive an error message if you try to access Message Queuing from an IIS server that is not part of a cluster.



CAUSE
This problem occurs because the clustered Web application runs on the local node, while the clustered Message Queuing service runs on the virtual cluster server, not on the local node. Although Message Queuing and IIS are both cluster-aware, they are clustered in different ways. A clustered instance of IIS runs locally on the active node in the cluster, while a clustered instance of Message Queuing runs on the virtual cluster server. The virtual cluster server behaves as a distinct physical server that is completely separate from any of the cluster nodes. Because Message Queuing must be running on any computers that have applications that access Message Queuing, you receive an error message from clustered Web applications unless the local Message Queuing service is started.



WORKAROUND
To work around this problem, start the local Message Queuing service on each of the cluster nodes. Before you do so, carefully consider the following limitations:  Because of Microsoft Distributed Transaction service (MSDTC) dependencies, the local Message Queuing service does not start automatically on a cluster node, and you cannot set it to automatic startup. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

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

 Your applications use the local node's service to access Message Queuing. The local node sees the cluster as a remote computer. Because of this, you cannot perform any Message Queuing-related operations that must be done locally. For example, you cannot create new clustered private queues or perform transactional remote reads of clustered queues. This configuration may result in behavior that is not expected when the cluster fails over. For example, the Web application uses the local node's outgoing queues to store messages when the destination is not immediately available. If the local node crashes and causes a failover, the messages in the outgoing queues are not sent because they are stored only on the local node. If you use the local node services, it can cause serious problems with transactional messages because in-order and exactly-once deliveries occur on a per service basis. Because each node runs its own separate Message Queuing service, transactional messaging may not work as expected after a failover occurs.

Because of these limitations, view this workaround as a temporary solution.



RESOLUTION
To resolve this problem, run IIS on a computer that is outside the cluster. Generally, Microsoft does not recommend clustering IIS. Microsoft recommends Network Load Balancing as the preferred high-availability solution for IIS.

If you cannot run IIS outside the cluster, you must configure your Web applications to run on the virtual cluster server instead of on the local node. This configuration removes any dependencies on the local node service and provides the full functionality of Message Queuing, even after a failover occurs.

To configure ASP pages to run on a virtual cluster server, follow these steps:  Open the Internet Services Manager, and then locate the directory or Web site that contains the ASP pages that access Message Queuing.</li> Right-click the directory or Web site, and then click Properties.</li> Click the Directory tab. An application name should be listed under Application Settings. If not, click Create to create a new application.</li> Under Application Protection, click High (isolated), click OK, and then close the Internet Services Manager.</li> To replicate the configuration changes to the other nodes in the cluster, run Iissync.exe. For additional information about Iissync.exe, click the following article number to view the article in the Microsoft Knowledge Base:

249603 Using IISSYNC to Synchronize Clustered Web Sites on Windows 2000 Advanced Server

</li> In Control Panel, double-click Administrative Tools, and then double-click Component Services.</li> Expand Component Services, expand Computers, expand My Computer, and then expand COM+ Applications.</li> Locate the COM+ application that corresponds to your Web application in IIS.

The COM+ application's name begins with IIS and contains the path of the directory for your Web application.</li> Right-click the COM+ application, and then click Properties.</li> Note the Application ID that is listed on the General tab, click OK, and then close Component Services.</li> Open Cluster Administrator.</li> Right-click the group that contains your clustered Message Queuing resource, point to New, and then click Resource.</li> In the New Resource Wizard, enter a name and description for the application.</li> In the Resource Type list, click Generic Application, and then click Next.</li> Select all the nodes that you want to run the application, and then click Next.

Note You will typically select all the nodes in your cluster.</li> Add the network name resource that Message Queuing depends on, and then click Next.</li> Type the following command line (where  is the application ID of the COM+ application that you noted in step 10), including the braces:

dllhost.exe /ProcessID:{ } </li> <li>Type C:\Winnt\System32 as the current directory, click the Use Network Name for computer name option, and then click Next.</li> <li>Click Finish.</li> <li>Restart IIS, and then use Cluster Administrator to bring the newly configured resource online.

The ASP pages that run inside that COM+ application now run on the virtual cluster server instead of on the local node.</li> <li>Repeat this process for any other Web applications that must access Message Queuing.</li></ol>

This process does not work for Microsoft ASP.NET applications. ASP.NET pages run inside the ASP.NET worker process (Aspnet_wp.exe), not inside COM+ applications, regardless of the application protection settings in IIS. There is no way to configure the ASP.NET worker process to run on the virtual cluster server. Instead, you must create a Component Object Model (COM) component that provides access to Message Queuing. Your ASP.NET pages should call this COM component instead of directly accessing Message Queuing. You can create a COM+ application to host this COM component, and then cluster the COM+ application by using the previous procedure. You must also install the COM+ application on all the computers in the cluster. For additional information about how to install the COM+ application, click the following article number to view the article in the Microsoft Knowledge Base:

271844 HOWTO: Set Up a COM+ Application on a Cluster Server

After you cluster the COM+ application, it runs on the virtual cluster server, and your ASP.NET pages can use it to run Message Queuing without relying on the local node service. This method also resolves problems with accessing Message Queuing from Internet Server API (ISAPI) filters and extensions and from Common Gateway Interface (CGI) applications that run in clustered instances of IIS.

If all your cluster nodes are running Microsoft Windows Server 2003 and you have a non-cluster computer running Message Queuing 3.0, you can configure the local cluster nodes to use Message Queuing over DCOM. Message Queuing over DCOM permits the cluster nodes to activate the Message Queuing COM component on a remote computer, instead of locally. You can then run Message Queuing-enabled applications, including ASP and ASP.NET pages, on the local cluster node without starting the local Message Queuing service. For more information about how to configure Message Queuing over DCOM, visit the following Microsoft Web site:

http://www.microsoft.com/windowsserver2003/technologies/msmq/default.mspx

<div class="status_section">

STATUS
This behavior is by design.

<div class="references_section">