Receiving this error when trying to launch Kofax Capture modules on a workstation
 KdoLib: Network I/O error.: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified) (-1).
The reason that we receive this error message is that the client stack could not receive the SSRP response UDP packet from SQL Browser.
Once you have performed the steps, you should not see this error message anymore. You may still fail to connect to SQL Server, but the error message should be different, with a different issue.
Every time a client makes a connection to the SQL Server named instance, we will send a SSRP UDP packet to the server machine UDP port 1434. We need this step to determine configuration information of the SQL instance, e.g., protocols enabled, TCP port, pipe name, etc. Without this information, the client doesn't know how to connect to the server and it fails with this specific error message.
1. Make sure the server name is correct, e.g., with no typo(s) in the name.
2. Make sure the instance name is correct and there is actually such an instance on the target machine. Some applications convert \\ to \. If you are not sure about the application, please try both Server\Instance and Server\\Instance in the connection string.
3. Make sure that both SQL Server Browser and SQL Server services are running on the server, using the "network service" account (default) or running as the local system account (try this if network service is already given). It has been seen that running the SQL Server Browser using a specific user and also using "network service" did not work.
4. If a firewall is enabled on the server, you need to put sqlbrowser.exe and/or UDP port 1434 into the exception list.
NOTE: On 64-bit systems, there are two Registry Key locations that store which port to use with which server (in this case, the server name = KCServer):
On a regular 32-bit system and on a 64-bit system for 64-bit applications, this goes here:
However, something that does not get created on a 64-bit system is the following Key:
" KCServer "="DBMSSOCN, KCServer,<Listening_Port>"
On 64-bit systems, make sure to run the 32-bit ODBC tool to create the proper Registry Keys and Values.
5. This error can occur if the workstation is not configured to use the same dynamic port that the SQL Server instance is listening on.
To resolve this issue:
a) Determine the dynamic port that the SQL Server instance is listening on.
b) Launch SQL Server Configuration Manager.
c) Under the SQL Server Network Configuration, select Protocols for <Instance Name>.
d) Right-click on TCP/IP protocol and select Properties.
e) Under the IP Addresses tab, scroll down to the IPAll section where it shows the “TCP Dynamic Ports” value.
f) Make an ODBC connection to the SQL Server instance using the dynamic port.
g) Run odbcad32.exe from either the Windows\System32 folder for a 32-bit machine or from the Windows\SysWOW64 folder for a 64-bit machine.
h) Click on the System DSN tab and add a new data source using SQL Server as the driver.
i) Provide a test name and SQL Server (Ex. [Server Name]\[Instance Name]) and click on Next.
j) Click on “Client Configuration”, uncheck “Dynamically determine port”, specify the dynamic port determined from Step 1 and click OK.
k) Click Next which may result in an “Login failed for user” error which means that the workstation is now able to connect to the SQL server instance using the dynamic port. Now, click Cancel.
A registry key named [Server Name]\[Instance Name] is now created under the following registry hive:
For 32-bit systems:
For 64-bit systems:
The value of this registry key will contain the dynamic port.
6. It has been seen in at least one case the customer opened up all the ports we require through the firewall but not the security group that was controlling the access. Once the customer opened up the proper ports within the Security Group everything worked like it should.
Here are the ports involved (Both inbound and outbound need to be set up):
TCP Ports:1433, 1434, 2424, and the Dynamic SQL Port
Check the client to make sure that it is configured to use the same dynamic port that the server is listening on.
7. In one instance, it was found that the IP-address was used instead of the machine-name for the ServerPath registry value. Kofax recommends using the machine name, however, if this cannot be used, the following may help resolve this issue.
NOTE: The following change will affect the machines network configuration. Consult with your network support prior to making these changes to verify that no other applications will be affected.
Adding a DNS entry to the Hosts file will resolve this.
The path to the Hosts file in Windows 7 is:
where %systemroot% is usually c:\windows unless you installed Windows on a different partition.
Make sure the server machine is reachable, e.g, DNS can be resolved correctly, and you are able to ping the server (not always true).
Level of Complexity
22648, 22558, 16859, 10683, 11452
Article # 3031693