That would be via Preferences -> app.update.auto = true

• https://github.com/mozilla/policy-templates/blob/master/README.md#preferences
• https://github.com/mozilla/policy-templates/blob/master/README.md#windows-54

{
  "policies": {
    "Preferences": {
      "app.update.auto": true
    }
  }
}

Thank you for the response, while your answer is correct I'm really looking for a way to lock that setting in. Using your method a user can still go in and change it to "check for updates but let you choose when to install them"

If you use the policies.json file with the above posted policy then the pref will be locked to true.

• "Preferences": {"app.update.auto": true}

You can check this on the about:config page.

• Preference Name: app.update.auto Status: Locked Type: Boolean Value: true

It is weird (likely a bug) that you can click the second radio choice (check and choose) on the Options/Preferences page. A reload of about:about:preferences still shows that the first setting (automatically) is still selected.

(As noted in the following reply, this information is for Windows only)

At some point, app.update.auto got migrated to a wholly different implementation that doesn't use a preference but instead uses a JSON file. On mine, it's here, and set to false:

C:\ProgramData\Mozilla\updates\308046B0AF4A39CB\update-config.json

That's for the Release version. For Nightly, it's here, and set to true:

C:\ProgramData\Mozilla\updates\6F193CCC56814779\update-config.json

Newer versions of Firefox will migrate the old preference automatically, setting app.update.auto.migrated to true. After that, the preference should be ignored. (Filter about:config on up*migr to see a related preference.)

Perhaps if you clear or flip the .migrated preference then your policy could override the previous preference (saved in the JSON file) for existing installations. Of course, that still wouldn't disable the UI for changing it again, so that isn't very efficient.

As as aside, I notice I now have a vast profusion of empty folders under

C:\ProgramData\Mozilla\updates\

and I don't know why. Possibly running moz-regression? I deleted all the empty ones.

This update-config.json file in the updates folder (UpdRootD) seems to be a Windows only feature. https://dxr.mozilla.org/mozilla-release/source/toolkit/modules/UpdateUtils.jsm

See also:

• Bug 1579332 - app.update.auto set to true and locked in about:config does not lock Check box in about:preferences

(please do not comment in bug reports
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html)

When I do the radio button switching for "let me to auto" the file is created in C:\ProgramData\Mozilla\updates\308046B0AF4A39CB\update-config.json I still can't seem to lock it out but this is certainly a step in the right direction for me to at least be able to make sure all the machines are set to this easily enough.

Thank you all for the info.

I'll say it here this is a way to stop Auto Update from happening but it will check and tell you there is a update but for this options is barred from mentioning it here.

WestEnd said

I'll say it here this is a way to stop Auto Update from happening but it will check and tell you there is a update but for this options is barred from mentioning it here.

Yes, that is the exact issue: the question is how to prevent users from making this change on the Options page:

jscher2000 said

WestEnd said

I'll say it here this is a way to stop Auto Update from happening but it will check and tell you there is a update but for this options is barred from mentioning it here.

Yes, that is the exact issue: the question is how to prevent users from making this change on the Options page:

That is correct, I know how to completely disable auto update and that is how we have done things for years and we have managed the updates internally. however times have changed and now we are looking into doing the auto update route but we want to make sure they ALL get updated. And not being able to lock that option puts users at risk.

I will move the thread to Firefox for Enterprise as that forum is more suitable for this issue.