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

Question

Question

Unattended Installation (LFGet.exe) - Permissions issue

asked on October 28 Show version history

While deploying powershell script via intune which all lfget.exe with this command:
 

install-product --product {A} --iacceptlicenseagreement --iagreetoprereqs --installation-code {B}

I get when run via intune using system context which use NT AUTHORITY\SYSTEM account:

System.IO.IOException: Le processus ne peut pas accéder au fichier 'WindowsClient 12.0.2510.972.exe', car il est en cours d'utilisation par un autre processus.
   à System.IO.Directory.DeleteHelper(String fullPath, String userPath, Boolean recursive, Boolean throwOnTopLevelDirectoryNotFound, WIN32_FIND_DATA& data)
   à System.IO.Directory.Delete(String fullPath, String userPath, Boolean recursive, Boolean checkHost)
   à LaserficheInstaller.DownloadAndInstallService.Dispose(Boolean disposing)
2025-10-27 18:50:01 L7678(30464) Error: Failed to clean up (i.e., delete) the temporary folder C:\WINDOWS\system32\config\systemprofile\AppData\Local\Laserfiche\LFInstaller\Temp\221b7872-3a35-447b-b487-d9b7d0ffa74e because: Le processus ne peut pas accéder au fichier 'WindowsClient 12.0.2510.972.exe', car il est en cours d'utilisation par un autre processus.

 

When I run it locally with administrator right as my own user it work.

 

I also tried to use 

download-product (to use a different path) and install-local-package (would be nice if we could just specify the folder path of the package)

but it still fail because it end up extracting the .exe to same location. Can you fix the permission issue (or wait correctly before it delete) or allow us to specify a temp folder which we could make sure the intune account would have enough privileges.

 

1 0

Replies

replied on October 29

Thanks for reporting this and our reference ID is #622075. We will add option to specify temp folder to address the issue.

1 0
replied on October 29 Show version history

Hi Maxime,

Thank you for reporting this issue. I believe I was able to reproduce a similar issue using "psexec -i -s" to run a PowerShell session as SYSTEM. The Dev team lead for LFGet was able to reproduce the issue as well, with additional diagnostics.

We've marked this as a Priority 1 bug and plan to release an update soon to address it.

Your error messages (translated) say:

  • The process cannot access the file 'WindowsClient 12.0.2510.972.exe' because it is being used by another process. 
  • Failed to clean up (i.e., delete) the temporary folder ... because: The process cannot access the file 'WindowsClient 12.0.2510.972.exe' because it is being used by another process.

 

This isn't a normal file permission issue. The SYSTEM account has Full Control of its profile AppData directory at "C:\Windows\system32\config\systemprofile\AppData\" (note that you cannot normally view this in Explorer). The issue looks to be that it's a controlled folder and preventing the self-extracting .exe from running normally. 

Either way, the solution is to have an optional parameter to provide your own Temp directory for package extraction, and/or skip user directories for LFGet entirely and use something like C:\Temp. I unfortunately don't think there's a simple workaround right now as the Intune agent always runs as SYSTEM.

Note: The \Temp path constructor uses a Windows API, not environment variables, so you can't override the user AppData path by setting session-scoped $env:TEMP or $env:TMP or similar.

0 0
replied on October 29 Show version history

When you say an update will be release soon is it a matter of days or weeks?

Also after further investigations I found:
fcappdb.exe        pid: 8544   type: File           7B4: C:\Windows\System32\config\systemprofile\AppData\Local\Laserfiche\LFInstaller\Temp\ae5ded79-b7cd-4cd8-a1f8-4b7b239d706c\WindowsClient\WindowsClient 12.0.2510.972.exe
fcappdb.exe        pid: 8544   type: File           7B4: C:\Windows\System32\config\systemprofile\AppData\Local\Laserfiche\LFInstaller\Temp\ae5ded79-b7cd-4cd8-a1f8-4b7b239d706c\WindowsClient\WindowsClient 12.0.2510.972.exe

https://docs.fortinet.com/document/forticlient/6.0.1/administration-guide/48323/forticlient-windows-processes

