BizTalk Server General - BizTalk 2004: File Receive Location Problem

Author

BizTalk 2004: File Receive Location Problem

Craig Beuker

2005-12-12, 8:48 pm

Greetings all.

I am investigating/trying to resolve an issue with BizTalk and a
pile of file receive functions monitoring different folders on a remote
linux box via file shares..

I have noticed that the files on our file shares aren't picked up
some times and that the receive locations end up shutting down saying it
exhausted network retry events.

While scouring google groups, I came across a post by Rasmus
Kristensen (subj: Files are taking long time to be picked up by a file
receive location on a network fileshare) which talks about the redirector
object / current commands counter in PerfMon and that if the value is to
high, it will cause problems. He also mentioned setting the
"FileReceivePollingInterval" for the biztalk service to 1 to prevent
polling of the folder (which reduced the number of current commands.)

I attempted this as well but noticed that files were just sitting in
our directories, not getting picked up at all. The BizTalk receive
locations were still running however but they didn't seem to do anything.
If I stopped and started BizTalk, shortly thereafter the files would
disappear and be processed.

So, being the vaguely curious fellow that I am, I started looking
into this redirector::Current Commands counter to find out what exactly
it is. And what values I should be expecting for this counter so I have
a rough idea what to look for. I came across the following:

"Shows the number of requests to the Redirector that are currently queued
for service. If this number is much larger than the number of network
adapter cards installed in the computer, the network(s) and/or the server
(s) being accessed are seriously bottlenecked."
(source:
http://www.microsoft.com/resources/...000/server/resk
it/en-us/Default.asp?
url=/resources/documentation/Windows/2000/server/reskit/en-
us/counters/counters2_irof.asp)

And this:

"Current Commands: This counts the number of requests to the Redirector
that are currently queued for service. Ideally, this value should not be
more than one command per installed NIC. If a value higher than one is
present, the redirector may be the bottleneck. This can happen if there
is an asymmetry between the speed of server and the redirector which is
causing inefficient communication between the local and remote systems.
This can also indicate that the network capacity is being pushed to its
limits and that it may be necessary to break the network into subnetworks
to reduce traffic."
(source: http://www.windowsitlibrary.com/Content/435/09/3.html)

So, the questions then are:
1) Why is this counter so high? On our current production box, the value
is lurking at about 34 (it varies slightly from time to time) and I am
pretty sure that we do not have 34 network cards on this machine. Our
Biztalk Server has roughly 27 receive locations pointing to various
directories on this Linux box where clients FTP files to. Plus a few
other receive functions pointing to other boxes (windows 2003) and local
directoriess
a) Does this counter go up by one for every file receive location
defined?
b) Should I *really* be concerned about this counter, or am I just
focusing on the wrong issue because the counter value is abnormally high
compared to what seems to be the going theory on how high this should be?
c) What happens if we put a pile more file recieve locations
pointing to this Linux server (say 30 more). Rasmus, mentioned in the
thread I mentioned at the start of this post that there seemed to be a
ceiling of about 50 current commands. Would this start causing BizTalk
to shut down receive locations more frequently because network attempts
have been exhausted?

2) What can I do to lower this counter? Is there anything which can be
done or will it 'just be that high given the number of file receive
locations being used'? Should I change the configuration and just use
the FTP file receive to ftp files from our FTP server to BizTalk instead?
(I would rather not)

3) I have also been noticing a lot of events from the MRxSmb source
stating that "The redirector failed to determine the connection type"
(event ID: 3019. See: http://www.eventid.net/display.asp?eventid=3019
&eventno=149&source=MRxSmb&phase=1). Given that this seems to be related
to the Redirector (mentioned above) as well, does this have something to
do with this problem? I keep reading in other posts that this warning
can safely be ignored. This just doesn't sit right with me given that
the current command counter seems high according to what I am reading.

Anyone have any thoughts/ideas on the subject?

Thanks in advance..

Craig..

WenJun Zhang[msft]

