Deploying the RAIC Extension via Microsoft Intune

The extension is published to the Chrome Web Store, so you don't need to host a CRX or allowlist an external domain. Point your MDM at the CWS extension ID and Google handles download, install, and silent updates.

• CWS listing: Rhindon Cyber — Shadow AI Discovery
• Extension ID (stable across versions): falfhokdohediejneohjlglhabjnbaon
• Update URL: https://clients2.google.com/service/update2/crx
• Force-install value (paste verbatim into ExtensionInstallForcelist): falfhokdohediejneohjlglhabjnbaon;https://clients2.google.com/service/update2/crx

Because installs come from the Web Store, you do not need to set ExtensionInstallSources or allow extensions.rhindoncyber.com. Skip those steps when using the CWS path.

For fleets that cannot reach clients2.google.com, we also host a signed CRX3 package and auto-update manifest. This path uses a different extension ID because the CRX is signed with the RAIC self-hosted key.

• Hosted CRX: https://extensions.rhindoncyber.com/raic-extension.crx
• Update manifest: https://extensions.rhindoncyber.com/update.xml
• Self-hosted extension ID: dmcnaplcadipjpacldccjlfdgdpocpld
• Force-install value: dmcnaplcadipjpacldccjlfdgdpocpld;https://extensions.rhindoncyber.com/update.xml

The signing key (raic-extension-key.pem) is held only by Rhindon Cyber and never shared with clients. This guarantees that only Rhindon Cyber can publish updates that your fleet will accept.

In Intune admin center → Devices → Configuration → Import ADMX, ingest the Google Chrome ADMX bundle (chrome.admx + google.admx) from chromeenterprise.google. Microsoft Edge already exposes the equivalent settings natively under Microsoft Edge\Extensions.

Skip this step if you only need to manage Edge.

Create a new Settings catalog profile in Intune (Devices → Configuration → Create → Windows 10 and later → Settings catalog) and add the following two settings under Google Chrome → Extensions (and/or the matching Microsoft Edge → Extensions path):

Assign the profile to the device or user group that should receive the extension. No further end-user action is required — the extension appears on next browser launch.

For zero-touch pairing on devices where users do not log in to app.rhindoncyber.com, push your organization key via Chrome's 3rd party extension settings (chrome.storage.managed):

{
  "org_key": {
    "Value": "raic_org_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
  }
}

Generate the key in Admin → Integrations → Browser Extension → Org Keys. It can be rotated or revoked at any time and takes effect on the next policy refresh — no browser restart required.

Chrome Web Store path (recommended): Google serves silent updates from https://clients2.google.com/service/update2/crx within a few hours of each release. Extension ID falfhokdohediejneohjlglhabjnbaon is permanent for the CWS listing.

Self-hosted CRX path: every new RAIC release is re-signed with the same key so the self-hosted ID dmcnaplcadipjpacldccjlfdgdpocpld also never changes. Chrome / Edge poll https://extensions.rhindoncyber.com/update.xml every ~5 hours.

Migrating from self-hosted to CWS is a one-line change: swap the force-install value from dmcnaplcadipjpacldccjlfdgdpocpld;https://extensions.rhindoncyber.com/update.xml to falfhokdohediejneohjlglhabjnbaon;https://clients2.google.com/service/update2/crx and remove the ExtensionInstallSources allowlist entry. Users get the CWS build on next browser launch; the old self-hosted build is silently uninstalled.

Intune normally checks in every ~8 hours. To pull policy immediately on a managed Windows device, use any of the following — all are equivalent:

• Settings UI: Settings → Accounts → Access work or school → click the work account → Info → under "Device sync status" click Sync.
• Company Portal app: open Company Portal → Settings → Sync.
• PowerShell (fastest):

  Get-ScheduledTask -TaskName "PushLaunch" |
    Where-Object { $_.TaskPath -like "*Microsoft*Windows*EnterpriseMgmt*" } |
    Start-ScheduledTask

• deviceenroller.exe:

  C:\Windows\system32\deviceenroller.exe /o <enrollment-id> /c /b

  (Enrollment ID is the GUID under HKLM\SOFTWARE\Microsoft\Enrollments with a non-empty UPN.)
• Intune admin center: Devices → All devices → select device → Sync. Triggers a remote check-in within ~1 minute.

After sync + browser reload, edge://policy (or chrome://policy) should show ExtensionInstallForcelist with status OK and the value falfhokdohediejneohjlglhabjnbaon;https://clients2.google.com/service/update2/crx. The value never changes — that exact string (extension ID + update URL) is correct for every tenant.

If you see "Unknown policy", that means the browser doesn't recognize the policy name (the OMA-URI path or Settings Catalog setting you picked is wrong) — it has nothing to do with the value being wrong. Common causes:

• Wrong OMA-URI path — must end in .../Policy/Config/Edge~Policy~microsoft_edge~Extensions/ExtensionInstallForcelist for Edge, or the matching Chrome~Policy~googlechrome~Extensions/... path for Chrome.
• You set User scope but assigned to a Device group (or vice versa) — see Section 3.3 above.
• Chrome only — you skipped ingesting the Chrome ADMX templates (Step 1).

Re-syncing won't fix any of these — the policy name itself has to be corrected in Intune.

Three reporting states show up repeatedly when force-installing the RAIC extension. They look like different problems but almost always point to the same root cause: two profiles supplying a Mandatory value for the same setting.