Seen like this process lock the WindowsClient. Do you have forticlient in your environnement too? I will try to add an exception later today and test again.

Edit: Added exclusion and still have the same issue.

0 0
replied on October 30

We don't have a specific target date for the update yet. The issue was verified and filed just last night with the highest priority and severity. I know the team is also thinking through related scenarios and retry logic, so we don't only partially fix the issue. We'll provide an update on timing here as soon as soon as we have one.

We don't have Fortinet FortiClient but when doing research on the issue something we saw people mention was that files in the C:\Windows\System32\config\systemprofile\ were likely to be quickly and aggressively scanned by AV/endpoint protection agents. Something like that is likely causing the "The process cannot access the file 'WindowsClient 12.0.2510.972.exe' because it is being used by another process" error you saw.

Do you still get that exact same error after adding the FortiClient exclusion? If so, a different process like Windows Defender may also hold a lock. We're interested in what process it is.

We still don't expect the command to succeed running as SYSTEM right now with LFGet version 12.0.2510.1223, but you should get the handled exception from LFGet shown below instead of a System.IO.IOException:

  • Encountered an error while unzipping. View the installation log for details and try installing the application again. [INST-1016]
1 0
replied on November 3

Hi Maxime,

We're targeting releasing an official update for the Laserfiche Installer and LFGet that includes this fix and several other fixes and enhancements for mid-November.

However, if you need it sooner, a hotfixed version of just LFGet that includes the SYSTEM user fix should be available to request through a support case in the next day or two. If you file a case requesting the hotfixed build, please reference bug # 622075 so Support can easily locate it for you.

1 0
replied on November 6

Hi Samuel,

 

We tested with the latest hotfixed version and it seem to work with the new default folder is used. However there seem to be a strange issue. Sometimes and seem to repeat over and over on some computers but not all. Installation seem to just stop randomly. Exit code is never returned to powershell script. Also when lfget.exe didn't exist yet we tried another powershell script which we found the forum and the same issue seemed to happen. When it happened we tried to install the Laserfiche installer and same error happened. Each time we looked in the logs folder. download.log and extract.log seem to be there but the msi and setup are sometime missing. Also sometime there is a part of msi logs but it seem to suddently stop and clearly the setup has not finish. Could there be a bug where the setup don't finish/ exit correctly/freeze?

0 0
replied on November 6

Hi Maxine, I haven't run into that issue myself. Could you please open a support case and provide as many details as possible, including all the logs, and the exact scripts and deployment method used?

You can remove potentially sensitive details like hostnames from the scripts and replace them with placeholder values like "$hostname" if necessary.

One thing I would check is if the machines where it fails have .NET Framework 4.8 (or 4.8.1, which is cumulative) installed. Because the full .NET Framework 4.8 installer is very large (~500 MB), the Laserfiche installers only include the .NET Framework 4.8 web installer, which is only a few MB and tries to download the full package from Microsoft over the internet. If the client machines don't already have .NET Framework 4.8/4.8.1, and the MS web installer runs but can't fetch the online package, it will silently fail in a way that the Laserfiche Installer can't easily detect. If that's the problem, you can try downloading the full offline installer from Microsoft and installing it beforehand: Download .NET Framework 4.8.1 | .NET. If the pre-req is already installed, the .NET Framework web installer will detect that and skip to success without attempting to download anything from the internet.

I don't know if that's the cause of the issues you're experiencing here, but I've run into it enough times in general it's worth checking for.

0 0
replied on November 20 Show version history
WixToolset.Dtf.WindowsInstaller.InstallerException: Une autre installation est en cours d’exécution. Terminez celle-ci avant d’effectuer cette installation.
   à WixToolset.Dtf.WindowsInstaller.Installer.CheckInstallResult(UInt32 ret) dans D:\a\wix\wix\src\dtf\WixToolset.Dtf.WindowsInstaller\Installer.cs:ligne 870
   à LaserficheInstaller.Preamble.<DoWork>d__12.MoveNext()
--- Fin de la trace de la pile à partir de l'emplacement précédent au niveau duquel l'exception a été levée ---
   à System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   à LaserficheInstaller.PreambleOrchestration.<DoWork>d__17.MoveNext()

