craig beuker

Greetings,

My comments are inline.

Are there any other errors/warnings in the event log?

You may want to look into the FileReceivePollingInterval registry setting
(It can be found in the BizTalk Docs)

You may want to look at:

http://support.microsoft.com/default.aspx?scid=kb;en-us;810886. Title:
"The network BIOS command limit has been reached" error message in
Windows Server 2003, in Windows XP, and in Windows 2000 Server

So you use the FTP adapter to receive these two files?

You seem to be running into the issue discussed on Charles Young's blog:
http://geekswithblogs.net/cyoung/archive/2004/08/10/9524.aspx

Hope this helps..

Craig..

craig beuker

Hello,

Ok. From talking with the MS Support person, they have basically
told us that we are on our own with regards to using File Receive
Locations against folders published by Samba on Linux.

reference: http://support.microsoft.com/?id=815070

So it's off to the FTP Receive Adapter I go. I have configured the FTP
Receive Adapter to use a folder local on the same machine as BizTalk is
running on. I threw a 50 meg file into the folder the FTP receive
function monitors and noticed that the file does get copied to this
temporary folder before biztalk sucks it in.

Anyways, For those that might be running into the similar issues
with netbios command limits and/or issues with File Receive Locations.
Hopefully this will help. Here is the email we received from our MS
Support Dude outlining the issues we were encountering: cmb..
<<start of email>>

In the cases that we are seeing the problem is two fold.
1) The NETBIOS command limit has been reached in the redirector or on the
Server (Note CMB: I believe this came from my query about "The redirector
failed to determine the connection type", event ID: 3019.)
2) BizTalk 2004 has encountered a coding defect in the BTSMsgCore!
CFileWatcher code (Note CMB: As we are pulling stuff from Linux and not
Windows, it's 'unsupported', hence no fix.)

============
PROBLEM ONE:
============

The first problem happens because the typical user of UNC location is
generally configured to connect to a single Server. Exceeding the Maximum
Command Limit or Work Contexts for the Redirector or Server. This can
occur if the amount of long term commands is greater than the negotiated
maximum command limit between the clients (BIZTALK server) and file
server. If a BIZTALK server has a large number of sites or virtual
directories mapped to a UNC path, they can exceed these limits. The
solution is to increase the values for MaxCmds on the BIZTALK server and
MaxMpxCt on the file server side. This is important because each
outstanding File Change Notification requires a work context. If there
are not enough work contexts or if MaxCmds is too low, some File Change
Notification requests will not be satisfied. The limit that can be used
is the lesser of MaxCmds or MaxMpxCt, and the explicit number is sent
from the server to the client in the negotiation part of an SMB session
setup. Because this can be either a Client or a Server problem we
recommend that you raise the Command limit on both the Client (Biztalk )
and the Server (Share Host machine). Knowledge base article 810886
outlines the procedure and requirements to complete this task. You should
use a value twice that of the total number of FRL in the Biztalk Server.

REMEMBER TO REBOOT THE SERVER AFTER MAKING THE CHANGE!!!!!!!

For additional information, click the article numbers below to view the
articles in the Microsoft Knowledge Base:

- MaxMpxCt and MaxCmds Limits in Windows 2000/2003 -
http://support.microsoft.com/default.aspx?scid=kb;en-us;810886

- How to Troubleshoot Event ID 2021 and Event ID 2022 -
http://support.microsoft.com/default.aspx?scid=kb;en-us;317249

Error Message: Error 56 - The Network BIOS Command Limit Has Been Reached
-

NOTE: Raising the Max Command limit has a cost in additional kernel mode
resources.


============
PROBLEM TWO:
============

This problem manifests itself by the FRL appearing not to pick up
documents or to take a long time to pick up documents. This problem is
due to the polling mechanism used in Biztalk 2004. Biztalk uses the
FindFirstChangeNotificationW() API to register and get a handle for event
notifications for changes in a directory or a UNC in this case then uses
the FindNextChangeNotificationW() API to get further notifications. These
notifications are not tied to any specific thread and this coupled with
the fact that Biztalk 2004 uses its own polling mechanism causes
problems in the CFileWatcher class. When a handle get a notification
for change the directory that Biztalk looks in is another. The result
is that if there are no files in the directory that Biztalk is looking
no documents are pulled into Messaging however the directory that the
notification was for contains a document that will not be pulled into
Biztalk. To resolve this then you can disable polling in Biztalk 2004.


- Disable FRF polling by modifying the registry:

By default the registry key does not exist in the registry it is
necessary to define needed registry keys under:

Registry hive -

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\BTSSvs{GUID}\.Key
Name FileReceivePollingInterval
Type - DWORD
Value - 1


For additional information, click the article numbers below to view the
articles in

the Microsoft Knowledge Base:

FileReceivePollingInterval -
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/operations/htm/ebiz_ops_adapt_file_lahz.asp

FindFirstChangeNotificationW -
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/fileio/base/findfirstchangenotification.asp

FindNextChangeNotification - http://msdn.microsoft.com/library/default.asp?url=/library/en- us/fileio/base/findnextchangenotification.asp
<<end of email>>