2005-12-13, 7:54 am

Hi Craig,

Does the problem only occurs on the linux file shares and doesn't happen on
the Windows 2003 share location? If so, this is probably a platform
compatibility issue. Which file share engine are you using?

BizTalk need to register for file change notifications with the file
system. I'm not familiar with Linux file sharing mechanism. I just heard
that NFS doesn't support this. Samba has file change notification which can
work with biztalk file receive function but please understand we do not
officially guarantee this is supported since we have no control over the
samba provider.

So if this does seem to be a compatibility issue, I'd recommend you switch
to HTTP/FTP receive to have a try.

Hope the info can be of some help. Thanks.

Best regards,

WenJun Zhang
Microsoft Online Partner Support

This posting is provided "AS IS" with no warranties, and confers no rights.

Craig Beuker

2005-12-14, 5:54 pm

wjzhang@online.microsoft.com ("WenJun Zhang[msft]") wrote in
news:bwkwTW#$FHA.832@TK2MSFTNGXA02.phx.gbl:

Greetings WenJun,

Our FTP server is running RedHat Linux and the file shares are
managed by Samba Server.

Well, this problem doesn't seem to occur consistently. Yesterday
morning I tried creating a empty .xml file in my one file receive
location and BizTalk seemed to pick it up without any issues, This
morning however, it decided not to pick it up. This indicates to me
BizTalk is getting the file receive events, sometimes. When we were
doing our testing on this environment, we didn't notice anything out of
the ordinary. BizTalk seems to work fine on these shares and then
mystically seems to stop listening.

In our old production environment before we moved servers, were we
used a Windows 2003 box as our FTP server where clients sent files to us.
The folders were exposed as a share and we just used a BizTalk File
Receive location to grab the files from these folders. We did have
issues where Receive Locations would shut down because the number of
network retries were exhausted (which lead me to all articles I mentioned
in the original post with reguards to the redirector and my concerns
about the Redirector:Current Commands counter being really high).

My original questions from my original post remain:

1) Why is the Redirector::Current Commands so high? Is it always like
this when using BizTalk Receive locations pointing to other machines? Is
it the cause of the problems? Is there anything which can be down about
it? Is the reason this counter is so high is because it is registering
for the file events from the remote system?

2) Is the event ID 3019 "The redirector failed to determine the
connection type" that I am seeing fill up the event logs in any way
something I should be concerned about with reguards to this problem?

Tbanks in advance..

Craig..

> Hi Craig,
>
> Does the problem only occurs on the linux file shares and doesn't
> happen on the Windows 2003 share location? If so, this is probably a
> platform compatibility issue. Which file share engine are you using?
>
> BizTalk need to register for file change notifications with the file
> system. I'm not familiar with Linux file sharing mechanism. I just
> heard that NFS doesn't support this. Samba has file change
> notification which can work with biztalk file receive function but
> please understand we do not officially guarantee this is supported
> since we have no control over the samba provider.
>
> So if this does seem to be a compatibility issue, I'd recommend you
> switch to HTTP/FTP receive to have a try.
>
> Hope the info can be of some help. Thanks.
>
> Best regards,
>
> WenJun Zhang
> Microsoft Online Partner Support
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>

Craig Beuker

2005-12-14, 8:49 pm

Craig Beuker <beukerc@community.nospam> wrote in
news:Xns972C621412E6Cbeukerccommunitynos
p@207.46.248.16:

Hello,

Thought I already made a post about this. Oh well, if you see
another post from me on this thread with the same general questions, you
can ignore it. :-)

Just a follow up from some more investigating.

It seems that the problem involves the number of files written to
share at one time. If I write 50 or so files to the share, about half
will get picked up and the rest will just sit there until another file is
dropped into the folder.

I have a question about the BizTalk File Receive Adapter. As I
understand it, it relies on file events being raised on directories being
monitors to determine if action needs to be taken on a directory (ie:
process files in the directory). Is that correct?

Also, as I mentioned, I was tinkering with the registry entry
FileReceivePollingInterval. When does this kick in as opposed to the
file events? I currently have this value set to 10000 in the registry.
As I understand it, this will tell the file receive adapter to poll the
monitored location every 10 seconds for files. Correct? If this is the
case, then this isn't working either from what I can tell. If I paste my
50 test files into the directory on our samba share, as I mentioned, some
will be processed and the rest will just sit there. The polling value
seems to have no effect as the rest of the files will sit there for much
longer than 10 seconds.

Thoughts, comments?

Thanks in advance.

Craig..

> Hi Craig,
>
> Does the problem only occurs on the linux file shares and doesn't
> happen on the Windows 2003 share location? If so, this is probably a
> platform compatibility issue. Which file share engine are you using?
>
> BizTalk need to register for file change notifications with the file
> system. I'm not familiar with Linux file sharing mechanism. I just
> heard that NFS doesn't support this. Samba has file change
> notification which can work with biztalk file receive function but
> please understand we do not officially guarantee this is supported
> since we have no control over the samba provider.
>
> So if this does seem to be a compatibility issue, I'd recommend you
> switch to HTTP/FTP receive to have a try.
>
> Hope the info can be of some help. Thanks.
>
> Best regards,
>
> WenJun Zhang
> Microsoft Online Partner Support
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>

WenJun Zhang[msft]

2005-12-16, 7:48 am

Hi Craig,

Yes, the FileReceivePollingInterval registry key controls the polling
feature of File Receive adapter. It should look for files remain in the
directory if file change notifications are not processed in time.

In the case you mentioned, about a half of the 50 files are processed and
the rest are stuck in the queue. Have you checked if the file receive
location is disabled at that time?

I hread the high number of connections ("Current Commands" on Redirector)
could be caused by BizTalk file receive locations simultaneously using
directory change notification and simple directory polling. So you may also
disable the polling by set FileReceivePollingInterval to 1 to have a test.

Another suggestion is you may enable BTS2004 adapter trace to take a look.

835451 How to use the BizTalk Adapter Trace Utility in BizTalk Server 2004
http://support.microsoft.com/?id=835451

Best regards,

WenJun Zhang
Microsoft Online Partner Support

This posting is provided "AS IS" with no warranties, and confers no rights.

Hersh

2005-12-16, 5:54 pm

Hi Craig,

I was having a similar issue with "exhausted network retry" errors.
When checking the "Current Command" count on our server it seems to top
out at 50 and refuses to go above that number. We have over 50 receive
location. I noticed that anytime a receive location was enabled the
"Current Command" count increased by one on the server that provides
the Windows Share . I'm guessing that everytime the location is
enabled the file adapter registers a handle using
FindFirstChangeNotification (which increases the Current Command?).
After some searching I came across this article
http://support.microsoft.com/?id=810886 (KB 810886) and applied these
changes to both the server and client machine. This change seems to
have fixed our problem. I can't verify 100% as we have only been
running with the change for a day. However, ports used to shutdown
often and now all have been running for a day.

I'm still not entirely sure what "Current Command" is, but the
Current Command on our Windows Share server is over 100 now and we
definetly do not have 100 NICs. I took a look at the network counters
provided in performance monitor and didn't notice any strange network
activity. So I'm still not sure why it is suggested that this number
be lower then the number of NICs.

Hope this helps,
Hersh

Craig Beuker

2005-12-19, 8:49 pm

"Hersh" <m3o3o3@gmail.com> wrote in news:1134747390.100399.317560
@g14g2000cwa.googlegroups.com:

Greetings,

We were getting that error in our previous environment prior to
getting new servers.. Now the problem seems to have morphed to the one
we are currently experiencing.

We have opened a ticket is MS Product support on the issue. Will
update this thread when we find out what the deal is.

In the mean time, figuring its time to look at other options, I have
begun investigating using the FTP receive adapter to pull the files from
the FTP server. I have noticed that this adapter isn't without it's own
set of 'features'. Specifically, possibly submitting multiple copies of
a message to BizTalk because a file transmission isn't complete yet.

