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:
co-authored by
Claude Opus 5
parent
e42e729189
commit
ce6fa6c0e1
+31
-12
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user