BizTalk group fails to run properly after restricting the SQL Server to use TLS 1.2 RRS feed

  • Question

  • Hi,

    I have an installation for BizTalk 2013, deployed over 2 servers, an Application and SQL server. The application server as been configured for a while now to accept HTTPS traffic using TLS 1.2 only and that's been working fine.

    It's now been decided that all the "internal" servers should also be configured to disable SSL 2.0, SSL 3.0 and TLS 1.0, regardless of whether their applications are making use of encryption or not. So this has been done to the SQL Server and where the issues start.

    Both the application server and SQL Server have had their SQL Server components patched to 11.0.6579 / 11.3.6579 so both support TLS 1.2 with SQL Server 2012. When the SQL Server is configured to only use TLS 1.2 it's possible to run SQLCMD on the application server to connect to the SQL Server. However BizTalk won't run correctly and when using the Admin console to view the Group to get a database connection error complaining about the SSL certificate. We aren't encrypting the traffic to the SQL Server (Force encryption isn't turned on for the SQL Server).

    When the SQL Server allows the old encryption protocols and BizTalk is running correctly I can see that some of the BizTalk connections to the BizTalkMgmtDb and BizTalkMsgBoxDb with an old protocol version. (1895825409 or 0x7100000, depending on how you want to view it). The commands over these connections include:

    • BizTalkMgmtDb.dbo.adm_ApplicationInstance_get_details;1
    • BizTalkMgmtDb.dbo.admsvr_ReceiveLocation_GetAllInApp;1

    Has anyone any experience of configuring their SQL Server to only use TLS 1.2 when it's part of the BizTalk group.

    Do they recognise the component / subsystem of BizTalk that would issue these commands, and have an idea on how to control with SQL driver / protocol it uses?

    Thanks in advance.

    Thursday, July 20, 2017 9:50 AM

All replies

  • Contact MS support as of now it's officially unsupported but you might get it to work through some registry hacks

    Check this thread in the BizTalk general forum

    hth /Peter

    Thursday, July 20, 2017 10:01 AM
  • First, try installing/updating the full SQL Client on the BizTalk computers, including ones used for BT Admin only.

    Next, this is why these somewhere arbitrary global decisions are always a headache.  Realize, you may have to get an 'exemption' from the TLS 1.2 'requirement'.

    Finally, this isn't really a problem with BizTalk Server.  All the TLS goop is handled by Windows and communications with the database are through a combination of Windows and the SQL Client. Is Windows also fully patched?

    Thursday, July 20, 2017 1:09 PM
  • Hi,

    The OS on all machines is fully up to date. Have installed the SSMS / SQL Client on the BizTalk application servers, but I can see that the MDAC / WDAC SQL Driver is still being used by some component of BizTalk, which is the root of the problem. This SQL driver is effectively the SQL Server 2000 driver, which won't support TLS 1.2.

    I think this is going to be a non-starter and will have to request an exception.

    Tuesday, July 25, 2017 9:01 AM
  • Interesting...something new.

    I suggest you either report it as a 'bug' or create a BizTalk User Voice item for this. I'm actually surprised this hasn't come up before.

    Tuesday, July 25, 2017 1:49 PM
  • We've just hit this problem. Any word on if this dependency on TLS 1.0 can be removed from BizTalk 2016?
    Monday, October 30, 2017 3:48 PM
  • No word as yet that I've seen.

    Feel free to vote for it on User Voice

    Update the configuration tooling to support TLS 1.2


    BizTalk adapters should be able either negotiate higher version of TLS or be configurable

    @Johns-305, it has come up before, but for BizTalk 2013, see  Does BizTalk Server 2013 support TLS1.2

    And on Stack Overflow BizTalk 2016 Administrator fails with forced tls1.1+

    Monday, October 30, 2017 6:18 PM