The MQSeries Adapter no longer retrieves messages from a clustered MQSeries queue manager when the queue manager fails over to a different cluster node

This article helps you work around the problem where MQSeries Adapter no longer retrieves messages from a clustered MQSeries queue manager when the queue manager fails over to a different cluster node.

Original product version:   BizTalk Server 2020, BizTalk Server 2016, BizTalk Server 2013, BizTalk Server 2010, BizTalk Server 2009
Original KB number:   893059

You configure the Microsoft BizTalk Server Adapter for MQSeries to receive messages from a clustered MQSeries queue manager. If the queue manager fails over to a different cluster node, the MQSeries Adapter no longer retrieves messages from the clustered queue. When this behavior occurs, the following event is logged in the Application log:

Event Type: Warning
Event Source: BizTalk Server 20xx
Event Category: BizTalk Server 20xx
Event ID: 5740
Date: 12/31/2006 Time: 11:12:13 AM
User: N/A
Computer:
Description: The adapter "MQSeries" raised an error message. Details "Error encountered on opening Queue Manager name = MYQMNAME Reason code = 2059.".

To work around this issue, create a scheduled task on both nodes. To do this, follow these steps:

1. On the active node, open Services.msc. You should see two MSDTC services listed: One that is local and has no GUID, and one that is clustered and has a GUID.

2. At an elevated command prompt, run the following command:

   sc queryex | find /I "Transaction"
   

   The command output contains the GUID that you must use for the script in this procedure. The GUID: Distributed Transaction Coordinator (01234567-89ab-cdef-0123-456789abcdef)

3. Save the following code to a file, and name the file Shutdownmqadapter.vbs. You can save the file to any disk other than the quorum disk.

   Note

   In this code, the indicated GUID (01234567-89ab-cdef-0123-456789abcdef) is a placeholder. Replace this GUID with the actual clustered MSDTC GUID that you noted in step 2.

   Option Explicit
   On Error Resume Next
   Dim sComputerName, oWMIService, colRunningServices, oService, colProcessList, objProcess 
   If Wscript.Arguments.Count = 0 Then  
     sComputerName = "."  
     Call ServStat  
     Wscript.Quit
   End If
   Sub ServStat
   Set oWMIService  = GetObject("winmgmts:" _  
     & "{impersonationLevel=impersonate}!\\" & sComputerName& "\root\cimv2")
   Set colRunningServices = oWMIService.ExecQuery _  
     ("Select * from Win32_Service where DisplayName='Distributed Transaction Coordinator (01234567-89ab-cdef-0123-456789abcdef)'")
   For Each oService in colRunningServices  
      'Wscript.Echo oService.DisplayName  & VbTab & oService.State  
      If (oService.State="Stopped") Then
         'Wscript.Echo "Stopped"
         'find the dllhost
          Set colProcessList = oWMIService.ExecQuery ("SELECT * FROM Win32_Process WHERE Name = 'DLLHOST.EXE'")
          For Each objProcess in colProcessList
            If inStr(objProcess.CommandLine, "C691D827-19A0-42E2-B5E8-2892401481F5")>0 Then
               'Wscript.Echo objProcess.ProcessId
               Dim objShell
               Set objShell = CreateObject("WScript.Shell")
               objShell.Run "cmd /k taskkill /F /PID " & objProcess.ProcessId & "& exit"
               WScript.Quit
            End If
          Next  
       End If
   Next
   End Sub
   

4. Select Start, type task, and then select Task Scheduler in the results list.

5. In Task Scheduler, select Action > Create Basic Task.

6. Run through the wizard screens to create a scheduled task that runs the Shutdownmqagent.vbs file daily.

Even if the IBM MQ queue manager is running as a clustered resource in a failover cluster role, you should not cluster the MQSAgent COM+ application. This is because DLLHost.exe, which is running the COM+ application, is not cluster-aware. You must have the MQSAgent COM+ application installed and configured individually on both nodes.
To ensure high availability, make sure that you use both the clustered IBM MQ queue manager resource and the clustered MSDTC resource in the same cluster role together with the monitoring script from the Workaround section.

• BizTalk Server 2020 Enterprise
• BizTalk Server 2016 Enterprise
• BizTalk Server 2013 R2 Enterprise
• BizTalk Server 2013 Enterprise
• BizTalk Server Enterprise 2010
• BizTalk Server 2009 Enterprise