Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

deploying firefox-add-ons via group policies doesn't work anymore after proxy-change

  • 11 majibu
  • 0 wana tatizo hili
  • 1 view
  • Last reply by mozilla355

more options

Hello,

I used to deploy add-ons via group policies - this worked like a charm: Firefox esr (91.11.0esr x64), ADMX-templates in Sysvol\PolicyDefinitions, Group Policies: User configuration, administrative templates, mozilla, firefox, add-ons --> install add-ons --> https://addons.mozilla.org/firefox/downloads/file/1234567/goodaddon-1.0.01.xpi

A few months ago, we had to change our network-configuration. We were using a proxy before, but our proxy had direct access to the internet. Now our proxy forwards everything to another proxy. Since about that time, add-on-deployment via gpo doesn't work anymore. It could be something else, but i suspect the proxy-change.

I tried to deploy unc-paths, internal websites and different syntaxes; none of this works:

  • http://192.168.100.10/goodaddon-1.0.01.xpi
  • http://internalwebsite/goodaddon-1.0.01.xpi
  • https://192.168.100.10/goodaddon-1.0.01.xpi
  • https://internalwebsite/goodaddon-1.0.01.xpi
  • \\192.168.100.20\netshare\goodaddon-1.0.01.xpi
  • \\internalfileserver\netshare\goodaddon-1.0.01.xpi
  • file://///192.168.100.20/netshare/goodaddon-1.0.01.xpi
  • file://///internalfileserver/netshare/goodaddon-1.0.01.xpi

As you can see I tried using internal sites, so that no proxy would be needed. And I also added these sites to the allowed add-on-installation-sites (computer configuration, same group policy). The sites are all accessible; if I enter these addresses as url, firefox can access the xpi-file.

I know how to pack add-ons into the firefox-setup-file; that still works. But first of all, firefox is already installed on most of my clients. Second, after a fresh installation of firefox with this self-created package, all add-ons are installed, but not activated. And I would like to restrict activation/deactivation of add-ons via gpo.

  1. 1 Are there other ways to deploy add-ons in a domain-network (e.g. script-based)?
  2. 2 Are there any logs where I could find out what exactly goes wrong?
  3. 3 Are there any other syntaxes I could try (group policy urls)?
  4. 4 Can anyone guess what the problem is (why it is not working anymore)?

Help would be very much appreciated.

Best regards.

Hello, I used to deploy add-ons via group policies - this worked like a charm: ''Firefox esr (91.11.0esr x64), ADMX-templates in Sysvol\PolicyDefinitions, Group Policies: User configuration, administrative templates, mozilla, firefox, add-ons --> install add-ons --> https://addons.mozilla.org/firefox/downloads/file/1234567/goodaddon-1.0.01.xpi'' A few months ago, we had to change our network-configuration. We were using a proxy before, but our proxy had direct access to the internet. Now our proxy forwards everything to another proxy. Since about that time, add-on-deployment via gpo doesn't work anymore. It could be something else, but i suspect the proxy-change. I tried to deploy unc-paths, internal websites and different syntaxes; none of this works: * http://192.168.100.10/goodaddon-1.0.01.xpi * http://internalwebsite/goodaddon-1.0.01.xpi * https://192.168.100.10/goodaddon-1.0.01.xpi * https://internalwebsite/goodaddon-1.0.01.xpi * \\192.168.100.20\netshare\goodaddon-1.0.01.xpi * \\internalfileserver\netshare\goodaddon-1.0.01.xpi * file://///192.168.100.20/netshare/goodaddon-1.0.01.xpi * file://///internalfileserver/netshare/goodaddon-1.0.01.xpi As you can see I tried using internal sites, so that no proxy would be needed. And I also added these sites to the allowed add-on-installation-sites (computer configuration, same group policy). The sites are all accessible; if I enter these addresses as url, firefox can access the xpi-file. I know how to pack add-ons into the firefox-setup-file; that still works. But first of all, firefox is already installed on most of my clients. Second, after a fresh installation of firefox with this self-created package, all add-ons are installed, but not activated. And I would like to restrict activation/deactivation of add-ons via gpo. #1 Are there other ways to deploy add-ons in a domain-network (e.g. script-based)? #2 Are there any logs where I could find out what exactly goes wrong? #3 Are there any other syntaxes I could try (group policy urls)? #4 Can anyone guess what the problem is (why it is not working anymore)? Help would be very much appreciated. Best regards.

Chosen solution

First: if I use the computerpart of the group policy, the deployment works. So that solves my problem.

Concerning answer 1: If you don't mind answering another question: I was using solution 1 (deploying firefox with extensions), but those extensions were only installed and not activated. If I forbid users to install/uninstall/activate/deactivate extensions, this solution doesn't work. Is there a way to deploy AND activate them using these packed setups?

Concerning answer 4: THANKS A LOT for the about:policies-tip. Didn't know that one. As I checked I thought: that's odd, I can see my deployment-settings in gpupdate /h but I cannot find them in about:policies. Still not sure why. But that's when I had the idea to check out the computerpart of the group policy, which worked. As I said: not sure why. The deployment via userpart of the gpo used to work. Don't know if this is a bug in later 90-firefox-versions or if others can reproduce this behaviour.

