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

Question

Question

LF Server 10 cannot connect with LFDS

Laserfiche Directory Server Version 10 Installation and Upgrades
Updated July 18, 2016
asked on December 14, 2015

Hello.  After upgrading our LFDS located on another server, we performed an upgrade of the LF server to version 10.  After the upgrade, the Admin Console 10 would not allow access using Windows Authentication.

It will allow the Admin account to sign in and I can see all users in our repository.  I added my name as a repository user and it logged in fine.  The problem it seems is with resolving the login using windows authentication.

I tried regenerating the licenses and synchronizing our active directory, but it will not allow any windows users to connect.  Any thoughts?  THis is the message when I try to sign on using windows authentication.

 

Thank you!

 

Error Code: 9010
Error Message: The user account name or password is incorrect. [9010]

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

LFSO:
    Call Stack: (Exception)
        CLFConnection::Create
    Additional Details:
        HRESULT: 0xc0042332 (ProcessResponseHeaders, LFSession.cpp:4887)
         (LFSO/9.2.0.468)
LF.exe (9.2.0.472):
    Call Stack: (Exception)
        CLoginDialog::AttemptLogin
        CLoginDialog::LoginToServer
        CLoginView::LoginHandler
    Call Stack: (Current)
        CLoginDialog::LoginToServer
        CLoginView::LoginHandler
    Additional Details:
        Exception: 0x80042332 [9010] (The user login or password is incorrect.) (CLoginDialog::AttemptLogin at LoginDialog.cpp:792)
    Call History:
        CLoginView::OnThreadComplete
        CLoginView::OnThreadComplete
        CLoginView::OnThreadComplete
        CLoginView::LoginHandler
         CLoginDialog::LoginToServer
          GetOptionString ([CAPSettings]AdminNoPassword)
          CLoginDialog::AttemptLogin
           GetOptionString ([Settings]CheckServerVersion)

0 0

Answer

APPROVED ANSWER
replied on March 15, 2016 • Show version history

Hey all,

Laserfiche Directory Server 10 Update 1 just released and fixed the variety of issues causing this. For those of you who had opened Support cases and received a hotfix for the issue, we still recommend applying the update as there are other various fixes and enhancements which have been included.

To review, the hotfix mentioned here applies when the following is true:

  1. The Laserfiche system is in a RIO environment, where Windows accounts are registered through LFDS before given Trusted access to the repository. If you've made your way here from the thread title, presumably this is the case. But if you have the same other symptoms while in an Avante environment, then it is a different issue as our findings deal strictly with LFDS.
  2. Windows users cannot log in through the desktop Client or Web Access on any machine through either the Windows authentication check box or through manually entering credentials, while Laserfiche repository named users are unaffected and can log in with no issue. (Depending on which of the specific situations is in play, there may be some Windows users who are able to log in.)
    • If any Laserfiche repository named users (i.e., not Windows accounts) are not able to log in, then it is a different issue.
    • If login is not working for other products (e.g. Forms) but it is working for the desktop Client or Web Access, then it is a different issue.
    • If login works for one but not both of Client or Web Access, then it is a different issue.
  3. The error displayed when attempting to log in is a 9010 "The username or password is incorrect" message. If it is a different message, it is likely a different issue.
    • 9013 "Access denied" messages will have more details logged to the Event Viewer and is likely to be resolved by examining security settings.
    • 9030 "The Maximum Number of Sessions That This Server Instance Is Licensed For Has Been Reached" messages typically have to do with licensing or the server registration in general and it is likely that if you receive this message, condition 2 above is not met.
  4. The full version of LFDS is 10.0.0.196. You can find the version of LFDS from the menu in the top right of the web console, in the About dialog.

Thanks for digging in thus far!

2 0
replied on April 16, 2016

Just to confirm for sure what is the version of LFDS.exe for  LFDS 10 Update 1?

It does not seem to list on the KB.

Just want to confirm it is 10.0.0.222.

Upon running the Update their did not seem to be a successful status message after running so want to be sure the update took.

0 0
replied on April 18, 2016

Hi William,

Yes; the version of LFDS after applying Update 1 should be 10.0.0.222.

If there is still an issue authenticating Windows users after applying this update, please open a Support case so we can look further into the issue.

