The managed-machine rule is Chromium's, not Edge's

Chrome blanks an off-store ExtensionInstallForcelist entry on an unmanaged
machine exactly as Edge does - the qualifying states are AD domain join, Entra
join, or Chrome Enterprise Core enrolment, and this box is none of them. The
guard now covers every browser and refuses up front, with the three ways
forward, instead of skipping Edge alone and letting Chrome fail the same way.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Brandon Li
2026-08-31 13:30:04 -05:00
co-authored by Claude Opus 5
parent e42e729189
commit ce6fa6c0e1
3 changed files with 71 additions and 33 deletions
+31 -12
View File
@@ -96,19 +96,38 @@ sudo scripts/install-extension-policy.sh
Both configure every Chromium-family browser they find, and narrowing that to
one is `-Browser Chrome`.
**Edge is the exception, and it is not one we can fix.** Unmanaged Edge installs
extensions from the Microsoft Store and nowhere else. It reads the policy and
then blanks it — `edge://policy` shows `[BLOCKED]<id>;<url>` with "This device
isn't managed by your organization" — so a self-hosted CRX cannot be installed
there at all unless the machine is domain-joined, Intune-enrolled or
Entra-joined. Chrome and Brave have no equivalent restriction. The script
detects this and skips Edge rather than leaving a permanent policy error and a
"Managed by your organization" badge behind; `-Force` overrides it.
### The machine has to be managed
On a machine that has to be Edge, load `extension/` unpacked there instead. It
still picks up releases: an unpacked copy reloads itself from disk when the
dashboard reports a newer version, which is what the updater has already
pulled.
This is the constraint the whole approach turns on, and it is worth stating
plainly. On Windows, Chromium force-installs an extension from outside its own
web store **only** when the instance is joined to an Active Directory domain,
joined to Entra ID, or enrolled in Chrome Enterprise Core. Edge says the same of
the Microsoft Store. On an ordinary machine the policy is read and then blanked:
```
Value ["[BLOCKED]lkjbblagjjbldlkeaaffhiopdlhniaan;https://ext.juicerroom.com/updates.xml"]
Error Error at ExtensionInstallForcelist[0]: Invalid extension ID.
Warning This computer is not detected as enterprise managed so policy can only
automatically install extensions hosted on the Chrome Webstore.
```
The "invalid extension ID" is just `[BLOCKED]` being parsed as the id. Nothing
about the CRX, the update manifest or the hive is wrong — the machine is what
Chrome is refusing. Both scripts check for this and write nothing rather than
leaving a permanent policy error and a "Managed by your organization" badge
behind; `-Force` overrides.
So the update server is only half a solution on an unmanaged box. The other half
is one of:
- **Load `extension/` unpacked.** No update channel, but it reloads itself from
disk when the dashboard reports a newer version, and the updater has already
pulled those files. Works today, any browser, nothing to enrol.
- **Enrol Chrome in Chrome Enterprise Core** (free, and it does not require a
domain-joined machine): one `CloudManagementEnrollmentToken` registry value
makes the browser managed, and everything here then works as designed.
- **Publish to a web store.** Store-hosted extensions update themselves with no
policy at all — at the price of a listing and a review on every release.
The Windows script writes to the current user's policy hive and needs no
elevation; `-Scope Machine` covers every account on the box and does need an