Charles Young blogged about it and guarenteed delivering using the
FTP adapter
(http://geekswithblogs.net/cyoung/ar...08/10/9524.aspx) by using
the temporary folder setting when putting together the FTP receive
location.

So, from my reading, for using the FTP Send adapter, you have to set
the temporary folder to a folder on the FTP server you are sending the
data to.

However, for using the FTP Receive adapter, you have to set the
temporary folder to a local folder on the machine BizTalk is running on,
is that correct?

How exactly do these temporary folders work with regards to a file
transfer? For the receive FTP adapter, I get the impression that files
are transferred to the FTP site, and the FTP adapter moves them, when
completed, to this temp folder. From there, BizTalk picks it up and
processes the complete file. Please correct me if I am wrong, which I
probably am.

Thanks in advance.

Craig.

> Hi Craig,
>
> I was having a similar issue with "exhausted network retry" errors.
> When checking the "Current Command" count on our server it seems to top
> out at 50 and refuses to go above that number. We have over 50 receive
> location. I noticed that anytime a receive location was enabled the
> "Current Command" count increased by one on the server that provides
> the Windows Share . I'm guessing that everytime the location is
> enabled the file adapter registers a handle using
> FindFirstChangeNotification (which increases the Current Command?).
> After some searching I came across this article
> http://support.microsoft.com/?id=810886 (KB 810886) and applied these
> changes to both the server and client machine. This change seems to
> have fixed our problem. I can't verify 100% as we have only been
> running with the change for a day. However, ports used to shutdown
> often and now all have been running for a day.
>
> I'm still not entirely sure what "Current Command" is, but the
> Current Command on our Windows Share server is over 100 now and we
> definetly do not have 100 NICs. I took a look at the network counters
> provided in performance monitor and didn't notice any strange network
> activity. So I'm still not sure why it is suggested that this number
> be lower then the number of NICs.
>
> Hope this helps,
> Hersh
>

WenJun Zhang[msft]

2005-12-20, 7:59 am

Hi Craig,

It's ideal that you have opened a case for this issue.

"However, for using the FTP Receive adapter, you have to set the temporary
folder to a local folder on the machine BizTalk is running on, is that
correct?"

Yes, it should be on the same harddisk. The details about how temporary
folder works can be found in the following article:

886989 Data may be duplicated or lost when you receive data in BizTalk
Server
http://support.microsoft.com/?id=886989

I'll wait for your update.

Thanks & Have a nice day!

Best regards,

WenJun Zhang
Microsoft Online Partner Support

This posting is provided "AS IS" with no warranties, and confers no rights.

Craig Beuker

2005-12-20, 5:54 pm

wjzhang@online.microsoft.com ("WenJun Zhang[msft]") wrote in
news:ZeGKLlVBGHA.1236@TK2MSFTNGXA02.phx.gbl:

Greetings,

Comments inline..

> "However, for using the FTP Receive adapter, you have to set the
> temporary folder to a local folder on the machine BizTalk is running
> on, is that correct?"
>
> Yes, it should be on the same harddisk. The details about how
> temporary folder works can be found in the following article:
>
> 886989 Data may be duplicated or lost when you receive data in BizTalk
> Server
> http://support.microsoft.com/?id=886989

I saw this article and somewhat understood what it was saying.

So, I have the following tree on the FTP Server:
<ftpRoot>\Client\send
<ftpRoot>\Client\sendStaging
<ftpRoot>\Client\receive

where:
"send" folder is where they put files.
"sendStaging" would be my "Temporary folder"
"receive" is where I put files the client downloads.

I tried putting the folder (sendStaging) on the FTP Server (our Linux
box) as I described above and got the following warnings and errors
before the FTP receive adapter shut down:

Our FTP machine is running RedHat Enterprise Linux, release 4

----
Warning (11 of these, which match the "number of errors before shutdown"
property on the FTP Receive adapter):

The adapter "FTP" raised an error message. Details "Could not find a part
of the path "sendStaging".".

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

-----
I then got the following errors (many of these)
The receive location "ftp://<server>:21/send/*.csv" is shutting down.
Details:"Error Threshold exceeded ".

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

---

Does the Temporary Folder have to be an absolute path?
For example \home\client\sendStaging or something like that?

If I put the sendStaging folder on the BizTalk server, the error goes
away, but I have no idea if it's being used. I see nothing in the logs
referring to that sendStaging folder. And from the article you
mentioned, from sounds of it, this is bad anyways..

Thoughts, comments?

Thanks in advance

Craig..

WenJun Zhang[msft]

2005-12-23, 7:49 am

Hi Craig,

Yes, for FTP receiving scenario, the temp folder should be located on your
BizTalk machine. The detailed story is explained in the following article:

BizTalk Server 2004: FTP guaranteed delivery
http://geekswithblogs.net/cyoung/ar...08/10/9524.aspx

Thanks.

Best regards,

WenJun Zhang
Microsoft Online Partner Support

This posting is provided "AS IS" with no warranties, and confers no rights.

sachuhere@gmail.com

2006-01-01, 6:00 pm

Hi Everyone,

Wish u all a very happy and peaceful new year, though I dont have
so.

I have 2 big problem and I really wants help from you all. Our project
has gone live for past one month and the problem what we are facing
currently is similar to some thing what I read below. We never faced
the problem in any of our Dev/Test/Pre-Prod Boxes.

Prob-1 : We have total 8 different orchestration for downloading the
file does different processing and 7 different orchestration for
uploading the file. this has total of some where around 50-60 receive
location. Out of which few receive location are shutting down
randomlly. For a network share, the File receive adapter disables few
of the receive location after all retry attempts have been exhausted.

The error what I get in EventLog is "The receivelocation is shutting
down after all retry attempts have been exhausted".

Prob-2 : We download file from FTP Server using Microsoft FTP Adapter.
There is two different types of file which has to be downloaded , one
transaction file and another trailer file.
Transaction files are big in size lets say 400-500 MB where as trailer
file is only 1KB (some 82 bytes). First transaction file is dropped to
FTP Server and once that is finished trailer file is dropped to FTP
Location.
We have our receive location polling to FTP Server for trailer file
which indicates that trasaction file is completly dropped into FTP
Server , this is to avoid partial file download. The moment trailer
file is dropped biztalk picks up and start processing , but this happen
so fast that biztalk sees the trailer file in the FTP Server location
when it is just dropped it picks that up and at that time the file is
not even copied fully to that FTP Server location which makes biztalk
process a 0 KB file where as the actual file is 1KB.

I am really in help from you all. I really appritiate if some one can
help me in this regard.

Sachin.

Craig Beuker wrote:[vbcol=seagreen]
> wjzhang@online.microsoft.com ("WenJun Zhang[msft]") wrote in
> news:bwkwTW#$FHA.832@TK2MSFTNGXA02.phx.gbl:
>
> Greetings WenJun,
>
> Our FTP server is running RedHat Linux and the file shares are
> managed by Samba Server.
>
> Well, this problem doesn't seem to occur consistently. Yesterday
> morning I tried creating a empty .xml file in my one file receive
> location and BizTalk seemed to pick it up without any issues, This
> morning however, it decided not to pick it up. This indicates to me
> BizTalk is getting the file receive events, sometimes. When we were
> doing our testing on this environment, we didn't notice anything out of
> the ordinary. BizTalk seems to work fine on these shares and then
> mystically seems to stop listening.
>
> In our old production environment before we moved servers, were we
> used a Windows 2003 box as our FTP server where clients sent files to us.
> The folders were exposed as a share and we just used a BizTalk File
> Receive location to grab the files from these folders. We did have
> issues where Receive Locations would shut down because the number of
> network retries were exhausted (which lead me to all articles I mentioned
> in the original post with reguards to the redirector and my concerns
> about the Redirector:Current Commands counter being really high).
>
> My original questions from my original post remain:
>
> 1) Why is the Redirector::Current Commands so high? Is it always like
> this when using BizTalk Receive locations pointing to other machines? Is
> it the cause of the problems? Is there anything which can be down about
> it? Is the reason this counter is so high is because it is registering
> for the file events from the remote system?
>
> 2) Is the event ID 3019 "The redirector failed to determine the
> connection type" that I am seeing fill up the event logs in any way
> something I should be concerned about with reguards to this problem?
>
> Tbanks in advance..
>
> Craig..
>

