DLP Agent Chrome and Edge browser extension management
search cancel

DLP Agent Chrome and Edge browser extension management


Article ID: 204478


Updated On:


Data Loss Prevention Endpoint Prevent


Google Chrome and Microsoft Edge Chromium utilize a browser extension to report the current tab's URL to the DLP Agent (via the Native Messaging Host - brkrprcs64.exe to edpa.exe). The URL is needed when processing policies to understand the destination and to report the URL on incidents. The extension is not installed until after the respective browser has been launched with the extension reference in place.

Important: Chrome extension for DLP Agents 15.8 and newer also actively takes part in detection process (as the detection capabilities were moved there), that's why "Chrome extension not deployed" appears as Agent critical state where "Edge extension not deployed" appears as Agent warning state.

For Chrome extension on Mac see Creating an MDM configuration profile to support monitoring in Google Chrome on macOS endpoints.

For Edge extension on Mac in DLP 16.0, see Deploy the Symantec extension to monitor Edge

The Symantec Extension registry value/data information is as follows:


Symantec Extension - DLP 15.7 and below


Registry Type/Data/Value (the value could change, depending on whether there are already any other local extension policies in place):


Type: REG_SZ

Value: 1

Data: eelojgpfkmhiikmhkineneemcahoehjo;https://clients2.google.com/service/update2/crx


Symantec Extension - DLP 15.8 and above


Registry Type/Data/Value (the value could change, depending on whether there are already any other local extension policies in place):


Type: REG_SZ

Value: 1

Data: dehobbhellcfbmcaeppgfjhnldeimdph;https://clients2.google.com/service/update2/crx



Symantec Extension - All DLP Versions


Registry Type/Data/Value (the value could change, depending on whether there are already any other local extension policies in place):

Type: REG_SZ

Value: 1

Data: lgliocaeggimgcpgbbejhdnbmajgaiii


These are added into the Registry at the following keys for the respective browsers:




These extension policies are also added to the Local Group Policy - %windir%\System32\GroupPolicy\Machine\registry.pol. Placing the extension policies in the LGPO prevents users from permanently disabling the extension by removing the Registry entries since during Group Policy processing it will be reloaded into the registry from the registry.pol file.

With DLP 15.5 and 15.7, the Chrome policy entry is created during the agent installation. The agent installer uses a Local Group Policy Windows API call to install/uninstall our Chrome browser extension into the LGPO at HKLM/Software/Policies/Google/Chrome/ExtensionInstallForceList. To determine the position, the LGPO API enumerates those entries defined within LGPO only (i.e. Registry.pol) and increments our entry by the last string value + 1. Directly created Registry entries within this same key (non-GPO / ExtensionInstallForceList) that have a colliding position value will be overwritten once the Group Policies processing occurs. In other words, a direct registry entry at position 1, with no other LGPO entries defined, would be overwritten by our extension at position 1.

With DLP 15.8 and higher, the Chrome and Edge policy entry is managed on-demand when the respective (HTTPS) channel is enabled/disabled, and also at agent service startup. The advanced agent setting ExtensionEnablement.INSTALL_BROWSER_EXTENSION.int determines whether the agent creates the ExtensionInstallForceList LGPO policies for Chrome and Edge (1) or not (0).

For agent versions 15.5 - 15.7, you can skip installing the Chrome extension during the agent installation by adding the INSTALLCHROMEPLUGIN=0 parameter to the installation command in the install_agent.bat file.



DLP 15.x

DLP 16.0


We recommend that customers who are enforcing Chrome or Edge ExtensionInstallForcelist policies at the Domain GPO level also add the Extension for each browser to the Domain policy and that they be managed at the "Computer (Machine Hive)" level (not at the User level).

This is due to the policy processing order of Windows GPOs combined with Chromium policy behavior. During GPO processing Domain policies are processed last and any key defined in a Domain GPO takes full precedence over the Local GPOs, which means that Registry keys defined in the same hive in competing GPOs do not merge values. Chromium browser policy processing stops at the first defined policy location in this order (1) Device / Machine policy -> (2) Machine-level cloud policy -> (3) OS User policy -> (4) Chrome profile as outlined in the following article:

Understand Chrome policy management


  • Extension policies defined at LGPO - Computer (Machine) and in Domain GPO - Computer (Machine).
    • The Domain - Computer (Machine) policies win because they are the last to process, fully overwriting the ExtensionInstallForcelist key with the Domain policies.
  • Extension policies defined at LGPO - Computer (Machine) and in Domain GPO - User.
    • The LGPO policies win, because they remain after GPO processing, and Chromium favors Machine policies over User policies.


To view an endpoint's Resultant Set of Policy to see where browsers' extension policies are loading from you can run rsop.msc, which will give you a view similar to the following for domain policies:

And when coming from the local group policy, it would appear similar to the following:

You can view the currently installed extensions in each browser by navigating to their respective extensions URLs. To view the current browser policy information, navigate to the browser's policy URL, e.g.:








Additional Information

See also: What are the EdgeChromeExtension.zip and EdgeChromiumGPODeployment.zip in the support portal downloads?

See also: Chrome ExtensionInstallForcelist entries in the HKLM registry prevent equivalent entries in HKCU key path from functioning

See also: Incidents generated by Endpoint Prevent Chrome / Edge HTTPS monitor display the URL as 'Unknown'


Please note, as of DLP 16.0 it will be expected behavior to see duplicate registry entries