• Unknown policy — the browser doesn't recognize the policy name. Wrong OMA-URI path, wrong scope (User vs Device), or (Chrome only) the ADMX templates were never ingested. Re-syncing won't help; fix the policy definition in Intune.
• Conflict + error code 0 — "Error 0" is not a real Windows error. It means the CSP didn't return a Win32 failure code; Intune just couldn't pick a winner because two sources are pushing the same Mandatory setting. Look for duplicates, not for a Windows bug.
• Temporarily not available (2007) — Intune's per-setting view of the same conflict. It means "I received the setting but another policy is fighting it." It will sit at 2007 indefinitely. Re-syncing, restarting Edge, or reinstalling the extension will not clear it. Only removing one of the two assignments will.

Most common duplicate combinations

• Settings Catalog (Microsoft Edge → Extensions → Control which extensions are installed silently) and a Custom OMA-URI profile pushing the same string to the same path.
• Two Configuration Profiles assigned to overlapping groups (a user is in both groups).
• One Device-scope profile and one User-scope profile both targeting the same session host.

Recommended fix

Keep the Settings Catalog profile, unassign the Custom OMA-URI profile (or vice versa — pick one source of truth), then on the device run Sync from Settings → Accounts → Access work or school and reopen Edge. Status should flip to Succeeded within 5–10 minutes.

When the profile is assigned to users (not device groups) — the standard pattern for AVD / Windows 365 multi-session — the per-device "Device configuration" report won't tell the whole story. Check from the user angle in this order:

1. Intune → Users → [the AVD user] → Device configuration. Shows every profile assigned to that user (directly or via group), with status per session host they've signed into. Fastest way to see if the same setting is coming from two profiles.
2. Intune → Reports → Device configuration → Per-setting status. Filter the setting name to ExtensionInstallForcelist. Any row showing Conflict, Error, or Temporarily not available (2007) means two sources. Click the row → it lists every profile + every user/device contributing that value.
3. Intune → Devices → [the AVD session host] → Device configuration. Even though you assigned to users, the policy lands on the session host the user signed into. Open the host → Device configuration tab → find the profile with Conflict status → "View report" → shows which user's assignment caused it.
4. On the AVD session host (ground truth):
   • Open Edge → edge://policy → find ExtensionInstallForcelist. If the status shows Conflict or the value is missing, the CSP rejected it.
   • Event Viewer → Applications and Services Logs → Microsoft → Windows → DeviceManagement-Enterprise-Diagnostics-Provider → Admin → filter Event ID 404 (policy conflict) or 1098 (CSP error). The event body names both conflicting policy URIs.
   • Registry: HKLM\SOFTWARE\Microsoft\PolicyManager\AdmxInstalled\<enrollmentID>\Microsoft.Policies.Edge — two entries for the same setting under different enrollment IDs = the duplicate.

Why user-assignment in AVD is especially prone to this

When User A and User B sign into the same session host, Intune applies both of their user-targeted profiles to that host's user-scope CSP. If both profiles touch ExtensionInstallForcelist, the host sees two Mandatory sources for the same setting and reports Conflict — even though neither user is in two groups. The fix is the same: one master profile assigned to one inclusive user group (e.g. AVD-Users-All), or use assignment filters (e.g. device.deviceCategory equals AVD) on a single profile rather than spinning up parallel profiles per group.

Both Microsoft Edge and Google Chrome expose ExtensionInstallForcelist (a.k.a. "Control which extensions are installed silently") under two separate scopes:

• Device (Computer): registry hive HKLM\Software\Policies\Microsoft\Edge — OMA-URI prefix ./Device/Vendor/MSFT/Policy/Config/.... Applies to every user who signs into the device.
• User: registry hive HKCU\Software\Policies\Microsoft\Edge — OMA-URI prefix ./User/Vendor/MSFT/Policy/Config/.... Follows the user across devices but only takes effect when that user is signed in.

Do not set both for the same extension ID. If you do, the browser picks one and Intune marks the other "Not applicable" to avoid the conflict.

Recommendation for RAIC: use Device scope on standard corporate Windows endpoints — it covers every user (including local accounts and guests) and survives user re-imaging.

Azure Virtual Desktop (AVD) and multi-session hosts

On AVD, Windows 365 Cloud PC, and other multi-session / non-persistent VDI scenarios, use User scope:

• AVD session hosts running Windows 11 Enterprise multi-session are typically device-enrolled to Intune as a single shared device (or not Intune-enrolled at all and managed via FSLogix + GPO). Device-scope policy on a shared host applies the same forcelist to every concurrent user, but per-user Edge / Chrome profiles live in FSLogix containers, so user-scope is what reliably "follows the profile."
• Assign the configuration profile to a user group (the users who will sign into AVD), not a device group. Use OMA-URI prefix ./User/Vendor/MSFT/Policy/Config/....
• If the AVD host is not Intune-enrolled (common — most AVD fleets are managed by Group Policy, not Intune), deliver the same value via GPO under User Configuration → Policies → Administrative Templates → Microsoft Edge → Extensions → Control which extensions are installed silently. The forcelist value (falfhokdohediejneohjlglhabjnbaon;https://clients2.google.com/service/update2/crx) is identical.
• For persistent / single-session Cloud PCs (Windows 365 Enterprise) that are individually Intune-enrolled, Device scope works fine and is simpler.

The Chrome Web Store force-install value falfhokdohediejneohjlglhabjnbaon;https://clients2.google.com/service/update2/crx is the same across every MDM. Only the container changes.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>ExtensionInstallForcelist</key>
    <array>
      <string>falfhokdohediejneohjlglhabjnbaon;https://clients2.google.com/service/update2/crx</string>
    </array>
  </dict>
</plist>

Need help with a different MDM (Kandji, Mosyle, Workspace ONE, Ivanti)? Contact [email protected].