Thanks!

1 0

Replies

replied on February 10, 2016 • Show version history

Hello all,

Thank you for bearing with us during this time of troubleshooting. Through our investigation, we have discovered there were multiple causes of the same issue, which I am going to summarize here. Note that there are specific symptoms to what we have discovered; if your behavior does not match these three conditions then you are likely experiencing something altogether different:

  1. The Laserfiche system is in a RIO environment, where Windows accounts are registered through LFDS before given Trusted access to the repository. If you've made your way here from the thread title, presumably this is the case. But if you have the same other symptoms while in an Avante environment, then it is a different issue as our findings deal strictly with LFDS.
  2. Windows users cannot log in through the desktop Client or Web Access on any machine through either the Windows authentication check box or through manually entering credentials, while Laserfiche repository named users are unaffected and can log in with no issue. (Depending on which of the specific situations is in play, there may be some Windows users who are able to log in.)
    • If any Laserfiche repository named users (i.e., not Windows accounts) are not able to log in, then it is a different issue.
    • If login is not working for other products (e.g. Forms) but it is working for the desktop Client or Web Access, then it is a different issue.
  3. The error displayed when attempting to log in is a 9010 "The username or password is incorrect" message. If it is a different message, it is likely a different issue.
    • 9013 "Access denied" messages will have more details logged to the Event Viewer and is likely to be resolved by examining security settings.
    • 9030 "The Maximum Number of Sessions That This Server Instance Is Licensed For Has Been Reached" messages typically have to do with licensing or the server registration in general and it is likely that if you receive this message, condition 2 above is not met.

If you verify that all of the above conditions hold, we have identified three different cases which would cause the issue. Two of them had been mentioned previously in this thread.

  1. Mismatch of LFDS Licensing Site name and Licensing Database Legacy Name (139919)
    • The title matches the cause of the issue; this can happen for example when upgrading from LFDS 9.2 to LFDS 10 and choosing a different name for the Licensing Site than before.
    • To detect/resolve this issue, consult Brianna's post in this thread.
  2. Upgraded from LFDS 9.2 to LFDS 10 with LFS 10, or are using LFDS 9.2 with LFS 10 (138520)
    • This was mentioned previously in the original workaround provided in this thread.
    • Note: In that post it was said that you may need to change the user used by the LFDS service before effecting the workaround. After looking at several cases, it seems that this has only been the case for one customer so far; tellingly though, they were able to switch back to the original user afterward. As of this post we are unsure why this was the case, and so it may or may not work for this workaround.
  3. Supplying Windows credentials manually (i.e. with the "Use Windows authentication" box unchecked), giving the username "DOMAIN\username" and password returns the error, but supplying the UPN "username@domain.local" and password allows for logging in (140106)
    • This had been reported earlier in this thread, and we have recently identified this as a symptom of another separate result related to the way in which LFDS 10 queries the Active Directory.
    • Therefore unlike the other two cases, creating a brand new (non-migrated) licensing database will not resolve this issue, nor is there a simple workaround.
      • We do have a hotfix for this; until such time as either an update to LFDS or the hotfix itself is available through the Support site, contact your reseller to open a ticket with us so we can confirm the presence of the issue and if so, provide the fix.
      • Please do verify that the above two workarounds do not resolve the issue first; we are likely to ask you to confirm that through the case, anyway.

If your behavior matches the conditions at the top of this post but none of the three cases apply or resolve the issue, then please do open a ticket with us and we can investigate. But so far each case that we've seen has fallen into one of these three categories.

Thank you all again for your patience through this ordeal, and we hope that we can help get your systems back in shape and running smoothly.

EDIT: Missed a very crucial "not" in Condition 2. Thanks Brianna!

EDIT 2: The above issues were resolved in LFDS 10 Update 1.

2 0
replied on December 14, 2015

Try applying the workarounds found in https://support.laserfiche.com/KB/1013628

1 0
View 12 previous replies
replied on December 14, 2015

Thank you for responding Raymond.  I tried the last workaround, but that didn't work.  The LFDS was already at version 10 before upgrading the LF Server to version 10 on another machine.