Anyhow, right now my problem is solved. Thanks!

Read this answer in context 👍 0

All Replies (11)

more options

I don't have problems with a specific add-on. I'm having problems deploying any add-on using firefox-admx-templates and group policies.

So my problem is the add-on-deployment-functionality of firefox (or the administration of add-ons in a business environment).

more options

Let's say you are an administrator of a company with 500 clients. Your want all clients to have firefox. You want all clients to have an adblocker, a scriptblocker, a cookieblocker and a https-redirector. You also want to prevent users from installing add-ons and from disabling the add-ons you provided.

How would you do that?

I did it using admx-templates and group policies. This used to work. Now it doesn't anymore. I suspect it has something to do with the new proxy-structure. Maybe the group-policy tries to download and install the add-ons, but cannot access the download-site.

But a) we had a proxy before and b) our firefox-installations can easily access the internet.

So: this is a question regarding the administration of firefox-add-ons. Not a question regarding one specific add-on.

more options

You'll find the group-policy-settings attached. These are the settings that used to work.

more options

I understand that some might think that the question described here is a problem of our Windows server environment and that the Mozilla forum is not the right place.

But what is in any case an important question for the Mozilla forum: how can add-ons be distributed and managed centrally? This question has nothing to do with our server environment and is relevant for all administrators who want to use Firefox in a business environment.

And here the questions arise: 1. are there other ways besides distribution via GPO (if so, which ones)? 2. what syntax is to use when distributing via GPO (e.g. can you use UNC paths and if so, how)? 3. are there any other requirements for distribution via GPO (e.g. if using a proxy server)? 4. if distribution via GPO does not work, is it possible to view any log files that give more information about the error?

more options

1. are there other ways besides distribution via GPO (if so, which ones)?

You could put them in a distribution directory in Firefox:

https://support.mozilla.org/en-US/kb/deploying-firefox-with-extensions

But what you're doing should work.

2. what syntax is to use when distributing via GPO (e.g. can you use UNC paths and if so, how)?

You can use file:// URLs which do allow UNC paths (assuming you are using the ExtensionSettings policy)

https://github.com/mozilla/policy-templates/blob/master/README.md#extensionsettings

3. are there any other requirements for distribution via GPO (e.g. if using a proxy server)?

No, there shouldn't be. We just grab the URL and install from it.

4. if distribution via GPO does not work, is it possible to view any log files that give more information about the error?

IF you go to about:policies, it should show the reason that the install failed. There also might be something if you bring up the JS console (Ctrl+Shift+J).

I'd love to work with you directly to solve this. If you don't want to continue here, you can reach me as mkaply at mozilla.com

more options

Suluhisho teule

First: if I use the computerpart of the group policy, the deployment works. So that solves my problem.

Concerning answer 1: If you don't mind answering another question: I was using solution 1 (deploying firefox with extensions), but those extensions were only installed and not activated. If I forbid users to install/uninstall/activate/deactivate extensions, this solution doesn't work. Is there a way to deploy AND activate them using these packed setups?

Concerning answer 4: THANKS A LOT for the about:policies-tip. Didn't know that one. As I checked I thought: that's odd, I can see my deployment-settings in gpupdate /h but I cannot find them in about:policies. Still not sure why. But that's when I had the idea to check out the computerpart of the group policy, which worked. As I said: not sure why. The deployment via userpart of the gpo used to work. Don't know if this is a bug in later 90-firefox-versions or if others can reproduce this behaviour.

Anyhow, right now my problem is solved. Thanks!

more options

> Is there a way to deploy AND activate them using these packed setups?

If you put them in the distribution directory, they are enabled. It's only if you use other sideloading methods (registry for example), that they are disabled by default. And we don't provide a way to enable in that case.

In my testing, Intune policies take forever to come down, even with gpupdate. If the entries are in the registry and we aren't reading them, that would be a bug, but usually what I find is that haven't made it there for some reason.

As far as user/computer goes, we definitely do both, but if you have computer, we don't read user at all. We don't combine them. (this is consistent with other Windows applications).

more options

> If you put them in the distribution directory, they are enabled

Ok, I will check that out, if the gpo-deployment fails again. What we did before, was repackaging the Setup.exe (https://support.mozilla.org/en-US/kb/repackaging-windows-installer). This way, the add-ons were definetively not activated.

> As far as user/computer goes, we definitely do both, but if you have computer, we don't read user at all. We don't combine them. (this is consistent with other Windows applications).

We are using one gpo for all firefox-settings. All settings were configured in the user-configuration. The computer-configuration was deactivated. So there were no contradicting settings in both configurations. As I said, it used to work in the user-configuration, now it only works in the computer-configuration (I moved the add-on-part into the computer-configuration).

Anyhow, I was just mentioning it in case this behaviour is reproduceable. If this problem only occurs in my network, well, so be it, I have a workaround.

Cheers.

more options

PS: We don't deploy registry-settings via gpo. We only use the gpo-settings provided with the admx-template.

more options

I'm wondering if the problem is that there is an empty key in computer and so we're not reading some user settings?

If this does happen again, can you check

HKEY_CURRENT_USER\Software\Policies\Mozilla and HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Mozilla

and see if both have values?

more options

That's good advice (checking Software\Policies). Should have thought of that myself...