BizTalk 2009: Windows Server 2008 and SAMBA shares

Another adventure that we experienced during a recent BizTalk 2009 cutover was the behaviour that Windows 2008 has on SAMBA shares.  For those of you who are unfamiliar with SAMBA shares they basically provide you the ability to access *nix shares from Windows based computers.

In our previous setup(BizTalk 2006 running on Windows 2003) we had no issues communicating with SAMBA shares. Our infrastructure team recently updated the test system that we connect to version > 3.x of SAMBA where we had no issues when communicating with Windows 2008/BizTalk 2009 servers.  When we went live with this cutover in Prod, the SAMBA version had not been updated in that environment yet and we were running an older version of SAMBA (2.2.x).  The result of this was the following error which led to Host Instances going offline.

 

Event Type:        Error
Event Source:    BizTalk Server 2009
Event Category:                (1)
Event ID:              6913
Date:                     11/7/2009
Time:                     7:00:50 PM
User:                     N/A
Computer:          Server
Description:

An attempt to connect to "BizTalkMgmtDb" SQL Server database on server "SQLServer\SQLInstance" failed.

Error: "Login failed. The login is from an untrusted domain and cannot be used with Windows authentication."

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

The underlying cause for these errors was the BizTalk Host Instance account, that is used to connect to these shares, was being locked out due the issues in connecting with SAMBA.  Pretty much a BizTalk Developer/Admin/Architect’s worst nightmare.

After performing some online searches we ran into the following article. The Article simply states that “Windows Vista and Server 2008 have a default version requirement of MS-LAN Manager communication that prohibits communication to older Linux-based Samba installations. This can be fixed via group policy or the local security policy.”

You can read the article for more details, but what helped us was setting the LAN Manager authentication level to “Send LM & NTLM responses”.  Upon forcing a Group Policy update we were back in business thanks to the help of a few members of our infrastructure team.

We also looked into providing Authentication credentials but that wouldn't help since these are only provided when the Host Instance does not have access.  The BizTalk user did have access so those credentials are sent before these configured credentials are passed anyways.

BizTalk 2009 – NSoftware FTP Adapter FTP protocol error: 550 rename: Cross-device link

During a recent Production implementation of BizTalk 2009 we ran into an issue with the temporary folder option in the NSoftware FTP adapter.  The error itself is not an NSoftware bug, but rather a feature/limitation of the FTP Protocol.

Event Type:    Error
Event Source:    nsoftware BizTalk FTP Transmit Adapter
Event Category:    None
Event ID:    0
Date:        11/7/2009
Time:        2:50:22 PM
User:        N/A
Computer:    Server
Description:
Source: nsoftware BizTalk FTP Transmit Adapter (3.5.3488.0)
Source URI: FTP://%User%@%FTPServer%:21/%RemotePath%/%RemoteFile%
Message Type: Error
Current Thread: 71
Transmission failed for message "019ef16e-0b57-4309-8a37-b5c05a61e7f9": Error uploading FTP data: FTP protocol error: 550 rename: Cross-device link

If this error persists, you may enable Warning or Verbose logging modes to enable the adapter to report more information regarding the progression of this error.

 

Our scenario involved writing files in a specific sequence using delivery notification and using a temporary folder to support some reliability requirements.  The idea behind using a temp folder is you get the data to a “staging” area and once the adapter can confirm that all data was written it performs a rename operation on that file which is extremely quick.  It also reduces the risk of a consuming application retrieving the data from the file as it is being written.  This is especially important in *nix environments since file level locking has not been implemented the same way as it has in Windows environments.

Here is how our destination folders have been configured:

/home/work

/home/arch

/home/temp

Since we are using delivery notification, the “work” file has to be written to first.  Once that operation has completed, then the arch(archive) file can be written.  Both of these messages are being sent through a dynamic send port and we have a routing rules repository where we store the specifics of where the message is suppose to be delivered to.  Our configuration called for both operations to use the same temp location. (Hindsight is 20/20)

In Test, everything worked out perfectly but when we ran this process in Prod we ended up with the aforementioned error.  The difference between these environments is that the “arch” folder exists on a separate disk than “work” or “temp” in Prod.  Essentially the FTP Protocol cannot perform the rename operation from the “temp” folder across to a folder on a different disk that has been mounted to the same server.

I was able to validate this by opening up a command prompt and establishing an FTP session.  Once I connected I tried to rename a file and place it on the “arch” disk.  I got a similar error:

ftp> rename list.txt /home/arch

350 File exists, ready for destination name

550 rename: Cross-device link

ftp>

 

In a previous blog post I discussed that NSoftware use to have a property called temporary file extension.  This property is no longer a property that is exposed in the Send Port configuration but is still supported when you dive into their documentation.  To use this property , you want to click on the “…” button beside the “Other” property.

 

In this property dialog box, populate TemporaryUploadExtension=.tmp

This feature acts similarly to the temp folder, the difference is that the “temp” file will be written to the same folder as the file that you are transferring .  A consuming system that respects file extensions will still be “OK” with this situation since the file name will have “.tmp” added to it until the entire file has been written and at this point will remove this temporary extension via the rename operation.

This situation just highlights how important matching your QA/Test environments and Production really is.  The other lesson is that not everything is exactly as it appears.  In our case the folder structures were exactly the same.  The difference was that one of the folders was mounted to a different disk. Finding this out is not a lot of fun when you are in the middle of a go live.