After the server upgrade, everything appeared to be ok.  The Search DB asked to be upgraded, but I opted to run that after setting everything else up first.  When trying to sign on with a full user (any licensed user with sufficient rights) into the Admin Console, an error 9010 was returned.  Same thing when trying to use the Version 10 client.

The machine that was upgraded to version 10 has our repository attached.  When signing on to the Admin Console 10 with the admin account, it validates fine and I can see all of the windows users/groups from before.  It just wont let us sign on with any of them.  Nothing should have changed with our active directory.

One thing I noticed is that the Laserfiche Directory Accounts section in the console is empty.  Should that have something in there?  There is also a new section in the LFDS regarding single signon (machinename/LFDSSTS/configuration), but when I try to click the link I get an error.

Now wishing I wouldn't have tried to upgrade.  Any other tips?

 

0 0
replied on December 14, 2015

What account is the LF server service using? 

0 0
replied on December 14, 2015

The LS10 is using Local System.  I believe that didn't change.

0 0
replied on December 14, 2015

Is the LF server licensed correctly? If you open the admin console, select the "servername" node, the right hand pane should show a summary of the licenses available.  Does it show the correct number and does it show the server as licensed?

0 0
replied on December 14, 2015

Thank you.  Highlighting the server instance in the console, it lists our server version and products.  No # of users listed there.  This is the screen shot.  Would it be useful to remove the LFserver10 from the machine and reinstall?

I'm almost thinking the right fingerprint was registered.  I'm stumped.

 

Screen-Shot-2015-12-14-at-111420-AMpng.png
Screen-Shot-2015-12-14-at-111420-AMpng.png (39.25 KB)
Download
0 0
replied on December 14, 2015 • Show version history

Try removing one of the accounts and adding it back in the Admin console (and/or reconfiguring the named user).

On one of the client machines, using another windows account, try logging into the client by typing in the actual "domain\username" in the username field, with their windows password in the password field.  Uncheck windows authentication and see if you can login to the repository using windows credentials entered that way.

0 0
replied on December 14, 2015

I tried removing and adding back and that didn't help.  Also tried removing one AD user from LFDS and when I tried adding it back as a Windows user, LFDS added it back.  I renewed the license and tried again.  No luck.

Might it be the DS connection with AD?  I am running out of ideas.  Thank you for all your help by the way.

0 0
replied on December 14, 2015 • Show version history

I did regenerate licenses for the problem machine and the machine that the LFDS is running.  This did give me slightly different results for the console information.  So now it shows the following.  This seems to be license related.  Doesn't look like it is getting the correct information from the LFDS ?  I haven't seen "Viewer" before.

One thing is that we are not using SSL right now, so I am not sure if any of these connections need to be https.

 

0 0
replied on December 14, 2015

Your screenshot indicates that LFS is unable to load the license, that the license is invalid, or that LFS cannot confirm the license validity with LFDS.

The three scenarios I can think of are:

  1. There is a fingerprint mismatch between the license from LFDS and the machine
  2. LFS on this machine cannot reach LFDS to confirm that it is licensed
  3. The license file was for a different product

 

Try checking the LFS event viewer now that you have relicensed the server and see what the license error is. You could also check the LFDS event viewer in case there is an issue on the LFDS side.

To check (1), you can view the hardware fingerprint in the license file and run showhwfp.exe on the LFS machine to see if they match. For easier reading of the license, I recommend using either a program like Visual Studio that can read XML well, or an online XML formatter.

I'm not sure what the best way to check (2) is; perhaps Support has some suggestions.

To check (3), read the license file and see if it says Laserfiche Server.

1 0
replied on December 14, 2015

Thank you Brianna.  Chasing after those I got the following errors.  The license file looked ok, but looking at the log it reads:

LFS received an unrecognized or unexpected error from LFDS. Service Call=GetUnsignedTokenEx; LFDS error code=0

lots of those messages

I am wondering if the entire LFDS license needs to be deactivated and reinstalled?  Usually I can just replace the lf-licx file for the Server, or whichever application isn't working and it would fix it.  I am going to keep looking at these fingerprints to see if I can spot anything.

 

0 0
replied on December 14, 2015

Well, I haven't had much luck.  Tried just about everything other than uninstalling LF products from the problem machine or, deauthorizing the licensing DB.  I did remove the LF Server instance from LFDS and tried to use the activation tool instead.  The key worked, but when I clicked :Activate:  I received an odd message.

