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

Question

Question

Administration Hub 12 Error LFAH500-Internal Error

Self-Hosted Version 12 Administration Hub
Updated May 9
asked on May 3 • Show version history

I just started my upgrade journey to Laserfiche 12.

I've upgraded LFDS to 12, but none of the other core software yet.

But I thought it wouldn't hurt to try out the new Administration Hub, so I installed the Hub on the same server that I have LFDS (12.0.2503.265) and LFServer (11.0.2.238).

I also installed the Hub Agent on both the same server as the Hub and also the server where I have LFForms (11.0.2311.50553) and LFWorfklow (11.0.2306.898).

I am having some licensing issues with the installer (see post: https://answers.laserfiche.com/questions/228869/Laserfiche-12-Installer--Error-Selecting-LFDS-for-Licensing ) but it did appear to be successfully installed using the option to complete licensing after activation.

Administration Hub version is 12.0.2503.10396 (installed on 1 server).

Administration Hub Agent version is 12.0.2503.10396 (installed on 2 servers).

Unfortunately, the Administration Hub keeps giving me an error.

I couldn't find any logs under the Event Viewer as they were on Laserfiche 11 (which I guess makes sense if they are supposed to be centralized here to the Hub), but other post mentioned a log in ProgramData.  This post: https://answers.laserfiche.com/questions/228118/Administration-Hub-Diagram-Error-LFAH500  This log file: C:\ProgramData\Laserfiche\AdminHub\Logs\AdminHubLog_w3wp.log

In that file, the most recent entry says the following: 

2025-05-03 09:54:32.4694||ERROR|AdminHubLogs|36|--- 2025-05-03T15:54:32.4604571Z AHWebContext started.
[+8ms][ERROR][Thread-36] [CreateExceptionFromResponseErrors]: HTTP status code: Unauthorized.
[+9ms][ERROR][Thread-36] Object reference not set to an instance of an object.
Stack Trace:
Caught exception: System.NullReferenceException
Message: Object reference not set to an instance of an object.
   at Laserfiche.AdminHub.Core.AgentController.AgentControllerApiClient.<CreateExceptionFromResponseErrors>d__13.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.ConfiguredTaskAwaitable`1.ConfiguredTaskAwaiter.GetResult()
   at Laserfiche.AdminHub.Core.AgentController.AgentControllerApiClient.<GetApplicationInfos>d__10.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Laserfiche.AdminHub.Web.WebAPI.ApplicationInfoController.<Get>d__3.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Threading.Tasks.TaskHelpersExtensions.<CastToObject>d__1`1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Web.Http.Controllers.ApiControllerActionInvoker.<InvokeActionAsyncCore>d__1.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Web.Http.Controllers.ActionFilterResult.<ExecuteAsync>d__5.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Web.Http.Controllers.ExceptionFilterResult.<ExecuteAsync>d__6.MoveNext()
[+9ms][ERROR][Thread-36] AHWebContext operation successful.

 

0 0

Answer

SELECTED ANSWER
replied on May 6

Thank you @████████ for getting me pointed in the right direction.

And thank you @████████from CDI for helping me test everything out.

What we ultimately found is a long-standing issue that I've been fighting with for years.

We don't currently have an internal certificate authority.  We have been using certificates purchased from an online provider (GoDaddy) for both our Laserfiche server and our Forms server, with addresses like lf.website.com and lfforms.website.com.  This has worked well for years with our staff connecting to those sites via browser.  But it causes some problems with the back-end of things, where the system is not wanting to use those designated addresses, but defaulting over to the machine.domain.local FQDN instead of lf.website.com  FQDN that we have set-up.

Even though we've told the Admin Hub to use lf.website.com, it seems it actually wants to use machine.domain.local.  Once we switched the configuration (C:\Program Files\Laserfiche\AdminHub\AgentController\Laserfiche.AdminHub.AdminHubUtility.exe) to using a self-signed certificate for machine.domain.local - it worked without the errors.

I've had similar problems for years trying to get STS working through LFDS, and have come up against this problem.  The advice I received years ago is that we need an internal certificate authority set-up that can generate a single certificate that includes SANs (Subject Alternate Names) so that the same certificate works for lf.website.com and machine.domain.local and localhost.

Unfortunately, I've been pushing management for years to get that internal certificate authority set-up, and it still hasn't been done.  So I'm kind of stuck right now.

3 0

Replies

replied on May 5

I ended up opening a ticket with CDI about this issue.

1 0
replied on May 6

Hi Matthew,

The screenshot with [LFAH500-InternalError] indicates that you already login as administrator. But from the error log, http status is Unauthorized, which means Administration Hub api calls losing the authentication as administrator.

This could be Administration Hub configuration issue. Could you try using Laserfiche.AdminHub.AdminHubUtility.exe(under C:\Program Files\Laserfiche\AdminHub\AgentController) to reconfigure Administration Hub?

1 0
View 1 previous reply
SELECTED ANSWER
replied on May 6

Thank you @████████ for getting me pointed in the right direction.

And thank you @████████from CDI for helping me test everything out.

What we ultimately found is a long-standing issue that I've been fighting with for years.

We don't currently have an internal certificate authority.  We have been using certificates purchased from an online provider (GoDaddy) for both our Laserfiche server and our Forms server, with addresses like lf.website.com and lfforms.website.com.  This has worked well for years with our staff connecting to those sites via browser.  But it causes some problems with the back-end of things, where the system is not wanting to use those designated addresses, but defaulting over to the machine.domain.local FQDN instead of lf.website.com  FQDN that we have set-up.

Even though we've told the Admin Hub to use lf.website.com, it seems it actually wants to use machine.domain.local.  Once we switched the configuration (C:\Program Files\Laserfiche\AdminHub\AgentController\Laserfiche.AdminHub.AdminHubUtility.exe) to using a self-signed certificate for machine.domain.local - it worked without the errors.

I've had similar problems for years trying to get STS working through LFDS, and have come up against this problem.  The advice I received years ago is that we need an internal certificate authority set-up that can generate a single certificate that includes SANs (Subject Alternate Names) so that the same certificate works for lf.website.com and machine.domain.local and localhost.

Unfortunately, I've been pushing management for years to get that internal certificate authority set-up, and it still hasn't been done.  So I'm kind of stuck right now.

3 0
replied on May 6

You may already be aware of this, but @████████made a nice video on the topic:

 

2 0
replied on May 6

Thank you @████████ - I was aware, @████████always has great videos.  I think its very helpful to have it listed here in case anyone comes along later with the same issue.

 

1 0
replied on May 9

Matt,

Thanks a ton for posting what worked for you.  I agree that this and other back-end Laserfiche components need to be better at working with 3rd party SSL certs associated with the server's DNS and not the FQDN.  Hopefully in future iterations of the Admin Hub it will be updated to do this.  For now though at least we have a workaround.

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

Sign in to reply to this post.

Details
Related Posts
Loading ...