Allowing Silent Elevation for .msi Automated Installer Processes

Example policy for .msi automated installer processes

Background

Many enterprise applications use an automated management or update tool that — rather than running the .msi file directly — launches a separate elevated helper .exe to complete the installation or update. When Keeper Privilege Manager (EPM) has applied Least Privilege to the machine, these elevation requests are blocked, causing the update to fail.

This pattern is common across a range of widely-deployed enterprise software. Autodesk, for example, uses an application called Autodesk Access that launches an elevated helper process called ProcessManager.exe, which in turn spawns additional elevated processes to complete the installation. The .msi itself is not what KPM needs to target — the helper .exe is.

The table below lists several common enterprise applications that follow this same pattern, along with the elevated helper process each one uses. Your own environment may differ — always verify the specific process name using a tool such as Process Monitor or Windows Task Manager before configuring your policy.

Application	MSI Installer	Elevated Helper .exe	Typical Path
Autodesk (via Autodesk Access)	Autodesk ODIS MSI	ProcessManager.exe	C:\Program Files\Autodesk\AdODIS\V1\Setup\ProcessManager.exe
Adobe Acrobat / Reader	AcroPro.msi / AdbeRdr*.msi	AdobeARM.exe	C:\Program Files\Common Files\Adobe\ARM\1.0\AdobeARM.exe
Citrix Workspace App	CitrixWorkspaceApp.msi	TrolleyExpress.exe ¹	C:\ProgramData\Citrix\Citrix Workspace <version>\TrolleyExpress.exe
Google Chrome Enterprise	googlechromestandaloneenterprise64.msi	GoogleUpdate.exe	C:\Program Files (x86)\Google\Update\GoogleUpdate.exe
Zoom Workplace	ZoomInstallerFull.msi	ZoomInstaller.exe	%LocalAppData%\Zoom\ZoomInstaller.exe

Note: The elevated helper .exe is specific to each vendor's tooling and may change across product versions. The configuration steps below are the same regardless of which application you are targeting — only the Application Collection contents will differ.

Solution: Create a Privilege Elevation Policy

You need a Privilege Elevation policy that silently allows the vendor's elevated helper process to run — without any user interaction. The steps below use Autodesk's ProcessManager.exe as the worked example; substitute your own application's helper .exe where indicated.

Step-by-Step Configuration

1

Create an Application Collection for the Elevated Helper .exe (e.g., ProcessManager.exe for Autodesk)

Different MSI-based applications use different helper processes for elevated installs and updates. Before creating this collection, confirm the exact .exe name and path for your application — refer to the table above, your vendor's documentation, or observe the process in Process Monitor during an update.

In the Keeper Admin Console:

• Create a new Application Collection and give it a descriptive name that identifies both the application and the helper process (e.g., "Autodesk – ProcessManager" or "Adobe Acrobat – AdobeARM").

• Add a single application entry targeting the helper .exe. You can match by file name or full path. Using a full path is recommended for narrower, more secure targeting.

Autodesk example:

C:\Program Files\Autodesk\AdODIS\V1\Setup\ProcessManager.exe

Generic pattern (replace with your vendor's values):

C:\Program Files\<Vendor>\<UpdateTool>\<HelperProcess>.exe

Keep this collection as narrow as possible — only include the specific helper .exe, not all executables for the application.

2

Create a Privilege Elevation Policy

In the Keeper Admin Console, create a new policy with the following settings:

Setting	Value
Policy Type	Privilege Elevation
Name	e.g., "Autodesk Access – Allow ProcessManager Elevation" (adjust to match your application)
Status	Start with Monitor to validate, then switch to Enforce
Control	Allow
Application Collection	Select the collection created in Step 1
User Collection	Select the appropriate users or use "All Users"
Machine Collection	Select the machines where the application is deployed

3

Deploy and Verify

• Set the policy to Monitor first to confirm it matches the correct elevation events in your logs.

• Once verified, switch the status to Enforce.

• Trigger an update or install for the application to confirm it completes successfully without user interaction.

For Autodesk, this means triggering an update through Autodesk Access on an affected endpoint and confirming the update completes without a UAC prompt or EPM block.

Important: Why You Must Use the "Allow" Control

The Allow control is required because automated installer and update processes are non-interactive. When the helper .exe requests elevation, EPM must grant it immediately and silently.

The Allow control applies only to this specific application collection. All other elevation requests on the machine continue to be governed by your existing Least Privilege and Privilege Elevation policies.

Do not use Justification, Approval, or MFA controls for this policy. These controls present a prompt to the user and wait for a response. An automated installer does not wait for this interaction — it will time out and fail even if the user eventually responds. The process expects elevation to be granted instantly.

Autodesk's ProcessManager.exe is a clear example of this behavior: if a prompt appears during an Autodesk Access update, the update process will time out before any response can be given. The same is true of the other applications listed in the table above.

Control	Result
Allow	Elevation is granted silently — install or update succeeds
Justification	User is prompted; automated process times out — install fails
Approval	Request is sent to approver; automated process times out — install fails
MFA	User is prompted for MFA; automated process times out — install fails

Security Considerations

• Scope the Policy Narrowly: Only include the specific helper .exe in the Application Collection — do not broadly allow all executables for the application or all files in a directory.

• Use Full Paths: Matching by file name alone (e.g., ProcessManager.exe) is more permissive than matching by full path. Where your vendor's install path is predictable and stable, prefer the full path.

• Machine Targeting: If the application is only deployed to a subset of machines, restrict the policy to those machines using a Machine Collection. Avoid applying the policy fleet-wide if the application is not universally deployed.

• Verify the Helper .exe Before Deploying: Vendor tooling changes across product versions. Confirm the correct process name and path using Process Monitor or Task Manager during an actual update before building your collection.