0 0
replied on December 14, 2015 • Show version history

Activating using the activation tool won't work for LFS in a Rio situation: you only have one key, which will get you the master license. The master license cannot be used for individual products.

At this point, it might be best to contact your reseller for further troubleshooting, and open a case with Support if necessary.

The error message you posted earlier implies that LFS can reach LFDS, and that LFDS didn't throw an error, but the response from LFDS was not what LFS was expecting. I'm not sure what could be causing this error at this point.

Are there any errors in the LFDS event viewer?

0 0
replied on December 14, 2015

I just looked and this one was repeated many times.

 

System.NullReferenceException: Object reference not set to an instance of an object.
   at Laserfiche.LicenseManager.Utils.LookupDn(IdentityProviderSpecs specs, String dn)
   at Laserfiche.LicenseManager.LicenseManagerService.GetUnsignedToken(LicenseDatabase database, String sidString, String identityProviderName)
   at Laserfiche.LicenseManager.LicenseManagerService.GetUnsignedTokenEx(LicenseManagerServiceCallArgs _args)
   at Laserfiche.LicenseManager.LicenseManagerService.DispatchFunction(LicenseManagerServiceCall func, LicenseManagerServiceCallArgs args)

Type:
System.NullReferenceException

Stack Trace:
   at Laserfiche.LicenseManager.Utils.LookupDn(IdentityProviderSpecs specs, String dn)
   at Laserfiche.LicenseManager.LicenseManagerService.GetUnsignedToken(LicenseDatabase database, String sidString, String identityProviderName)
   at Laserfiche.LicenseManager.LicenseManagerService.GetUnsignedTokenEx(LicenseManagerServiceCallArgs _args)
   at Laserfiche.LicenseManager.LicenseManagerService.DispatchFunction(LicenseManagerServiceCall func, LicenseManagerServiceCallArgs args)

0 0
replied on February 10, 2016

Hi Kevin,

I believe we have a hotfix available for your situation. If you've not done so already, please contact your reseller to open a case with us and we can provide the fix through the case.

Thanks and regards

0 0
replied on February 15, 2016

Thanks James.  We have had several issues all surrounding either authorization and permission.   Our approach was to document all service logins that were in use, audit local and database permissions, and reconfigure ownership across all servers and databases.

Things seem to have been working more consistently lately and I believe our errors were a result of several of the issues being discussed.  It just took documenting / diagramming how applications were installed along with the connections being made.

For us, moving from 9.2 not using LFDS into using LFDS and then upgrading to LF10 introduced more complexity in authorization and permissions.  My takeaway from it is to stay consistent and diagram the permissions, access levels, and passwords being used for the service accounts and databases.

0 0
replied on December 16, 2015 • Show version history

Hi all,

We found after a few support cases that there was a bug in LFDS 9.2.1 which caused service user logins to fail. While it was fixed for LFDS 10, upgrading from 9.2.1 to 10 does not resolve the issue, and the failed logins are a manifestation of this problem. Note that if you upgrade Laserfiche server to version 10, but still have LFDS 9.2.1, the same problem will occur.

In the meantime, a workaround is to unregister any affected applications from LFDS, generate a new license instance for the application, and download the new license file (lf.licx) to the appropriate directory for the application. You may need to change the LFDS and LFS service accounts to a different domain admin than currently in use, if applicable and if the above steps do not immediately resolve the issue. (You may be able to switch back to the originally-used accounts after everything is working.)

If this workaround does not work, I highly encourage you to contact your reseller for further troubleshooting. Thank you for helping to bring this to our attention.

EDIT: Corrected/Clarified original problem description. Thanks Brianna.

1 0
replied on January 31, 2016

So I have multiple Application servers and I upgraded 2 of them when LF 10 first came out and had no issues.  Just this morning I upgraded another one of our servers that include the Update 1 and I ran into this issue.  This is a pretty big issue at the moment because we are unable to use the regular service account that we have used for years with LF.  This was a production machine and I had to do the above situation.  I had to change the service account on the LF Application server and the service account on our Directory Server in order to allow for Windows Authentication to work.  Is there an SCR number for this issue or has Laserfiche detected this as a bug and going to get resolved with Service Pack 1 or anything?

