> ## Documentation Index
> Fetch the complete documentation index at: https://support.i.moneyforward.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 2-1. Browser Extension Setup Guide (Windows Solo Setup)
> Steps to manually install the browser extension on a single PC.
## 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.
| File | Description | Download |
| ---------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| `edge_chrome_extension.bat.txt` | Main script that force-installs the extension and writes policy values (ApiKey, etc.) to the registry | [Download](https://files.support.i.moneyforward.com/files/it-management/admina-extension/windows-solo-setup/edge_chrome_extension.bat.txt) |
| `set_useremail_env.bat.txt` | Script that sets the user's email address as an environment variable (used in `ENV_REF` mode; usually not needed for the standard solo setup configuration) | [Download](https://files.support.i.moneyforward.com/files/it-management/admina-extension/windows-solo-setup/set_useremail_env.bat.txt) |
| `check_extension_registry.bat.txt` | Read-only tool that checks the current registry configuration | [Download](https://files.support.i.moneyforward.com/files/it-management/admina-extension/windows-solo-setup/check_extension_registry.bat.txt) |
To get everything at once, use [Download all files as ZIP](https://files.support.i.moneyforward.com/files/it-management/admina-extension/windows-solo-setup/all-files.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.
* [Distribution via Windows GPO](/en/it-management/admina-extension/qegqblx598-windows-gpo)
* [Distribution via Windows Intune](/en/it-management/admina-extension/windows-intune)
### 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](/en/it-management/admina-extension/qegqblx598-windows-gpo) or [Windows Intune distribution](/en/it-management/admina-extension/windows-intune) instead.
Ensure the following network paths are available 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 |
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
```text theme={null}
┌─────────────────────────────────────────────────────────────┐
│ 配布フェーズ（管理者権限: bat 手動実行） │
│ │
│ レジストリに書く: │
│ [HKLM] ExtensionSettings\ │
│ installation_mode="force_installed" │
│ update_url="https://..." │
│ [HKCU] 3rdparty\extensions\\policy │
│ ApiKey, CreatedDate, OrganizationID │
│ UserEmail = user@example.com ← DIRECT で解決 │
│ UserPC = "%COMPUTERNAME%" │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 実行フェーズ（ユーザーログオン時） │
│ │
│ ブラウザ起動 → ポリシー読み込み │
│ │
│ 拡張機能が受け取る値: │
│ ApiKey = eyJhbG... │
│ UserEmail = user@example.com │
│ UserPC = DESKTOP-ABC1234 │
└─────────────────────────────────────────────────────────────┘
```
### 2.2 Registry tree
Place ExtensionSettings (force-install directive) in **HKLM** and 3rdparty/policy (parameters passed to the extension) in **HKCU** \[Note 1].
#### Chrome
```text theme={null}
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 = <管理画面から取得>
CreatedDate = 2025-12-11T00:00:00Z
OrganizationID = <管理画面から取得>
UserEmail = user@example.com
UserPC = %COMPUTERNAME%
```
#### Edge
```text theme={null}
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 = <管理画面から取得>
CreatedDate = 2025-12-11T00:00:00Z
OrganizationID = <管理画面から取得>
UserEmail = user@example.com
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 email address | Resolved via `whoami /upn` at bat runtime |
| `UserPC` | Dynamic | Device hostname | System environment variable `COMPUTERNAME` |
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 bundled `edge_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 of `edge_chrome_extension.bat`.
| Variable | Setting | Recommended for standalone |
| ----------------- | --------------------------------------------------------------------------- | --------------------------- |
| `DomainPart` | Domain after `@` in the email address | `example.com` |
| `UserEmailMode` | `DIRECT` (resolved by script) or `ENV_REF` (environment variable reference) | `DIRECT` |
| `ApiKey` | Value from section 3.1 | (from admin console) |
| `CreatedDate` | Value from section 3.1 | e.g. `2025-12-11T00:00:00Z` |
| `OrganizationID` | Value from section 3.1 | (from admin console) |
| `ExtSettingsRoot` | ExtensionSettings delivery target | `HKLM` |
| `PolicyRoot` | 3rdparty/policy delivery target | `HKCU` |
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**. With `PolicyRoot=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 how `UserEmail` 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 run `edge_chrome_extension.bat` manually, each step's result appears during execution. Expected output with the recommended layout (ExtensionSettings=HKLM, 3rdparty/policy=HKCU):
```text theme={null}
==============================
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:
...(レジストリ値一覧が表示されます)...
==============================
FINISHED
==============================
```
Confirm that steps `[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 bundled `check_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.
```text theme={null}
================================================================
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 =
[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
```
The same "HKLM=ExtensionSettings, HKCU=3rdparty/policy" layout is correct for standalone operation.
### 4.3 Checking extension display
After the browser reloads policies, confirm the extension is installed.
* Chrome: `chrome://extensions`
* Edge: `edge://extensions`
If the Admina extension appears in the list and is enabled, setup succeeded. Force-installed extensions show as "Installed by your organization".
### 4.4 Verifying parameter delivery
Open `chrome://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 data](/en/it-management/admina-extension/344geptwee-diag)
### 5.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)
PowerShell example:
```text theme={null}
Test-NetConnection -ComputerName api.itmc.i.moneyforward.com -Port 443
```
A successful check responds within one second. Long waits suggest a blockage somewhere along the path.
***
## 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.
If `chrome://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 rejects `PolicyRoot=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's `edge://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 to `HKLM\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
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 with Source (`Platform`) and Scope (`Machine` / `User`). Use the Scope column to tell HKLM from HKCU origin.
### A.2 Edge: Verifying 3rdparty/policy
Edge's `edge://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.
1. Open `edge://extensions` and turn on Developer mode
2. Click **Details** on the target extension, then **Inspect Service Worker**
3. In the DevTools Console tab, run:
```text theme={null}
chrome.storage.managed.get(null, (data) => console.log(data))
```
Example output:
```text theme={null}
{
ApiKey: "eyJhbGciOiJIUzI1NiIs...",
CreatedDate: "2025-12-11T00:00:00Z",
OrganizationID: "99581857",
UserEmail: "user@example.com",
UserPC: "MYPC-001"
}
```
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. [How to check Diag data](/en/it-management/admina-extension/344geptwee-diag)
***
## 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, open `chrome://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\bdeanmdeckegmfjpbnngomallcedjold`
* `HKLM\Software\Policies\Microsoft\Edge\ExtensionSettings\flggmhlpipcopffjfkpgkoljghfkmfcg`
* `HKCU\Software\Policies\Google\Chrome\3rdparty\extensions\bdeanmdeckegmfjpbnngomallcedjold`
* `HKCU\Software\Policies\Microsoft\Edge\3rdparty\extensions\flggmhlpipcopffjfkpgkoljghfkmfcg`
Delete command example: `reg delete "HKLM\Software\Policies\Google\Chrome\ExtensionSettings\" /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 update `ApiKey` or `UserEmail`, re-run the same script to overwrite safely.
### Q. What if ExtensionSettings shows a conflict warning?
If `chrome://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 to `USERNAME@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.