Question

797 Errors

Version 10

Updated July 18, 2016

asked on June 2, 2016 • Show version history

Hello,

We're running version 10.1 of Rio. Of late, we've been getting lots of 797 errors. I believe that we've traced the connectivity issue down to our antivirus software VIPRE. When it's turned completely off on my machine, I don't get the errors. As soon as I turn it back on, I do. We've created exemptions in the software for c:\program files\laserfiche (and it’s x86 cousin) and c:\program files\common files (and it’s x86 counterpart). Does anyone know if there are other areas that might need exemptions?

Thanks,

Michael

0 0

Replies

replied on June 6, 2016

Make all the Laserfiche exe files exceptions. Also, make all the LF files and folders exceptions (Program files\Laserfiche and Program Files (x86)\Laserfiche.

With Vipre turn off, open Laserfiche and then open Task Manager. Make all the LF processes listed in the Processes tab exceptions as well.

0 0

replied on June 13, 2016

Hi Raymond,

I went through that process, but I'm still getting the errors. The issue isn't consistent and is very random. Sometimes the client opens just fine, other times a user will get several 797 errors in a row.

The following is what shows up under details for the error:

Error Code: 797
Error Message: Could not connect to the Laserfiche Server. [797]

------------ Technical Details: ------------

LFSO:
Call Stack: (Exception)
SSPILogin
InternalDoLogin
LFSession::Login
CLFConnection::Create
Additional Details:
ERROR: 797 (SSPILogin, LFSession.cpp:1863)
(LFSO/10.0.0.865)
LF.exe (10.0.0.994):
Call Stack: (Exception)
CLoginDialog::AttemptLogin
CLoginDialog::LoginToServer
CLoginView::LoginHandler
Call Stack: (Current)
CLoginDialog::LoginToServer
CLoginView::LoginHandler
Additional Details:
Exception: 0x8004031d [797] (Could not connect to the Laserfiche Server.) (CLoginDialog::AttemptLogin at LoginDialog.cpp:796)
Call History:
GetOptionString ([Settings]LastCloudAccountID)
GetOptionString ([Settings]LastCloudUsername)
CLoginView::OnThreadComplete
CLoginView::LoginHandler
CLoginDialog::LoginToServer
GetOptionString ([StatelandsSettings]AdminNoPassword)
CLoginDialog::AttemptLogin
GetOptionString ([Settings]CheckServerVersion)

0 0

replied on June 14, 2016

Also check if Vipre has port blocking or filtering enabled. You should white list ports 80, 5050 and 5051. Hope this helps!

0 0

replied on June 14, 2016

Hi Chris,

I checked, but unfortunately those ports are already open. Thanks for the suggestion though.

Thanks,

Michael

0 0

replied on June 14, 2016

When the behavior occurs, is it machine specific? If you do to the server, or other workstations, does the LF client work on those other machines?

0 0

replied on June 14, 2016

Raymond,

It's affecting multiple machines throughout the agency. It does not happen when running the Client on the Laserfiche server, which is also running VIPRE.

Thanks,

Michael

0 0

replied on June 14, 2016

Are all the machines in the same physical network? Are there any that work all the time? Is the network segmented? Do workstations on specific switches work all the time while other do not?

0 0

replied on June 14, 2016

They're all on the same network and it's not segmented. We do have different switches, however, as the problem goes away when VIPRE is turned off, I don't believe that it's a network issue.

0 0

replied on June 14, 2016

If Vipre is running on both the client machines and the LF server, you need to make the exceptions on both. You also need to white list all the LF ports on both ends (https://support.laserfiche.com/ow.aspx?Ports#h2)

0 0

replied on June 14, 2016

From what I can tell, the ports are open. However, as the error is sporadic, wouldn't that indicate that it's not a ports issue? Meaning, if the ports or network settings weren't correct, then it'd would never connect and we'd always get the 797 error.

0 0

replied on June 15, 2016

Hi Michael,

Like you say, this is clearly something to do with Vipre and not a network issue as removing/disabling Vipre resolves the issue.

Just a suggestion, have you tried raising this with Vipre? They may have come across this before and know what settings to change?

Cheers!

0 0

replied on June 15, 2016

Hi Chris,

I have recently opened a ticket with VIPRE. Just working this from both ends to try and find a solution.

Thanks,

Michael

0 0

replied on June 21, 2016

We've managed to narrow it down to VIPRE's web filtering. We've added the domain of our Laserfiche server to the exclusion list, but the problem still persists when web filtering is enabled. Any suggestions of what to possibly look for? I downloaded Wireshark, but as I've never used it before, it's a tad on the intimidating side.

0 0

View 5 previous replies

replied on June 22, 2016

I'm going to hazard a wild guess that if the issue is with web filtering you would be best to start looking on port 80. Laserfiche also uses port 80.

0 0

replied on July 6, 2016

Chris,

I think you may be right. When Malicious URL Blocking is enabled, which filters port 80 by default, the error occurs. Excuse my ignorance, but is there a way to switch to a different port? I know that servers listen to port 80 by default.

Thanks,

Michael

0 0

replied on July 6, 2016

Hi Michael,

You can change this in the Laserfiche admin console under the server settings node.

1 0

replied on July 6, 2016

Hi Chris,

Thank you very much! Am I correct in assuming that this wouldn't have any impacts on Laserfiche Client, Forms and other Laserfiche products communicating with the primary server if I change that port?

Thanks,

Michael

0 0

replied on July 6, 2016

You would have to update the port information in the other products by specifying the server name in the name:port or IP:port format. The clients assume port 80 if only the machine name is used.

1 0

replied on July 6, 2016

Thanks Miruna,

So, for the Clients, would they need to be configured to use the IP using the Laserfiche Client shortcut options?

Thanks,

Michael

0 0

replied on July 16, 2016

Hello again,

I've updated the port and am able to connect via the Client, Web Access, Admin Panel and our internal Forms server. However, I'm having problems connecting via our DMZ forms server. I've added the correct port using the IP:port format in the User Authentication section of Forms config, but I get an error message stating that the server provided is not valid. I also get another error message above stating that the RPC server is unavailable. I believe that I've opened up the correct ports in Windows firewall for both the DMZ Forms server and Laserfiche server. Any suggestions as to where I should look next?

Thanks,

Michael

0 0

replied on July 18, 2016

For some reason, after changing the port, although the errors stopped, it was taking a long time for the client to load and connect to the repository. Our network admin ended up disabling the web filtering with VIPRE, and move that functionality to our new firewall. We switched the port back to the default and everything seems to be good now.

0 0

replied on July 6, 2016

In the error details I posted above, it lists what appears to be IP address (LFSO/10.0.0.865) -LF.exe (10.0.0.994). Those aren't address within our IP range. Does anyone know where Laserfiche might be pulling these from?

0 0

replied on July 6, 2016

Actually, those are the version numbers of LF.exe (the main desktop client) and lfso.dll (the main communication library to the Lf Server).

0 0

replied on July 6, 2016

Thanks Justin, I just realized that as I was looking through the logs after running an LFSO trace.

0 0

You are not allowed to follow up in this post.

Question

Question

797 Errors

Replies

Sign in to reply to this post.