Ok, I am currently keeping everything on an HTTP non-secure connection for testing.

So this means there really is no extra configuration left to do outside of the Config Page. I really don't have many options in the config page, except entering the machine name. I don't know what else to do to allow forms to talk to it's notification service.

I wish the logic in the notification service was instead in the routing service. Forms has no issues talking to the routing service ever, but in every installation, it can't talk to the notification service.

You might try some of the troubleshooting/diagnostic steps I describe in this related Answers post, especially about looking at the browser calls in DevTools.

I agree that it would be more convenient if the notification service were self-contained within the routing service. I've certainly spent my fair share of time troubleshooting Forms Notification issues. It's something we've discussed internally before and unfortunately isn't a small or low-effort change.

I pulled up the dev tools and it does show a 500 error

{"errors":[{"status":500,"code":"NotificationServerConnectionDown","message":"A connection to the notification server could not be made. Notifications and real-time updates have been disabled. [LFF8100-NotificationServerConnectionDown]"}]}

Then in the LFNotificationService event log it gives this error, indicating that the problem is Forms not using the correct URI format. I think this is why the notification service does not work in any environment, regardless of how simple the environment is. Forms needs to use the correct URI.

Invalid URI: The format of the URI could not be determined.

Stack Trace:
Caught exception: System.UriFormatException
Message: Invalid URI: The format of the URI could not be determined.
   at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
   at System.Uri..ctor(String uriString)
   at Microsoft.AspNet.SignalR.Client.Http.DefaultHttpClient.Get(String url, Action`1 prepareRequest, Boolean isLongRunning)
   at Microsoft.AspNet.SignalR.Client.Transports.TransportHelper.GetNegotiationResponse(IHttpClient httpClient, IConnection connection, String connectionData)
   at Microsoft.AspNet.SignalR.Client.Transports.AutoTransport.GetNegotiateResponse(IConnection connection, String connectionData)
   at Microsoft.AspNet.SignalR.Client.Transports.AutoTransport.Negotiate(IConnection connection, String connectionData)
   at Microsoft.AspNet.SignalR.Client.Connection.Negotiate(IClientTransport transport)
   at Microsoft.AspNet.SignalR.Client.Connection.Start(IClientTransport transport)
   at Laserfiche.SignalR.Client.LFHubProxy.Connect()
   at Laserfiche.SignalR.Client.Factories.LFHubProxyFactory.Create(HubEndPoint hubEndPoint)
   at Laserfiche.PushNotificationService.Master.Services.RegisterService.Register(PushServiceRegisterRequest registerData)
   at Laserfiche.PushNotificationService.Master.PushNotificationService.Register(PushServiceRegisterRequest registerData)
   at SyncInvokeRegister(Object , Object[] , Object[] )
   at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)
   at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage41(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage3(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage2(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage11(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage1(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)

Most of the time we see that error it's due to a typo, invisible character, or similar issue in the Laserfiche Notification Hub URL configuration. See attached screenshot.

You can see from the stack trace that the error is coming from Microsoft's System.Uri library, so there's something in the string getting passed it can't parse.

That's something we should probably validate when you try saving the value in FormsConfig instead of at runtime though, so I'll file an enhancement request for a better validation check.

I am going to paste what is in the configuration in here so you can verify there is no invalid characters.

I do not think this is a configuration mistake, this is a built in problem with Forms.

//LAPTOP-HBSSS28P:8181

I copy/pasted that into my own Forms 10.4.4.444 instance, added a hosts file entry to point LAPTOP-HBSSS28P to the local IP, and do not receive the Uri error.

I can however easily trigger the Uri error by adding extra slashes at the beginning like "////LAPTOP-HBSSS28P:8181"

Try opening up the file at "C:\Program Files (x86)\Laserfiche\Laserfiche Notification\Service\Laserfiche.PushNotificationService.Master.Host.exe.config" and checking the HubAddress value under the <appSettings> node. That what the FormsConfig Laserfiche Notification Hub URL sets.

Set the HubAddress value to "http://LAPTOP-HBSSS28P:8181" directly within that file (replace it with a clean string even if it already looks the same), save, restart the three Forms/Notification services, and see if it works or if you get a different error.

I found the problem, it is a problem with the latest installers. I just uninstalled and did a fresh install to confirm. Also this is not noted anywhere in the documentation, or I would rather have it right on the config page instead of buried in the documentation.

In the config app there is a Laserfiche tab, this tab ALSO has a notification service configuration (which is strange being that there is an entire section for notification service)

It looks like this and it is auto configured by the installer.

Test connection works showing that nothing is wrong with the connection.

However, simply changing the word localhost to the machine name fixed the URI error and now I see the count of tasks in my inbox. This one actually doesn't even have the //machine: requirement notated.

I was just trying random things and decided to replace this with the machine name, I can't understand how anyone else in the world has figured this out. How is this service working for anyone?