Error: There was a failure executing the receive pipeline: Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35: msg=Could not find file 'C:\Windows\system32\Shipment.dtd'., stack=   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)

<?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE ShipmentTransaction PUBLIC "Shipment" "Shipment.dtd">

Surprisingly, the same message processed successfully on BizTalk server 2009 but failed in BizTalk server 2013R2, though we have verified that ‘Shipment.dtd’ file exists in the location ‘C:\Windows\system32’ on both servers with all required permissions.

The alternative approach to process this message is to remove this DTD reference in incoming message, which worked on BizTalk server 2013R2.

One of the BizTalk out-of-the-box features-B2B communication, would certainly need a set of business policies to be followed upon by both trading partners involved in transaction. In one of those scenarios, a trading partner (say Partner ‘A’) might need to include a Document Type Definition included in their core communication (XML in current scenario) with their Partner ‘B’. It is now Partner B’s responsibility how to handle the DTD references in inbound messages to generate corresponding XML schemas. In this case, above mentioned alternative approach does not work for Partner ‘B’ as they receive high volume of messages per day from Partner ‘A’. Though this could be handled in different ways of exception handling, we need to verify below points before we proceed to customization (From partner B’s perspective). ->Is the server a 32-bit or 64-bit server? On which host (32-bit or 64-bit) the BizTalk artifact is running? Reason:

A 32-bit Host process running on a 32-bit server, by default, search for DTD file in ‘C:\Windows\System32’ location. Therefore, BizTalk server 2009, running on a 32-bit server, and the artifact (Receive location in this scenario) is running on 32-bit host would check for ‘Shipment.dtd’ file in ‘C:\Windows\System32’ location and process the message successfully.

Things differ for 64-bit server as per below.

A 32-bit Host process running on a 64-bit server refers to ‘c:\windows\syswow64’, whereas, 64-bit Host process refers to ‘c:\windows\system32’.

In our case, BizTalk server 2013R2, running on a 64-bit server, and the artifact (Receive location in this scenario) running on 32-bit host would check for ‘Shipment.dtd’ is referring to ‘c:\windows\syswow64’ where there is NO ‘Shipment.dtd’ file located. Once we place this DTD file in syswow64 folder, the message was processed successfully. Hence, the error message misleading us to check only system32 folder on the server.

Written By Sandeepkumar Pasumarthy Microsoft GTSC

While applying BizTalk CU2 patch on production environment, it failed with error - Error 5003. Regsvcs failed for assembly <BizTalk nstallation Path>\Microsoft.BizTalk.ApplicationDeployment.Engine.dll. Return Code 1.

At this stage, the installer started rolling back the progress and finally ended with the below message.

• Invalid or corrupt dll registry entry.
• Virus or malware infection which has corrupted the dll files.
• Microsoft hardware failure, such as a bad hard drive, which has corrupted the dll file.
• Another program overwrote the required version of dll.
• Another program maliciously or mistakenly deleted the dll file.
• Another program uninstalled the dll file.

1. To verify if DTC was uninstalled successfully, review the application event log.
2. Open regedit and make sure the following registry keys have been deleted (they all may not be present):

• HKEY_CLASSES_ROOT\CID
• HKEY_CLASSES_ROOT\CID.Local for Windows 2008
• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDTC
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSDTC

1. Now reboot the Server
2. Open command prompt and run “msdtc -install” without the quotes again.
3. Once again verify the MSDTC was installed successfully by reviewing the application event log.
4. Use command prompt and run “msdtc -resetlog” without the quotes.
5. In the Administrative tools, Services verify the Distributed Transaction Coordinator service is started and then change the properties of the service so the startup type is “automatic.”
6. Enable DTC network access by locating the local DTC on the component services.

None of the above steps seems to resolve the issue.

Written by Swarna Prabhu Microsoft GTSC