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

Question

Question

How We Solved LFF706-UnableToTriggerRouting and LFF3004-UnableToOpenServiceProxy After Upgrading to Forms 11

Forms
Updated November 25, 2024
asked on April 20, 2022

We now have this issue resolved - but I wanted to share the solution we found in case it helps anyone else down the line.

This plagued us for weeks, and finally took a support call between myself, our VAR, and a rep from Laserfiche in order to resolve it.

We were trying to run Forms on a test server, and could not get any process to run, repeatedly seeing errors stating LFF706-UnableToTriggerRouting and LFF3004-UnableToOpenServiceProxy.

We evenually narrowed down that the service worked fine when installed on earlier versions (we tested 10.2.0, 10.2.1, and 10.4.3) but wasn't working on the newer versions (we tested 11 and 11 Update 2).

I'll post the solution we finally figured out and mark it as the answer below.

3 0

Answer

SELECTED ANSWER
replied on April 20, 2022

A new service was added after version 10.4.3 - I don't know if it's in 10.4.4 or doesn't show until version 11 - I do know it wasn't there when we tested with 10.4.3, but was there with 11.

In the C:\Program Files\Laserfiche\Laserfiche Forms\Forms\Web.config file the line looks like this: 

<endpoint address="net.tcp://localhost:8172/lfinstance" binding="netTcpBinding" bindingConfiguration="timeoutBinding" contract="Laserfiche.Forms.Routing.IInstanceProcessing" name="" />

In the C:\Program Files\Laserfiche\Laserfiche Forms\Forms\bin\RoutingEngineServiceHost.exe.config file there were two lines that looked like this: 

<add baseAddress="net.tcp://localhost:8172/lfinstance"/>

and 

<endpoint address="net.tcp://localhost:8172/lfinstance" binding="netTcpBinding" bindingConfiguration="timeoutBinding" contract="Laserfiche.Forms.Routing.IInstanceProcessing" name=""/>

As you can see, those three points all reference port 8172.

When running this line from an administrator elevated command prompt: 

netstat -ano -p tcp

We were able to see that the port was being used by a different PID than Forms - in this case, one that showed "System" when we checked the Details under Task Manager.

Under Windows Firewall, we found rules indicating that the port was being opened for use by "Web Management Service".  A little more research, and we found that is a service used by IIS in order to allow the Web Deploy functionality (and probably other stuff too).  I had installed Web Management Service and Web Deploy because I have several custom sites that I have created and publish from Visual Studio directly to IIS the server.  This hasn't been an issue on the older versions of forms, but with the new version trying to use port 8172, we couldn't get any forms to route through the system properly.

This port conflict was the source of our issue.

We switched the three references in the configurations to use Port 8176 instead of 8172, added Windows Firewall inbound and outbound rules to allow access within our domain to port 8176, and rebooted the server.  After that, all the errors were resolved, and Forms began operating as expected.

Because this was such as weird situation, I wanted to share the solution here in case it helps anyone in the future.

9 0
View 9 previous replies
replied on April 22, 2022

Hi Matthew,

    Sorry for the confliction of the ports and thanks for sharing your solution with the community. We will update the port in next release of Forms to avoid such confliction. 

2 0
replied on April 22, 2022

Wow!  I didn't expect a change to the release over this!  Thank you @████████!

0 0
replied on September 13, 2022 • Show version history

This has been a frustrating issue for me as well. Thank you for sharing this resolution.

0 0
replied on September 18, 2022

Excellent write-up, and it helped us get to the root of our identical issue, right down to Web Deploy.  We used 8176 as well.  Thanks very much @████████!

@████████, do you know if the updated port will be 8176 or something else at this time?  I'd like to avoid this next time we upgrade to the next version of Forms.

0 0
replied on September 18, 2022

We will change the port to 8176 since there is no common services using this port. 

1 0
replied on September 20, 2022

I'm so happy to hear this post helped you @████████ and @████████!

0 0
replied on December 9, 2022

Super strange scenario with this. On the 4th at 11am this port got hijacked (why does Forms give it up?)

All forms submissions were halted and the moment we logged onto the server was the moment nothing was using the port again. So we could never run the command to find out what it was.

The last entry regarding the port being in use was at 9:08am just before logging into the server to see what was going on. I restarted the Forms Routing service at 9:12am and ever since the port is not in use, so we could never see what was using it.

No Web Deploy or Management Service is installed, and it could not have been uninstalled since the errors were occurring all the way up to within 4 minutes of us logging in to the server.

It is almost as if the Forms Routing service will continue to complain about the port being in use whether it is or not until restarted.

0 0
replied on December 11, 2022

