You get the following error when you do a BTDF deploy.


x does not belong to the same application as “Y” or its references.

Full example of error

Information: Importing bindings "C:\Users\...\Projects\MyEDIProject\MyEDIProject.Deployment\PortBindings.xml" into application "MyEDIProject" in BizTalk configuration database (server="MyServer1", database="BizTalkMgmtDb")...
Error: Failed to update binding information.
"Microsoft.BizTalk.Edi.DefaultPipelines.EdiSend" could not be bound to "sp_MyProj_Process_EDI_File". The artifact "Microsoft.BizTalk.Edi.DefaultPipelines.EdiSend" does not belong to the same application as "sp_MyProj_Process_EDI_File" or its references.


The pipeline is in a different project. When BTDF deletes your project and redploys it, it loses the project references. You must add the project cross references in the BTDFProj file, as shown below.

<AppsToReference Include=?MyProj2? />

The above shows you how to add a “Project Reference” to your BTDF configuration file.

In the past, I admit, I was a GAC’cer.  Yes, that means that I would run GACUTIL to deploy minor code changes to BizTalk Ochestrations.

Where I currently work, that is not the best practice for several reasons.  One reason is that if you  create an MSI after doing the GAC, the MSI will not contain the newest DLL.  At other places I worked, this was not an issue, because we used the BizTalk Deployment Framework (BTDF).

Last week, I had an orchestration that was rather difficult to test in my own environment.  So I wanted to compile it, deploy the .DLL to our QA environment, and test it there.  But I had to do this over-and-over, making minor little changes.

The manual process was:

  1. Stop the orchestration (and make sure to terminate any suspended instances).
  2. Go to the “Add Resource”, click a button to find the .DLL, wait a few seconds, then click a few check boxes, and click the “OK” button, and wait a few more seconds.
  3. Since we had two machines in our QA environment, I had to repeat Step 2 on the second machine.
  4. Then start the orchestration
  5. Then restart the host instances (so the new code would be picked up)

I vaguely remember the BTSTASK command, but haven’t used it for years outside of BTDF, so I looked it up, and created the following .cmd file:

cscript "c:\Program Files (x86)\Microsoft BizTalk Server 2010\SDK\Samples\Admin\WMI\Stop Orchestration\VBScript\StopOrch.vbs" "MyProjNamespace.MyOrchName" "MyAppName" Unenlist
"c:\Program Files (x86)\Microsoft BizTalk Server 2010\BTSTask.exe" AddResource /ApplicationName:MyAppName /Type:System.BizTalk:BizTalkAssembly /Overwrite /Source:MyProjNamespace.dll /Options:GacOnAdd,GacOnInstall,GacOnImport &gt;ReplaceResources_Log.txt
cscript "VBScript\StartOrch.vbs" "MyProjNamespace.MyOrchName" "MyAppName"

The program called StopOrch.vbs existed in the BizTalk provided SDK/examples. However, there was no StartOrch.vbs, so I had to create the VBScript to start an orchestration (see link to separate blog on that).  Heres the MSDN Doc for BTSTask with the AddResource parameter.

I’m still doing Step 5 manually.  I copy the .DLL to server1 and server 2 in the BizTalk group.  I then run the above script on each server.  Then I restart the host instances manually.

When you Deploy a BizTalk project, it has to update a BizTalk SQL database, which by default is called BizTalkMgmtDB.

Suppose you have been using BizTalk on the same server for days, weeks, or months, and you open someone else’s project, change the server name, and get the error below. That’s the specific case I’m covering here. At the bottom of the blog, I refer you to other possible solutions if you’ve never got it to work before.


Text error:

error DEPLOY: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server) The network path was not found 

Same Error in Screen shot of Visual Studio. Once in Error List and once in View Output.

Tricky Solution – Did you Save the Changes?

Ok, suppose you know the server is up, you just deployed another project, and all the settings are identical.
Here is a trap that I fell into more than once.

I opened a BizTalk solution from our source control. The prior developer had checked in the code with his machine name it. While I think that’s a bad practice, I have to continue and fix it.

