Skip to content

How to manage Google Chrome extensions and apps with ease

Brigg Angus headshot
Brigg Angus|February 24, 2017
Enforcing Execution of Browser Extensions Explicitly
Enforcing Execution of Browser Extensions Explicitly

Given the Cisco WebEx Browser Extension Vulnerability, and the resultant hours of near-terror that ensued, you might be wondering how you can better manage browser extensions for your users.

Many of you asked, “Does PDQ manage extensions?” The short answer is no, we don’t manage browser extension easily. Like most things, using the right tools will often result in more expedient, easily managed solutions. Group Policy (GPO) is that tool.

The included instructions are for Google Chrome. Like Internet Explorer, Chrome is an enterprise browser. We’ll tackle handling add-ons for IE in a (near) future blog post.

Extension management for Chrome

If you don’t already have them, get the ADM* files for Chrome, which can be downloaded here. Import the ADMX and ADML files into your GPO schema (I use the central store for all Administrative Templates).

Assuming you’ve imported the ADMX/ADML files properly and opened the GPMC again, you’ll see Computer Configuration > Policies > Administrative Templates > Google > Google Chrome. This is where the magic happens. Navigate to Extensions and you’ll see something like this:


Here is where we make a decision between whether we want to blacklist or whitelist Chrome extensions. My preference is to whitelist since there are far more extensions I don’t want to allow than those I do. It’s a lot easier to stay on top of what extensions are needed than to filter what could be harmful, hurt compliance, end Western Civilization as we know it, or cause other unintended difficulties.

Before we whitelist, we need to get the Chrome extension ID. The easiest way to do this is to go to the Google Chrome Web Store and search for the extensions you want to allow.

For this example, I’m going to whitelist the following extensions:

  • uBlock Origin

  • Privacy Badger

  • Office Online

  • Google Hangouts

To get the extension ID, search for the extension, select the extension from the results and the ID will appear in the address bar:




In this case, my extension IDs are as follows:

uBlock Origin = cjpalhdlnbpafiamejdnhcphjbkeiagm Privacy Badger = pkehgijcmpdhfbdbbnkijodmdjhbjlgp Office Online = ndjpnladcallmjemlbaebfadecfhkepb Google Hangouts = nckgahadagoaajjgafhacjanaoiihapd

The next step, and by far the easiest and most fun, is to blacklist everything. In your GPO, navigate to Computer Configuration > Policies > Administrative Templates > Google > Google Chrome > Extensions and open Configure extension installation blacklist. Enable the policy, click “Show” in the Options section, and use the * (wildcard) as the value:


At this point, all extensions are now blacklisted. If you were to apply this GPO to the domain, site, or OU, all impacted Chrome instances would no longer have any available extensions, even if previously installed by the user. Likewise, the user would be unable to install any extensions.

To avoid the angry, pitchfork wielding mob of users storming through your office gate, create a whitelist of extensions to appease the Great Unwashed. We’ll whitelist the following: uBlock Origin, Privacy Badger, Office Online, and Google Hangouts in Computer Configuration > Policies > Administrative Templates > Google > Google Chrome > Extensions and open Configure extension installation whitelist.

The process is the same for configuring the blacklist. Enable the policy, then configure the extension IDs to exempt from the blacklist.


When viewing the policy settings, you should now see the wildcard blacklist and all of the whitelisted extensions IDs like:


Now, prior to applying the GPO, let’s go back to our user. If we have a look at Nigel’s Chrome extensions, we see:


As a test, apply the GPO, and do it with some force, using the Remote Command tool from PDQ Inventory:


In remote command, simply run gpupdate or gpupdate /force.

After we’ve confirmed the test is successful, update all your machines (prior to the GPO actually taking effect), by deploying a GPUpdate package:


On the target machine (Nigel’s), we left Chrome open. No reason to close it down, as the GPO will apply the appropriate settings while the process runs. This is the result:


And what happens when a user tries to install an extension that’s not whitelisted?


But really, we don’t even want users to go to the extension store at all. So, we go back to our GPO and edit the Computer Configuration > Policies > Administrative Templates > Google > Google Chrome > Extensions, and open the Configure the list of force-installed apps and extensions policy. Enable the policy and choose the whitelisted extension IDs and update URL.

Typically, the install/update URL is going to be You can check the Update URL by going to:

%USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\Extensions\[Extension ID]\[Extension Version]\manifest.json

Check for the following line (in this example, the URL is

"update_url": ""

The entry in the GPO follows this:

[Extension ID];[URL] (no spaces and don’t forget the semicolon)

For example:


Now update the GPO on your target machines by testing with PDQ Inventory (if desired) and then deploying with PDQ Deploy.



In testing this process, a restart of Chrome was necessary for some extension installations. In others, it required a reboot of the machine. Unlike certain user-initiated extension installations, this does not store the extension information in the registry. Instead, the information is stored in: %USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\Extensions\[Extension ID].If you use the Configure the list of force-installed apps and extensions setting, you don’t need to whitelist those extensions. It’s a good idea, but the force-installed extensions overrides blacklists and whitelists. That means you can force-install some extensions, but have others that are optional the user can choose to install if needed via the Google Web Store.

Brigg Angus headshot
Brigg Angus

Invented in the late 1900s, Brigg was an early utilizer of technology one finds in museums. After conquering Canada, he schlepped out technical support for Windows 95 & 98 while learning non-Windows systems. After a series of SysAdmin jobs spanning near-decades, his fossilized remains landed at PDQ, where he has served on occasion as a "resident expert" and deranged webcast personality on PDQ that airs each Thursday on YouTube. Brigg currently resides in Salt Lake with a fish and a plant. He holds a license to practice Active Directory and is board certified in the DNS arts.

Related articles