BTDF (BizTalk Deployment Facility) gave this error during a deploy in Visual Studio to the local machine:

Error: Domain accounts must include the domain name. Local accounts must not include a domain or computer name.

Other people mention that you are using computer or domain account when the other is needed.
In my case, my setting file had “BTS Application Users”, but my computer was set up according to the client’s instructions, and it should have been “BizTalk Application Users”.

So the solution is just to type in the correct value in the “Default Values” or “Local” column of the SettingsFileGenerator.xml file. Usually, it opens in Excel (if you have Excel installed on the machine), and change the value, then save it.

One of the pains of the BizTalk Deployment Framework (BTDF) is that frequently, you build a PortBindingMaster file, then you change your port names, or make other changes, and have to rebuild it manually.

The manual process is to export the binding file, then carefully go through the file, making the changes to the BTDF variables (which have the pattern ${variableName}. You define those variables in the SettingFileGenerator.xml file (which is opened and edited as an Excel spreadsheet).

So I built a Powershell that would do the work for me. It could be more complicated, but for now, I usually only have to change my RabbitMQ host name, the SQL server and instance name, and sometimes a filename.

$appName = "MyApp" 
$exportFilename = "d:\GitMyApp_Dev\MyApp\MyApp.Deployment\PortBindingsMaster.xml"

cd "Biztalk:\Applications"
$app = get-item $appName 
export-bindings $app $exportFilename

$binding = get-content $exportFilename 
#Note: $ sign must be escaped in the replace statements 
$binding = $binding.replace("rabbit@localhost","rabbit@`${RabbitMQHostName}") 
#Note: if file has different case of string - the match will not happen 
$binding = $binding.replace("mssql://","mssql://`${DB01Server}/`${DB01Instance}") 
$binding = $binding.replace("mssql://.//","mssql://`${DB01Server}/`${DB01Instance}")
$binding = $binding.replace("c:\Integrations\MyApp\BizTalk2010File","`${FilePathFor2010}") 
Set-Content -Path $exportFilename -Value $binding 


Assumes you have installed the Powershell Extensions for BizTalk and have the:
“Add-PSSnapin BiztalkFactory.Powershell.Extensions” set up in your startup script.

It could be fancier, for example it could use RegEx to find the pattern of the SQL server name, but for now, it’s saving me a lot of time as it is.

I’m starting to write a script to build my BizTalk Deployment Framework Binding (BTDF) files. I’m planning to substite the few things that are unique with the BTDF variables. So the first step is to automate the export of the binding file.

$appName = "Echo.BSSR.FrontEnd.LTLShipmentOut" 
$bindingsDirectory = "c:\Users\NWalters\AppData\Local\BizTalk\Binding Files"
$exportFilename = "$bindingsDirectory.\$appName.xml"

cd "Biztalk:\Applications"
$app = get-item $appName 
export-bindings $app $exportFilename


Assumes you have installed the Powershell Extensions for BizTalk and have the:
“Add-PSSnapin BiztalkFactory.Powershell.Extensions” set up in your startup script.

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