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

Question

Question

New Laserfiche version 2025 H2 (Fall release) -- Unattended Installation (LFGet.exe)

asked on October 22

In the provided online documentation...

https://doc.laserfiche.com/laserfiche.documentation/12/userguide/en-us/content/install-installer.htm#UnattendedInstallation(LFGet.exe)   

...it talks about how to deploy some components locally to a server.

The deployment scenario I'm looking for is... How do I automate LF Windows Client deployment/upgrade to multiple workstations using the LFGet.exe? trying to get an example from Laserfiche on this. My customer Will need to update the following components:

  • OCR
  • OfficePluginSetup
  • RepositoryAdmin  
  • ScanningSetup  
  • Snapshot  
  • WebToolsAgent  
  • WindowsClient


Any example available?

0 0

Replies

replied on October 24 Show version history

LFGet is a standalone utility which is available on the workstation where Laserfiche Installer is install. People can copy the folder %localappdata%\Laserfiche\LFInstaller\Plugins\LFGet to remote machines and run the utility by different methods:

 

For example, copy LFGet to C:\LFGet\ to remote machines and run C:\LFGet\LFGet.exe install-local-package --package 'C:\Laserfiche Software\LF12 2025H2\WebToolsAgent 11.0.2509.11.exe' --iacceptlicenseagreement --iagreetoprereqs

LFGet runs against the packages Laserfiche Installer downloads, people don't need to unzip/extract.

1 0
replied on October 22

The documentation on LFGet appears to be pretty lacking, and what is available, is hard to find (as is the LFGet exe itself). I found some documentation here: https://doc.laserfiche.com/laserfiche.documentation/12/userguide/en-us/content/install-installer.htm#UsingtheInstallertoManuallyInstallaLocalPackage but still have a few questions myself, for example do we run LFGet against the self extracting .exe file that Laserfiche installer provides, or are we supposed to unzip it and run it against a specific file in the unzipped package?

0 0
replied on October 24 Show version history

It appears the remote installation part of the LFGet documentation didn't make it out with the release for some reason. Thanks for pointing that out - we're following up internally and will get it updated, along with some improved examples. In the meantime, I can answer both of your questions.

For the install-local-package method, the --package (or -g) parameter takes the self-extracting .exe you get from the Download option in the Laserfiche Installer. You don't need to unzip/extract it.

Here's a full working command string for that against a downloaded Webtools Agent package:

.\LFGet install-local-package --package 'C:\Laserfiche Software\LF12 2025H2\WebToolsAgent 11.0.2509.11.exe' --iacceptlicenseagreement --iagreetoprereqs

LFGet.exe is a standalone utility. You get the initial copy with an instance of the Laserfiche Installer, and can find it at the default path:

C:\Users\%username%\AppData\Local\Laserfiche\LFInstaller\Plugins\LFGet\LFGet.exe

From there, the basic idea is to copy LFGet.exe to remote machines and use different ways to run it. You can run it with install-local-package (which you can point to a local or network location with pre-downloaded exe packages) or install-product and it'll download what it needs. You can also run it with download-product to download a product package without using the Laserfiche Installer GUI.

Some example methods are:

  • Windows Remote Management (winrs)
  • PsExec -h -i \\remoteComputerName -c LFGet.exe $params
  • Group Policy (which can run scripts)
  • SCCM, BigFix, Intune, or other IT deployment manager tools that can run scripts

 

Daniel, in your case, you'd (programmatically) copy LFGet to each client machine. Then run commands with it to install each product from an online or local package source. If local package source, either have your script copy the packages to each client machine locally as well or store them at an accessible network location. 

2 0
replied on October 27

