Hi everyone, I've written a pair of PowerShell scripts for LFGet that should cover most/all of your client software deployment scenarios. The first script, LFGet-BulkAction.ps1, handles running LFGet actions on a list of products, and the second, Invoke-LFGetBulkAction.ps1, launches the former silently.
LFGet itself operates at the smallest unit of work - a single operation for a single product. To run it for multiple products requires wrapping it in a script. Rather than customers and Solution Providers having to write their own different scripts for every client deployment scenario, you should be able to use these.
All inputs are parameterized, so you don't need to modify the scripts themselves to run them for different scenarios. They're well-commented with examples for each command and parameter. If you find they don't fully meet your needs/use case, you're welcome to extend/enhance them and encouraged to share you changes here with the community so we can all benefit.
Due to Answers file type upload restrictions, I renamed the scripts from "*.ps1" to "*-ps1.txt". Change them back to .ps1 before use.
LFGet-BulkAction.ps1
A scriptable wrapper around Laserfiche’s LFGet tool that runs one or more products through install-product, install-local-package, download-product, repair-product, or uninstall-product.
Key features:
- Centralizes the LFGet parameters.
- Writes a PowerShell output transcript plus LFGet’s own logs to a configurable directory (defaults to C:\Temp\LFGet\Logs\).
- Accepts single or comma separated list of products (case-sensitive).
- Automatic package discovery from source directory for install-local-package - no more manual entry of versioned package files.
Run it directly when you want interactive progress and log capture. Example:
.\LFGet-BulkAction.ps1 `
-LFGetCommand install-product `
-LFGetDirectory 'C:\Temp\LFGet\LFGet' `
-InstallationCode 'XXXXXXXXXX' `
-Products 'WebToolsAgent,WindowsClient'
Invoke-LFGetBulkAction.ps1
A companion launcher that starts LFGet-BulkAction.ps1 in an elevated, hidden Windows PowerShell session while forwarding any optional parameters. Use it when you need unattended or scheduled execution (such as through a deployment agent like Intune) and still want transcript logging (handled by the LFGet-BulkAction script itself). Example:
.\Invoke-LFGetBulkAction.ps1 `
-Script 'C:\Temp\LFGet\LFGet-BulkAction.ps1' `
-LFGetCommand install-local-package `
-LFGetDirectory 'C:\Temp\LFGet\LFGet' `
-PackageDirectory 'C:\Temp\LFGet\Packages' `
-Products 'WebToolsAgent,WindowsClient'
Together, these scripts let you queue LFGet operations reliably - either interactively (run the LFGet-BulkAction script directly) or silently (launch it through the Invoke-LFGetBulkAction script).
--------------
While I've done hours of local testing and made a reasonable effort to cover the various paths, there's no way I could validate every deployment scenario. If you encounter any issues using the scripts, especially with deployment tools like Intune or SCCM, bug/issue reports are welcome. Please check the detailed output logs first to verify if it's an actual script issue, not something like an invalid parameter input.
The scripts can handle making a copy of the \LFGet\ directory from an accessible source with the $CopyLFGetFromSource parameter. The default "LFGetDirectory" parameter value is "C:\Users\${env:USERNAME}\AppData\Local\Laserfiche\LFInstaller\Plugins\LFGet\" where the Laserfiche Installer puts LFGet.exe and its dependencies. While your own machines may have the Laserfiche Installer and thus LFGet at the default path, end user client machines typically won't. For "install-local-package", they can also handle copying packages for the specified products from an accessible source directory (network share, etc.) with the $CopyPackagesFromSource parameter.
They use native PowerShell with no dependencies other than LFGet. You can run them any way you'd run PowerShell scripts, including Group Policy and IT deployment management tools like Microsoft Intune, SCCM / Endpoint Configuration Manager, BigFix, PDQ Deploy, and others. (2025-11-13: See note at bottom about a bug in the initial release build that prevents running as the SYSTEM user - fix will be out soon).
If you encounter errors running the scripts because your systems have PowerShell Execution Policies that block unsigned scripts downloaded from the internet, you may need to run the Unblock-File command on them. Per Microsoft: "Internally, the Unblock-File cmdlet removes the Zone.Identifier alternate data stream, which has a value of 3 to indicate that it was downloaded from the internet."
Obligatory: Please review scripts you download from the internet before running them, even if they appear to come from a trustworthy source such as Laserfiche staff member like myself. It's not impossible for Answers to be hacked and some bad actor to replace my original scripts with malicious ones, etc. etc. I've uploaded the SHA256 file checksums for the scripts in "File-Checksums-20251113.txt" so you can validate their integrity yourself, but that's not a substitute for reviewing the scripts; an attacker could replace the checksums file too.
--------------
[2025-11-13] Please note that running LFGet as the SYSTEM user (as is common for deployment agents) requires LFGet 12.0.2511.1267 (an update should be out through normal distribution around Nov 24; a hotfix release is currently available through Support if you can't wait) or above. The initial release version 12.0.2510.1223 contains a bug where LFGet cannot extract the .exe self-extracting executable installation packages in the SYSTEM user profile folder, a special protected Windows directory that blocks running exe files. The hotfixed version and later default to extracting the packages in "C:\Temp\" instead.