BizTalk support and product teams have investigated into the possible impact of the issue and remedial measures. The escalation engineering team has put together an excellent FAQ explaining all of these in detail. I encourage you to please go through this before calling for support.
Here is an extract from the FAQ for customers who have not been able to apply the fix yet as of 2/29/2012:
Unfortunately, it depends. What you will see are suspended receive or send pipelines. You may see failed orchestrations if they were somehow dependent on the failed pipeline.
For a send pipeline, it will be suspended (resumable) and you can simply resume the instance after updating the machine to have the Leap Year Fix installed.
A receive pipeline instance will be suspended (resumable) but resuming them will just result in the following error:
Event Source: BizTalk Server 2006
Event ID: 5719
There was a failure executing the receive pipeline:"Microsoft.BizTalk.Edi.DefaultPipelines.EdiReceive,Microsoft.BizTalk.Edi.EdiPipelines, Version=18.104.22.168, Culture=neutral,PublicKeyToken=31bf3856ad364e35" Source: "EDI disassembler"Receive Port: "<RP>" URI: "<URI>" Reason: NoDisassemble stage components can recognize the data.
The reason is that the failed instance has already converted the EDI message to XML (since the datatype validation happens after conversion) and resuming just hands this XML back to the pipeline and the EDI Disassembler component does not recognize XML data.
In the case of a single EDI file that uses interchange splitting to split into multiple XML messages, you will have a suspended instance for each split message (since datatypevalidation also happens after splitting) and again resuming will fail since EDI Disassembler will not recognize the XML data.
In order to successfully resume the instance, you will need to change the pipeline used by the receive port to a pipeline that can handle the XML data. That would be the passthrough pipeline, XML pipeline, or a custom pipeline. The message context properties will be preserved but be aware that EDI contextproperties will no longer be promoted. This means that although the context properties will be available from an orchestration if you dorouting based on EDI-specific context, they will fail because they require promoted context properties. The list of properties that will still bepromoted even after resume are as follows:
There may be a few additional promoted properties for custom pipelines or specific adapters. Since BTS.MessageType is still promoted, you will still be able to route based on the type of EDI document - but the main thing to notice is that none of the actual EDI context properties are promoted. In order to have them promoted, you must create a custom pipeline that will promote the EDI properties that you use for routing and use that pipeline when resuming.
How do I rollback this fix? We think it's causing duplication problems in biztalk.