0 0
replied on February 1, 2016

Hi Derick, 

We do plan to release a fix for LFDS, and we will post here when it is released.

James' described workaround says that you should be able to change back to the original accounts if you had to change the service account during the troubleshooting process. If this is not the case, you may be encountering some issue aside from the one we are already planning to fix. Did you try changing back to the initial service user?

If you get errors upon changing back to your desired service user, you may wish to open a support case so that we can look into ways to address your issue.

0 0
replied on February 10, 2016

I tried to change the user back to the Original user that I was using both on the LF Application server and the LFDS server, but the second I did that and restarted the services, I was not able to log in using Windows Authentication again.  So I had to change those services back to my domain account so it would work again.  I will wait until March for Service Pack 1 to be released and then I will apply Service pack 1 and see if I can then change back to our LF Service account that we usually use.

0 0
replied on February 2, 2016 • Show version history

If you are encountering a [9010] error and the stated workaround did not help, you may be running into an issue where the "legacy name" of the LFDS database doesn't match the current display name.

 

To check whether this is the issue, run the following SQL command:

 

SELECT *
  FROM [yourDBname].[dbo].[db_settings]
  where name = 'legacyName'

Replacing “yourDBName” with their LFDS SQL database name.

Then, compare that value to what is shown in the LFDS UI:

 

If the two do not match, you have have two options to fix this (option 2 requires more work; I strongly recommend option 1)

  1. Change the display name to match the legacy name
    1. Detach the site, make sure to leave “Delete SQL db” UNCHECKED
    2. Reattach the site, and use the legacy name when asked for the display name
  2. Change the legacy name to match the display name
    1. Run the following SQL query (replacing yourSQLdbname and yourSiteDisplayName) 
      USE [yourSQLdbname]
GO

UPDATE [dbo].[db_settings]
   SET [value] = 'yourSiteDisplayName'
  where name = 'legacyName'
GO
    2. Detach and reattach the site, using the same display name. This step re-loads the legacy name into an encrypted LFDS config file.
    3. Reissue licenses to all applications that use SSO and/or check back for licensing
      1. Even if not using SSO, replace LFS and Quick Fields licenses
      2. If you are using SSO, replace Web Access, Forms, Mobile, and Social BPM licenses
1 0
replied on December 14, 2015

I'm currently having the same issue you are after an upgrade. Similar setup as well where the LFDS is located on a different server than the Laserfiche Server. I've also taken the same steps as you too with no results. I do noticed that SSO is working fine.

0 0
replied on December 14, 2015

Well that stinks Eddie.  Yeah, it appeared that everything was ok and I had remounted the repo using Web Admin 10.  Then I was making some sort of change and I kept getting messages about needing to be signed on as a manager which I was.  I'd set my password in again and it looked like I was signed on.  Said so up top.

AppPool errors started to pop up as I navigated around.  Checked those out and everything was set okay.  And so the day went. . . 

I'll have to try SSO to see if that does anything.  But it didn't earlier.  We sent LF a few logs and they said this has been popping a bit.  I'll reply if the developers turn up anything.  Good luck!

0 0
replied on December 14, 2015
0 0
replied on January 21, 2016

Had this issue come up today, so putting a couple more ideas out there. 9010 error for Windows Accounts after upgrading to 10. Turns out our upgraded license ended up having 0 repository user licenses, but the Admin account had a license assigned. (We ran into an issue that led to creating a new license rather than being able to update what was there currently.)

Recreating the Server license with some repository users allocated fixed the problem. Weird that Windows Accounts that do have a license were unable to log in due to this issue.

0 0
replied on January 25, 2016

Currently working on the same issue in a support case as we speak.  I will update as soon as I get anything.

No changes made to their AD.  Spitting the error out only when user tries to log on with Windows account   DOMAIN\user.

user@domain.local    actually works.

2 0
replied on January 30, 2016

We're having the same problem as everyone else here, did an upgrade from 9.21 to 10 just now.  No windows logins work, I've tried assigning some full licenses to the server license file directly and replacing it (and restarting the server) but it doesn't appear to fix anything.  Problem affects weblink too.  I followed Chase's advice above about logging in manually using the 'username@domain.local' which actually works on both the client and weblink, but domain\username does not work nor does using SSO.

 

