LN Transfer Service - Consistently failing after outages/patches

Hi All,

'We are using the LN Transfer Service with our Multi-Tenant cloud instance to process print jobs and file downloads and finding that the Transfer Service fails after every outage and never recovers. The service continues to be in a "Running" state in Windows, but no longer processes any files or print jobs and there are a slew of error messages in the logs until we restart the service in Windows.

We've opened a ticket with Infor, but curious if anybody else experiencing this issue? If so, how do you handle? It's simple enough to restart the service and get it running again, but looking for an automated solution or workaround.

Thanks!

Find more posts tagged with

Baan / LN - General Discussions

Accepted answers

All comments

unknown

According to one of the old KBs, the user under whom the service of LN File Transfer is run should be an administrator on that server. Please verify that and change it if needed.

aplatt2

Hi Eyal, good to see you on here! Hope all is well.

I did verify that the account the service is running under is an administrator on the server.

The service itself runs great, it just doesn't seem to handle outages very gracefully and doesn't recover. The Windows Service continues to run, but the error logs start piling up. A simple restart of the service fixes, but it just doesn't look good to our end users so was hoping somebody had a remedy.

unknown

Sorry to see MU not doing that good.

We had similar issues in the past and it was fixed by changing the user whom the service runs under. I would recommend to update the software to the latest release and check again. If still an issue, create a case with support and let them help you.

Ken Stulce

To answer your main questions, Yes, it is possible to just restart the related LN FTS Windows service to get things running again.

Since LN FTS is a locally installed application (on your network), make sure to pay attention to software updates for the application. The application doesn't exist where you would normally think it does with Software Downloads in Concierge, so I had to do some digging after discovering of newer versions and bug fixes released in relation to this issue. See KB 1629931 "Tools: Generic solution for Infor LN Transfer Service" link below with version and download options. Save, Favorite, and subscribe to this KB to keep up to date on released versions.

https://customerportal.infor.com/csmcore?id=kb_article_view&sysparm_article=KB1629931

Also, make sure you have one folder of separation with relation to LN FTS "Download" process tasks, as the polling interval can and will download files that are still in the process of writing on InforOS, regardless of how large or small they are. It really has no way of knowing a file is still being written before trying to download it (per Infor Support/Dev). Because of this issue and the fact that short polling intervals could potentially download incomplete chunks of a file being actively written (such as by Export Data sessions), I suggest to change you polling interval to at least 600 seconds (10 minutes) or greater to avoid timing related issues. It has helped us a bunch, but still not perfect.

I'm in the process of implementing/testing a Python script ran by Windows Scheduled Task to enable and disable an LN FTS Download task for a specific Connection in the overall FTS configuration XML file, in order to have more control of when the task runs, since polling interval is our only option. The only issue is related to "reloading" the configuration, which is what happens in the Windows Snap-In MMC program when saving changes, versus restarting the overall Windows Service. I'm unsure if a service restart for LN FTS happens gracefully for any existing printing or download tasks are in process at that moment, but it is a current research task for me to verify. See link to latest LN FTS docs below. Also, see link to page for "File Name Filtering", as I just learned recently that it can except Regular Expressions.

https://docs.infor.com/ln/latest/en-us/lnesolh/default.html?helpcontent=lnrptcpsag%2Fcover.html

https://docs.infor.com/ln/latest/en-us/lnesolh/default.html?helpcontent=lnrptcpsag/ehm1554905699912.html

It is possible to programmatically restart the Windows service with a PowerShell script running from Scheduled Tasks, but there's no way of really knowing if FTS is hung, except for reviewing the logging errors. The recent updates of LN FTS has better connection handling to avoid timeouts for large files/long downloads. I recently found in documentation mentioning where there are two modes for Downloads - 1) LN method <= 10MB files, or 2) S3 method >10MB files. I believe the S3 method writes to InforOS at AWS_S3 folder path, whereas LN seems to write to AppData folder path. This may be well known in other circles, but it wasn't widely known or documented for us, in IGS.

Also, you may want to review the Windows Service "Recovery" options, especially if there is a power outage locally. I set ours to restart the service, up to three times, though it's possible to add an alert type of option, to inform you directly if service is having problems restarting. This doesn't necessarily recover any partially downloaded or processed jobs though that I can tell.

In relations to printing, I prefer generating a PDF for print jobs (via Display output option) and using locally installed print drivers, so end-users can print to whichever printer and as many copies as needed. The only exception for us is check printing, where it should be one and done per payment batch, with limited user visibility. Using locally installed print drivers option also gets around issues where printers cannot print a PDF file natively and need the print driver to convert and render the job in its known language.

I hope some of this information is helpful.

Copyright © 2025 Infor. All rights reserved.