Craig Beuker

2006-01-09, 5:57 pm

Greetings,

My comments are inline.

sachuhere@gmail.com wrote in
news:1136149592.871924.61630@g43g2000cwa.googlegroups.com:

> Hi Everyone,
>
> Wish u all a very happy and peaceful new year, though I dont have
> so.
>
> I have 2 big problem and I really wants help from you all. Our project
> has gone live for past one month and the problem what we are facing
> currently is similar to some thing what I read below. We never faced
> the problem in any of our Dev/Test/Pre-Prod Boxes.
>
> Prob-1 : We have total 8 different orchestration for downloading the
> file does different processing and 7 different orchestration for
> uploading the file. this has total of some where around 50-60 receive
> location. Out of which few receive location are shutting down
> randomlly. For a network share, the File receive adapter disables few
> of the receive location after all retry attempts have been exhausted.
>
> The error what I get in EventLog is "The receivelocation is shutting
> down after all retry attempts have been exhausted".

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/defaul...b;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

> Prob-2 : We download file from FTP Server using Microsoft FTP Adapter.
> There is two different types of file which has to be downloaded , one
> transaction file and another trailer file.
> Transaction files are big in size lets say 400-500 MB where as trailer
> file is only 1KB (some 82 bytes). First transaction file is dropped to
> FTP Server and once that is finished trailer file is dropped to FTP
> Location.
> We have our receive location polling to FTP Server for trailer file
> which indicates that trasaction file is completly dropped into FTP
> Server , this is to avoid partial file download. The moment trailer
> file is dropped biztalk picks up and start processing , but this
> happen so fast that biztalk sees the trailer file in the FTP Server
> location when it is just dropped it picks that up and at that time the
> file is not even copied fully to that FTP Server location which makes
> biztalk process a 0 KB file where as the actual file is 1KB.
>
> I am really in help from you all. I really appritiate if some one can
> help me in this regard.
>
> Sachin.

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/ar...08/10/9524.aspx

