# Allowing Silent Elevation 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.

<table><thead><tr><th width="158.33331298828125">Application</th><th>MSI Installer</th><th>Elevated Helper .exe</th><th>Typical Path</th></tr></thead><tbody><tr><td><strong>Autodesk</strong> (via Autodesk Access)</td><td>Autodesk ODIS MSI</td><td><code>ProcessManager.exe</code></td><td><code>C:\Program Files\Autodesk\AdODIS\V1\Setup\ProcessManager.exe</code></td></tr><tr><td><strong>Adobe Acrobat / Reader</strong></td><td><code>AcroPro.msi</code> / <code>AdbeRdr*.msi</code></td><td><code>AdobeARM.exe</code></td><td><code>C:\Program Files\Common Files\Adobe\ARM\1.0\AdobeARM.exe</code></td></tr><tr><td><strong>Citrix Workspace App</strong></td><td><code>CitrixWorkspaceApp.msi</code></td><td><code>TrolleyExpress.exe</code> ¹</td><td><code>C:\ProgramData\Citrix\Citrix Workspace &#x3C;version>\TrolleyExpress.exe</code></td></tr><tr><td><strong>Google Chrome Enterprise</strong></td><td><code>googlechromestandaloneenterprise64.msi</code></td><td><code>GoogleUpdate.exe</code></td><td><code>C:\Program Files (x86)\Google\Update\GoogleUpdate.exe</code></td></tr><tr><td><strong>Zoom Workplace</strong></td><td><code>ZoomInstallerFull.msi</code></td><td><code>ZoomInstaller.exe</code></td><td><code>%LocalAppData%\Zoom\ZoomInstaller.exe</code></td></tr></tbody></table>

{% hint style="info" %}
**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.
{% endhint %}

## 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

{% stepper %}
{% step %}
**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.
{% endstep %}

{% step %}
**Create a Privilege Elevation Policy**

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

<table><thead><tr><th width="197">Setting</th><th>Value</th></tr></thead><tbody><tr><td><strong>Policy Type</strong></td><td>Privilege Elevation</td></tr><tr><td><strong>Name</strong></td><td>e.g., "Autodesk Access – Allow ProcessManager Elevation" (adjust to match your application)</td></tr><tr><td><strong>Status</strong></td><td>Start with <strong>Monitor</strong> to validate, then switch to <strong>Enforce</strong></td></tr><tr><td><strong>Control</strong></td><td><strong>Allow</strong></td></tr><tr><td><strong>Application Collection</strong></td><td>Select the collection created in Step 1</td></tr><tr><td><strong>User Collection</strong></td><td>Select the appropriate users or use "All Users"</td></tr><tr><td><strong>Machine Collection</strong></td><td>Select the machines where the application is deployed</td></tr></tbody></table>
{% endstep %}

{% step %}
**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.
{% endstep %}
{% endstepper %}

## 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.

<table><thead><tr><th width="120.6666259765625">Control</th><th>Result</th></tr></thead><tbody><tr><td><strong>Allow</strong></td><td>Elevation is granted silently — install or update succeeds</td></tr><tr><td>Justification</td><td>User is prompted; automated process times out — <strong>install fails</strong></td></tr><tr><td>Approval</td><td>Request is sent to approver; automated process times out — <strong>install fails</strong></td></tr><tr><td>MFA</td><td>User is prompted for MFA; automated process times out — <strong>install fails</strong></td></tr></tbody></table>

## 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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.keeper.io/keeperpam/endpoint-privilege-manager/policies/policy-examples/allowing-silent-elevation-for-.msi-automated-installer-processes.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
