Share via

Troubleshooting the BizTalk MQSeries Adapter

  • Article

Recently, I came across a customer issue where they were trying to use the MQSeries Adapter to read messages from a MQSeries queue.
The MQSeries adapter has two parts: the adapter running under BizTalk Server and a COM+ application, MQSAgent, running under MQSeries Server.

Please note that this is not to be confused with the MQSC Adapter, which ships with the “BizTalk Adapters for Host Systems” (Host integration Server). More on that here - https://www.microsoft.com/en-us/download/details.aspx?id=23949

On to the issue now. While enabling the MQSeries receive location on Biztalk 2006 R2, we were getting this error - The adapter "MQSeries" raised an error message.
Details "Creating an instance of the COM component with CLSID {C34AE9CE-8410-4191-8205-900E08603EC2} from the IClassFactory failed due to the following error: 800706b9."
At the same time on the MQ server we noticed the below error:
A COM+ application hangs with an 'Access violation' in amqmtmgr.dll and a dump is produced showing:
amqmtmgr.dll!_FreeHConn() + 0xd5 bytes
amqmtmgr.dll!_tmzstMQDISC() + 0x17d bytes.

(Please note that the above error on the MQ Server may also indicate a known bug with IBM’s MQSeries Server. Ref - https://www-01.ibm.com/support/docview.wss?uid=swg1IC64203.
However, in this case, the reason for the error was something quite different! )

Now, there’s an article on MSDN about MQSeries adapter troubleshooting that talks of checking the following, one after the other (https://msdn.microsoft.com/en-us/library/aa547863.aspx)

1: Enable network COM+ access on the Microsoft Windows Server 2003 or Windows Server 2008 SP2-based computer
Enable network COM+ access on a Microsoft Windows Server 2003 or Windows Server 2008 SP2-based computer by following the steps documented in How to enable network COM+ access in Windows Server 2003.

2: Configure MSDTC settings
Follow the steps in the Set the appropriate MSDTC Security Configuration options on Windows Server 2008 SP2 section of https://msdn.microsoft.com/en-us/library/aa561924.aspx to configure MSDTC settings.

3: Verify that the host account is added to the role in the MQSAgent COM+ application
Verify that the host account for the MQSeries adapter is added to the role that was created in the MQSAgent COM+ application on the MQSeries server. You can verify this in the Component Services management console interface.

4: Verify that the host account for the MQSeries adapter is a member of the Distributed COM Users group
On a Windows Windows Server 2003 or Windows Server 2008 SP2-based server, examine the group memberships of the host account for the MQSeries adapter. Make sure that the account is a member of the Distributed COM Users group on the MQSeries server where the MQSAgent COM+ application is installed.

However, even after checking the above, we were still getting the error. And also nearing desperation!!!

We dug deeper into MSDTC permissions. To display the discretionary access control list (DACL) for MSDTC, from an elevated command prompt, we ran this (More on DACL here - https://msdn.microsoft.com/en-us/library/windows/desktop/aa446597%28v=vs.85%29.aspx) –
> Sc sdshow msdtc.

From the output of the above, we found out that Authenticated users didn’t have sufficient privileges on the MSDTC service.

To fix this, we ran this from the above prompt–
> sc sdset msdtc
D:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA) (A;;GRCR;;;AU)
(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCLCSWRPLORC;;;NS)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)
The security descriptor, as displayed by scsdshow, is formatted according to the Security Descriptor Definition Language (SDDL). Each section, inside the parenthesis, represents a specific entry(security/auditing). Inside the parenthesis, the user account and the correct
permissions are specified.
Each bracketed segment above represents the permission set for that service for a particular Windows security principal/well-known alias. The last two letters in each parenthesis define the security principal assigned with these permissions (a SID or well-known alias). The parenthesis in bold above represents the permission set for the “Authenticated Users” group (AU).

We needed to fix the permission set for the Authenticated Users group (indicated by AU) in the above command. The bracketed part in bold above, prior to running the above command was (A;;CR;;;AU) . The first ‘A’ means allow access. CR stands for SERVICE_USER_DEFINED_CONTROL - send a service control defined by the service's authors.

So, we needed to add GR to (A;;CR;;;AU), which means the new group looks like - (A;;GRCR;;;AU) . This adds the GENERIC_READ access right for Authenticated Users for the MSDTC service. After running the above command, if you do a Sc sdshow msdtc now, the output for Authenticated Users would look like – (A;;CCLCSWLOCRRC;;;AU). Reason?

You can see in the new output that ‘GR’ is replaced with ‘CCLCSWLORC’. This is because GENERIC_READ for a service is:

  • READ_CONTROL (RC)
  • SERVICE_QUERY_CONFIG or Query service configuration information (CC)
  • SERVICE_QUERY_STATUS or Query status of service (LC)
  • SERVICE_INTERROGATE or Query information from service (LO)
  • SERVICE_ENUMERATE_DEPENDENTS or Enumerate dependencies of service (SW)

This will ensure the user has the GENERIC_READ access right to MSDTC. Following this, a restart of the MSDTC service should do the trick!

Detailed information on setting MSDTC permissions can be found here –https://blogs.msdn.com/b/distributedservices/archive/2009/03/13/troubleshooting-msdtc-permission-issues-when-a-distributed-transaction-starts.aspx

 

Written by
Arindam Paul Roy

Reviewed by
Jainath V R

Microsoft India GTSC