Click here to Skip to main content
1,078 members
Articles / Security / .NET 1.1
Posted 12 Apr 2012



Pitfalls Encountered and their Workarounds during Development of BizTalk Projects

Rate me:
Please Sign up or sign in to vote.
0.00/5 (No votes)
12 Apr 2012CPOL
This article discusses the pitfalls encountered and their workarounds during development of BizTalk Projects

This article is a sponsored article. Articles such as these are intended to provide you with information on products and services that we consider useful and of value to developers


This article explains some of the commonly encountered pitfalls and their workarounds during the development of BizTalk Project.


The reader is expected to have a basic understanding of:

  • § Microsoft BizTalk Server concepts
  • § Microsoft .NET Framework
  • § Microsoft SQL Server

Pitfalls Encountered and their Workarounds

1. Installation Failure of BizTalk 2004 in Win XP with SP2

  • Failed to enable the single sign-on(SSO) service
  • Failed to generate the master secret code


Use the Group policy object editor to enforce the use of authenticated client calls to the RPC End point Mapper and to disable the RestrictRemoteClients setting that is enforced by the RPC protocol.

  1. Click Start, click Run, type gpedit.msc, and then click OK.
  2. In the Group Policy Object Editor, expand Computer Configuration, expand Administrative Templates, expand System, click Remote Procedure Call, and then click RPC Endpoint Mapper Client Authentication.
  3. Change the value for RPC Endpoint Mapper Client Authentication to Enabled.
  4. Click Restrictions for Unauthenticated RPC Clients.
  5. Change the value for Restrictions for Unauthenticated RPC Clients to Disabled.

Use Registry Editor to enforce the use of authenticated client calls to the RPC Endpoint Mapper and to disable the RestrictRemoteClients setting that is enforced by the RPC protocol.

  1. Click Start, click Run, type regedit, and then click OK.
  2. Locate and then click the following registry key : HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT
  3. Look for a subkey that is named RPC. If this key exists, click the RPC subkey, and then go to step 6. If this key does not exist, go to step 4.
  4. On the Edit menu, point to New, and then click Key.
  5. While the new key is selected, type RPC, and then press ENTER.
  6. On the Edit menu, point to New, and then click DWORD Value.
  7. Type EnableAuthEpResolution, and then press ENTER.
  8. On the Edit menu, click Modify.
  9. In the Value data box, type the number 1. Click OK.
  10. On the Edit menu, point to New, and then click DWORD Value.
  11. Type RestrictRemoteClients, and then press ENTER.
  12. On the Edit menu, click Modify.
  13. In the Value data box, type 0, and then click OK.
  14. Quit Registry Editor.

2. Issues with SQL Adapter Distributed Transactions and their Isolation levels


  • Transaction Manager has disabled its support for remote network transactions


  • First of all, verify that "Distribute Transaction Coordinator" Service is running on both database server computer and client computers.
    1. Go to "Administrative Tools > Services"
    2. Turn on the "Distribute Transaction Coordinator" Service if it is not running.
  • If it is running, then the following settings need to be done on the computer running database server.
    1. Go to "Administrative Tools > Component Services".
    2. On the left navigation tree, go to "<Component Services><Computers > My Computer" (you may need to double click and wait as some nodes need time to expand).
    3. Right click on "My Computer", select "Properties".
    4. Select "MSDTC" tab.
    5. Click "Security Configuration".
    6. Make sure you check "Network DTC Access", "Allow Remote Client", "Allow Inbound/Outbound", and "Enable TIP".
    7. The service will restart.
    8. But you may need to reboot your server if it still doesn't work.

On your client computer, use the same above procedure to open the"Security Configuration" setting, make sure you check "Network DTCAccess", "Allow Inbound/Outbound" option, restart service and computer if necessary.

3. Issues with Disassembly of Messages using Envelope Schemas


  • We can use custom pipelines with XML Disassembler to cut an envelope message coming from a SQL receive location to obtain its constituent document messages. If proper options are not specified in the pipeline and the Receive Location through which the envelope message will be coming, the disassembly fails and no document messages are returned, resulting to message loss.


  • It is the responsibility of the Receive Location to add the envelope node to the incoming XML, along with the Namespace URI, which is the means by which the messaging engine identifies the type of the message. So, proper envelope node name (Document Root Name) and Namespace URI must be specified when creating the SQL receive location.
  • The Namespace URI specified in the Receive Location must also be specified as the Document Namespace of both the Envelope Schema and the Document Schema.
  • While designing the custom pipeline, the Document Schema and the Envelope Schema of the XML Disassembler stage component must be specified. The custom pipeline must be explicitly specified as the Receive handler of the SQL Receive Location.

4. Message Construction Issues Inside Orchestrations


  • Message is not constructed inside construct shape of the Orchestration.


  • Before using a BizTalk XML Message inside an orchestration, it must first be constructed. In fact this is just populating the message with XML. If there is an attempt to use this message before it is constructed, the above error will come. Some messages come pre-constructed, such as messages that originate from a send port
  • There are several ways to construct a message inside an orchestration:
    1. Create a new message from an existing message using BizTalk map
    2. Assign one message to other(i.e. creating a copy of an existing message)
    3. Creating a message with the help of a System.XML.XMLDocument variable

We have to first declare an orchestration variable of type XmlDocument. Then in a message assignment shape, we need to do something like this:

myxmlDoc = new XmlDocument(); 
myMsgBeingConstructed = myxmlDoc;


  • 10th September, 2010: Initial post


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Abhijit Mahato
Software Developer (Senior)
India India
This member doesn't quite have enough reputation to be able to display their biography and homepage.

Comments and Discussions

-- There are no messages in this forum --