How extension deployment works

For the technician who wants to know what the deployment script does to a computer before running it. Every deployment method does the same thing in a different console: one PowerShell script runs as SYSTEM on each Windows computer and writes browser policy to the registry. Chrome and Edge then install the Lemhi AI Usage extension from their own stores, silently. Nothing is downloaded or executed by the script itself.

The script comes from the client's Deployment tab in Engage. Copy script writes the client's key into it, so every copied script is a per-client script.

What the script writes

Under HKLM\SOFTWARE\Policies\Google\Chrome and HKLM\SOFTWARE\Policies\Microsoft\Edge:

1. ExtensionInstallForcelist: one new numbered value whose data is the browser's extension id. The script takes the next free number and never touches entries you already have. It never overwrites entry 1. If the id is already there, it adds nothing.

2. 3rdparty\extensions\<extension id>\policy: three string values the extension reads as its managed configuration.

The extension sends nothing until all three are present.

A browser that isn't installed on the computer gets the extension once it is.

What the script checks and prints

1. Before writing anything, it checks the key's shape (lemhi_dk_ plus 43 characters, 52 in all). A wrong key prints clientKey is not a Lemhi deployment key (expected 52 characters starting lemhi_dk_); copy it again from the Deployment tab, writes nothing and exits 1.

2. After writing, it reads every value back. Per browser it prints the forcelist entry number, the first 12 characters of the key, the computer name, the ingest URL, and whether the browser is installed. Any value that reads back different exits 1, so your RMM shows the run as failed.

3. Three checks that never fail the run: whether the extension is installed yet (with version and profile count), whether the browser's store update host is reachable, and whether Lemhi's ingest host answers /healthz. These run as SYSTEM, whose proxy settings can differ from the users' browsers, so the Deployment tab is still the deciding result.

Why the forcelist and not ExtensionSettings

There is no separate "silent install" setting. The alternative to the forcelist is the ExtensionSettings policy with installation_mode: force_installed. It has the same effect, but it's a single JSON value shared with every other extension rule you have, so a script that writes it can wipe your existing configuration. Lemhi doesn't use it.

When it takes effect

Browsers read policy at start and on their periodic refresh, roughly every few hours. They don't re-read when the registry changes. A computer whose browser is already open picks up the extension on the next browser restart or policy refresh, and no reboot is needed. Once the browser installs the extension, it checks in, and the computer appears on the client's Deployment tab within a few minutes.

Re-running

The script is safe to re-run. It adds no duplicate forcelist entries and overwrites the three values in place. Schedule it daily or weekly in your RMM so a removed registry key heals itself.

Computers already managed by Chrome Enterprise Core or Intune

Those policies still merge, but if a cloud or Intune policy sets ExtensionInstallForcelist, the two sources can conflict. For Intune-managed clients, follow Deploy the extension with Microsoft Intune.

Related

• Deploy the extension with your RMM

• Deploy the extension with Microsoft Intune

• Check that a computer has the extension

• Rotate a client's deployment key