So I changed from his server (machine) name, to (LOCAL), which means the server I’m running on right now.

Then I did a deploy and got the error. I did several times, and was getting very frustrated.

The settings you see on the screen are retrieved (and eventually saved) in the .btuser file.

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="">
  <PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Debug|AnyCPU'">
    <ApplicationName>xxxx webservices</ApplicationName>

Finally, when watching this file in NotePad++, I realized that changing the value on the screen does not save it in the file! You have to first either do a manual “save”. Not even backing out of the Deployment Properties seems to cause the save to happen. Thus, when I was compiling, I was using the old values on the disk, and not the values that looked plainly obvious on the screen.

Other Solutions

If this is the first time you have deployed, the issue could be caused by other reasons.

Refer to this blog for general causes of not being to connect to a SQL server: Pinal Dave SQL Authority site – could not open a connection to SQL server

Hope this helps! Just be sure and click SAVE before you DEPLOY.


SSOSettingsFileImport.exe /userGroupName:"BizTalk Application Users" /adminGroupName:"BizTalk Server Administrators" exited with code 1


In this case, you probably didn’t change the values of the SsoAppUserGroup and SsoAppAdminGroup in the default SettingsFileGenerator.xml, and your site has different user groups for SSO.


Could not enlist orchestration...


This can happen when you forget to change the default PortBindingsMaster.xml file. The setup gives you a valid PortBindingsMaster.xml file, but it practically empty. You need to export your Bindings either directly to this file, or massage your Bindings file and add your desired substitutional variables that can be set by the SettingsFileGenerator.xml file.

When I treid to start a project, several SendPorts would not start.  When I tried to start each one manually, some of them were giving this misleading error in the EventLog.

Unable to communicate with MessageBox BizTalkMsgBoxDb on SQL Instance DAL-BIZ-APP01. Error Code: 0x8004d00e. Possible reasons include:
1) The MessageBox is unavailable.
2) The network link from this machine to the MessageBox is down.
3) The DTC Configuration on either this local machine or the machine hosting this MessageBox is incorrect.

We use BizTalk Deployment Framework (BTDF).  I had copied my binding file and updated in Visual Studio.  This is the second or third time that the XML editor of Visual Studio has bit me; it re-arranges the XML in the binding file, and the binding file import is apparently very picky about the layout.  Not sure why it cannot use standard XML conventions.

The moral of the story is to use NotePad++, NotePad or some other safe editor that doesn’t take any liberties with reformatting the XML. I rebuilt my MSI, redeployed, and it worked fine.

What helped me figure it out was this blog:
Sure enough I looked at the SendPorts and they had no filters; i.e. the filters had been lost somehow by the editor issue.  Now why it causes the error “unable to communicate with the Messagebox” is entirely a mystery.


I cannot count how many times I have got the error below:

It typically happens when you try to import a BizTalk MSI application fro, one machine and export it to another. What it implies is that that system you have exported from, and the system to which you are importing, having different settings on the Host. The first thing you normally do is go check your “trust levels” and whether the host is 32-bit or not. If that matches, then what do you do?

The secret is that this error can also indicate a problem with the adapters being related to the Host Name. In the above case, we had added the Open Source “NullAdapter” on the “from system”, and had installed the adapter on the “to system” as well. But we forgot to attach the adapter to the Host Instance, which was also called “NullAdapter” (we still don’t have good naming convention for our host instances at this site, as we inherited what was already here).

You can see this by looking at the adapters in BizTalk Admin Console:

Note in the above screen shot that the “NullAdapter” Host Name is missing from the list of “Host Names”, and in fact, there is no need for the other two “Host Names” to be there.

So first, right-click on the Adapter, click “new” then add the desired “Host Name”, as shown below. Make the new Host Name the default by checking the “Make this the default handler”. I actually forgot to that, so I got an error when I tried to delete the Host Name “BizTalkServerApplication” from the NullAdapter.

Then, associate the Adapter to the desired “Host Name”, by picking from the list of “Host Names”:

At the end, after deleting the two “Host Names” that should not have been there, the list of “Host Names” looks like this:

Remember again, I wouldn’t normally name the “Host Instance” the exact same name as the Adapter, but in this case it kind of made sense, because the “Null Adapter” is only used by us in a couple of odd places. How you should properly set up your Hosts could be the topic of another blog.

I was at a new client, trying to run a Powershell to help build my BizTalk binding files for the BizTalk Deployment Framework,
and I got this error:

PS C:developmentAllProjects.Deployment> .GenerateMasterBindingsFromLocal.ps1
File C:developmentAllProjects.DeploymentGenerateMasterBindingsFromLocal.ps1 cannot be loaded because the execution o
f scripts is disabled on this system. Please see "get-help about_signing" for more details.
At line:1 char:38
+ .GenerateMasterBindingsFromLocal.ps1 <<<< + CategoryInfo : NotSpecified: (:) [], PSSecurityException + FullyQualifiedErrorId : RuntimeException

At first, I thought maybe the issue was a Group Policy, but it wasn't. You just need to run the command below, however, it does update the registry, so if you are not running as Administrator, you get this error:

PS C:developmentAllProjects.Deployment> set-executionpolicy remotesigned

Execution Policy Change
The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose
you to the security risks described in the about_Execution_Policies help topic. Do you want to change the execution
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): y
Set-ExecutionPolicy : Access to the registry key 'HKEY_LOCAL_MACHINESOFTWAREMicrosoftPowerShell1ShellIdsMicrosoft
.PowerShell' is denied.
At line:1 char:20
+ set-executionpolicy <<<< remotesigned + CategoryInfo : NotSpecified: (:) [Set-ExecutionPolicy], UnauthorizedAccessException + FullyQualifiedErrorId : System.UnauthorizedAccessException,Microsoft.PowerShell.Commands.SetExecutionPolicyComma nd

When you open Powershell as Admin, then run the same command, it runs and looks like this:

Execution Policy Change
The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose
you to the security risks described in the about_Execution_Policies help topic. Do you want to change the execution
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): y

As you are well aware, all BizTalk programs must reside in the GAC. Many of use the “shell extension” to drag and drop programs to the GAC. But BEWARE, this tool is gone in .NET 4.0.

See here for the Microsoft Official Statement:

Former link was moved by MSDN:

“Beginning with the .NET Framework version 4, the Assembly Cache Viewer (Shfusion.dll) is obsolete and has been removed. Use Gacutil.exe (Global Assembly Cache Tool) to view and manipulate the global assembly cache.”

For a good explanation, see the answer to this popular question on Stack Overflow (GAC).

BizTalk Deployment Framework

Download or read more information on CodePlex:

Handling Error: “More than one schema is deployed for the same message type”

If you have worked with Biztalk very long, you have undoubtedly got the following error:

Event ID: 5719
There was a failure executing the receive pipeline: “Microsoft.BizTalk.DefaultPipelines.XMLReceive” Source: “XML disassembler” Receive Location: “c:OdimoRedbirdOrdersIn*.xml” Reason: The disassembler cannot retrieve the document specification by using this type: “RedOrders”. Either the schema is not deployed correctly, or more than one schema is deployed for the same message type.

Usually, this error is because you didn’t deploy your project, but occassionally, you will have duplicates. How are you supposed to find them?

Here is an SQL statement that will help you list all schemas. Who knows? Someone in an entire different application may have already used the root element you are using.

use biztalkmgmtdb
select msgtype, body_xpath, clr_namespace, clr_typename, clr_assemblyname, schema_root_name,
from bt_DocumentSpec
order by msgtype –(which is the schema-name)
–order by date_modified desc — (probably the date deployed?)

You are looking for two things in this report:
1) Did you deploy the same schema more than once?
2) Did you not deploy the schema?

Look in the msgtype column for your schema name. ?
Do you see more than one of them?

NEW: 08/02/2005 If instead you get error 0xCOC01657 Verify that schema is deployed properly and that the schema assembly implements the document spec.
Check the windowsassembly (GAC) to see if your .dll’s are really there.
Through normaly deployment they should be, but I have seen the GAC out of WACK probably due to my own fault.

Happy Schema Hunting!