Partilhar via


Message for the File Send Adapter remains in active state

This was an interesting issue on which I worked with Shaheer (Biztalk Escalation Engineer) for 2 customers, so I thought I would share it with all.

Customer is using File Adapter at Send Port to write files to a file server. Sometimes, the send message stuck inside in Biztalk with active status and a 0 Kb file is created on the share on the file server. The message remains in active state until we restart the host instance, and then the message is written to the file share.

We took the Biztalk traces and although we did not see anything for the send port other than them being stuck, at the same time that the send ports were stuck, we could see the receive locations hitting the same file server were throwing error 0x800703E5 and Win32 Error = 56 in the traces and even sometimes 80070038

[filelistener]Network connection to location (\\<fileshare>) is down. Error = 80070038

--- 0x80070038 means:
ERROR_TOO_MANY_CMDS winerror.h
# The network BIOS command limit has been reached.

--- 0x800703E5 means:
ERROR_IO_PENDING winerror.h
Overlapped I/O operation is in progress.

--- Win32 Error = 56 means:
Network Bios Command limit has been reached.

This means the network bios command limit has been reached between the Biztalk Sever and the file server. This can happen when there is a very high load of SMB traffic between Windows servers since the default network bios command limit may not be high enough to handle this load. This will effect any SMB traffic between BTS & that file server so even though the error in trace was happening for receive location, it would apply to send port hitting same file server also.

Now comes the resolution part:

Need to follow the below steps as per KB 810886 to increase command limit by setting BOTH of the following registry keys on all the Biztalk Servers AND the File server AND any other file server that you may have problems with:
1. Click Start, click Run, type regedit, and then click OK.
2. Locate and then click the following key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters
3. In the right pane, double-click the MaxCmds value and in the Value data box change the value to decimal 5000. (If the MaxCmds value does not exist, create it as a new REG_DWORD value of decimal 5000)
4. Locate and then click the following key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters
5. In the right-pane, double-click the MaxMpxCt value and in the Value data box change the value to decimal 5000. (If the MaxMpxCt value does not exist, create it as a new REG_DWORD value of decimal 5000)
6. Quit Registry Editor.
7. Reboot the computer

We have said above value 5000, taking less cautious route to start with a high value and work your way down. If we want to be cautious, we can start by increasing it to 1000 and then see if we still have the problem and if so, increase it again. In a very high load environment, even 5000 may not be enough and the value would have to be increased further. Only thing we could think with high value even as high as 50,000 is that we may run into high cpu on file server if it can't handle the load.

[Note: The maximum number of simultaneous, active requests between an SMB client and the server is determined when a client/server session is negotiated. The maximum number of requests that a client supports is determined by the MaxCmds registry value. The maximum number of requests that a server supports is determined by the MaxMpxCt registry value. For a particular client and server pair, the number of simultaneous, active requests is the lesser of these two values. This is documented at KB 810886.]