Deploy the Velatir browser extension on Windows without the MSI: PowerShell, manual registry, and Intune Settings Catalog
Most Windows fleets should use the MSI. Use the methods on this page when you do not deploy via the MSI, for example when you push policy through Group Policy Preferences, a policies.json file, or the Intune Settings Catalog. Unlike the MSI (which configures Chrome, Edge, and Firefox), the PowerShell script and manual registry tables here also cover Vivaldi and Brave.
Browser policy can live in the per-user hive (HKCU\Software\Policies\…) instead of HKLM. That subtree is privileged — a non-elevated process cannot write it — so per-user rollout uses a mechanism that runs with the necessary rights: Group Policy, Intune, or the per-user MSI run elevated.The keys are identical to the manual registry tables below; only the hive changes (HKCU instead of HKLM).
Use a user-scoped GPO. Group Policy Preferences Registry items can write the full key set — force-install plus the apiToken / organizationName managed config — to HKCU\Software\Policies\…. The Group Policy engine applies them in each user’s context with the rights those keys require, so this single mechanism covers both force-install and managed configuration.
Assign the policies to user groups (not device groups):
Force-install — covered by the Settings Catalog: Chrome “Configure the list of force-installed apps and extensions” and Edge “Control which extensions are installed silently”. Use the Velatir extension IDs from the Settings Catalog section.
Managed config (apiToken / organizationName) — this per-extension managed storage is not a Settings Catalog setting. Deliver it via Group Policy Preferences (above) alongside Intune force-install, or via a custom OMA-URI / ingested ADMX if you are Intune-only.
The per-user MSI (VelatirExtension-PerUser-<arch>.msi, x64 · arm64) writes the force-install and managed-config keys straight to HKCU\Software\Policies in one step, with no Group Policy or ADMX work. Because that subtree is privileged, it must run elevated in the target user’s session (a non-elevated run fails). Deliver it where that holds — the user runs it as a local admin, or your tooling launches it elevated in the user’s context. It is registry-only and never carries the directory-context host.
For fleets that already push force-installed extensions via a per-user GPO (HKCU\Software\Policies\<Google\Chrome|Microsoft\Edge>\ExtensionInstallForcelist), the cleanest rollout is to add the Velatir extension IDs to that existing GPO rather than deploying the per-machine MSI for the forcelist. Chrome and Edge resolve same-policy values across hives by precedence — HKLM beats HKCU, with no cross-scope merge available — so a per-machine MSI deployed on top of a per-user GPO would hide every other extension the GPO was pushing.
Firefox does not use the ExtensionInstallForcelist policy; it uses HKCU\Software\Policies\Mozilla\Firefox\Extensions\Install with the XPI URL as the value (no extension ID prefix). See the manual registry tables below for the full key shape.Use a high value name (e.g. 1000) for the new entry to avoid colliding with your other GPO-managed forcelist entries, which conventionally start at 1.
The forcelist installs the extension but does not configure it. Add the per-extension managed-config keys to the same GPO so each user gets apiToken, organizationName, and machineId populated automatically. The key paths and value names match the manual registry tables below — just swap HKLM for HKCU and deliver them from your GPO instead of the MSI. The machineId value can be anything stable per device; the MSI uses the Windows computer name (%COMPUTERNAME%).
If you want every trace enriched with the user’s AD / Entra organisational context (department, OU hierarchy, group memberships), the directory-context host still ships in the per-machine MSI and can be installed standalone, writing no browser-policy keys, via LDAP_ONLY=1. The browser-policy components are suppressed, so API_TOKEN and ORGANIZATION_NAME are not needed:
The MSI then touches only C:\Program Files\Velatir\ and the per-browser native-messaging-host registrations under HKLM\SOFTWARE\<browser>\NativeMessagingHosts\com.velatir.ldap_host. Your GPO continues to own every ...\Policies\... key. See Directory Context for what the host sends.
After updating the GPO, run gpupdate /force on a test box, then open chrome://policy and edge://policy and click Reload policies. The ExtensionInstallForcelist row should list every extension your GPO was already pushing plus the Velatir entry, all sourced from the same hive. Each extension should auto-install within a minute or two.
A single PowerShell script covers Chrome, Edge, Firefox, Vivaldi and Brave. It uses the Windows computer name ($env:COMPUTERNAME) as the machineId shared across all five browsers, matching the MSI’s behaviour so both deployment paths produce the same value.Edit $ApiToken and $OrganizationName at the top of the script, then run it as Administrator or SYSTEM in 64-bit PowerShell. Set $EnablePrivateBrowsing = $true to enable the extension in Edge InPrivate and Firefox private browsing.Configuration script (Configure-Velatir.ps1):
The script uses the Windows computer name ($env:COMPUTERNAME) as the machineId and writes it into each browser’s managed policy. The value is stable across reruns and consistent between Chrome, Edge, Firefox, Vivaldi and Brave, matching the MSI deployment behaviour.
To deploy to a subset of browsers, comment out the corresponding Chrome, Edge, Firefox, Vivaldi, or Brave section in both the configuration and uninstall scripts.
In Firefox, setting $EnablePrivateBrowsing = $true enables the extension in private browsing automatically. In Edge, the policy requires the extension to be allowed in InPrivate, but each user must still manually enable the extension for InPrivate mode in their browser settings. Chrome does not support an Incognito policy on Windows.
To reverse everything the configuration script writes, run the script below. It’s safe to run whether or not the configuration script has been applied, and it leaves any MDM-managed policies (at forcelist indexes other than 1000) untouched.Uninstall script (Remove-Velatir.ps1):
Removing the force-install policy does not uninstall the extension from existing browser profiles. Users will simply be able to disable or remove it themselves. To force removal, block the extension first (Chrome/Edge ExtensionInstallBlocklist, or Firefox ExtensionSettings with installation_mode: blocked) before running the uninstall script.
If you deployed via the MSI rather than this script, use msiexec /x VelatirExtension-x64.msi /qn (or VelatirExtension-arm64.msi for ARM64 fleets) — the MSI’s uninstall removes its own registry writes cleanly.
If you prefer a policies.json file over registry keys for Firefox, use the following script instead of (or alongside) the Firefox section above.Configuration script (Configure-VelatirFirefoxJson.ps1):
Firefox updates may remove the distribution folder. If using this method, schedule the script to run regularly (e.g., once per day) to ensure the file is recreated after updates.
Use this method if you only need to force-install the extension without pre-configured settings. Users will need to enter their API token manually after installation.
The Intune Settings Catalog does not support Firefox extension deployment. For Firefox, use the MSI or the PowerShell script above.
If you’re not using Intune or SCCM, you can apply the same policies directly to the Windows registry. Use regedit, Group Policy Preferences, or any other tool that writes registry values. The tables below list every key, value name, and data needed.All values are written under HKEY_LOCAL_MACHINE (HKLM) as REG_SZ (String). Run any tool you use in 64-bit context so writes don’t land under WOW6432Node.
Use the value name 1000 for the force-install entries. This avoids colliding with MDM-managed entries, which typically start at 1.
{"velatir@velatir.com":{"private_browsing":true}} (enables the extension in private browsing)
ExtensionSettings is a single JSON value. If you already use it for other extensions, merge the velatir@velatir.com entry into the existing JSON rather than overwriting it.
Vivaldi is Chromium-based and reads the standard ExtensionInstallForcelist and 3rdparty\extensions\<id>\policy keys under its own vendor namespace. It installs the Chrome Web Store build of the extension and therefore reuses Chrome’s extension ID.Required
Vivaldi has no Edge-style MandatoryExtensionsForInPrivateNavigation equivalent.
Brave’s install directory is Brave-Browser but the documented policy root drops the suffix and lives at SOFTWARE\Policies\BraveSoftware\Brave. It installs the Chrome Web Store build of the extension and therefore reuses Chrome’s extension ID.Required
Brave has no Edge-style InPrivate-mandatory policy.
To remove the configuration, delete the values you added. Removing the force-install entry doesn’t uninstall the extension from existing browser profiles. Users will simply be able to disable or remove it themselves.
Windows MSI (recommended)
The simpler, supported path for most Windows fleets
Verify the deployment
Confirm policies applied and the extension is installed