In LFGet.log

We try to install those 6 products and we tried many different ways. We ended switching to your script from other thread but there is something that just don't work. Some products install and there is always a failure somewhere. I think it never ended installed thoses 6 products without any issue. I found this exception in LFGet.log

6 products:
WindowsClient,Snapshot,ScanningSetup,OCR,WebToolsAgent,OfficePluginSetup

The .msi logs seem to be overwrite each minute or so and but it never succeed probably because a previous step failed.

For case 2 it seem to just to end. Most cases throw this exception or seem to "end" at webtools agent.

0 0
replied on November 21

Hi Maxime,

The error message translated to English is:

WixToolset.Dtf.WindowsInstaller.InstallerException: Another installation is running. Complete it before performing this installation. 2 at WixToolset.Dtf.WindowsInstaller.Installer.CheckInstallResult(UInt32 ret) in D:\a\wix\wix\src\dtf\WixToolset.Dtf.WindowsInstaller\Installer.cs:line 870 3 at LaserficheInstaller.Preamble.<DoWork>d__12.MoveNext() 4 --- End of stack trace from the previous location where the exception was thrown --- 5 at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() 6 at LaserficheInstaller.PreambleOrchestration.<DoWork>d__17.MoveNext()

The "PreambleOrchestration" likely refers to the Preamble section of each installation's package.manifest file that lists out packages to uninstall before running the main installation. For example, here's the package.manifest for product Snapshot :

{
    "ID":  "Snapshot",
    "Name":  "Snapshot",
    "Version":  "12.0.2509.942",
    "InstallerFile":  "Snapshot-x64.msi",
    "PackageType":  "LFMsi",
    "LaunchUnattended":  false,
    "RequiresElevation":  true,
    "Prereqs":  [
                    {
                        "Name":  "Visual C++ Redistributable for Visual Studio 2022 (x86)",
                        "Path":  "VC_redist.x86.exe",
                        "Commandline":  "/quiet /norestart",
                        "CheckType":  "Registry",
                        "CheckKey":  "SOFTWARE\\WOW6432Node\\Microsoft\\VisualStudio\\14.0\\VC\\Runtimes\\x86",
                        "CheckValue":  "Bld",
                        "CheckValueTarget":  "33810",
                        "CheckValueRelation":  "GE",
                        "RequiresElevation":  true
                    },
                    {
                        "Name":  "Visual C++ Redistributable for Visual Studio 2022 (x64)",
                        "Path":  "VC_redist.x64.exe",
                        "Commandline":  "/quiet /norestart",
                        "CheckType":  "Registry",
                        "CheckKey":  "SOFTWARE\\Microsoft\\VisualStudio\\14.0\\VC\\Runtimes\\x64",
                        "CheckValue":  "Bld",
                        "CheckValueTarget":  "33810",
                        "CheckValueRelation":  "GE",
                        "RequiresElevation":  true
                    }
                ],
    "Preambles":  [
                      {
                          "PreambleType":  "UninstallPackage",
                          "Data":  "{6D5DE936-AB30-4B38-9089-C2CFC3740616}",
                          "Scope":  1
                      },
                      {
                          "PreambleType":  "UninstallPackage",
                          "Data":  "{4634FEE5-E19B-4C52-9EBB-FE3E9D2816E9}",
                          "Scope":  1
                      },
                      {
                          "PreambleType":  "UninstallPackage",
                          "Data":  "{36596786-7877-494D-B8CD-9140E9BFAFDD}",
                          "Scope":  1
                      },
[truncated a bunch of other "UninstallPackage" preambles]
                      {
                          "PreambleType":  "UninstallPackage",
                          "Data":  "{58F26869-0624-4054-9688-95D581D69DA4}",
                          "Scope":  1
                      }
                  ]
}

I believe the data fields are product GUIDs for older versions of the application that correspond with potential entries you'd find in registry paths:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
  • HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall

 

Of the 6 products you listed, only WindowsClient and Snapshot have preambles. This might mean LFGet is trying to uninstall the existing version of WindowsClient and/or Snapshot, that's failing/hanging for some reason (maybe because a user has the application is running and needs to be closed first), and then the other installations are failing because the uninstall (which Windows considers an "installation in progress") is stuck.

