Does the Web Tools Agent have a log anywhere? We are trying to see why it is not listening on it's port and there is nothing in the event viewer.
It logs to the user's Local Application Data folder, which by default is C:\Users\username\AppData\Local\Laserfiche\Webtools Agent\Logs.
What problem are you having Chad?
A customer had installed web scanning but they were told over and over again that there was a new update released and asked to download the new update.
It was as if a new update was being released every minute.
In the past I have troubleshot scanning before and I know it relies on the installation of the web tools agent so we made sure this was installed. I also know that you can check for errors under Options > Advanced and here we saw that it was failing on all ports.
After running a netstat we see that those ports have nothing listening.
This was very odd, so I am looking to see if maybe there is an error being posted in a hidden log that could explain why the service would not be listening on at least one of the 3 listed ports.
So the update prompting and port (not) listening are likely independent issues.
The way the update checks work is that the local service (WebTools, Scanning, etc.) build number gets checked against the value in a file on the Web Client side. In a self-hosted Laserfiche system, the file paths on the server are like ".\Program Files\Laserfiche\Web Access\Web Files\Webtools\WebtoolsBuildNum.txt" and the contents will be a string like "11.0.0.52". There are a few of these, so look for them under these directories:
If Web Client detects the local build number is lower than the one it has the the "*BuildNum.txt" file, it'll throw the "An update is available" prompt. It might also throw the update prompt if a "*BuildNum.txt" file or its contents are missing. That could be a reason why it gets thrown every time. I vaguely recall that Web Client logs an event with a message like "*BuildNum.txt could not be found" when that happens.
Regarding the port listener:
The Webtools Agent process on the user's local machine dynamically picks an available listening port from the 18435-18437 range on startup. The available ports are determined at the host machine level, so if a customer is using VDI / terminal server desktops where many users have sessions on the same underlying host, the first three users on a given VDI host to run Webtools Agent will claim listening ports 18435, 18436, and 18437, and the unlucky fourth(+) user will get a "No listening port is available" error. I'm not sure running netstat from an individual user's session will show you other port listeners from other user's sessions on the same VDI host.
The next update for Web Client 11 will add the ability to configure a larger port range to accommodate those scenarios.
Other random Webtools Agent info:
Webtools Agent has a bundled public TLS certificate for plugin.laserfichelocalhost.com [plugin.laserfichelocalhost.com]. When this cert expires, Webtools Agent attempts to fetch an updated one over the internet from a Laserfiche-owned public AWS S3 bucket. This is a public domain that Laserfiche owns, and we have a public DNS A record [whatsmydns.net] for it that resolves it to 127.0.0.1, the universal localhost [localhost] IP. Very clever. You should only need an internal DNS or local hosts file DNS entry mapping plugin.laserfichelocalhost.com [plugin.laserfichelocalhost.com] to 127.0.0.1 if the end user machine cannot resolve the public DNS entry (not the case here).
Web Client can't know upfront which port a given user is listening on so it tries to connect to plugin.laserfichelocalhost.com [plugin.laserfichelocalhost.com]:18435-18437, and whichever call goes to the port the local Webtools Agent process is listening on will succeed/connect and all the others will fail.
By way of analogy, imagine there is a row of a three doors (ports), one of which (at random from your perspective) might have a person behind it. You knock on the doors in a row to see which one (if any) the person answers. If one opens (connects), you then have a lovely conversation about Scanning or opening Word documents or whatever people who are stand-ins for ECM plugin code talk about.
Thank you, this helps me understand much better except one critical thing. How is a website out on the internet, app.laserfiche.com, looking at a text file on the local C drive of the users workstation (BuildNum.txt)? It can do this simply by the user visiting a website in their Chrome browser?
It doesn't need to have a conversation with the web tools agent and ask the local agent to read the file?
The reason I ask is because if the agent isn't listening for requests, then the build number can not be read and therefore the port not listening is not independent of the problem.
Ah, this is Laserfiche Cloud. It's always helpful to specify that in the original post.
It would need a connection. Web Client connects to Webtools Agent and then asks it for its version numbers, Webtool Agent responds, Web Client checks that reported value against what it has as the latest on its side, and then throws the dialog (or not).
What I suspect might be happening is: