locked
MSDTC error RRS feed

  • Question

  • Hi,

    A host instance in our BizTalk environment is failing and the send port that it serves is using wcf-custom adapter.

    Even when I try to create a new send port and try to configure a wcf-custom adapter, I get the following error:

    ===================================

    The Microsoft Distributed Transaction Coordinator (MSDTC) may not be configured correctly. Ensure that the MSDTC service is running and DTC network access is allowed on the BizTalk, SQL and SSO Master servers. For more information, see "MSDTC Configuration settings required for BizTalk Server" in the BizTalk Server Help.

    Internal error: "Connection failure" (WinMgmt)

    ------------------------------
    Program Location:

       at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
       at System.Management.ManagementObjectSearcher.Get()
       at Microsoft.BizTalk.SnapIn.Framework.WmiProvider.SelectWhere(String className, String condition)
       at Microsoft.BizTalk.SnapIn.Framework.WmiProvider.SelectRemote(String className, String whereClause)
       at Microsoft.BizTalk.Administration.SnapIn.Forms.SendPort.General.getHandlerProperty(IProtocolType2 protocolType, ISendHandler sendHandler)
       at Microsoft.BizTalk.Administration.SnapIn.Forms.SendPort.General.<buttonTransportURI_Click>b__8()
       at Microsoft.BizTalk.Administration.SnapIn.Forms.Common.ExplorerPropertyPage.PropagateUIChangeToOM(MethodInvoker commit, MethodInvoker rollback)

    Please help.

    Thanks

    A

    Friday, June 12, 2015 6:17 AM

Answers

  • IMHO MSDTC is not specific to Host Instances. You should check to see if you're having issues with SSO specifically if the Master Secret Server is available? is the Enterprise SSO service running ?

    Regards.

    Friday, June 12, 2015 6:27 AM

All replies

  • IMHO MSDTC is not specific to Host Instances. You should check to see if you're having issues with SSO specifically if the Master Secret Server is available? is the Enterprise SSO service running ?

    Regards.

    Friday, June 12, 2015 6:27 AM
  • The Microsoft Distributed Transaction Coordinator (MSDTC) may not be configured correctly. Ensure that the MSDTC service is running and DTC network access is allowed on the BizTalk, SQL and SSO Master servers.

    Use the DTCPing (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=5e325025-4dcd-4658-a549-1d549ac17644) to check whether it works between BizTalk and SQL Server machine.

    Thanks

    Abhishek

    Monday, June 15, 2015 5:22 AM
  • This is more related to SSO issue. Make sure your SSO services are running.

    Please refer following TechNet wiki for more details

    BizTalk Server 2010: Enterprise SSO Survival Guide 

    Hope this helps.


    Greetings,HTH
    Naushad Alam

    When you see answers and helpful posts, please click Vote As Helpful, Propose As Answer, and/or Mark As Answer
    alamnaushad.wordpress.com

    Tuesday, June 16, 2015 3:19 PM
    Moderator
  • Posting this here since "issue with SSO" is not really specific enough I think there is more that can be done to troubleshoot before blaming SSO. 

    In my experience (in a multi-server environment), this is most often a RPC or DTC service issue or network (port) issue, so first you should check if the RPC (port 135) or DTC ports are closed or services are not responding on both the application server(s) or the database server(s). You should attempt a telnet test on port 135 (RPC) and the FIRST DTC port (since it’s a range) from both the DB to the application server(s) and from the application servers to the database servers (see this to determine DTC ports, they should be the same on DB and app servers). If telnet fails from server to server then either the RPC and/or DTC services are not running on the destination or ports are blocked on the network/firewall level.

    *If telnet fails from one server (source) to the remote server (destination), then run the same telnet on the destination server (to itself) to see if it fails also.

    **If it fails from the destination server to itself, this means the service (Remote Procedure Call or Distributed Transaction Coordinator) is either not running or is not responding

    ***Check in Services.msc to see if the services are running and start them if they are not.

    ***If the services are running, then reboot the server to unbind them (you may be able to restart DTC to fix but RPC requires reboot). I cannot say why RPC/DTC can be running and stop responding to calls/requests, but I have seen it happen at least once. 

    **If the telnet (on destination server to destination server) is successful for both port 135 and DTC, then this means the services are running fine on the destination server and the port is blocked on the network. You need to open firewall ports for the ports that failed the telnet test from the source server to the destination server to resolve.

    If you dont know, telnet command (run in CMD/command prompt) is below

    telnet <destination.domain.com> <port>

    telnet myapp.domain.com 135


    • Edited by Malisk Friday, March 15, 2019 7:23 PM
    Friday, March 15, 2019 7:20 PM