MQSeries adapter with BizTalk 2016 and MQ 8.0 RRS feed

  • Question

  • Hi,

    Has anybody had success using server side MQ adapter with BizTalk 2016 and MQ 8? MQ 8 is 64bit product and MQSAgent2 is 32bit. I receive access  violation from the COM+ component.



    Thursday, January 5, 2017 8:28 AM

All replies

  • Hi Antti

    It would be preferred to use the MQSC adapter (you need to install this from the HIS installer that ships with BizTalk) to connect - this bypasses the need for the COM+ component.

    Note that you need to install the correct version of MQClient on BizTalk server for the MQSC adapter to work correctly.


    Thanks Arindam

    Thursday, January 5, 2017 9:28 AM
  • Hi,

    Has anybody had success using server side MQ adapter with BizTalk 2016 and MQ 8? MQ 8 is 64bit product and MQSAgent2 is 32bit. I receive access  violation from the COM+ component.



    The MQSAgent COM+ application is supported on a 64-bit Windows server. It will run as a 32-bit process under WOW64. A BizTalk Server-based computer that is running on a 64-bit version of Windows Server can communicate with a remote 32-bit computer that has the MQSAgent installed.

    For troubleshooting the access violation from the COM+ component error please refer the below articles:

    Known Issues with the MQSeries Adapter

    Troubleshooting the BizTalk MQSeries Adapter

    BizTalk Server: Integration With MQ Series

    The MQSeries adapter uses MSDTC for transactions so it is absolute necessary to check below things before starting:

    1) Ensure MQSAgent is installed on MQ Server; make sure to use the correct version of BizTalk Setup.

    2) 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.

    3)  Make sure below are installed on the windows machine.

    4) Ensure Firewall are not blocking RPC ports.
    5) Enable support for XA transactions.

    Rachit Sikroria (Microsoft Azure MVP)

    Friday, January 6, 2017 2:50 AM
  • Hi,

    All those references are unfortunately targeting older versions of OS and BizTalk. Unfortunately there are no up to date documentation - at least I could not find any.

    I have had success with BizTalk 2010 and MQ 7.0 but a lot has changed from those days.

    Here is a couple of observation with BizTalk 2016 and MQ 8.0.5.

    1. Server side adapter fails after message has successfully been delivered to MQ. But if transactions are enabled it does not work at all.

    2. Client side adapter works but not with IBM client if transactions are enabled. However Microsoft MQ client works.

    To me it seems that adapter does not recognize that IBM client supports transactions and tries to communicate with a non-existent extended client. 

    There is no documentation about Microsoft client. Does it support multi-instance queue managers?

    Finally is it the idea to use  affiliate application to have some basic security with MQ. What is the impact on performance with up to 500 msgs/second if each has sso ticket set? 



    Saturday, January 7, 2017 3:30 PM
  • Hello,

    With BizTalk 2016 you can install HIS 2016.

    Then you have to ways to connect to IBM MQ Server :

    1. Using the MQSC Adapter together with the IBM MQ Client (I recommend

    2. Using the MQSC Adapter together with the new Microsoft MQ Client (HIS 2016).

    Both support XA - Transactions (DTC must be configured).

    The Microsoft MQ Client was in my tests 4 times faster than the IBM MQ Client.

    Best regards,

    Steve Melan - BCEE My Blog :

    Monday, January 9, 2017 8:14 PM
  • Hi,

    So basically server side adapter is dead???

    I am using HIS 2016.
    I could not make IBM client to work with transactions.
    Microsoft client does.

    Have you used multi-instance Queue Managers to achieve HA - or server clustering?
    We would prefer former but need guidance how to configure BizTalk send ports and receive locations.


    Tuesday, January 10, 2017 11:49 AM
  • Hi, 

    From my point of view, the server side adapter should be avoided.

    What are your issues ? 

    I have a multi-instance Queue Manager defined. As far as I remember, please check the GROUPUR Flag on the MQ Server. Check if the Windows DTC and XA (in DTC) is activated.

    What is the MQRC code you're getting ?

    Best regards,

    Steve Melan - BCEE My Blog :

    Thursday, January 12, 2017 9:22 PM
  • Hi,

    Actually it starts with how to configure a send port:

    I suppose Connection name is where you somehow specify that MQ has multi-instance queue manager configuration. To survive failover we need to know server1 and server2. I would be grateful if you could provide me a sample binding file.


    Friday, January 13, 2017 12:02 PM
  • Hi,

    Transaction Support = Yes

    Channel Name = The Channel Name that you have defined in the MQ Server

    Connection Name = IP ADDRESS or NETWORK NAME of the MQ Server --> MQT(1234)  --> NETWORK_NAME(PORT)

    Queue = The Queue to which you want to send your message

    Queue Manager = The name of the remote Queue Manager (Defined in the MQ Server)

    These parameters should be enough to get it working...

    Best regards,

    Steve Melan - BCEE My Blog :

    Friday, January 13, 2017 12:43 PM
  • Hi,

    That would only work with normal or clustered queue manager (where the address is static). I am referring to multi-instance queue manager.

    Client should be ready to switch automatically from instance1 to instance2 when there is a failover.


    Friday, January 13, 2017 2:39 PM
  • Steve, why do you recommend avoiding the MQSeries adapter?

    Thanks in advance,


    Friday, January 20, 2017 7:46 AM
  • Erik,

    • Does not require MQ Server to be on Windows Platform 
    • Uses IBM Client MQI API or the new Microsoft HIS MQ Client
    • Provides direct access to non-Windows MQM (Queue Manager) 
    • Free transactional and non-transactional client (Base)

    Best regards,

    Steve Melan - BCEE My Blog :

    Saturday, January 21, 2017 9:50 PM
  • Those reasons are not compelling to me. Server side adapter supports transactions too and if you have MQ on Windows server it should be ok to use server side adapter.

    The fact that it has always been very complicated to setup and has always been very fragile let's me think that it should not be used.


    Wednesday, January 25, 2017 7:19 AM
  • There were several obstacles but finally we have a working setup.

    1. XA support requires regedit to introduce 32 bit MQ dlls.

    2. MSDTC must be run using account that has access to MQ

    3. Path must be changed so that MQSAgent will use dlls compiled with earlier version of c++ compiler.

    There might be other things to consider but these are the new ones to me and apply for  MQ 8.0.5 and BizTalk 2016 CU1.


    Tuesday, February 14, 2017 8:31 AM
  • That's good to hear that you have a working setup now :-)

    Have you any issues where you need some additional support ?

    Steve Melan - BCEE My Blog :

    Tuesday, February 14, 2017 8:55 AM
  • Nice to hear it got resolved. Here is similar issue and explanation of how to configure.

    In short:

    - Use latest IBM fix pack for v8 so you get C++ 2005 compatible libraries (they were not in original v8 release)

    - Change path to include the C++ 2005 IBM MQ DLLs:

    • 32-bit applications: SET PATH=<IBM MQ install folder>\bin\vs2005
    • ( 64-bit applications: SET PATH=<IBM MQ install folder>\bin64\vs2005 )

    MQSAgent2 COM+ DLLHost is 32-bit application so set path to 32-bit above and before any other IBM paths so this is picked up first before the other incompatible C++ 2012 DLLs.

    If using BizTalk 2016 CU2 or later you should not add (remove) the extra Path setting as it should work without this. Send may fail if path is there (BizTalk: 0x800706BE, MQ: 0xc0000005)

    For MSDTC transactions to work add com+ network feature and exclusions for com+ in firewall. In Windows 2016 ensure that RemoteAccessEnabled is set to 1 (instead of feature): 


    reg add HKLM\SOFTWARE\Microsoft\COM3 /v RemoteAccessEnabled /t REG_DWORD /d 1 /f


    Add BizTalk and MQ computer accounts and BizTalk/MQSAgent service account to "Distributed com users" local groups on BizTalk and MQ servers. You may also have to add user account to local mqm group (and domain mqm group) on MQ server.

    Alternatively as mentioned you can specify a custom account in MSDTC settings, but this may not be an account that is allowed to be used against other transaction coordinators (BizTalk SQL, WCF-SQL, WCF-Oracle, MSMQ etc) so better to keep Network Service. 

    Monday, February 20, 2017 7:41 AM
  • Hello,

    We had exactly your problem with BizTalk 2016 and MQ 8. 

    The problem is related to HIS 2016 or HIS 2013 for BizTalk 2013.

    You need to install CU1 for HIS 2016 or CU3 for HIS 2013 - that will fix your access violation problem.

    • Proposed as answer by Richer M Friday, February 24, 2017 8:32 PM
    Friday, February 24, 2017 8:32 PM
  • To connect to a multi-instance queue manager using MQSC you should enter the addresses of the queue managers in the Connection Name property separated by commas like;,

    Unfortunately, this causes the Application Event Log to receive a lot of errors with WebSphere MQ as event source.

    The above information is for BizTalk 2010 and HIS 2010 using MQ Client 7.0.x. However, I am not aware of any differences in the newer versions of these products.

    Tuesday, March 7, 2017 3:08 PM
  • Although the above sounds promising, it does not even allow me to connect to MQ.

    The adapter "MQSC" raised an error message. Details "Invalid format for ConnectionName:,".

    After this error message is not suspended but remains active.


    Saturday, April 29, 2017 2:31 PM
  • Hello,

    Just use one connection for the ConnectionName


    This should work. Either use a NLB (Network Load Balancer) or create a GROUP Cluster for the MQ Server.

    Best regards,

    Steve Melan - BCEE My Blog :

    Sunday, May 7, 2017 8:59 PM
  • Hi Steve,

    Does this mean the official line is that the MQSC Adapter does not support multi-instance queue managers by specifying comma-delimited server(port) entries in the ConnectionName property? If this is the case do you know if this is a feature which will be supported in the future?



    Friday, September 29, 2017 10:38 AM
  • The IBM Client uses parenthesis to specify the Port.  Meaning, it's not a comma issue.
    Friday, September 29, 2017 2:05 PM
  • Hi,

    I'm afraid you may have misconstrued my question Johns-305.

    I want official confirmation that I can specify the ConnectionName on the MQSC Adapter configuration properties to be a value like, as the client should support this for multi-instance queue managers.



    Wednesday, October 4, 2017 11:00 AM
  • It used to work in earlier HIS/MQSC versions, but currently there is an issue in parsing of this comma separated multi-instance queue manager connection string so it doesn't work in latest HIS 2016 version, but we are working on trying to fix this for upcoming HIS 2016 CU. You can contact me (niklase) at ms domain for more details. 

    Update: Please test with HIS 2016 CU2 which is released now for Multi-Instance Queue Manager. 

    Wednesday, October 4, 2017 11:59 AM
  • Ah, got it.  No, sorry.  Never has. :(

    You can ask the WMQ team if MI-QM is the only failover option they support.

    Thursday, October 5, 2017 4:35 PM