There must be a bug here somewhere...  

0 0
replied on February 1, 2016 • Show version history

Hi Shaun,

From your post, it doesn't sound like you've read James' reply that had a description of the bug that was found and the workaround to fix it: https://answers.laserfiche.com/questions/88453/LF-Server-10-cannot-connect-with-LFDS#88697

From the support case he opened, the case Chase is describing is unrelated to the this bug, and may be specific to certain domain configurations. We'll update once we know more, but it's much more likely that you are running into the general case that we already have a workaround for.

To be clear, just replacing the license on LFS isn't the workaround. You must register a NEW instance of LFS and download the license from that new instance.

0 0
replied on February 2, 2016 • Show version history

I've already rolled back to 9.2.1 which worked fine after spending more than 4 hours on this in the middle of night.  I'll wait for your patch.

0 0
replied on July 13, 2016

Hello,

We are experiencing similar behavior and none of the solutions have worked for us. Moreover, certain users can use Windows authentication to access the desktop client, while other receive the below error. Additionally, all users can access the web interface successfully. I would like to open a ticket, but this seems to be the only place I have access to contact support

Error Code: 9528
Error Message: Cannot connect to the Laserfiche Directory Server. [9528]

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

LFSO:
    Call Stack: (Exception)
        ProcessResponseHeaders
        InternalDoLogin
        LFSession::Login
        CLFConnection::Create
    Additional Details:
        HRESULT: 0xc0042538 (ProcessResponseHeaders, LFSession.cpp:4892)
         (LFSO/10.1.0.209)
LF.exe (10.1.1.254):
    Call Stack: (Exception)
        CLoginDialog::AttemptLogin
        CLoginDialog::LoginToServer
        CLoginView::LoginHandler
    Call Stack: (Current)
        CLoginDialog::LoginToServer
        CLoginView::LoginHandler
    Additional Details:
        Exception: 0x80042538 [9528] (Cannot connect to the Laserfiche Directory Server.) (CLoginDialog::AttemptLogin at LoginDialog.cpp:796)
    Call History:
           CLFClientAutomation::ExecuteAutomationCommand (GetWindowInfo)
        LFFlushPrivateProfile
        CLoginView::LoginHandler
         CLoginDialog::LoginToServer
          GetOptionString ([PWSettings]AdminNoPassword)
          CLoginDialog::AttemptLogin
           GetOptionString ([Settings]CheckServerVersion)
           CLFClientAutomation::ExecuteAutomationCommand (GetInstanceInfo)

0 0
replied on July 14, 2016

Hi Chase,

This error indicates that you are completely unable to reach LFDS, which is not related to the above issues. I would recommend starting a new post, as this one is already quite long and does not apply to your error message.

Furthermore, if you feel you need to open a support case, you should contact your VAR/reseller.

As a first troubleshooting steps, I'd recommend the following: check if the users who are having login issues can log in successfully using a machine of a user that can login (or the other way around; do users that can log in successfully get the error message on the other user's machine)

0 0
replied on July 18, 2016

Hi Brianna,

I have started a new thread here:http://answers.laserfiche.com/questions/101883/Error-Code-9010-Error-Message-The-user-account-name-or-password-is-incorrect-9010 regarding our error message. We tried your suggestion and users who are having login issues can not log in successfully using a machine of a user that can login, Which is puzzling because the permissions are identical.

0 0
replied on July 14, 2016

This is exactly what we are experiencing right now.  Out of the blue.  Two days ago everyone could connect and after that, some people can connect some of the time.

Ironically, I started this thread last year and things were eventually resolved.  Now I do not know what is preventing access.  I have also tried using the ADMIN account as well with sporadic results.  We are either of these:

Error 784 -- Operation Timed Out (detail below)

Error 797 -- Could not connect to the Laserfiche Server (detail below)

HTTP operation has timed out  (when trying to access WebAdmin)

We are racking our brain to figure it out.  We tried both the machine name and the IP address in the "Attach" section.  Nothing seems to work.  Our LFDS is on one VM and our server is located on another VM.

I have regenerated our license for our server and refreshed the master license.  No luck.