It's also possible that an installation from a prereq like .NET Framework 4.8 is stuck (sometimes happens with the .NET or Edge WebView2 runtime online installers when the machine can't download the package from Microsoft over the internet), which is also an "installation in progress" to Windows and could a Laserfiche preamble uninstall.

I would be curious if you still experience the error if you run the LFGet installation on a machine without older versions of the software installed. A good test case would be:

  1. Manually uninstall the Laserfiche client applications from a machine you encountered the errors on with LFGet
  2. Reboot the machine
  3. Run the same LFGet installation as before and see if you get the error
0 0
replied on November 28

I slightly modified your script to kill some process that seemed to block us and LFGET because it seemed to get stuck forever and then cause issues if Intune retried to install again (we ended with multiple LFGET.exe trying to same product when if fail. I think there should be a timeout or there is a case where it is not managed correctly. Like when there is another installation in progress it seem like an unhandled exception in logs). Then after the install loop I start those again. Now we are facing a new issue with Webtools agent. (Exit code are for Intune to know if it failed or not)

In main log:

[2025-11-28 10:48:39] Start
Laserfiche Webtools Agent 11.0.2509.11

Download started
Downloading...................
Download succeeded

Installation started

Installation canceled

Download log:
 

2025-11-28 15:48:41 L7374(45936) Created the directory C:\Temp\6970aa6f-09ca-4b7c-8190-c93a2df57a23\WebToolsAgent

Extract log:
 

2025-11-28 15:48:41 L7374(45936) Verifying checksum: 'DF2E46188D13D09388FCB667F49A1833C42FC6538A63B3E02701BD59A29FCB2F'.
2025-11-28 15:48:41 L7374(45936) Verifying the signature of package 'C:\Temp\6970aa6f-09ca-4b7c-8190-c93a2df57a23\WebToolsAgent\WebToolsAgent 11.0.2509.11.exe'.
2025-11-28 15:48:42 L7374(45936) Extracting package 'C:\Temp\6970aa6f-09ca-4b7c-8190-c93a2df57a23\WebToolsAgent\WebToolsAgent 11.0.2509.11.exe' to 'C:\Temp\6970aa6f-09ca-4b7c-8190-c93a2df57a23\WebToolsAgent'.

And setup.log:

[PID: 12780] 2025-11-28  Laserfiche Setup (C:\Temp\6970aa6f-09ca-4b7c-8190-c93a2df57a23\WebToolsAgent\ClientWeb\SetupLf.exe) Log
[PID: 12780] 10:48:43.767  Setup.exe was run with the command line:  /log C:\Temp\LFGet\Logs\2025-11-28 104841 Laserfiche Webtools Agent 11.0.2509.11 /lang fr-FR /noui /silent /iacceptlicenseagreement
[PID: 12780] 10:48:43.767  Beginning silent installation.
[PID: 12780] 10:48:43.767  Loading language Français‏ - French.
[PID: 12780] 10:48:43.780  Finished loading language.
[PID: 12780] 10:48:43.780  Beginning MSI update check.
[PID: 12780] 10:48:43.780  No MSI update was necessary.
[PID: 12780] 10:48:43.800  Version 11.0.2502.10 of Laserfiche Webtools Agent is installed (minor upgrade).
[PID: 12780] 10:48:43.819  Found file 'C:\Temp\6970aa6f-09ca-4b7c-8190-c93a2df57a23\WebToolsAgent\ClientWeb\lfwebtools.msi'.
[PID: 12780] 10:48:43.832  Beginning prerequisite install.
[PID: 12780] 10:48:43.833  Beginning main install.
[PID: 12780] 10:48:43.905  Main install failed. Canceling setup.

Main install failed but there is no reason at all. Nothing in windows event viewer and main log just say installation cancelled. It seem to happen to all test deployment group users. The folder seem to be deleted immediataly and there is no msi log file. Also it would be nice if LFGet would have an action to verify if a product update is available so I could only kill those process if needed.

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

Sign in to reply to this post.