You are viewing limited content. For full access, please sign in.

Discussion

Discussion

Virtual Desktop- 784 Timeout when logging into the Desktop Client

Laserfiche Version 11
Updated May 20, 2022
posted on March 30, 2022

Hello,

Customer is testing virtual desktops in Azure and they reached out to state:

"Users are getting timed out when trying to sign into Laserfiche. If they keep trying to sign in they will continually get timed out. What seems to correct it so far is if they close the application and launch it again, they can sign in successfully after that."

I am not seeing any errors in the Content Repository logs for this.

All we see is this from the error details on the desktop:

ERROR: 784 (TestLastError, LFSession.cpp:930)

         (LFSO/11.0.2102.9)

LF.exe (11.0.2103.223):

    Call Stack: (Exception)

        CLoginDialog::AttemptLogin

        CLoginDialog::LoginToServer

        CLoginView::LoginHandler

    Call Stack: (Current)

        CLoginDialog::LoginToServer

        CLoginView::LoginHandler

    Additional Details:

        Exception: 0x80040310 [784] (Operation timed out.)

Since this is an Azure environment connecting to a LF Server that is not in Azure, are their some timing mechanism that needs to be adjusted?

Appreciate the feedback,

Jeff Curtis

0 0
replied on March 31, 2022

There is a registry value that can be used to override the timeout. On the desktop client machine, set HKEY_CURRENT_USER\Software\Laserfiche\LFSO\11.0\LoginTimeoutSeconds to a DWORD of 60 to increase the timeout to 60 seconds (default is 20).

1 0
replied on March 31, 2022

Thanks Robert,

Perfect Timing as I am typing the email to the customer now laugh

I will pass this along to see if it helps with the timeout.

Jeff Curtis

0 0
replied on May 20, 2022

Hello Robert and Sam,

Issue is still ongoing.

We are noticing now when we look in the Directory Service->Server->Operational Trace logs,  the following error is registered at the time of the timeout:

System.Net.Sockets.SocketException (0x80004005): No such host is known
   at System.Net.Dns.GetAddrInfo(String name)
   at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6)
   at System.Net.Dns.GetHostAddresses(String hostNameOrAddress)
   at System.Net.Sockets.UdpClient.Connect(String hostname, Int32 port)
   at Laserfiche.LicenseManager.Notification.NotificationManager.LegacySender(ActivityEvent actEvt, Application app, Host host)

Type:
System.Net.Sockets.SocketException

Stack Trace:
   at System.Net.Dns.GetAddrInfo(String name)
   at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6)
   at System.Net.Dns.GetHostAddresses(String hostNameOrAddress)
   at System.Net.Sockets.UdpClient.Connect(String hostname, Int32 port)
   at Laserfiche.LicenseManager.Notification.NotificationManager.LegacySender(ActivityEvent actEvt, Application app, Host host)

Customer's IT is going to try and setup Wireshark to get a trace the next time the error is encountered.

Appreciate all the feedback,

Jeff Curtis

0 0
replied on March 30, 2022 • Show version history

Sounds like a transient connectivity issue between their Azure VNet and wherever LFS is hosted. Presumably there's a site-to-site VPN or ExpressRoute tunnel. I would start by having the customer investigate there.

The operation is almost certainly timing out because it lost network connectivity to LFS.

The Laserfiche Windows Client doesn't have any kind of "timing mechanisms" you can adjust.

Edit: Please see Robert Strickland's comment about the LoginTimeoutSeconds registry value above. That said, adjusting it is almost certainly addressing a symptom rather than the root cause.

1 0
replied on March 31, 2022

Hello Sam,

Thanks for the note.

I will pass this along to the Customer's IT to investigate.

Jeff Curtis

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...