BizTalk 2013R2 SB-Messaging: The X.509 certificate CN=servicebus.windows.net is not in the trusted people store.

The Problem:

After configuring a brand new BizTalk 2013R2 production environment and requesting the needed firewall exclusions to the security department, we were unable to send messages to Azure ServiceBus using the SB-Messaging adapter in BizTalk 2013R2 (using ACS authentication). We found the following warning in the EventLog:

The adapter “SB-Messaging” raised an error message. Details “System.ServiceModel.EndpointNotFoundException: The X.509 certificate CN=servicebus.windows.net is not in the trusted people store. The X.509 certificate CN=servicebus.windows.net chain building failed. The certificate that was used has a trust chain that cannot be verified. Replace the certificate or change the certificateValidationMode. A certificate chain could not be built to a trusted root authority.

2016-04-08 17_19_28-2

 

The Solution:

Thanks to this post on StackOverflow I was able to fix the problem by “auto installing” the missing certificate.

The following steps solved our problem:

  1. Configure the company web proxy needed for internet connectivity on the server used by BizTalk for ServiceBus connectivity
  2. Use a .NET console test application to send/receive a dummy message to an Azure ServiceBus test queue
  3. Remove the web proxy config
  4. Repeat on every server
  5. Test using the BizTalk SB-Messaging Adapter

 

After using the console test application, we got the following info message in the eventlog:

2016-04-08 17_15_10-1

 

Small sidenote regarding the .NET console test application, make sure you use the “AutoDetect” connectivity mode:

1
ServiceBusEnvironment.SystemConnectivity.Mode = ConnectivityMode.AutoDetect;

Migration from BizTalk 2006 to 2013R2: lessons learned

What we learned when migrating a BizTalk Server 2006 farm (with multiple solutions/projects) to BizTalk Server 2013R2:

1. You need an intermediate step

Migrating BizTalk 2006 solutions directly to BizTalk 2013R2 (Visualt Studio 2013) is not supported. You will need to migrate the solution to BizTalk 2010 (Visual Studio 2010) first as an intermediate step. More information here in a MSDN forum thread. (nothing fancy in this one I must admit, but you need to take this step into account when estimating an upgrade…)

2. Install the latest BizTalk CU on your development machine

The fact that we needed an extra intermediate step in the migration process was no big deal in our situatuion. We had an emtpy VM with BizTalk 2010 and Visual Studio 2010 in place. This machine was installed a few years ago by a developer, but was never used. It had no BizTalk Cumulative Updates installed.

We didn’t have any issues when migrating simple BizTalk 2006 solutions. We migrated to BizTalk 2010 and then migrated to BizTalk 2013R2 on an other machine.

When migrating the more complex solutions (big orchestrations and lots of ASMX web ports), we started to experience some weird behaviour in Visual Studio 2010:

That last error lead us in the right direction: BizTalk Server 2010 CU2:

This issue might also occur when you try to build a BizTalk Server 2010 solution that was converted from a Microsoft BizTalk Server 2006 R2 or Microsoft BizTalk Server 2009 solution in Visual Studio 2010.

After installing BizTalk Server 2010 CU8 on our development machine (the latest update at that moment), we restarted the migration (from the original BizTalk 2006 solution) of those complex projects, without the need to replace anything. The whole migration process completed without any error!

So, spare yourself the misery and start with a fully up to date BizTalk 2010 development environment. Other blogs on the internet might suggest to fix the “mismatched ‘braces’ ‘{}’ error” error by manually editting the .odx file. This was not the correct fix in our case as the error kept returning after every other change in the orchestration.

Find BizTalk map by source and destination MessageType

In a current integration scenario we are heavily using dynamic transforms in our solution. The combination with the Business Rules Engine (that holds the logic to determine the required output message version) makes it possible to map to the desired message format and version for a given partner.

The problem in our case was that we don’t now the version of the assembly that holds the BizTalk maps (caused by our build server setup). Otherwise we would have been able to store the MapName and AssemblyName in the BRE like showcased in this MSDN sample. Thanks to this query against the BizTalkMgmtDb we are able to find the correct map currently deployed on BizTalk Server. The query needs the incoming message type and the destination message type. (in our solution the destination message type is dynamically returned by the BRE)

Sample output of the query:

2015-12-05 12_06_20-SQLQuery1.sql - wp0905.BizTalkMgmtDb (ATOMIUM_JMSAI83 (51))_ - Microsoft SQL Ser