We have upgraded from ESB 2.0 to ESB 2.1 and found a bug in the ESB Exception handling mechanism. We trap errors in our orchestration and create & send an ESB fault as per the documentation: ErrorMessage = Microsoft.Practices.ESB.ExceptionHandling.ExceptionMgmt.CreateFaultMessage(); Microsoft.Practices.ESB.ExceptionHandling.ExceptionMgmt.AddMessage(ErrorMessage,SourceMsg); The orchestration then sends the fault. However if the error message is > 256 characters a BizTalk error is generated in the ALL.Exceptions send handler: A message sent to adapter "SQL" on send port "ALL.Exceptions" with URI "SQL://mydb/EsbExceptionDb/" is suspended. Error details: There was a failure executing the send pipeline: "Microsoft.Practices.ESB.ExceptionHandling.Pipelines.ESBFaultProcessor, Microsoft.Practices.ESB.ExceptionHandling.Pipelines, Version=188.8.131.52, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Source: "ESB Exception Encoder" Send Port: "ALL.Exceptions" URI: "SQL://mydb/EsbExceptionDb/" Reason: The property "Description" has a value with length greater than 256 characters. It seems that for some reason, when fault messages are generated by an orchestration that the ESB is trying to promote the "Description" and FaultDescription fields. Note that we do not set the Description field - it is set by the ESB toolkit when creating the error message. Also, faults that occur directly on a messaging port do not result in these fields being promoted. I have checked on our ESB 2.0 and this issue does not arise, presumably because these fields are not being promoted. The net result of this error is that the error message we want to report gets suspended, so the support team never sees the error.