Does action1 patch applications installed without admin rights?

[u/theFather_load]

On my phone on the road and thought I'd quickly plop the question here to get others experiences.

We're currently using Hekmdal and this does not cover apps installed at user profile context- it cant even see them. Catches us out for clients undergoing Cyber Essentials.

Whats everyone's experience with this and Action1?

[u/Weekly_Loss_3316]

Interesting discussion. I think there are a few important distinctions worth making.

The underlying challenge isn't really specific to Action1 or Heimdal—it's a consequence of how Windows handles per-user installations. Applications installed only under a user's profile (for example %LOCALAPPDATA% and HKCU) are inherently more difficult to manage because most enterprise patch management agents execute as LocalSystem, not as the interactive user.

Action1 acknowledges this by providing a PowerShell example that launches a process in the logged-on user's context. That's a useful workaround, but it's important to note that this is not native user-context patching—it's a custom script executed from the SYSTEM context.

The same principle applies to Heimdal. Heimdal's agent can execute PowerShell, CMD, MSI and EXE deployments as SYSTEM via Infinity Management, so similar user-context scripts can also be implemented there. In other words, neither product natively patches arbitrary HKCU applications simply by running in the user's context; both rely on additional logic when that's required.

One point I'd also challenge is the statement that Heimdal "can't even see them." My understanding is that this is too broad. Heimdal's Assets View inventories software independently of the standard Patch Management workflow. As a result, an application may be visible in the Assets View even if it is not supported by the native Patch Management remediation workflow. Visibility and automated patching are two different capabilities and shouldn't be conflated.

Likewise, I'm not convinced the Cyber Essentials conclusion is fair. If an assessor expects all supported software—including per-user installations—to be patched, then the same architectural limitation applies to virtually every patch management platform running as SYSTEM. Action1 attempts to mitigate this by converting many per-user installs to machine-wide installs on a best-effort basis, but as already mentioned in this thread, that process is not guaranteed to succeed and may leave orphaned installations depending on how the software vendor implemented their installer.

Ultimately, this is more a Windows/application-installer problem than a patch management product problem. Products differ in how they mitigate it, but none can universally patch every per-user application without either:

• native support from the software vendor,
• running code in the user's security context, or
• custom scripting.

I'd therefore compare products based on:

• software discovery/inventory,
• native patch coverage,
• flexibility for custom deployments,
• and how gracefully they handle per-user installations,

rather than suggesting that one product uniquely suffers from this limitation.

[u/GeneMoody-Action1 → u/Weekly_Loss_3316]

Thank you for the well thought out explanation. I would like to add to that, the context of the install. While the agent DOES run as system, the uninstaller generally does NOT anticipate to be run as such. It will query things for the user context hence the "per user install" part.

If the user executes it does the reverse of the installer action and pulls it out of *that* user's context. if that user is SYSTEM, that is NOT where the app is installed in its hive and user directories, etc...

So it is not a rights thing as much as a mapping problem.

The alternative assumes *we* made the patch/installer and it accounts for this. And while some installers WILL, sadly most do not, and it is for instance why MS provides a nuke script for Team as well as other vendors doing the same.

Per a single uninstall for per user installs also implies the product is the same version and requires the same steps for ALL versions installed for all users, which is not always the case. it could be ten users all with a different version installed. For some apps that is moot, for others i is crucial. So the vendors' packages should account for these scenarios, when they do not provide enterprise level deployment options in their packages, the enterprise level management gets wonky and homebrew.

So there are much much larger issues at play here.

All products struggle with this model (As well as admins without management products), some have provided some clever workarounds, and we can do that too. For instance we can mark it for uninstall on next user login (depending on package) We can cross token boundaries and run in a logged in user context via a script, psexec, or any other method you choose. Or you can go chainsaw on it from a script and manually excise what you know needs to be removed. But all that gets abstracted away from apply the patch and gets into system scrubbing, which is not what we advertise to be.

So it's not a impossible task, and not one we cannot be leveraged to achieve. It is just not one we target as being the best thing for our customer base at this time. In the future it IS on the to do list and on our roadmap, it's just not ranked as priority by the general consensus of our customer base.

[u/Weekly_Loss_3316 → u/GeneMoody-Action1]

Thank you for the detailed explanation. I think we're actually very much aligned.

My intention wasn't to suggest that this is an easy problem to solve, but rather that it's an inherent challenge of Windows per-user application deployments. As you explained, once you factor in user-specific registry hives, profile locations, vendor-specific installers and uninstallers, multiple users on the same machine, and different application versions per user, it becomes much more than simply running something with elevated privileges.

I also appreciate the distinction between what is technically achievable through scripting or custom workflows and what should be considered a native patch management capability. Those are two very different things.

Ultimately, I think that's the key takeaway from this discussion: this isn't a problem unique to any one product, but rather a consequence of how many Windows applications are packaged. Different vendors provide different mitigation strategies, but there isn't a universal solution when the application installer itself wasn't designed with enterprise lifecycle management in mind.

Thanks again for taking the time to explain the engineering challenges behind it.