Chapter 1: Overview
Purpose of This Document
This document is a setup guide for deploying the browser extension to Windows environments. It covers bulk distribution via Active Directory GPO (Group Policy) or MDM. It also covers manual installation on individual machines.
Target Audience
This guide is intended for IT administrators (Active Directory / Entra ID administrators) and IT department staff.
Prerequisites
Target machines must run Windows 10 or later with Google Chrome or Microsoft Edge installed. GPO distribution requires an Active Directory domain environment and GPO management privileges. MDM distribution requires management privileges for the target MDM product.
The following network paths must be open for extension download and data transmission.
| Destination | Port | Purpose |
|---|
clients2.google.com | 443 (HTTPS) | Chrome extension download / update |
edge.microsoft.com | 443 (HTTPS) | Edge extension download / update |
api.itmc.i.moneyforward.com | 443 (HTTPS) | Data transmission / API access |
itmc.i.moneyforward.com | 443 (HTTPS) | Web access |
Disclaimer
GPO/MDM configurations vary widely across organizations. The distribution procedures in this document are provided as reference information only. The extension itself has been validated. However, we cannot guarantee that the distribution configuration will not affect your existing policies or environment. We recommend testing in a validation environment before deployment.
Chapter 2: Architecture Overview
The setup consists of two layers: registry and user environment variables. The registry holds browser policy settings, and user environment variables hold per-user values (email addresses). When the browser reads the policy, it expands %USEREMAIL% from the registry value using the user environment variable. This single registry value then delivers the correct value to each user.
2.1 Data Flow
┌─────────────────────────────────────────────────────────────┐
│ Distribution Phase (admin privileges: GPO / MDM / bat) │
│ │
│ Write to registry: │
│ [HKLM] ExtensionSettings\<ID> │
│ installation_mode="force_installed" │
│ update_url="https://..." │
│ [HKCU] 3rdparty\extensions\<ID>\policy │
│ ApiKey, CreatedDate, OrganizationID │
│ UserEmail = "%USEREMAIL%" ← literal reference │
│ UserPc = "%COMPUTERNAME%" │
│ │
│ Write user environment variable (logon script): │
│ USEREMAIL = user@example.com ← actual value per user │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ Runtime Phase (at user logon) │
│ │
│ Browser starts → loads policy → expands %USEREMAIL% │
│ │
│ Values received by extension: │
│ ApiKey = eyJhbG... │
│ UserEmail = user@example.com ← expanded value │
│ UserPc = DESKTOP-ABC1234 │
└─────────────────────────────────────────────────────────────┘
2.2 Registry Tree
The recommended configuration places ExtensionSettings (force-install instruction) in HKLM. It places 3rdparty/policy (parameters passed to the extension) in HKCU [※1].
Chrome
HKLM\Software\Policies\Google\Chrome\
└─ ExtensionSettings\bdeanmdeckegmfjpbnngomallcedjold\
installation_mode = "force_installed"
update_url = "https://clients2.google.com/service/update2/crx"
HKCU\Software\Policies\Google\Chrome\
└─ 3rdparty\extensions\bdeanmdeckegmfjpbnngomallcedjold\policy\
ApiKey = <obtained from the admin console>
CreatedDate = 2025-12-11T00:00:00Z
OrganizationID = <obtained from the admin console>
UserEmail = %USEREMAIL%
UserPc = %COMPUTERNAME%
Edge
HKLM\Software\Policies\Microsoft\Edge\
└─ ExtensionSettings\flggmhlpipcopffjfkpgkoljghfkmfcg\
installation_mode = "force_installed"
update_url = "https://edge.microsoft.com/extensionwebstorebase/v1/crx"
HKCU\Software\Policies\Microsoft\Edge\
└─ 3rdparty\extensions\flggmhlpipcopffjfkpgkoljghfkmfcg\policy\
ApiKey = <obtained from the admin console>
CreatedDate = 2025-12-11T00:00:00Z
OrganizationID = <obtained from the admin console>
UserEmail = %USEREMAIL%
UserPc = %COMPUTERNAME%
2.3 Parameter List
| Parameter | Type | Purpose | Value source |
|---|
ApiKey | Fixed | Authentication token | Admin console |
CreatedDate | Fixed | Policy creation timestamp | Admin console |
OrganizationID | Fixed | Organization ID | Admin console |
UserEmail | Dynamic | User’s email address | User environment variable USEREMAIL |
UserPc | Dynamic | Device hostname | System environment variable COMPUTERNAME |
Chapter 3: Configuration Steps
3.1 Retrieving Values from the Admin Console
Log in and open Settings > Organization > Browser Extension > Extension Policy. Generate or copy the policy, then paste the clipboard content into a text editor. Note the three values: ApiKey, CreatedDate, and OrganizationID. These three values are fixed and shared across all devices.
3.2 Choosing a Distribution Method
Choose one of the following based on your environment.
- 3.3 Distribution via GPO: AD domain environments. Use Registry Preferences for direct delivery.
- 3.4 Distribution via MDM: Intune and similar. Use the MDM product’s script or registry distribution feature.
- 3.5 Manual execution on standalone PCs: Standalone PCs not managed by AD or MDM. Run the included bat file with administrator privileges.
3.3 Distribution via GPO
In GPO distribution, deliver the registry tree from section 2.2 to Computer Configuration (HKLM). Also deliver it to User Configuration (HKCU). Additionally, distribute the logon script that sets the USEREMAIL environment variable.
3.3.1 Delivering the HKLM Side (ExtensionSettings)
Edit the target GPO in GPMC and open Computer Configuration → Preferences → Windows Settings → Registry. For all items, use Hive = HKEY_LOCAL_MACHINE, Action = Update [※2] and create the following four entries.
Chrome ExtensionSettings
Key Path: Software\Policies\Google\Chrome\ExtensionSettings\bdeanmdeckegmfjpbnngomallcedjold
| Value name | Value type | Value data |
|---|
installation_mode | REG_SZ | force_installed |
update_url | REG_SZ | https://clients2.google.com/service/update2/crx |
Software\Policies\Microsoft\Edge\ExtensionSettings\flggmhlpipcopffjfkpgkoljghfkmfcg
| Value name | Value type | Value data |
|---|
installation_mode | REG_SZ | force_installed |
update_url | REG_SZ | https://edge.microsoft.com/extensionwebstorebase/v1/crx |
Writing ExtensionSettings to both HKLM and HKCU causes a conflict where one side is ignored [※3]. Place it in HKLM only.
3.3.2 Delivering the HKCU Side (3rdparty/policy)
Open User Configuration → Preferences → Windows Settings → Registry. For all items, use Hive = HKEY_CURRENT_USER, Action = Update and create the following ten entries.
Chrome 3rdparty Policy
Key Path: Software\Policies\Google\Chrome\3rdparty\extensions\bdeanmdeckegmfjpbnngomallcedjold\policy
| Value name | Value type | Value data |
|---|
ApiKey | REG_SZ | (value obtained from the admin console) |
CreatedDate | REG_SZ | e.g. 2025-12-11T00:00:00Z |
OrganizationID | REG_SZ | (value obtained from the admin console) |
UserEmail | REG_EXPAND_SZ | %USEREMAIL% |
UserPc | REG_EXPAND_SZ | %COMPUTERNAME% |
Software\Policies\Microsoft\Edge\3rdparty\extensions\flggmhlpipcopffjfkpgkoljghfkmfcg\policy
| Value name | Value type | Value data |
|---|
ApiKey | REG_SZ | (value obtained from the admin console) |
CreatedDate | REG_SZ | e.g. 2025-12-11T00:00:00Z |
OrganizationID | REG_SZ | (value obtained from the admin console) |
UserEmail | REG_EXPAND_SZ | %USEREMAIL% |
UserPc | REG_EXPAND_SZ | %COMPUTERNAME% |
Do not write 3rdparty/policy to both HKLM and HKCU [※4]. When the same value name exists in both, HKLM takes precedence, and the UserEmail value expanded in HKCU is overridden.
3.3.3 Delivering the USEREMAIL Environment Variable (Logon Script)
To deliver UserEmail as a %USEREMAIL% reference, each user’s logon must set the USEREMAIL environment variable [※5]. Place the included set_useremail_env.bat in SYSVOL and register it as a GPO logon script.
- Edit the
DomainPart variable at the top of set_useremail_env.bat to your domain name (e.g. example.com).
- Place in SYSVOL:
\\<DOMAIN>\SYSVOL\<DOMAIN>\scripts\admina\set_useremail_env.bat
- Edit the target GPO in GPMC. Add the script path to
User Configuration → Policies → Windows Settings → Scripts (Logon/Logoff) → Logon.
The script attempts to retrieve the UPN using whoami /upn. On failure, it falls back to USERNAME@DomainPart. It persists the value as a user environment variable using setx USEREMAIL "<value>".
3.3.4 Alternative: Startup Script Method
You can also deliver settings using a bat script instead of GPO Preferences. Place edge_chrome_extension.bat in SYSVOL and register it as a startup script. Edit the constants section and the ExtSettingsRoot/PolicyRoot variables in the bat file (see section 3.5).
3.3.5 Applying the GPO
Link the GPO to the target OU. Then run gpupdate /force on the client machines or log off and back on to apply changes.
For more details on GPO configuration, see: Deploy via GPO on Windows
3.4 Distribution via MDM
When using MDM (such as Intune), distribute the registry tree from section 2.2. Use the MDM product’s script distribution or registry management feature.
- Script distribution: Distribute and run
edge_chrome_extension.bat (see section 3.5 for bat configuration).
- Registry distribution: Define the keys and values from section 2.2 directly using the MDM’s registry management feature.
When delivering via MDM, scripts typically run under the SYSTEM account. Note that in this case, HKCU points to a different hive than expected [※6]. Follow the documentation for your MDM product for specific configuration steps.
3.5 Manual Execution on Standalone PCs
For manual setup on a standalone Windows PC not managed by AD or MDM, use the included edge_chrome_extension.bat. Even in a standalone configuration, the recommended layout is the same as section 2.2. Use ExtensionSettings in HKLM, 3rdparty/policy in HKCU.
In standalone mode, the target user runs the bat themselves. This means you can use UserEmailMode=DIRECT (the script automatically resolves the email via whoami /upn). You do not need to separately configure the USEREMAIL environment variable as required in GPO/MDM distribution.
3.5.1 Editing the Script
Edit the constants section at the top of edge_chrome_extension.bat.
| Variable | Description | Recommended value for standalone |
|---|
DomainPart | The part after @ in the email address | example.com |
UserEmailMode | DIRECT (resolved by script) or ENV_REF (environment variable reference) | DIRECT |
ApiKey | Value obtained in section 3.1 | (from the admin console) |
CreatedDate | Value obtained in section 3.1 | e.g. 2025-12-11T00:00:00Z |
OrganizationID | Value obtained in section 3.1 | (from the admin console) |
ExtSettingsRoot | Delivery target for ExtensionSettings | HKLM |
PolicyRoot | Delivery target for 3rdparty/policy | HKCU |
PolicyRoot=HKLM is rejected by the bat script. The 3rdparty/policy area holds user-specific parameters (such as UserEmail), so always specify HKCU for the hive.
3.5.2 How to Run
When the target user has local administrator privileges: Right-click the bat file and select “Run as administrator”. With PolicyRoot=HKCU, the script writes to the target user’s HKCU.
The target user does not have administrator privileges, and elevation uses a different admin account. Running “Run as administrator” with another account’s credentials elevates the process. The process then runs in that admin account’s context, not the target user’s. HKCU points to the elevating admin account’s hive, not the target user’s [※6]. In this case, use GPO distribution instead. Alternatively, use a method such as runas /user:<target user> ... to run the script in the target user’s own context.
3.5.3 Differences from GPO/MDM Distribution
The registry layout (ExtensionSettings=HKLM, 3rdparty/policy=HKCU) is identical for standalone and GPO/MDM distribution. The main difference is how UserEmail is resolved. Standalone uses UserEmailMode=DIRECT, which resolves the value at runtime. GPO/MDM uses ENV_REF, which expands %USEREMAIL% from each user’s environment variable at runtime (※5).
Chapter 4: Verification
4.1 Checking Script Output
When you run edge_chrome_extension.bat manually, results for each step are displayed during execution. Expected output for the recommended configuration (ExtensionSettings=HKLM, 3rdparty/policy=HKCU):
==============================
Edge + Chrome Extension Initializer
==============================
ExtensionSettings root: HKLM (HKEY_LOCAL_MACHINE)
3rdparty policy root : HKCU (HKEY_CURRENT_USER)
[1] Generating UserEmail ...
Got from whoami /upn
UserEmail = user@example.com
[2] Reading hostname for UserPc ...
Got from COMPUTERNAME
UserPc = DESKTOP-ABC1234
[3] Writing Chrome ExtensionSettings (HKLM) and 3rdparty policy (HKCU)...
The operation completed successfully.
Chrome extension and policy applied.
[4] Writing Edge ExtensionSettings (HKLM) and 3rdparty policy (HKCU)...
The operation completed successfully.
Edge extension and policy applied.
[5] Registry values written:
...(registry value list is displayed here)...
==============================
FINISHED
==============================
[1] through [5]. Also confirm that the registry value list in [5] shows each parameter written as intended.
4.2 Verification with the Check Script
The included check_extension_registry.bat is a read-only tool that does not write to the registry. It scans both HKCU and HKLM and displays the results.
In the expected output for the recommended configuration, only ExtensionSettings shows [OK] on the HKLM side. Only 3rdparty/policy shows [OK] on the HKCU side. The opposite sides show [--] NOT SET. A [--] entry simply means that item was intentionally not placed there — it is not an error.
================================================================
Extension Registry Checker (read-only)
================================================================
----------------------------------------
HKCU (HKEY_CURRENT_USER)
----------------------------------------
[Chrome ExtensionSettings]
[--] installation_mode NOT SET
[--] update_url NOT SET
[Chrome 3rdparty Policy]
[OK] ApiKey = xxxx...xxxx
[OK] CreatedDate = 2025-12-11T00:00:00Z
[OK] OrganizationID = <YOUR_ORG_ID>
[OK] UserEmail = user@example.com
[OK] UserPc = DESKTOP-ABC1234
[Edge ExtensionSettings]
[--] installation_mode NOT SET
[--] update_url NOT SET
[Edge 3rdparty Policy]
[OK] ApiKey = xxxx...xxxx
...
----------------------------------------
HKLM (HKEY_LOCAL_MACHINE)
----------------------------------------
[Chrome ExtensionSettings]
[OK] installation_mode = force_installed
[OK] update_url = https://clients2.google.com/service/update2/crx
[Chrome 3rdparty Policy]
[--] ApiKey NOT SET
[--] ... NOT SET
[Edge ExtensionSettings]
[OK] installation_mode = force_installed
[OK] update_url = https://edge.microsoft.com/extensionwebstorebase/v1/crx
[Edge 3rdparty Policy]
[--] ApiKey NOT SET
[--] ... NOT SET
4.3 Confirming Extension Installation in the Browser
After the browser reloads its policy, confirm that the extension is installed.
- Chrome:
chrome://extensions
- Edge:
edge://extensions
If the Admina extension appears in the list and is enabled, the installation succeeded. A force-installed extension displays as “Installed by your organization.”
4.4 Confirming Parameter Delivery
In Chrome, open chrome://policy and click “Reload policies”. The Admina extension policy section shows the following parameters. They include ApiKey, CreatedDate, OrganizationID, UserEmail, and UserPc.
Edge does not display extension parameters at edge://policy [※7]. Use an alternative method to verify. See Appendix A for details.
Once all values are confirmed correct, setup is complete. Data transmission begins within 5 to 30 minutes.
Chapter 5: Connectivity and Data Verification
5.1 Connectivity Verification
When parameters are correctly configured, data reaches the server within approximately 30 minutes. Check Integrations > Event Log and confirm that entries with a source of “Chrome” or “Edge” appear.
5.2 Troubleshooting No Data
Click the extension icon in the browser and open the settings page from the gear icon (⚙️). If no warnings appear, data should be transmitting. If warnings appear, contact us via chat and include a screenshot and Diag data. How to check Diag data
5.3 Network Investigation
Verify connectivity to the following destinations.
api.itmc.i.moneyforward.com:443 (data transmission / API access)itmc.i.moneyforward.com:443 (web access)
Example verification using PowerShell:
Test-NetConnection -ComputerName api.itmc.i.moneyforward.com -Port 443
Chapter 6: Technical Notes (Annotation Details)
This chapter explains the background for the annotations (※1–※7) referenced in Chapters 2–3. Refer to this section when you need to understand operational reasoning or troubleshoot issues.
※1 Why ExtensionSettings in HKLM and 3rdparty/policy in HKCU?
Registry locations fall into two categories: HKLM (machine-wide) and HKCU (per-logged-in-user). Because these behave differently, the appropriate hive depends on the type of policy.
ExtensionSettings is a machine-wide setting. The instruction to force-install the extension is the same regardless of which user logs in. Writing it once to HKLM is sufficient. Because the value is shared across all devices, management stays simple.
3rdparty/policy holds parameters evaluated in the user context. In particular, UserEmail must deliver a different value per user. Writing it to HKCU and expanding it with the USEREMAIL user environment variable solves this. The registry then only needs to store a single %USEREMAIL% reference. This reference resolves to the correct value for each logged-in user.
Technically it is possible to write everything to HKLM. However, doing so makes UserEmail a fixed value machine-wide, which is a problem on shared PCs. Writing everything to HKCU increases sensitivity to process context issues (※6). Splitting the responsibility between the two hives is the most manageable operational configuration.
※2 Why Use the “Update” Action?
GPO Preferences Registry Items support the following Actions.
- Create: Creates the value only if it does not exist. Existing values are skipped.
- Update: Creates if absent, overwrites if present. Other values under the same key are preserved.
- Replace: Deletes and recreates the entire key. Other values under the same key are also deleted.
- Delete: Deletes the value.
Update is recommended here for three reasons. First, values such as ApiKey that may change in the future are reliably updated to the latest version. Create only applies on first delivery, so it cannot refresh values afterward. Second, it does not carry the side effect of deleting other values under the same key as Replace does. Third, it acts as “create if absent” for the first deployment. This means the same Action works for both initial and subsequent deliveries.
※3 Why Does Writing ExtensionSettings to Both HKLM and HKCU Cause a Conflict?
ExtensionSettings is treated internally as a dictionary-type policy. When the browser reads registry subkeys, it groups them by extension ID into one large JSON dictionary. This aggregation happens before evaluation.
The Chromium policy priority order is “Platform/Machine (HKLM) > Platform/User (HKCU)”. When ExtensionSettings exists in both HKLM and HKCU, the entire HKLM dictionary wins. The HKCU dictionary is not merged at all. For example, if extension A is written to HKLM and extension B to HKCU, extension B is ignored entirely.
Conflict warnings (yellow or red markers) on ExtensionSettings in chrome://policy or edge://policy indicate this cause. The fix is to consolidate to either HKLM or HKCU.
Note that 3rdparty/policy is not subject to this dictionary-level aggregation — it operates independently per value. As long as value names do not collide between HKLM and HKCU, the values are merged. They are then delivered to the extension (see also ※4).
※4 What Happens When the Same Value Name Exists in Both HKLM and HKCU for 3rdparty/policy?
Unlike ExtensionSettings, 3rdparty/policy does not apply a winner-takes-all dictionary rule. However, when the same value name exists in both HKLM and HKCU, HKLM takes precedence. This is because the Chromium policy priority rule (Machine > User) applies directly.
In this document’s recommended configuration, 3rdparty/policy is placed in HKCU only, so this conflict does not occur. However, in environments where HKLM-side 3rdparty/policy keys were written in the past, this can differ. The %USEREMAIL% value expanded in HKCU loses to HKLM, and the literal string reaches the extension instead. Before deploying, confirm that the HKLM-side 3rdparty/policy subkey is empty.
※5 Why Use an Environment Variable Reference Instead of Writing UserEmail Directly to the Registry?
In a Computer Configuration (HKLM-side) registry item in GPO Preferences, writing %USEREMAIL% produces a literal string. It is not expanded. This happens because the process context during GPO application runs as the SYSTEM account. This account cannot see the user environment variable USEREMAIL. This is an architectural constraint of Windows and cannot be worked around.
In contrast, User Configuration (HKCU-side) applies in the logged-on user’s context, so %USEREMAIL% expands correctly. This is one of the primary reasons this document places 3rdparty/policy in HKCU.
Note that %COMPUTERNAME% used for UserPc is a system environment variable. It expands regardless of whether it is written to HKLM or HKCU. UserEmail is special because it is a user environment variable.
※6 Mismatch Between Executing User and HKCU Target (Run as Administrator and MDM Execution Pitfall)
When writing to HKCU, the hive that is written to depends on the user context of the process running the script. Unless the target user runs the script themselves, nothing is written to that user’s HKCU.
This causes problems in the following two cases.
- A standard user elevates using Run as Administrator with another account’s credentials (e.g. Administrator’s). The process then runs in that admin account’s context. HKCU points to the admin account’s hive, so the target user’s browser cannot read those values.
- MDM or SCCM runs the script as SYSTEM. When a script is delivered via an MDM agent, it typically runs as
SYSTEM or an MDM service account. HKCU points to that service account’s hive and is never applied to the actual user.
To avoid this problem, the recommended configuration delivers the HKCU-side settings via GPO User Configuration. This applies in the logged-on user’s context. For standalone execution, the target user must also run the bat in their own context (e.g. using runas). The bat script is designed to reject PolicyRoot=HKLM as invalid. This prevents user-specific values from being written to the machine-wide hive.
※7 Why Doesn’t edge://policy Display 3rdparty/policy?
Edge’s edge://policy shows the browser’s own policies and ExtensionSettings. However, it does not display custom policies under 3rdparty/extensions//policy. This is a known Edge behavior. Microsoft has stated that “Edge respects 3rdparty registry entries but does not have UI support to display them”. The values are delivered correctly to the extension — they are just not visible in the UI.
As an alternative method to verify delivery in Edge, you can call the chrome.storage.managed.get() API. Call it from the extension’s Service Worker console. See Appendix A.2.
Note 1: Permissions on HKCU\Software\Policies
HKCU is generally readable and writable by the user. However, the Software\Policies subtree is restricted to administrators by default ACL. This is by Windows design to prevent users from modifying the policy area.
The distribution methods in this document therefore require either GPO or MDM, both of which run with SYSTEM privileges. Manual execution requires administrator rights instead. A standard user logon script attempting to write directly to HKCU\Software\Policies will fail with Access Denied. Logon scripts running as the user can only write user environment variables such as USEREMAIL. They cannot write registry policies.
Note 2: 64-bit Registry View (/reg:64)
Chrome and Edge are 64-bit applications and read policies from the 64-bit registry view. A bat file run from a standard cmd.exe accesses the 64-bit view. However, from a 32-bit SCCM or MDM agent context, HKLM writes redirect to HKLM\SOFTWARE\WOW6432Node\Policies\.... The browser cannot read this location.
The included scripts add the /reg:64 flag to all reg add and reg query commands. This ensures writes and reads always target the 64-bit view regardless of the calling context. Settings delivered via GPO Preferences are written directly to the 64-bit view. This means the write targets match perfectly between bat and GPO delivery. When troubleshooting, check HKLM\SOFTWARE\WOW6432Node\Policies\... in regedit. Confirming no stray values exist there is also useful.
Appendix A: Verifying Policies in the Browser
A.1 Chrome: chrome://policy
Enter chrome://policy in the address bar and click “Reload policies” to fetch the latest state.
The Extension policies section at the bottom of the page shows values such as ApiKey and UserEmail for each extension. It also shows Source (Platform) and Scope (Machine / User). The Scope column lets you identify whether each value originates from HKLM or HKCU.
A.2 Edge: How to Verify 3rdparty/policy
Edge’s edge://policy shows ExtensionSettings but not 3rdparty/policy (see ※7). Use the following methods to verify that values are being delivered.
Method 1: Check the Registry Directly
Run check_extension_registry.bat to confirm the values are present. Alternatively, open regedit and browse to the relevant key under HKCU/HKLM. If the values are written, Edge is reading them.
Method 2: Verify via chrome.storage.managed API
You can confirm the values actually received by the extension from the Service Worker console.
- Open
edge://extensions and enable Developer mode.
- Click “Details” for the target extension, then click “Inspect service worker.”
- Run the following in the DevTools Console tab:
chrome.storage.managed.get(null, (data) => console.log(data))
{
ApiKey: "eyJhbGciOiJIUzI1NiIs...",
CreatedDate: "2025-12-11T00:00:00Z",
OrganizationID: "99581857",
UserEmail: "user@example.com",
UserPc: "MYPC-001"
}
Appendix B: Q&A
Q. Is a browser restart required after configuring the registry?
No. Chrome and Edge periodically reload policy settings in the background, so changes apply automatically after some time. For immediate effect, open chrome://policy or edge://policy and click “Reload policies.”
Q. How do I uninstall the extension? Does removing it from GPO remove it from devices?
Removing it from GPO alone does not remove the extension. Items delivered via GPO Preferences Update or Create actions remain on client machines like a “tattoo”. This is a Windows Group Policy Preferences behavior. To remove the extension, do one of the following.
- Deliver an explicit Delete action via GPO. For each of the four keys (Chrome/Edge ExtensionSettings and 3rdparty/extensions), create a new Registry Item. Set Action =
Delete and leave the Value name empty. An empty Value name deletes the entire subtree under the key.
- Distribute a deletion bat. Run
reg delete "HKLM\Software\Policies\Google\Chrome\ExtensionSettings\<ID>" /f /reg:64 on client machines.
The extension is removed the next time the browser reloads its policy. Keep the deletion GPO in place until it has applied to all devices, including offline machines. This can take multiple weeks to a month, so wait before removing the GPO.
If the GPO Action is Update, registry values are simply overwritten and no duplicate installation occurs. When updating ApiKey or UserEmail, running the same GPO or script again safely overwrites the existing values.
Q. What should I do if ExtensionSettings shows a conflict warning?
A warning (yellow or red marker) on an ExtensionSettings entry in chrome://policy or edge://policy indicates a conflict. ExtensionSettings exists in both HKLM and HKCU (see ※3). The HKLM dictionary wins entirely and the HKCU dictionary is ignored.
The fix is to consolidate to either HKLM or HKCU. To align with the recommended configuration in this document, delete the ExtensionSettings subkey on the HKCU side.
Q. What if asset management software such as SKYSEA, LANSCOPE, or SS1 already uses ExtensionSettings?
These products also use ExtensionSettings to force-install their own extensions. The Admina extension has different IDs from other products. Chrome uses bdeanmdeckegmfjpbnngomallcedjold, and Edge uses flggmhlpipcopffjfkpgkoljghfkmfcg. So, they can coexist at the subkey level.
However, note that the browser reads ExtensionSettings from only one hive — either HKLM or HKCU (see ※3 rule). If the asset management software writes to HKLM, Admina must also deliver to HKLM. If it writes to HKCU, align Admina to HKCU as well. The browser reads from only one location, so mismatched delivery targets cause one side to be ignored.
In regedit, check HKLM\Software\Policies\Google\Chrome\ExtensionSettings. Also check HKCU\Software\Policies\Google\Chrome\ExtensionSettings. This shows which hive the existing software is using.
The 3rdparty/extensions side is independent per extension ID and does not interfere with other products.
Q. What if whoami /upn is not available?
In on-premises AD-only environments where UPN cannot be retrieved, the script falls back to USERNAME@DomainPart. Set the DomainPart variable at the top of the script to the correct domain name.
If the environment makes it impossible to construct the correct email address, you have another option. You can register the resulting email as a secondary address in the directory to enable user matching.
Q. Why do Chrome and Edge use different extension IDs?
The Chrome Web Store and Microsoft Edge Add-ons are independent stores. The same extension receives different IDs in each. The distribution script handles both.
Q. Can Software\Policies be modified without administrator privileges?
No. HKCU is generally writable by the user, but the Software\Policies subtree is an exception. By default ACL, write access is granted only to administrators. All distribution scenarios in this document assume either GPO, MDM, or manual execution with administrator privileges.
Download bat Files
The bat files are available for download below.
※ Clicking the links below opens the file in the same tab. After downloading, use your browser’s back button to return to this page.
