Download the distribution files
Download the bat files used for setup from the links below. Clicking a link opens the file in the same tab. After downloading, use the browser Back button to return to this page.
To get everything at once, use Download all files as ZIP.
See section 3.2 for how to use each file.
Chapter 1: Overview
Purpose
This guide covers manual browser extension setup on a standalone Windows PC that is not managed by Active Directory or MDM.Intended audience
This guide is for IT administrators, information systems staff, or users with local administrator rights on the target PC. For bulk distribution via GPO or Intune, see the respective guides below.Prerequisites
You need Windows 10 or later with Google Chrome or Microsoft Edge installed.This guide assumes that the user who already holds local administrator rights on the target PC runs the setup themselves. Elevating via “Run as administrator” with a different administrator account’s ID and password does not work with this guide’s steps. The elevated process runs in that other account’s context, so the registry is written to the elevating account’s HKCU instead of the target user’s HKCU.If the target user does not have administrator rights, use Windows GPO distribution or Windows Intune distribution instead.
If outbound traffic is restricted, add these domains to your proxy or firewall allow list. See Chapter 5 for connectivity verification steps.
Disclaimer
The distribution steps in this guide are provided for reference. Extension behavior has been verified, but we do not guarantee that registry settings will not affect existing policies or your environment. Test in a validation environment before deploying to production.Chapter 2: Architecture overview
Setup uses two layers: registry and user environment variables. Registry stores browser policies. User environment variables hold per-user values (email address). When the browser reads policies,%USEREMAIL% in registry values expands from the user environment variable. One registry value can deliver the correct value to each user.
In standalone configuration, use UserEmailMode=DIRECT. The bat file resolves the email address from whoami /upn at runtime. You do not need to set the USEREMAIL environment variable separately.
2.1 Data flow
2.2 Registry tree
Place ExtensionSettings (force-install directive) in HKLM and 3rdparty/policy (parameters passed to the extension) in HKCU [Note 1].Chrome
Edge
2.3 Parameter list
See section 3.1 for details on obtaining values.
Chapter 3: Configuration steps
3.1 Obtaining values from the admin console
Sign in and open Settings > Organization > Browser extension > Extension policy. Generate or copy the policy, paste the clipboard contents into a text editor, and note the three values:ApiKey, CreatedDate, and OrganizationID. These three are fixed values shared across all devices.
3.2 Manual execution on a standalone PC
For manual setup on a standalone Windows PC not under AD or MDM management, use the bundlededge_chrome_extension.bat. In standalone configuration, write ExtensionSettings to HKLM and 3rdparty/policy to HKCU, same as the recommended layout in section 2.2.
Because the target user runs the bat themselves in standalone mode, you can use UserEmailMode=DIRECT (auto-resolved from whoami /upn inside the script).
3.2.1 Editing the script
Edit the constant section at the top ofedge_chrome_extension.bat.
The bat script rejects
PolicyRoot=HKLM. Because 3rdparty/policy holds user-specific parameters such as UserEmail, always set the hive to HKCU.3.2.2 How to run
Sign in as the target user, using an account that already has local administrator rights, then right-click the bat file and select Run as administrator. WithPolicyRoot=HKCU, values are written to the target user’s HKCU.
You cannot use the “Run as administrator” prompt to elevate with a different administrator account’s ID and password. The process then runs in the elevating account’s context, so HKCU points to that account’s hive instead of the target user’s [Note 6]. If the target user lacks administrator rights, use GPO or Intune distribution instead (see 3.2.3).
3.2.3 Differences from other distribution methods
Standalone and GPO / Intune delivery use the same registry placement (ExtensionSettings=HKLM, 3rdparty/policy=HKCU). The main difference is howUserEmail is resolved: standalone uses UserEmailMode=DIRECT (resolved at runtime), while GPO / Intune uses ENV_REF (expands %USEREMAIL% from each user’s environment variable at runtime).
Chapter 4: Verification
4.1 Checking install script output
When you runedge_chrome_extension.bat manually, each step’s result appears during execution. Expected output with the recommended layout (ExtensionSettings=HKLM, 3rdparty/policy=HKCU):
[1] through [5] show no errors and that the registry value list in [5] contains the expected parameters.
4.2 Verification with the check script
The bundledcheck_extension_registry.bat is read-only. It does not write to the registry. It scans both HKCU and HKLM and displays the results.
With the recommended layout, expect only ExtensionSettings [OK] on the HKLM side and only 3rdparty/policy [OK] on the HKCU side, with [--] NOT SET on the opposite side. Items marked [--] mean the value was intentionally placed elsewhere, not an error.
4.3 Checking extension display
After the browser reloads policies, confirm the extension is installed.- Chrome:
chrome://extensions - Edge:
edge://extensions
4.4 Verifying parameter delivery
Openchrome://policy in Chrome and click Reload policies. The Admina extension policy lists ApiKey, CreatedDate, OrganizationID, UserEmail, and UserPC.
Edge does not show extension parameters at edge://policy [Note 7]. Use an alternative method. See Appendix A for details.
When all values are confirmed, setup is complete. Data transmission starts within 5 to 30 minutes.
Chapter 5: Connectivity and data verification
5.1 Connectivity check
When parameters are set and applied correctly, data reaches the server within about 30 minutes. Check Integrations > Event Log for entries with source “Chrome” or “Edge”.5.2 Troubleshooting when data does not arrive
Click the extension icon in the browser and open the settings page from the settings icon (⚙️). If no warning appears, data is being sent. If a warning appears, contact us via chat with a screenshot and Diag data. How to check Diag data5.3 Network investigation
Verify connectivity to the following destinations.api.itmc.i.moneyforward.com:443(data destination / API access)itmc.i.moneyforward.com:443(web access)
Chapter 6: Technical notes (annotation details)
This chapter explains the background for annotations (Notes 1, 3–7) from Chapters 2–3. Refer here to understand operational rationale or to isolate causes during troubleshooting.Note 1: Why ExtensionSettings in HKLM and 3rdparty/policy in HKCU
Registry writes go to HKLM (machine-wide) or HKCU (per logged-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 (Note 6). Splitting roles is the most manageable layout in practice.
Note 3: 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 before evaluation. Chromium policy priority is “Platform/Machine (HKLM) > Platform/User (HKCU)”. When ExtensionSettings exist in both HKLM and HKCU, the HKLM dictionary wins entirely and the HKCU dictionary is not merged at all. For example, if HKLM has extension A and HKCU has extension B separately, B is ignored. Ifchrome://policy or edge://policy shows conflict warnings (yellow or red markers) for ExtensionSettings, 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, so HKLM and HKCU merge as long as value names do not collide (see also Note 4).
Note 4: What happens 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 per Chromium policy priority (Machine > User). The recommended layout in this guide 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 and unintended values reach the extension. Before deploying, confirm HKLM 3rdparty/policy subkeys are empty.Note 6: Executing user vs HKCU delivery target (Run as Administrator pitfall)
When writing to HKCU, the user context of the process that runs the script determines which user’s HKCU receives the write. Unless the target user runs the script themselves, their HKCU is not updated. With Run as Administrator, when a standard user elevates with another account’s credentials (Administrator, etc.), the process runs in Administrator’s context. HKCU points to Administrator’s hive, and the target user’s browser cannot read those values. There is no simple way to work around this from the bat file alone, so standalone execution assumes the target user themselves signs in with an account that already has administrator rights. If the target user lacks administrator rights, use GPO or Intune distribution instead. The bat script rejectsPolicyRoot=HKLM as invalid, preventing user-specific values from being written to the machine-wide hive.
Note 7: Why 3rdparty/policy does not appear at edge://policy
Edge’sedge://policy shows browser policies and ExtensionSettings, but does not display custom policies under 3rdparty/extensions//policy. This is known Edge behavior. Microsoft documents that Edge respects 3rdparty registry entries but does not support displaying them in the UI. Values still reach the extension correctly; they are just not visible on that page.
As an alternative to verify delivery on Edge, call the chrome.storage.managed.get() API from the extension’s Service Worker console. See Appendix A.2.
Supplement 1: 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, the delivery methods in this guide assume manual execution with administrator rights. Standard users get Access Denied when attempting to write directly to HKCU\Software\Policies.
Supplement 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 run from normal cmd.exe accesses the 64-bit view. When invoked from a 32-bit context, HKLM writes redirect toHKLM\SOFTWARE\WOW6432Node\Policies\..., which browsers cannot read.
The bundled scripts add the /reg:64 flag to all reg add and reg query calls so reads and writes target the 64-bit view regardless of calling context. During troubleshooting, check in regedit whether values landed under HKLM\SOFTWARE\WOW6432Node\Policies\....
Appendix A: Verifying policies in the browser
A.1 Chrome: chrome://policy
Enterchrome://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 with Source (Platform) and Scope (Machine / User). Use the Scope column to tell HKLM from HKCU origin.
A.2 Edge: Verifying 3rdparty/policy
Edge’sedge://policy shows ExtensionSettings but not 3rdparty/policy (see Note 7). 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. If written, Edge reads them.
Method 2: Verify with chrome.storage.managed API
From the extension’s Service Worker console, confirm the values that actually arrived.
- Open
edge://extensionsand turn on Developer mode - Click Details on the target extension, then Inspect Service Worker
- In the DevTools Console tab, run:
Appendix B: 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, openchrome://policy or edge://policy and click Reload policies.
Q. How do I uninstall the extension?
Delete the following registry keys.HKLM\Software\Policies\Google\Chrome\ExtensionSettings\bdeanmdeckegmfjpbnngomallcedjoldHKLM\Software\Policies\Microsoft\Edge\ExtensionSettings\flggmhlpipcopffjfkpgkoljghfkmfcgHKCU\Software\Policies\Google\Chrome\3rdparty\extensions\bdeanmdeckegmfjpbnngomallcedjoldHKCU\Software\Policies\Microsoft\Edge\3rdparty\extensions\flggmhlpipcopffjfkpgkoljghfkmfcg
reg delete "HKLM\Software\Policies\Google\Chrome\ExtensionSettings\<ID>" /f /reg:64
The extension is removed when the browser next reloads policies.
Q. What happens if I re-run on a device that already has the extension?
Re-running the same bat overwrites registry values only. No double installation occurs. To updateApiKey or UserEmail, re-run the same script to overwrite safely.
Q. What if ExtensionSettings shows a conflict warning?
Ifchrome://policy / edge://policy shows warnings (yellow or red markers) on ExtensionSettings entries, ExtensionSettings exist in both HKLM and HKCU (see Note 3). HKLM wins the whole dictionary and HKCU is ignored.
Consolidate to either HKLM or HKCU only. To match the recommended layout in this guide, 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 (Chrome:bdeanmdeckegmfjpbnngomallcedjold, Edge: flggmhlpipcopffjfkpgkoljghfkmfcg), so they coexist at the subkey level.
One important caveat: the browser reads ExtensionSettings from either HKLM or HKCU, not both (Note 3 rule). 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.
Check regedit for both HKLM\Software\Policies\Google\Chrome\ExtensionSettings and 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.
Q. What if whoami /upn is unavailable?
In environments such as on-premises AD only where UPN cannot be retrieved, the script falls back toUSERNAME@DomainPart. Set the DomainPart variable at the top of the script to the correct domain name.
Even if you cannot construct the correct email address, registering the configured email as a secondary address in the directory enables 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. The distribution script supports both.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. The delivery scenarios in this guide assume manual execution with administrator rights.