Hi Samuel, thank you for the info, I appreciate it. One follow up question, when running the install, a cmd window opens, is there a switch/option for a quiet install (I checked the /? but didn't see one listed).

0 0
replied two days ago Show version history

Eric, I also tried to figure this out, but not having any luck. The support and lack of foresight by Laserfiche is really amazing.

 

Samuel, do you have any input on a silent install switch or have an ETA on when this will be available? Even if we relay an install will take place on a users machine if they see a black box with white text it in pop up they'll close it out...

 

Edit: Eric, I'm not sure how you are deploying LF, but I was able to deploy it and not have pop-ups by using PDQ Connect. Though I'm sure PDQ Deploy would work too along with other deployment types.

 

How are you trying to deploy LF 12 and I can try to help you out or provide feedback with how I was able to do it. 

0 0
replied two days ago

Hi Lance, we are deploying through Microsoft Configuration Manager (formerly SCCM) and Software Center.

I have noticed two issues so far, the black CMD screen comes up, and when running a powershell script to script multiple installs (such as desktop client, and snapshot), those seem to fail as well. I think it may be the next install calling the LFGet, which bumps the previous install (I think the downloading... part of LFGet is reporting as completion, satisfying the -Wait switch we use in our PS Script, so then the next install starts, cutting off the previous one). I'm going to try multiple copies of the LFGet folder in our deployment, one for each installer, to see if that resolves that part of the issue.

0 0
replied two days ago Show version history

So it's been a while since I used SCCM. But, it should pretty much work the same way as PDQ.

 

Are you having SCCM call the script/powershell or are you just having it execute the commands? I think that could be the cause of the prompts popping up. As for it trying to bump the previous install that's where the wait command helps in my scripts that it calls. Perhaps this will give you a few ideas?

 

Sorry about the text wrapping... There is probably a good way to straighten it out and I can do that if needed/share my scripts.

 

For instance I have it setup this way:

1. I have the installation files copied over to C:\Installs\Laserfiche in a zip file that then extract the folder containing the LFGET resources.

2. Install pre-reqs as they don't always pull down for some reason. This is in a batch file that PDQ copies over and then runs. (Some redistributables)  My script is below:

echo off
CD C:\Installs\Laserfiche\MSVC2012\
REM Install MSVC 2012 x86 Redistributable silently and wait for completion
start /wait "" "C:\Installs\Laserfiche\MSVC2012\vcredist_x86.exe" /quiet /norestart
echo MSVC 2012 x86 Redistributable installation completed with exit code %errorlevel%.

REM Install MSVC 2012 x64 Redistributable silently and wait for completion
start /wait "" "C:\Installs\Laserfiche\MSVC2012\vcredist_x64.exe" /quiet /norestart
echo MSVC 2012 x64 Redistributable installation completed with exit code %errorlevel%.

CD C:\Installs\Laserfiche\MSVC2022\
REM Install MSVC 2022 x86 Redistributable silently and wait for completion
start /wait "" "C:\Installs\Laserfiche\MSVC2022\vc_redist.x86.exe" /quiet /norestart
echo MSVC 2022 x86 Redistributable installation completed with exit code %errorlevel%.

REM Install MSVC 2022 x64 Redistributable silently and wait for completion
start /wait "" "C:\Installs\Laserfiche\MSVC2022\vc_redist.x64.exe" /quiet /norestart
echo MSVC 2022 x64 Redistributable installation completed with exit code %errorlevel%.

echo All installations completed.

 

3. Then I have a script that runs that kills all associated processes that can bomb out the install. (Not sure if you've had that problem in the past, but if say someone opens an Office app it can kill the install)

4. Now I have another script that actually calls the LFGET program

echo on (this is simply on for helping me troubleshoot you could turn to off)
REM Installs the Laserfiche OCR utility silently and wait for completion.
CD C:\Installs\Laserfiche\
start /wait C:\Installs\Laserfiche\LFGet.exe install-product --product "OCR" --iacceptlicenseagreement --iagreetoprereqs --installation-code XXXXXXX --licensing-mode lfds --license-server SERVERNAME --license-database SERVERNAME --log "C:\Installs\Logs"

REM Installs the Laserfiche Office Plugin silently and wait for completion.
start /wait C:\Installs\Laserfiche\LFGet.exe install-product --product "OfficePluginSetup" --iacceptlicenseagreement --iagreetoprereqs --installation-code XXXXXX --licensing-mode lfds --license-server SERVERNAME --license-database SERVERNAME --log "C:\Installs\Logs"

REM Installs the Laserfiche Scanning utility silently and wait for completion.
start /wait C:\Installs\Laserfiche\LFGet.exe install-product --product "ScanningSetup" --iacceptlicenseagreement --iagreetoprereqs --installation-code XXXXXXXX --licensing-mode lfds --license-server SERVERNAME --license-database SERVERNAME --log "C:\Installs\Logs"

REM Installs the Laserfiche Snapshot utility silently and wait for completion.
start /wait C:\Installs\Laserfiche\LFGet.exe install-product --product "Snapshot" --iacceptlicenseagreement --iagreetoprereqs --installation-code xxxxxxxxxx --licensing-mode lfds --license-server SERVERNAME --license-database SERVERNAME --log "C:\Installs\Logs"

REM Installs the Laserfiche Webtools Agent silently and wait for completion.
start /wait C:\Installs\Laserfiche\LFGet.exe install-product --product "WebToolsAgent" --iacceptlicenseagreement --iagreetoprereqs --installation-code XXXXXXXXXXXXX --licensing-mode lfds --license-server SERVERNAME --license-database SERVERNAME --log "C:\Installs\Logs"

REM Installs the Laserfiche Client silently and wait for completion.
start /wait C:\Installs\Laserfiche\LFGet.exe install-product --product "WindowsClient" --iacceptlicenseagreement --iagreetoprereqs --installation-code XXXXXXxx --licensing-mode lfds --license-server SERVERNAME --license-database SERVERNAME --log "C:\Installs\Logs"

echo The Laserfiche Client installation completed with exit code %errorlevel%.

 

I can share the files if needed. But, I think this may help you out. Sometimes just having it run the code vs a script it doesn't work depending on the circumstances from what I've had happen in the past.

 

There is also a discussion over here where someone created a 3rd party PS script for the install. I didn't want to use a 3rd party script, but others have had success with it. https://answers.laserfiche.com/questions/228123/New-Laserfiche-Installer-unattended-installation-documentation

0 0
replied one day ago

Welcome to Answers, Lance. It's totally fair to want a smoother experience for end users. That said, be nice, especially if you're asking for help. Constructive feedback always more helpful than venting.

I've asked internally about a native silent install switch for LFGet and will share any updates as soon as I hear back.

In the meantime, since LFGet will typically run via PowerShell or CMD, you can use their built-in features to run it in the background so users don’t see a terminal window while it's running. That can help avoid confusion or premature closure.

Also note: this only matters if the install script process runs under the user's own identity. If your deployment tools run the script as SYSTEM or other such service identity, the user won't see anything anyway. This is easy to test with 

PowerShell Example 

With install PowerShell script:

# LFGet-Test.ps1

$InstallationCode = 'Your Laserfiche Support site installation code'
$LFGetDirectory = 'C:\Your\Path\To\LFGet'
$DownloadDirectory = 'C:\Your\Download\Path'
$LogDirectory = 'C:\Your\Log\Path'

# Refer to available product values at:  https://doc.laserfiche.com/laserfiche.documentation/12/userguide/en-us/content/install-installer.htm
$Products = @(
    'WebToolsAgent'
    'WindowsClient'
)

Set-Location $LFGetDirectory

foreach ($Product in $Products) {

	.\LFGet download-product --product $Product --installation-code $InstallationCode --dest $DownloadDirectory --log $LogDirectory
}

Invoke the script with PowerShell parameter "-WindowStyle Hidden":

$scriptPath = 'C:\Users\samuel.carson\Documents\Projects\5-Resources\Laserfiche Software\LFGet-Test\LFGet-Test.ps1'

Start-Process PowerShell.exe -ArgumentList "-ExecutionPolicy Bypass -WindowStyle Hidden -File `"$scriptPath`""

The terminal window will flash once and then disappear into the background before a user could plausibly interact with it. And again, only relevant if you're running the install script under the user's own identity in the first place.

Note: I also tried using "-NoNewWindow" instead of "-WindowStyle Hidden" but it didn't work. PowerShell appears to launch and close without invoking the script. Possibly related to this Stack Overflow thread: powershell - Suppressing The Command Window Opening When Using Start-Process - Stack Overflow

CMD Example

With install batch script:

REM LFGet-Test.bat

@echo off
setlocal
set "InstallationCode=Your Laserfiche Support site installation code"
set "LFGetDirectory=C:\Your\Path\To\LFGet"
set "DownloadDirectory=C:\Your\Download\Path"
set "LogDirectory=C:\Your\Log\Path"

REM Change to LFGet directory
cd /d "%LFGetDirectory%"

REM List of products to download
set Products=WebToolsAgent WindowsClient

REM NOTE: Use %%P if saving this as a .bat file. Use %P if running interactively.
for %%P in (%Products%) do (
    start /b LFGet download-product --product %%P --installation-code %InstallationCode% --dest "%DownloadDirectory%" --log "%LogDirectory%"

)

Where "start /b" runs LFGet in the background, so no terminal window stays open.

You can invoke the batch script itself in the background with:

START /B CMD /C CALL "C:\Your\Path\To\LFGet-Test.bat"

Hope that helps.

-Sam

0 0
replied one day ago

Hi Lance and Sam,

I can confirm the box/window does open even when ran as SYSTEM (Which SCCM does), but it is not the CMD window, it is the LFGet window, with its steps running (ie downloading...) then it closes, and almost immediately another one runs (presumably the next step), again a LFGet window with downloading.... (I can grab a screen shot if you'd like?).

For the SCCM deployment, we are sending all of the files to local machine, along with a PS script, and the SCCM SYSTEM account runs the script (which is standard for us, as regular users do not have Admin or software install rights).

Here is the install portion of my script, if it helps??


 

Write-Host "Installing Desktop Client"
Start-Process -FilePath '.\LFGet\LFGet.exe' -ArgumentList 'install-local-package', '--package ".\WindowsClient 12.0.2510.972.exe"', '--iacceptlicenseagreement', '--iagreetoprereqs', '--log "C:\Logs\LF_Desktop_Installer"' -Wait

Write-Host "Installing Web Tools"
Start-Process -FilePath '.\LFGet\LFGet.exe' -ArgumentList 'install-local-package', '--package ".\WebToolsAgent 11.0.2509.11.exe"', '--iacceptlicenseagreement', '--iagreetoprereqs', '--log "C:\Logs\LF_Webtools_Installer"' -Wait

Write-Host "Installing Snapshot"
Start-Process -FilePath '.\LFGet\LFGet.exe' -ArgumentList 'install-local-package', '--package ".\Snapshot 12.0.2509.942.exe"', '--iacceptlicenseagreement', '--iagreetoprereqs', '--log "C:\Logs\LF_Snapshot_Installer"' -Wait

Write-Host "Installing Scanning"
Start-Process -FilePath '.\LFGet\LFGet.exe' -ArgumentList 'install-local-package', '--package ".\ScanningSetup 12.0.2507.188.exe"', '--iacceptlicenseagreement', '--iagreetoprereqs', '--log "C:\Logs\LF_Scanning_Installer"' -Wait

Write-Host "Installing Office Plugin"
Start-Process -FilePath '.\LFGet\LFGet.exe' -ArgumentList 'install-local-package', '--package ".\OfficePluginSetup 11.1.2510.875.exe"', '--iacceptlicenseagreement', '--iagreetoprereqs', '--log "C:\Logs\LF_OfficePlugins_Installer"' -Wait

Write-Host "Installing OCR"
Start-Process -FilePath '.\LFGet\LFGet.exe' -ArgumentList 'install-local-package', '--package ".\OCR 12.0.2509.116.exe"', '--iacceptlicenseagreement', '--iagreetoprereqs', '--log "C:\Logs\LF_OCR_Installer"' -Wait

1 0
replied one day ago Show version history

Eric, see my reply above. Add "-WindowStyle Hidden" to your Start-Process commands.

I'd also recommend cleaning that up by making an array of product/package strings and running a foreach loop on them as I did. You don't need to pass separate product-specific log directories to each as LFGet automatically create a subfolder for each product's logs. Just pass "--log "C:\Logs\LFGet" and it'll automatically create folders like these as it goes:

"C:\Logs\LFGet\2025-10-28 060742 Laserfiche Webtools Agent 11.0.2509.11"

0 0
replied one day ago Show version history

Here's a sample script pair:

# LFGet-InstallLocalPackages

$LFGetDirectory = 'C:\Your\Path\To\LFGet'
$PackageDirectory = 'C:\Your\Package\Path'
$LogDirectory = 'C:\Your\Log\Path'

# Refer to available product values at:  https://doc.laserfiche.com/laserfiche.documentation/12/userguide/en-us/content/install-installer.htm
$Products = @(
    @{Name='WindowsClient'; Package='WindowsClient 12.0.2510.972.exe'},
    @{Name='WebToolsAgent'; Package='WebToolsAgent 11.0.2509.11.exe'},
	@{Name='Snapshot'; Package='Snapshot 12.0.2509.942.exe'},
	@{Name='ScanningSetup'; Package='ScanningSetup 12.0.2507.188.exe'},
	@{Name='OfficePluginSetup'; Package='OfficePluginSetup 11.1.2510.875.exe'},
	@{Name='OCR'; Package='OCR 12.0.2509.116.exe'}
)

Set-Location $LFGetDirectory

foreach ($Product in $Products) {
	
	$PackagePath = Join-Path $PackageDirectory -ChildPath $Product.Package
	.\LFGet.exe install-local-package --package "$PackagePath" --iacceptlicenseagreement --iagreetoprereqs --log $LogDirectory
}

You then use SCCM (or other deployment tool) invoke that script in a hidden window with:

$scriptPath = 'C:\Your\Path\To\LFGet-InstallLocalPackages.ps1

Start-Process PowerShell.exe -ArgumentList "-ExecutionPolicy Bypass -WindowStyle Hidden -File `"$scriptPath`""

All the LFGet invocations in the invoked script then run within the hidden PowerShell session.

0 0
replied one day ago Show version history

Here's an enhanced version of the first script that dynamically auto-detects the latest version of each local .exe in the package directory for each product in the $ProductNames list. This way you don't have to update the script itself with new paths/file names each time there's an update - just ensure the latest package is in the folder.

# LFGet-InstallLocalPackages

$LFGetDirectory = 'C:\Your\Path\To\LFGet'
$PackageDirectory = 'C:\Your\Package\Path'
$LogDirectory = 'C:\Your\Log\Path'

# Refer to available product values at:  https://doc.laserfiche.com/laserfiche.documentation/12/userguide/en-us/content/install-installer.htm
$ProductNames = @(
    'WebToolsAgent'
    'WindowsClient'
    'Snapshot'
    'ScanningSetup'
    'OfficePluginSetup'
    'OCR'
)

function Get-LatestExeVersions {
    [CmdletBinding()]
    param(
        [Parameter(Mandatory)]
        [string]$BaseDirectory,

        [Parameter(Mandatory)]
        [string[]]$Prefixes
    )

    # Build regex for prefixes (starts-with match)
    $pattern = '^(' + (($Prefixes | ForEach-Object { [regex]::Escape($_) }) -join '|') + ')\b'

    # Collect all matching exe files and parse versions
    $all = Get-ChildItem -Path $BaseDirectory -File -Filter *.exe |
           Where-Object { $_.BaseName -match $pattern } |
           ForEach-Object {
               $token = [regex]::Match($_.BaseName, $pattern).Groups[1].Value
               $m = [regex]::Matches($_.BaseName, '\d{1,3}(?:\.\d{1,4}){3}') | Select-Object -Last 1
               if ($m) {
                   [pscustomobject]@{
                       Prefix  = $token
                       Version = [version]$m.Value
                       File    = $_
                   }
               }
           }

    # Group by prefix and select latest version
    $rows = $all |
        Group-Object Prefix |
        ForEach-Object {
            $latest = $_.Group | Sort-Object Version -Descending | Select-Object -First 1
            [pscustomobject]@{
                Name             = $_.Name
                LatestExeVersion = $latest.Version.ToString()
                PackageName      = $latest.File.Name
                PackagePath      = $latest.File.FullName
            }
        }

    return $rows
}

$Products = Get-LatestExeVersions -BaseDirectory $PackageDirectory -Prefixes $ProductNames


Set-Location $LFGetDirectory

foreach ($Product in $Products) {
    Write-Host "$($Product.Name)"
    .\LFGet.exe install-local-package --package "$($Product.PackagePath)" --iacceptlicenseagreement --iagreetoprereqs --log $LogDirectory
    Write-Host "`n`n"
}
# End script

For a "silent" install, you'd still run this with:

$scriptPath = 'C:\Your\Path\To\LFGet-InstallLocalPackages.ps1

Start-Process PowerShell.exe -ArgumentList "-ExecutionPolicy Bypass -WindowStyle Hidden -File `"$scriptPath`""

-Sam

2 0
replied one day ago

Samuel,

 

Thank you for everything you've done not only to help Eric, but the community, and myself as well. This is a lot easier and cleaner than the way I was trying to install it remotely.

 

I can create a new post if easier, but I am having issues with this script deployment myself and can't figure out specifics. Perhaps it'd make sense to you, but it appears to be failing on the extraction portion of the process. Since the install is taking place as the Local System account instead of a user account I think it's extracting or trying to extract the files to system32? 

 

I've attached the extract log for you. If you have a chance to look at it and help me out I'd appreciate it. I've also pasted the error output from the cmd prompt that PDQ Connect captured below.

 

Download started

Downloading...................

Download succeeded

Extraction failed Encountered an error while unzipping. View the installation log for details and try installing the application again. [INST-1016]

 

Lionel

 

 

extract.txt (686 B)
1 0
replied 4 hours ago

You've run into the issue reported here: Unattended Installation (LFGet.exe) - Permissions issue - Laserfiche Answers

Which we've reproduced and filed as Severity 1/Priority 1 bug #622075 for LFGet.exe (12.0.2510.1223) not working when running as the NT AUTHORITY\SYSTEM account.

The root cause is the SYSTEM account's profile folder "C:\Windows\System32\config\systemprofile\*" being specially protected in various ways that prevent the self-extracting executables from running. We'll add an option to specify a custom temp folder for package extraction to address the issue.

I'll post an update in this thread once the fix is released as well.

In the meantime, if your deployment tools have an option to run as an Administrator use other than SYSTEM, that'll work. If not (like for Intune) you'll have to wait for the fix, which we'll get out as soon as we can. You can continue to build and tests scripts as a non-SYSTEM administrator in preparation as well.

0 0
replied 2 hours ago

Thank you Samuel for the update. I am confused how it worked a few times, but when you are building a deployment you test, test, test and it has been a non-stop issue which has halted our deployment.

 

That being said I hope they can resolve it as we do not have another option to run as another account besides the user which does not have installation privileges.

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

Sign in to reply to this post.