Microsoft.ServiceModel.Channels.Common.ConnectionException: Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.
—> System.Data.SqlClient.SqlException: Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.
The user was correct, and that was driving me crazy. I had just built the database from a script, and I set and double-checked the security in SSMS for that database.
I’m running on my own VM on my desktop; and the userid is my VM-Name/bts_host_ins (and that’s the user that all the host instances run with).
There could be other reasons for this error, but here was my reason…
My SendPort was pointing to our development system which is on the “DEV” domain, and my VM where I’m testing is on the primary domain.
The fix was just to repoint the SendPort to my local VM which is what I wanted anyway. If I really did want to go to the DEV domain, then I would have to use a user on that domain to run my host instance.
The adapter failed to transmit message going to send port “sp_Test_SFTP” with URL “sftp://sftp.mycompany.com:22/%MessageID%.xml”. It will be retransmitted after the retry interval specified for this Send Port. Details:”System.IO.FileLoadException: Could not load file or assembly ‘WinSCPnet, Version=184.108.40.20657, Culture=neutral, PublicKeyToken=2271ec4a3c56d0bf’ or one of its dependencies. General Exception (Exception from HRESULT: 0x80131500)
File name: ‘WinSCPnet, Version=220.127.116.1157, Culture=neutral, PublicKeyToken=2271ec4a3c56d0bf’ —> System.Exception: SFTP adapter requires WinSCP to be installed. Please refer http://go.microsoft.com/fwlink/?LinkID=730458&clcid=0x409 . —> System.IO.FileNotFoundException: Could not load file or assembly ‘file:///C:\Windows\Microsoft.Net\assembly\GAC_MSIL\Microsoft.BizTalk.Adapter.Sftp\v4.0_18.104.22.168__31bf3856ad364e35\WinSCPnet.dll’ or one of its dependencies. The system cannot find the file specified.
I think BizTalk requires a specific older version of WinSCP and you can’t just download the latest one.
This error could also occur if you didn’t copy the file to the proper directly.
Shape name: msgABCDetail
Exception thrown from: segment 4, progress 22
Inner exception: Root element is missing.
This error occurs in an orchestration, typically after you have run a map, and the map doesn’t create any output.
The map is in a construct statement, and presumably the message created in the construct statement should not be empty.
The way to test or fix this is as follows:
1) Obtain a copy of a the message that goes into the map (might have to add debug or write message to disk or trace), and save to disk.
2) Test that message in Visual Studio using the right click “Test Map” option on the map (first set the “TestMap Input Instance” property to the filename you saved from the step above.
3) Typically the issue is a namespace or higher level node is missing. This causes none of the xpaths in the XSLT to match, and thus nothing is generating on the “right side” of the map. When you test the map, the Output window will show something like this: “The output is stored in the following file: xxx.xml”. If you cntl-click on that file, that file will open. In all likelihood it will be empty (blank). [If it has data in it, there is a chance the code you are running doesn’t match the current version of the source code/map you are testing, indicating you might need to redeploy.]
4) To check further, you can also check the file against the schema, to make sure it is valid. This may help indicate an element name or namespace that is wrong that could cause the map to result in empty output. Set the schema property “Input Instance Filename”, then right click on the schema and select “Validate Instance”. If it fails, you might try generating an instance, then use a file compare or your own eyeballs to compare the generated instance to the instance you were validating (experience teaches you what to look for).
Here’s a specific case I dealt with today. My data file had a root element named eisresultset. It was built by xpathing to a node of the data data returned to us by a vendor. Due to the way the vendor packs the data in a generic XmlDoc packet, the WSDL did not build the schemas for us, and I had to do it manually. When I built the schema for esiresultset, I misspelled the root element name and had esiresultset. The reversal of those two letters make a huge difference!
When I validated the data instance against the schema, the output window told me clearly:
e:\MyDir\MySubDir\map_EsiResultSet_To_DBTableMotoDetails_TestIn1.xml: error BEC2004: The ‘eisresultset’ element is not declared.
The second mistake I made, was in my map, I had mapped eisrecord, a separate schema with that repeats inside of eisresultset. So mapping a schema that starts with a higher level element than what I mapped would never result in a good map output.
This is a “back to the basics” post with a list of reasons BizTalk might not be processing (consuming) your file that you have placed (dropped) in a directory associated with a Receive Location.
1. Are the Host Instances started? (Specifically the Host Instance associated with the Receive Location). Be sure and refresh (F5 or right-click refresh) to make sure you are not looking at old statuses.
Each receive location has a “Receive Handler”. See Figure 1 below.
See Figure 2 below to check if the Host Instances are started. Be sure and refresh (F5 or right-click refresh) to make sure you are not looking at old statuses.
In the case above, the Receive Location Hander is BizTalkServeApplication. So it doesn’t matter that the Rosetta Host Instance is not started.
Figure 2 – Status of Host Instances
2. Make sure the Receive Location itself is “Enabled”. The figure below doesn’t show, but I opened BizTalk Admin console, navigated to the Application on the left menu, then expanded the “Receive Locations”
Figure 3 – Receive Location Status
3. Check Windows Application Event Viewer for Errors:
For example, here is an error I had today:
The FILE receive adapter cannot process file e:\Messages\Charter\Inbox\StarterParams\StartParams_Prod.xml because of one of the following reasons:
1) The file is read-only.
2) The file is a system file.
3) The FILE receive adapter does not have write permissions on the file.
To see if the file is read only, right click on the file and make sure the checkbox next to “read-only” attribute is NOT checked. Also make sure the file you are copying/dropping into the pickup directory is not “read-only”, because that attribute sticks when you copy it. NOTE: You might have a sample file in your Visual Studio Project, then when you check that project in to TFS (or some other source control system), the read-only attribute of that file is turned on. You might want to have a copy of your file for testing that is not part of TFS check-in so that the read-only attribute will stay off.
To check security, from Windows Explorer, right click the directory (not the file), click on the Security tab, and make sure that the userid that runs the Receive Handler Host Instance (see Figures 1 and 2 above) have Full Control. If in doubt, you could always add the user “Everyone” and give it full access. Then once you get it working, go back and tighten-up the security. If you are working on your own laptop or development computer, the security probably doesn’t matter. But on a shared development, QA, or production environment, security can be very important.
4. Consider checking the CPU performance on the machine.
I’ve seen cases where there is a task using 100% of the CPU, and that is preventing the BizTalk host instance to do its work.
The short cut to open Windows Task Manager is Cntl-Shift-Escape. I like to check the “Performance tab” to see what CPU Usage is, if it is high, and how long it has been high. If it is really high, like 90-100%, you can click Processes (then sort by CPU) and find out which task is taking all the CPU.
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.
A message sent to adapter "BiztalkMessagingEngine" on send port "XX.FMA.Extract_22.214.171.124_XX.FMA.Extract.SendExtract_DynamicFTP_f136abb33540170c" with URI "ftp://126.96.36.199:21/%SourceFileName%" is suspended.
Error details: Unknown Error Description
We moved code to a new target environment, where the Host-Instances didn’t match the source environment. We reconfigured some of the HostInstances to allow for a default 32-bit host instance, then restarted the Host Instances.
Orchestration is being used to send files to a dynamic FTP. We store the FTP site, user, password in a SQL table to allow us send to many different FTP trading partners.
Unenlist and re-start the dynamic send port. Apparently restarting the Host Instances was not enough.
Exception type: InvalidOperationException
Target Site: System.Object Deserialize(System.Xml.XmlReader,
The following is a stack trace that identifies the location where the
I was using the BizTalk orchestration xpath command, like this:
myString = xpath(myMessage,myXpath);
The problem was, that I forgot to wrap the xpath with the string() function, like this:
I got this error today, and it was very difficult to figure out. I wasted about two hours on it.
There was a failure executing the receive pipeline: “pipeline name” Source: “Pipeline ” Receive Port: “SQLPollingWire” URI: “SQL://Server/ECData_SharedDev/4” Reason: Input string was not in a correct format.
I was using the polling of the built-in SQL adapter, and add a new element to my SQL query, and thus manually added the same element to the schema.
In the schem a, the new field w as defined as a string, not a number, so why would this blow-up in the pipeline?
The error is the same error that is thrown when you would get if you tried this: System.Convert.ToInt32(“test”).
The answer is that I did a quick-promote on it, and accidentally associated it with field in the property schema that was an “int”. Thus, when the pipeline was doing the promotion of the field, that’s when it died.
Another error solved, and more time wasted. Hope this helps if you get this error.
This week, we finally agreed on our TFS structure, and I checked in all our BizTalk code. It compiled okay before check-in, but after check-in it was giving the following strange error:
Build failed. Assembly builder could not generate final assembly
ll’. Access to the path
zTalk.ArtifactsOrchestrationsProcessWireTransfer.odx.cs’ is denied.
At first, I went off on a red herring. I thought this was related to the “obj’ directory needing to be deleted, or that some other file was accessing it.
Then it dawned on me, the problem was really with the xxx.odx.cs file. Why this file? The compiler generates this file, so it never really needed to be checked-in to TFS in the first place. Since I did a mass-checkin from disk (by doing “Add-Files”), these files ended up in TFS as well. Thus, when they were brought down to a new disk structure, they had the “read-only” attribute set.
So I had two solutions, either check-them-out, or delete them. I went with the concept of deleting them on TFS, then deleting them on disk, then the compile worked.
NOTE: When testing with this on TFS, it’s useful to do a test with two developers. Just because it works on one developers machine, doesn’t 100% guarantee that when the second developer checks it out that it will work.
An example of this point is our “add references”. We reference a common binaries folder to allow for more flexibility of each developer building his own solutions. In other words, we typically don’t do references with the solution, and instead reference the a special folder we created called “binaries”. It’s a little bit of a pain to keep it in sync.
Anyway, when we checked in the disk structure, the .DLLs in the Binaries by default were excluded. I had to go back and check them again manually, without the exclude of the .DLL suffix.
Here is one cause of the error below. In this case, a fellow developer GAC’ed the .DLL in the Deployment/bin instead of the Development/bin. There was a .DLL in the Deployment/bin, but it was much older, and didn’t have the specific orchestration being called for.
Failed while creating a Your.ProjectName.YourOrchestrationName service.
Exception type: ServiceCreationException
The following is a stack trace that identifies the location where the exception occured
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXSession._serviceCreator(Guid& instanceId, Object objCurrMsg)
at Microsoft.XLANGs.Core.ResourceContainer._allocateResource(Guid& key, UInt32 hashKey, ResourceCreator resCreator, Object creationContext)
at Microsoft.XLANGs.Core.ResourceContainer.Dispense(Guid& key, ResourceCreator resCreator, Object creationContext)
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXSession._dispenseService(Guid& instanceId, IBTMessage currMsg)
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXSession._tryReceiveOneMessage(Boolean& loggedError, Guid& instanceId, IBTMessage currMsg)
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXSession._receiveOneMessage(Guid& instanceId, Guid& serviceId, IBTMessage currentMsg)
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXSession.ReceiveMessages(IBTMessage messages, Int32 firstIdx, Int32 count)
at Microsoft.BizTalk.XLANGs.BTXEngine.AppDomains.AppDomainRoot.Microsoft.XLANGs.BizTalk.ProcessInterface.IAppDomainStub.ReceiveMessages(Object objMsg)
at Microsoft.XLANGs.BizTalk.CrossProcess.AppDomainStubProxy.Microsoft.XLANGs.BizTalk.ProcessInterface.IAppDomainStub.ReceiveMessages(Object msgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)
at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg)