Unattended Installation (LFGet.exe) - Permissions issue

asked two days ago • 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.

0 0

replied one day ago • 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 one day ago • 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 2 hours ago

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

Question

Question

Unattended Installation (LFGet.exe) - Permissions issue

Replies

Sign in to reply to this post.