This page covers technical background and common questions for distributing Admina Extension on Windows.
It applies regardless of distribution method (manual, GPO, or Intune). For step-by-step guides, start from Browser extension deployment on Windows.
Technical notes
This section explains the background for each method’s steps. Use it when you want operational rationale or need to isolate causes during troubleshooting.
Why ExtensionSettings go in HKLM and 3rdparty/policy in HKCU
Registry writes go to HKLM (machine-wide) or HKCU (per signed-in user). These hives differ in nature, so policy types use different targets.
ExtensionSettings are machine-wide settings. The “force-install this extension” directive is the same regardless of who signs in, so writing once to HKLM suffices. Shared values across all devices simplify management.
3rdparty/policy holds parameters evaluated in user context. UserEmail in particular must differ per user. Writing to HKCU delivers the correct value for each signed-in user.
You can write both to HKLM technically, but UserEmail becomes a fixed machine-wide value (problematic on shared PCs). Writing both to HKCU makes delivery sensitive to process context at deploy time (Executing user vs HKCU write target). Splitting roles is the most manageable layout in practice.
Why writing ExtensionSettings to both HKLM and HKCU causes conflicts
ExtensionSettings are treated internally as a dictionary (dict) policy. When reading registry subkeys, the browser aggregates all extension-ID subkeys into one large JSON dictionary. It then evaluates that dictionary.
Chromium policy priority is “Platform/Machine (HKLM) > Platform/User (HKCU)”.
When ExtensionSettings exist in both HKLM and HKCU, the HKLM dictionary wins entirely.
The HKCU dictionary is not merged at all.
For example, if HKLM has extension A and HKCU has extension B separately, B is ignored.
chrome://policy or edge://policy may show conflict warnings (yellow or red markers) for ExtensionSettings. If so, this is the cause. Fix by consolidating to either HKLM or HKCU only.
3rdparty/policy is not subject to this dict aggregation. Values are independent.
HKLM and HKCU merge as long as value names do not collide.
See also When the same value name exists in both HKLM and HKCU for 3rdparty/policy.
When the same value name exists in both HKLM and HKCU for 3rdparty/policy
Unlike ExtensionSettings, 3rdparty/policy does not use a whole-dictionary-wins rule. When the same value name exists in both HKLM and HKCU, HKLM takes priority. This follows Chromium policy priority (Machine > User).
The recommended layout places 3rdparty/policy in HKCU only, so this conflict does not occur. In environments with leftover HKLM entries from past deployments, HKCU values can lose. Unintended values then reach the extension. Before deploying, confirm HKLM 3rdparty/policy subkeys are empty.
Executing user vs HKCU write target (Run as Administrator pitfall)
When writing to HKCU, the user context of the process that runs the script determines whose HKCU receives the write. Unless the target user runs the script themselves, their HKCU is not updated.
With Run as Administrator, a standard user may elevate with another account’s credentials.
Examples include the built-in Administrator account.
In that case, the process runs in Administrator’s context.
HKCU points to Administrator’s hive. The target user’s browser cannot read those values.
There is no simple way to work around this from the bat file alone.
Install the browser extension (Windows manual) assumes the target user signs in locally.
That account must already have administrator rights.
If the target user lacks administrator rights, use GPO or Intune distribution instead.
The bat script rejects PolicyRoot=HKLM as invalid. This prevents user-specific values from being written to the machine-wide hive.
Why 3rdparty/policy does not appear at edge://policy
Edge’s edge://policy shows browser policies and ExtensionSettings. However, it does not display custom policies under 3rdparty/extensions//policy. Values still reach the extension correctly; they are just not visible on that page.
As an alternative, verify delivery on Edge from the extension’s Service Worker console.
Use the chrome.storage.managed.get() API. See Edge: How to verify 3rdparty/policy.
Permissions for HKCU\Software\Policies
Under HKCU, users can normally read and write their own keys. Only the Software\Policies subtree is restricted to administrators by default ACL. Windows designed the policy area so users cannot change it freely.
Therefore, manual writes require administrator rights. Standard users get Access Denied when attempting to write directly to HKCU\Software\Policies.
64-bit registry view (/reg:64)
Chrome and Edge are 64-bit applications and read policies from the 64-bit registry view. A bat run from normal cmd.exe accesses the 64-bit view. When invoked from a 32-bit context, HKLM writes redirect to HKLM\SOFTWARE\WOW6432Node\Policies\.... Browsers cannot read that location.
The bundled scripts add the /reg:64 flag to all reg add and reg query calls. Reads and writes then target the 64-bit view regardless of calling context. During troubleshooting, check in regedit whether values landed under HKLM\SOFTWARE\WOW6432Node\Policies\....
Verify policies in the browser
Chrome: chrome://policy
Enter chrome://policy in the address bar and click Reload policies for the latest state.
The Extension policies section at the bottom lists ApiKey, UserEmail, and other values per extension. Each value shows its Source (Platform) and Scope (Machine / User). Use the Scope column to tell HKLM from HKCU origin.
Edge: How to verify 3rdparty/policy
Edge’s edge://policy shows ExtensionSettings but not 3rdparty/policy.
See Why 3rdparty/policy does not appear at edge://policy.
Use one of the following to confirm values are delivered.
Method 1: Direct registry check
Run check_extension_registry.bat or open the relevant keys under HKCU/HKLM in regedit and confirm values are present. Written values can still be ignored because of policy conflicts or same-name value precedence. See How conflicts work. To confirm reliably, use method 2 (chrome.storage.managed).
Method 2: Verify with chrome.storage.managed API
From the extension’s Service Worker console, confirm the values that actually arrived.
- Open
edge://extensions and turn on Developer mode
- Click Details on the target extension, then Inspect Service Worker
- In the DevTools Console tab, run:
Example output:
If values appear, the policy reached the extension. The same method works in Chrome.
Method 3: Verify with Diag data
Diag data shows parameters delivered to the extension. See Get Diag data for the browser extension.
Q&A
Q. Is a browser restart required after registry configuration?
No. Chrome and Edge periodically reload policy settings in the background, so changes apply automatically after some time. To apply immediately, open chrome://policy or edge://policy and click Reload policies.
Q. What happens if I re-run on a device that already has the extension?
Re-running the same script overwrites registry values only. No double installation occurs. To update ApiKey or UserEmail, re-run the same script to overwrite safely.
Q. What if ExtensionSettings shows a conflict warning?
If chrome://policy or edge://policy shows warnings on ExtensionSettings, both HKLM and HKCU have ExtensionSettings.
See Why writing ExtensionSettings to both HKLM and HKCU causes conflicts.
HKLM wins the whole dictionary and HKCU is ignored.
Consolidate to either HKLM or HKCU only. To match the recommended layout, delete ExtensionSettings subkeys on the HKCU side.
Q. What if asset management software such as SKYSEA, LANSCOPE, or SS1 already uses ExtensionSettings?
These products can force-install their own extensions and write settings under ExtensionSettings.
The Admina extension uses different IDs for Chrome and Edge, so they coexist at the subkey level.
Chrome uses bdeanmdeckegmfjpbnngomallcedjold. Edge uses flggmhlpipcopffjfkpgkoljghfkmfcg.
One important caveat: the browser reads ExtensionSettings from either HKLM or HKCU, not both.
See Why writing ExtensionSettings to both HKLM and HKCU causes conflicts.
If asset management software writes to HKLM, deploy Admina to HKLM as well. If it writes to HKCU, align Admina to HKCU.
The reader checks only one location, so mismatched targets cause one side to be ignored.
In regedit, check HKLM\Software\Policies\Google\Chrome\ExtensionSettings.
Also check HKCU\Software\Policies\Google\Chrome\ExtensionSettings to see where the other product writes.
The 3rdparty/extensions side is independent per extension ID and does not interfere with other products.
If you cannot align the hive with your asset management software, open the workaround guide.
See Browser extension policy conflicts and workarounds.
Do the same if the extension still does not install after alignment.
Q. What if whoami /upn is unavailable?
In environments such as on-premises Active Directory only, UPN cannot be retrieved.
The script then falls back to USERNAME@DomainPart. Set the DomainPart variable in your script to the correct domain name.
For manual setup, use edge_chrome_extension.bat.
In ENV_REF mode, use Set-UserEmailEnv.bat instead.
For GPO distribution, use Set-UserEmailEnv.bat.
Sometimes you cannot construct the correct email address. In that case, register the configured email as a secondary address in the directory to enable user matching.
Q. Why do Chrome and Edge use different extension IDs?
Chrome Web Store and Microsoft Edge Add-ons are separate stores. The same extension receives different IDs on each. Windows distribution methods (manual, GPO, and Intune) support both browsers.
Q. Can I modify Software\Policies without administrator rights?
No. Under HKCU, users can normally write their own keys, but the Software\Policies subtree is an exception. Default ACL grants write access to administrators only. Manual writes therefore require administrator rights. Last modified on November 10, 2026
