Skip to main content
Kofax

Delay Opening, Closing and Processing Batches

Article # 3031683 - Page views: 461

Article # 3031683 - Page views: 461

Issue

There is a delay when opening Batch Manager, creating a new batch, processing a batch in Batch Manager, Scan, Validation, and other Kofax Capture modules from client workstations. 

Cause

  • Network connection/Firewall/Proxy
  • Bad configuration
  • Antivirus

Solution

1.    Perform a Process Monitor trace and look for an unusual number of TCP Reconnect operations.  These may be an indicator that something on the network is temporarily blocking or delaying traffic between the workstation and the Capture server on certain ports.

The Process Monitor trace will show something like the following:

Process Name: Kofax Capture module process name that is being monitored. Batch Manager module will show as ops.exe.

PID: Random number assigned by the Operating System.

Operation: TCP Reconnect

Path: workstationmachinename:portnumber1 -> servermachinename:portnumber2

Result: SUCCESS

Detail: Length: 0, seqnum: 0, connid: 0

Opening portnumber2 on the network should resolve the issue.

2.    Using Kofax Capture with a traditional client/server architecture over a WAN is not recommended by Kofax because it can lead to performance degradation impacting the user experience and usability of the software. This is not a limitation of our software, but rather has to do with network latency

3.    Kofax Capture never opens MDB files over the network, but copies them to \Ascent\Local to ensure local access. That is why you encounter a delay during batch open and close - the MDB (typically ~1MB) gets copied from/to the server then. You can avoid this by configuring KC to use "Batches in SQL"

4.    At least one case showed the results of a Process Monitor trace with 'TCP Reconnect' operations.

- A review of that TCP Reconnect operation detail showed the path pointing to an external website, as follows:

Date & Time: 2015-07-16 10:35:54

Event Class: Network

Operation: TCP Reconnect

Result: SUCCESS

Path: SIWNUMDEQ01.int.rrq.qc:7749 -> 207.34.231.56:http

TID: 0

Duration: 0.0000000

Length: 0

seqnum: 0

connid: 0

At least one case resolved this issue with these steps:

A.   1.Click Start > Control Panel > Internet Options.

B.   2.On the Advanced tab, unmark Check for Publisher's certificate revocation under Security, and click OK.

- A restart is not required

5.    This problem can be caused by the Batch Notification Service that is delaying the batch creation process from the Client-Workstation machine. This problem is normally followed by the following error message logged on the Kofax Capture ERR_yymm.txt log file:

"The call from a client to the server indicating that a batch is available failed. This can happen if the Kofax Capture Service isn’t running on the server, the Batch Notification Service isn’t installed, or the server isn’t connected to the network., Unable to connect to the remote server, "

6.    Check the Temporary Image Folder path for the Batch Class being used, ensuring that the path is pointing to the correct location and is accessible. Also, try a local folder path as a test to see if any delay is related to network access.

7.    This can be caused by firewall rules on the client side firewall on the server. There are several ways to fix this, the simplest being to create two rules to allow both sqlservr.exe and sqlbrowser.exe. You can also allow port 1434 for the SQL Browser service and specify the Kofax SQL Server instance in SQL Server Configuration Manager, and then allow that port.

8.    This can be caused by an improper server path and server name entry in the Registry on the workstations. Check the following Registry Key:

HKey_Local_Machine\Software\Kofax Image Products\Ascent Capture\3.0

On a 64-bit machine the Key path will be:

HKey_Local_Machine\Software\Wow6432Node\Kofax Image Products\Ascent Capture\3.0

Look for the following entries:

ServerName

ServerPath

ServerName should contain the machine name of the server.

ServerPath should have the UNC path to the CaptureSV share, for example: \\<Server_Name>\CaptureSV.

If the format is in the form of a domain path such as \\domain.net\apps\kofax, then the workstations will be contacting the server by going through the network top level and drilling down through the network, which will cause the delay.

9.    It was observed in one case that the account running the module did not have proper DCOM (Distributed Component Object Model) permissions configured. In this case, the Local Launch and Local Activation permissions were added to the following DCOM key: F41460E1-F8F2-409D-AD1F-C177F3F837B8 to resolve this issue.

Open Component Services by typing the following in the Start | Run: MMC comexp.msc /32

Navigate to: COM+ Applications -> DCOM config

Locate and right click on one of the three aforementioned keys and select properties.

Add the configured Service account to security and give it “Local Launch” and “Local Activation” permissions.

DCOM setting.png

10.   In some cases, it has been observed that disabling Kofax Reporting will resolve this issue. Kofax Reporting flushes statistical data to disk upon the closing of a Batch, therefore a delay might be due to accessing the storage which is located at %ALLUSERSPROFILE%\Kofax\Reporting\Client\Log. Use the following steps to disable Kofax Reporting if it is not being used:

  1. Back up the current ACConfig.xml file.
  2. Add the following element to the \\<ServerName>\CaptureSV\Config\ACConfig.xml file to the bottom right above the </ACConfig> closing tag:
    <ACConfig>
       ...
       <Reporting Enable="2"/>
       ...
    </ACConfig>
  3. Save this change.
  4. Restart the Kofax Capture service from the Service Control Manager.

 

Level of Complexity 

High

 

Applies to  

Product Version Build Environment Hardware
Kofax Capture 11.x N/A N/A N/A

References

22663, 22484,21347,20663, 15921,15802, 15458, 14722