A colleague asked me to look at a failing BizTalk application build on one of our CI agents. Long story short, after exporting the .MSI file the deployment scripts try to import the bindings file for the application. It just spins for an hour and then bails with the following error:
Error: Failed to update binding information. Exception of type ||'Microsoft.BizTalk.CachingService.NotificationFailedException||' was thrown.
The scripts use the BizTalk PowerShell snap-in via:
Add-PSSnapin –Name BizTalkFactory.PowerShell.Extensions
The line giving the error above is:
Import-Bindings -Path "BTS:\Applications\$AppToDeploy" -Source "$bindingsFileName"
This is a new application as far as the CI pipeline is concerned. I've tried running the same script on my local and another development BizTalk machine and it imports without incident.
Also tried importing the binding xml file manually using the BizTalk Administration Console. It also hangs on the CI box but works fine on the dev machine.
While it hangs, if you look at SQL (hosted on the same machine), there is a blocked process. The process causing the block is not doing any updates so I'm assuming it is a DTC lock of some sorts. There are no other active SQL users or applications loaded in BizTalk. The CPU is idle, memory is at 20% and disk activity is pretty dead.
Looks like something specific to the CI agent machine for this new application, just at a loss where to look next. Does BizTalk have any logs or tracing I can enable to see where and why the binding imports get stuck?
P.S. Imports of bindings for the other existing applications work fine. If I change the assembly version on the only orchestration in the bindings file to an invalid one, the import runs fine but obviously the application does not work because that assembly does not exist.
Finally! Thanks to some though provoking ideas from Dijkgraaf, got it working.
Short version: Start the SQL Agent on the CI box.
Turns out we have the following tracking options on the Orchestration in the bindings file:
TrackingOption="ServiceStartEnd MessageSendReceive InboundMessageBody OutboundMessageBody OrchestrationEvents TrackPropertiesForIncomingMessages TrackPropertiesForOutgoingMessages"
If this list was distilled down to:
TrackingOption="ServiceStartEnd MessageSendReceive OrchestrationEvents"
...the imports would work. This got me thinking it is a tracking infrastructure issue prompting me to check the SQL agent jobs that do the maintenance. Because it is the CI agent and nothing actually uses BizTalk functionaly, nothing would care to check the health of BizTalk.
After starting the agent and letting the jobs do their job, the import of the original bindings file works like a dream.
Hope this helps someone.