Did you get LFF706-UnableToTriggerRouting and LFF3004-UnableToOpenServiceProxy as well? Can you provide the event logs for the Forms and Windows Logs->Application and open a support case for further investigation? 

0 0
replied on March 9, 2023

We have the support case open but while we are waiting to hear on their findings, what is the technical term from Microsoft for a service being robbed of it's port?

I am not even aware of this ability within Windows Server. How can something "steal" a port that a service is already using?

0 0
replied on March 9, 2023

Is it for port 8172? If it is for 8172, that is because both Forms Routing Service and Web Management Service are using same port, so there is conflict. 

0 0
replied on March 10, 2023

Well in our case, it is for all ports. We switched away from that port.

But even if Web Management Service or any other service wanted to use a port that Laserfiche is using, how could it? What is the method of stealing a port from a service? Only one service can listen on a port at a time, so another service can not cause interference by trying to listen on the same port.

As far as I know it is impossible to have a conflict, unless you can point me to something I am unaware of with how ports work.

0 0
replied on March 4, 2024

What happens if you run this command and you find that [System] is using all 5 of the ports that the Forms service wants to use:

8176
8168
8268
8732
8736

Why in the world did the system decide it needed these exact ports? So crazy.

I feel like services, when they crash, can leave ports open inside of the system even after the service is closed out of memory. This happened following a null reference error and forced termination of the Forms service.

0 0

Replies

replied on January 6, 2023

We have changed the default port to 8176 for new installations or  when upgrade from versions before Forms 11 with Forms 11 Update 3.

You can see other changes of Forms 11 Update 3 from  https://support.laserfiche.com/kb/1014413/list-of-changes-for-laserfiche-forms-11-update-3 and get Forms 11 Update 3 from Laserfiche 11 package  https://support.laserfiche.com/kb/1014263/software-versions-and-fixes-included-in-the-laserfiche-11-download-package. 

3 0
View 2 previous replies
replied on January 25, 2023

@████████, I installed Forms 11 Update 3 in our test environment and when looking at the \Forms\web.config file I see that for the lfinstance endpoint that 8172 is still set. I do not see port 8176 configured on any of the end points.

1 0
replied on January 25, 2023

That's interesting @████████- I just checked mine on my test server (the only place I've upgraded so far) and it is showing 8176 in all three places across both files.  Of course, I had manually updated those in April 2022, but they both now show modified date of 1/13/2023, which is the day I upgraded that server.  I had assumed that it reinstalled those files, but with the modified ports.

0 0
replied on January 25, 2023

We upgraded from Forms 11 Update 2 so I would have expected it to change the ports based on Xiuhong's post, but doesn't look to have done that.

1 0
replied on January 27, 2023

We only changed to 8176 when there is no existing port 8172/lfinstance during upgrade in order to keep existing system unchanged as you may need to open new port to make your system work.

2 0
replied on August 2, 2023

Interesting. I was glad to find this post as I was not aware and when I saw Port 8176 I was confused. That being said I do not believe the LF 11 DMZ White Paper has been updated yet.

 

1 0
replied on November 25, 2024

Recently I upgraded Laserfiche 10.4 to 11 and started getting the LFF706-UnableToTriggerRouting and other errors.  (Like...  "An error occurred while running the process. Please make sure Laserfiche Forms is configured properly. Manually restart Laserfiche Forms Routing Service to ensure that all necessary changes take effect. [LFF706-UnableToTriggerRouting]")

I found that I had to register the URL's otherwise the Forms service couldn't open all of those ports listed above.  (We typically run our LF services using a normal user domain account and not one with Administrator access to the system.   Like...  DOMAIN\svc-lf-dev...)

From DOS, logged in as an administrator on the Forms server, I ran the following for each "[500]: System.ServiceModel.AddressAccessDeniedException: HTTP could not register URL" error that I noticed in the Event Log\Applications and Services Logs\Laserfiche\Forms\App\Operational log when starting the Laserfiche Forms Routing Service.

Here are two examples:

netsh http add urlacl url=http://+:8173/Design_Time_Addresses/InstanceProcessingServiceLib/Service1 user=YOURDOMAIN\YOURSERVICEACCOUNTNAME
netsh http add urlacl url=http://+:8175/Design_Time_Addresses/LookupService/Service1 user=YOURDOMAIN\YOURSERVICEACCOUNTNAME
 

Note the http://+ values are different.  (Port #'s as well as "folder" names.)  I copied the URL's from the error log messages when constructing the command line.

After that, I restarted the Forms Routine Service.

Note that I also ran the following from DOS before and then right after restarting the service:

netstat -a -b >netstat.txt

netstat -a -b >netstat_after.txt

When I compared the two resulting files, I found that the service was able to open a lot more ports.  :-)

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

Sign in to reply to this post.

Details
Related Posts
Loading ...