Hope this helps..

Craig..

Craig Beuker

2006-01-13, 9:59 pm

wjzhang@online.microsoft.com ("WenJun Zhang[msft]") wrote in
news:aamKqj6BGHA.1236@TK2MSFTNGXA02.phx.gbl:

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/defaul...kb;en-us;810886

- How to Troubleshoot Event ID 2021 and Event ID 2022 -
http://support.microsoft.com/defaul...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\CurrentControl
Set\Services\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/d...rl=/library/en-
us/operations/htm/ebiz_ops_adapt_file_lahz.asp

FindFirstChangeNotificationW -
http://msdn.microsoft.com/library/d...rl=/library/en-
us/fileio/base/findfirstchangenotification.asp

FindNextChangeNotification -
http://msdn.microsoft.com/library/d...rl=/library/en-
us/fileio/base/findnextchangenotification.asp

<<end of email>>

> Hi Craig,
>
> Yes, for FTP receiving scenario, the temp folder should be located on
> your BizTalk machine. The detailed story is explained in the following
> article:
>
> BizTalk Server 2004: FTP guaranteed delivery
> http://geekswithblogs.net/cyoung/ar...08/10/9524.aspx
>
> Thanks.
>
> Best regards,
>
> WenJun Zhang
> Microsoft Online Partner Support
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>