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.