This section provides detailed information about additional configurations of BizTalk 2013 R2 Accelerator for RosettaNet (BTARN) that you need to do before you start using it:
- Start BTARN orchestrations, send ports, and receive locations manually. These do not start automatically when you install and configure BTARN.
- Note: You need to start the PrivateInitiator_To_LOB and PrivateResponder_To_LOB send ports before you can start the PrivateInitiatorProcess and PrivateResponderProcess orchestrations.
- On computers where you have configured an Internet Information Services (IIS) virtual server with Secure Sockets Layer (SSL), you must configure the virtual server to accept the client certificate. For more information, see the Step 4: Enabling Secure Sockets Layer in IIS topic in the MSDN Double Action Tutorial.
📝 One-Minute Brief
Part 4 covers the post-install BTARN steps you must do before using RosettaNet: start the BTARN send ports, receive locations, and orchestrations (they don’t start automatically), validate all BTARN DLLs/resources are deployed, and fix common “missing ports/bindings” issues by importing the BTARN binding files and ensuring artifacts run under the correct BTARN hosts. It also shows how to set the BTARN IIS app pool identity correctly (32-bit + same service account as BTARN hosts).
Start BTARN orchestrations, send ports, and receive locations
- Start the BizTalk Server Administration console as an administrator.
- In the BizTalk Server Administration Console, in the left pane, expand BizTalk Group, expand Applications, and then expand BizTalk Application 1.
- Click Send Ports:
- In the right pane, for each BTARN send port that is not started, right-click and then click Start:
- PrivateInitiator_To_LOB – Static One-Way send port.
- PrivateResponder_To_LOB – Static One-Way send port.
- In the right pane, for each BTARN send port that is not started, right-click and then click Start:
- Click Receive Locations:
- In the right pane, for each BTARN receive location that is not started, right-click and then click Enable.
- Async_Http_Receive – HTTP location.
- Sync_Http_Receive – HTTP location.
- LOB_To_PrivateInitiator – SQL location.
- LOB_To_PrivateResponder – SQL location.
- In the right pane, for each BTARN receive location that is not started, right-click and then click Enable.
- Click Orchestrations:
- In the right pane, for each BTARN orchestration that is not started, right-click and then click Start.
- Microsoft.Solutions.BTARN.CommonTypes.OdxTypes
- Microsoft.Solutions.BTARN.CommonTypes.SendExceptionToLOB
- Microsoft.Solutions.BTARN.CommonTypes.SendExceptionToPrivateProcess
- Microsoft.Solutions.BTARN.PublicResponder.PublicResponderProcess
- Microsoft.Solutions.BTARN.PublicResponder.PublicResponderV11
- Microsoft.Solutions.BTARN.PublicInitiator.PublicInitiatorProcess
- Microsoft.Solutions.BTARN.PublicInitiator.PublicInitiatorV11
- Microsoft.Solutions.BTARN.PrivateResponder.PrivateResponderProcess
- Microsoft.Solutions.BTARN.PrivateInitiator.PrivateInitiatorProcess
- In the right pane, for each BTARN orchestration that is not started, right-click and then click Start.
However, sometimes, from some strange, unknown reasons, even if the installation/configuration ends up successfully, some of the artifacts may not be properly created/deployed in your BizTalk environment, for example, ports and/or bindings. This situation already happened to me twice in several installations.

In this particular problem, the reason was that, because the configuration process has their half dozens of failures/limitations/bugs, some of the binding files used by BTARN (generated by configuration/installation process) was configure to use the default host – that in my case it was incorrectly defined as “BizTalkServerApplication64Host”, a non-BTARN host – in the receive and send ports. The problem was that this particular host is used only to process orchestrations, and it is not associated with any BizTalk adapter.
The solution in these situations is to understand the problem and manually fix it. Fortunately for us, Microsoft made available all the BTARN resources: DLL, source code, binding files, and so on in the BTARN installation folder, which by default is:
- C:\Program Files (x86)\Microsoft BizTalk 2013 R2 Accelerator for RosettaNet.
It is recommended to validate that all the resources are correctly deployed and configured in your BizTalk Server. I already faced an issue where I found out after finishing the installation/configuration process that none of the DLL’s were deployed correctly in the environment:
- In the BizTalk Server Administration Console, in the left pane, expand BizTalk Group, expand Applications, and then expand BizTalk Application 1.
- Click Resources, and you should find there 11 BTARN DLL’s (otherwise you need to manually deploy the missing ones):
- Microsoft.Solutions.BTARN.CommonTypes.dll
- Microsoft.Solutions.BTARN.GlobalSchemas.dll
- Microsoft.Solutions.BTARN.PipelineReceive.dll
- Microsoft.Solutions.BTARN.PipelineSend.dll
- Microsoft.Solutions.BTARN.PrivateInitiator.dll
- Microsoft.Solutions.BTARN.PrivateResponder.dll
- Microsoft.Solutions.BTARN.PublicInitiator.dll
- Microsoft.Solutions.BTARN.PublicResponder.dll
- Microsoft.Solutions.BTARN.Schemas.RNIFv11.dll
- Microsoft.Solutions.BTARN.Schemas.RNIFv201.dll
- Microsoft.Solutions.BTARN.Schemas.RNPIPs.dll

Note: You will find these DLL’s in the BTARN installation folder under the Bin folder: C:\Program Files (x86)\Microsoft BizTalk 2013 R2 Accelerator for RosettaNet\Bin.
- The second step is to fix and import the binding files.
- Note: You will find these Binding Files in the BTARN installation folder under the Bin folder.
- Note: Before you import it, you need to manually fix it; that way, the Preparing your BizTalk Server 2013 R2 environment for BTARN section is very important to avoid these types of problems after the installation and configuration process.

- In this case, to solve the problem, you need to:
- The next step is to make sure that all the artifacts (orchestrations, send ports, and receive locations) are associated with the BTARN hosts:
- BizTalkServerApplication.
- BizTalkServerIsolatedHost.
- Click Send Ports and check if the following BTARN send ports are running under the BizTalkServerApplication send handler; you should modify it.
- PrivateInitiator_To_LOB.
- PrivateResponder_To_LOB.

- Click Receive Locations:
- Check if the following BTARN receive locations are running under the BizTalkServerIsolatedHost receive handler; you should modify them.
- Async_Http_Receive.
- Sync_Http_Receive.
- And check if the following BTARN receive locations are running under the BizTalkServerApplication receive handler; you should modify them.
- LOB_To_PrivateInitiator.
- LOB_To_PrivateResponder.
- Check if the following BTARN receive locations are running under the BizTalkServerIsolatedHost receive handler; you should modify them.

- Click Orchestrations and check if the following BTARN orchestrations are running under the BizTalkServerApplication host; you should modify them.
- Microsoft.Solutions.BTARN.CommonTypes.OdxTypes
- Microsoft.Solutions.BTARN.CommonTypes.SendExceptionToLOB
- Microsoft.Solutions.BTARN.CommonTypes.SendExceptionToPrivateProcess
- Microsoft.Solutions.BTARN.PublicResponder.PublicResponderProcess
- Microsoft.Solutions.BTARN.PublicResponder.PublicResponderV11
- Microsoft.Solutions.BTARN.PublicInitiator.PublicInitiatorProcess
- Microsoft.Solutions.BTARN.PublicInitiator.PublicInitiatorV11
- Microsoft.Solutions.BTARN.PrivateResponder.PrivateResponderProcess
- Microsoft.Solutions.BTARN.PrivateInitiator.PrivateInitiatorProcess

You should do all of this configuration to prevent future problems; otherwise, sooner or later, you will have problems with BTARN.
Note: The Official documentation specifies that should restart the BizTalk Server machine to apply any modifications made in configuration and permissions. Fortunately, you don’t need that.
Configuring IIS Application Pool Identities
IIS supports running 32- and 64-bit websites in separate application pools. Regarding BTARN is very important to:
- Set the BTARN application pool to 32-bit mode.
- The Identity used in the BTARN Application pools should be the same as that we use in the BTARN BizTalk Host Instance Account and the BizTalk Isolated Host Instance Account. Otherwise, BTARN in some situations may not work correctly.
- If the service account set for the BTARN application pools is different from the Isolated Host account, BTARN will not be able to process incoming messages correctly. When the receive “.aspx page” calls the pipeline, the pipeline will not have access to the appropriate certificates. Therefore, it will not be able to decrypt the incoming message or validate the signature. It will also not be able to access the MessageBox database.
To change the Identity property of BTARN application pools, you need to:
- Open the IIS Management Console.
- On the left tree in the Internet Information Services (IIS) Manager console, click on the Application Pools node underneath the machine node.
- Right-click the BTARNAppPool application pool and select Advanced Settings…
- Select the Identity list item and click the ellipsis, and the following dialog appears:
- Select the Custom account option and set the same service account used for the Isolated Host and Host instances.
Related links:
- How to Install and Configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet: Important considerations before you install BTARN (Part 1)
- How to Install and Configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet: Preparing your BizTalk Server 2013 R2 environment for BTARN (Part 2)
- How to Install and Configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet: Install and configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet (BTARN) (Part 3)
- How to Install and Configure Microsoft BizTalk 2013 R2 Accelerator for RosettaNet: Troubleshooting Your Installation (Part 5)
Hope you find this helpful! If you liked the content or found it useful and would like to support me in writing more, consider buying (or helping to buy) a Star Wars Lego set for my son.


In BizTalk 2020 Orchestrations, Sendports and Receivelocations related to Rosettanet are not getting deployed under ‘BizTalkApplication1’ even after successfully configuring the Rossettanet configuration.
There is a bug no the RosettaNet installation for BizTalk Server 2020. For now, you need to recreate all the ports manually. The best opinion for you at the moment is to contact MSFT support.
They will give you the necessary configuration that you need to apply.
I am trying to update the Trading Partner URL on my RosettaNet agreements, but it keeps sending to the old URL. I have shut down all applications, modified the URL, started all applications, restarted the host instances but nothing works. Any ideas on how to update the TPURL?