Error "There was an authentication failure"

Whenever our POP3 Receive Location read a signed mail, it throwed the following exception and suspended the instance:

A message received by adapter "POP3" on receive location "yyy" with URI "POP3://yyy#yyy\yyy" is suspended.
Error details: There was an authentication failure. "The status of the certificate authority that issued the certificate used to sign the message is unknown.".

The reason behind was, that the certificate was found, but the Certificate Revocation List (CRL) from the Internet could not be opened, because the server had no Internet access. Since the CRL is saved in public available CRL files, we only had to open the firewall for these types of files, and BizTalk could accept the mails.

BatchComplete-Error in Biztalk Base Adapter

After migrating from Biztalk 2006 to Biztalk 2010, our custom adapters threw new errors when a message suspended:

One from MS CoreAdapter

Batch.BatchComplete hrStatus:c000010x00c00001: BTS_S_EPM_MESSAGE_SUSPENDED (Transport Proxy)

... the other one in our customer Adapter:

[26] ERROR [(null)] BIZTALK_StammdatenTransfers_XferDBAdapter_StammdatenTransfer - Beim Versenden des Batches [BatchInfo(00d6d71f), Batch(00e70a8e)]trat ein Problem auf:

12582913-0x00c00001: BTS_S_EPM_MESSAGE_SUSPENDED (Transport Proxy)

The reason was a missing bugfix that Microsoft introduced in BTS2010 into the BaseAdapter. If you get the new version (however, with the same version number 1.0.2) from C:\Program Files (x86)\Microsoft BizTalk Server 2010\SDK\Samples\AdaptersDevelopment\BaseAdapter\v1.0.2, the problem should be fixed.

BizTalk 2010 Tracking error: Receive and Send Ports do not track

We've just run into the problem that our receive and send ports did not track anything, although we've checked all tracking options and all needed database jobs were running. After analysing the problem for a while, we found out that orchestrations and custom pipelines track, but not the Biztalk system pipelines XmlTransmit, XmlReceive and PassThru pipeline.

With the help of the Biztalk support team, we found that somehow the database was screwed up - while the UI showed us all tracking checks enabled, the exported binding file showed only PipelineEvents as TrackingOption, while ServiceStartEnd and MessageSendReceive were missing.

The actual error was in table TraceTrackingInfo where imgData had the value 0x10000000 instead of 0x13000000. You can change it with SQL but keep in mind that the column is in hexadecimal format. Manipulate the table hence like this (after making a backup):

begin transaction
update BizTalkMgmtDb.dbo.StaticTrackingInfo set imgData = 0x13000000 where strServiceName in (
'Microsoft.BizTalk.DefaultPipelines.XMLTransmit',
'Microsoft.BizTalk.DefaultPipelines.XMLReceive',
'Microsoft.BizTalk.DefaultPipelines.PassThruTransmit',
'Microsoft.BizTalk.DefaultPipelines.PassThruReceive')
--commit

Addition 24.10.2012: Two actions had changed the pipeline:

First, the wrong field value had been inserted by another, self-written script during a deplyoment step, so this is not a Biztalk error.

Second, when importing a binding file where TransmitPipeline had only the TrackingOption="PipelineEvents", this pipeline was modified to the wrong value.

If you now run into the same problem, you can check (and correct) imgData; then, you should also check which routine in your system might have modified imgData before.

Reading current UNB Reference numbers from Biztalk

While migrating EDIFACT partners from Biztalk 2006 to 2010, we had to read the current UNB Reference numbers from the Biztalk 2006 database. They are stored in the BiztalkMsgBoxDb database in table EdiSequenceNumbers. Using the column PartyId, one can link the numbers to the EDI party information from database BiztalkMgmtDb, table EdiPartnerEdifactInterchange. BTW, beginning from Biztalk 2009, you can directly set the UNB Reference number before sending the EDIFACT XML to the EDI Send Pipeline, hence it might be useful to create the number by oneself.