Bugzilla

(In reply to Robin Steuber (they/them) [:bytesized] from comment #20)
> > I'm going to untick it, close Firefox and check if the task(s) get executed in the morning.
> 
> Unchecking that will result in the background task not updating and, eventually, the task itself being unregistered.

Looks like the Firefox Background Update task has run.
Yesterday after creation it had Last Run Result of 0x41303.
This morning it has Last Run Result of 0x0 for both tasks.
Does this mean success? If so, then unticked `Use a background service to install updates` has no effect and GPO settings override it.

(In reply to Nick Alexander :nalexander [he/him] from comment #19)
> There are lots of situations where we don't schedule background tasks; most of them aren't errors and can't meaningfully be addressed by the user.  (For example, the most common is that they're using a langpack.)  If we spam the console they'll see an "error" every time they launch Firefox.

Fundamentally I think the goal should be to simplify this functionality and remove most of the dependencies that create these situations, so that this is more streamlined, robust and easier managed. This really should work regardless of proxy settings and langpacks should be handled by the upgrade itself, rather than being an outright blocker.

Until then, I guess at the very least the following needs to be done:
* Update the GPO documentation in the URL of this bug for `BackgroundAppUpdate` to mention the 2 proxy GPO settings that also need to be enabled for it to work.
* Update the KB article in this bug's `See also` to describe 4 GPO settings that need to be enabled.
* Update ADMX descriptions for `Background updater` and `Connection Type` to mention GPO settings that also need to be enabled for them to work.
* Have `Use a background service to install updates` GUI setting being disabled by GPO like the rest of them.

Also do we really need multiple Firefox Background Update tasks created under different security contexts?
Shouldn't Mozilla Maintenance Service creating just one task under the Admin account security context be sufficient?

(In reply to Robin Steuber (they/them) [:bytesized] from comment #20)
> > I'm going to untick it, close Firefox and check if the task(s) get executed in the morning.
> 
> Unchecking that will result in the background task not updating and, eventually, the task itself being unregistered.

Looks like the Firefox Background Update task has run.
Yesterday after creation it had Last Run Result of 0x41303.
This morning it has Last Run Result of 0x0 for both tasks.
Does this mean success? If so, then unticked `Use a background service to install updates` has no effect and GPO settings override it.

(In reply to Nick Alexander :nalexander [he/him] from comment #19)
> There are lots of situations where we don't schedule background tasks; most of them aren't errors and can't meaningfully be addressed by the user.  (For example, the most common is that they're using a langpack.)  If we spam the console they'll see an "error" every time they launch Firefox.

Fundamentally I think the goal should be to simplify this functionality and remove most of the dependencies that create these situations, so that this is more streamlined, robust and easier managed. This really should work regardless of proxy settings and langpacks should be handled by the upgrade itself, rather than being an outright blocker.

Until then, I guess at the very least the following needs to be done:
* Update the GPO documentation in the URL of this bug for `BackgroundAppUpdate` to mention the 2 proxy GPO settings that also need to be enabled for it to work.
* Update the KB article in this bug's `See also` to describe the 4 GPO settings that need to be enabled.
* Update ADMX descriptions for `Background updater` and `Connection Type` to mention the GPO settings that also need to be enabled for them to work.
* Have `Use a background service to install updates` GUI setting being disabled by GPO like the rest of them.

Also do we really need multiple Firefox Background Update tasks created under different security contexts?
Shouldn't Mozilla Maintenance Service creating just one task under the Admin account security context be sufficient?