Hi,
First of all, thank you for maintaining LSUClient , it’s a very useful module and widely adopted.
We’re currently using Get-LSUpdate -Model <model> in an automation context and wanted to ask whether it would be possible to support a catalog-only / no local system access mode.
Context
Even when -Model is explicitly specified, the module appears to perform several local system checks early in execution (hardware inventory, docking detection, storage, etc.). These involve WMI/COM/system providers and require elevated or local-machine permissions.
This makes it impossible to run Get-LSUpdate in sandboxed or cloud-native environments (for example, Azure Functions or other restricted automation runtimes), even when we are only interested in:
We tested combinations such as:
…but the local calls still occur before results are returned.
Feature request
Would it be feasible to add a switch or execution path such as:
-
-CatalogOnly
-
-NoLocalSystemChecks
or similar
…that skips all local hardware/system interrogation and relies purely on Lenovo’s update catalog when -Model is provided?
Why this could be valuable
-
Enables cloud-native automation and reporting scenarios
-
Makes LSUClient usable in restricted environments
-
Benefits organizations that want update awareness without running on endpoints
-
Backwards-compatible if implemented as an opt-in switch
If this isn’t feasible due to architectural constraints, that’s completely understandable — we’d mainly like to know whether this is technically possible or intentionally out of scope.
Thanks again for your work, and happy to provide additional details or testing if helpful.
Best regards,
Shahzad
Hi,
First of all, thank you for maintaining LSUClient , it’s a very useful module and widely adopted.
We’re currently using
Get-LSUpdate -Model <model>in an automation context and wanted to ask whether it would be possible to support a catalog-only / no local system access mode.Context
Even when
-Modelis explicitly specified, the module appears to perform several local system checks early in execution (hardware inventory, docking detection, storage, etc.). These involve WMI/COM/system providers and require elevated or local-machine permissions.This makes it impossible to run
Get-LSUpdatein sandboxed or cloud-native environments (for example, Azure Functions or other restricted automation runtimes), even when we are only interested in:querying updates for a specific model, and
reading metadata (not installing anything).
We tested combinations such as:
ModelNoTestInstalledfiltering results (e.g. Where-Object
{ $_.Installer.Unattended })…but the local calls still occur before results are returned.
Feature request
Would it be feasible to add a switch or execution path such as:
-CatalogOnly-NoLocalSystemChecksor similar
…that skips all local hardware/system interrogation and relies purely on Lenovo’s update catalog when
-Modelis provided?Why this could be valuable
Enables cloud-native automation and reporting scenarios
Makes LSUClient usable in restricted environments
Benefits organizations that want update awareness without running on endpoints
Backwards-compatible if implemented as an opt-in switch
If this isn’t feasible due to architectural constraints, that’s completely understandable — we’d mainly like to know whether this is technically possible or intentionally out of scope.
Thanks again for your work, and happy to provide additional details or testing if helpful.
Best regards,
Shahzad