I think it has something to do with the connection timing out.  I looked in the registry for the LFSO entry, but there isn't an LFSO entry there in both the 32bit and 64bit sections.

Help!  This really is puzzling.

 

Error Code: 784
Error Message: Operation timed out. [784]

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

LFSO:
    Call Stack: (Exception)
        SSPILogin
        InternalDoLogin
        LFSession::Login
        CLFConnection::Create
    Additional Details:
        ERROR: 784 (TestLastError, LFSession.cpp:925)
         (LFSO/10.0.0.865)
LF.exe (10.0.0.900):
    Call Stack: (Exception)
        CLoginDialog::AttemptLogin
        CLoginDialog::LoginToServer
        CLoginDialog::LoginToServer
    Call Stack: (Current)
        CLoginDialog::LoginToServer
        CLoginDialog::LoginToServer
    Additional Details:
        Exception: 0x80040310 [784] (Operation timed out.) (CLoginDialog::AttemptLogin at LoginDialog.cpp:796)
    Call History:
        CLoginDialog::LoginToServer
         CLoginDialog::LoginToServer
          GetOptionString ([CAPSettings]AdminNoPassword)
          GetOptionString ([CAPSettings]UserName)
          GetOptionString ([Settings]UseWindowsAuth)
          GetOptionString ([CAPSettings]UseWindowsAuth)
          CLoginDialog::AttemptLogin
           GetOptionString ([Settings]CheckServerVersion)

 

 

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

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

LFSO:
    Call Stack: (Exception)
        CLFServer::GetAllDatabases
    Additional Details:
        HRESULT: 0x8004031d (CLFServer::GetAllDatabases, LFServer.cpp:566)
         (LFSO/10.0.0.865)
LF.exe (10.0.0.900):
    Call Stack: (Current)
        CLoginDialog::LoginToServer
    Additional Details:
        Exception: 0x8004031d [797] (Could not connect to the Laserfiche Server.) (CLoginDialog::LoginToServer at LoginDialog.cpp:463)
    Call History:
          GetOptionString ([Settings]UseWindowsAuth)
          GetOptionString ([CAPSettings]UseWindowsAuth)
          CLoginDialog::AttemptLogin
           GetOptionString ([Settings]CheckServerVersion)
          CErrorDetailsDialog::OnInitDialog
           GetOptionString ([Settings]ErrorDetailsDialogPos)
          WriteOptionString ([Settings]ErrorDetailsDialogPos)
        CLoginDialog::LoginToServer

 

0 0
replied on July 14, 2016

Hi Kevin,

This error is different both from the original thread above and from Chase's recent reply. The error says you are completely unable to reach your Laserfiche Server, and may not be related to Directory Server at all.

Since this thread is already very busy and is unrelated, I recommend asking a new question so that it's easier for people who can help troubleshoot to find it.

0 0
replied on July 14, 2016

Thank you Brianna.  My apologies as I saw Chase's post and it was pretty spot on to our new issue

I will start a new question if this is so much different than the earlier posts.  What confuses things is that we could get any one of three errors dealing with time outs, LFDS communication, and other authentication messages.

To me...they all seem to interchange.

0 0
replied on July 15, 2016 • Show version history

It's not a problem; I just want to make sure your post is seen by people who can help and that it's easy for future users to get to.

For future reference, a good first step to distinguish issues is by the labeled error code/error message that appear at the top of the long event viewer message.

"I can't log in" is like "my car won't start". Is it battery problems? Ignition problems? Just out of fuel? Maybe even you used your spouse's car key? Some scenarios are more likely than others, but you can't tell the cause just from "my car won't start".

For example, the error messages in this thread originally were all 9010 errors:

Error Code: 9010
Error Message: The user account name or password is incorrect. [9010]

Chases problem was a 9528:

Error Code: 9528
Error Message: Cannot connect to the Laserfiche Directory Server. [9528]

And you had two different errors:

Error Code: 784
Error Message: Operation timed out. [784]
Error Code: 797
Error Message: Could not connect to the Laserfiche Server. [797]

The second error says "Laserfiche Server", not "Laserfiche Directory Server", so the issue is in the first part of signing in where the desktop Client connects to LFS, before LFDS is even involved.

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

Sign in to reply to this post.

Details
Attachments
Related Posts
Loading ...