<div dir="ltr"><div>Coexisting policies.json and GPO is high on my list and I am trying to get it in before the next major ESR.</div><div><br></div><div>Unfortunately the only other solution I have involves ignoring GPO completely in favor of policies.json and that doesn't help you.</div><div><br></div><div>What is your timeline?</div><div><br></div><div>Mike<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 21, 2021 at 2:05 PM Andrew J. Buehler <<a href="mailto:wanderer@fastmail.fm">wanderer@fastmail.fm</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA512<br>
<br>
My organization is (still) in the process of preparing to migrate from<br>
an older Firefox ESR to the current ESR, and is planning to migrate from<br>
32-bit Firefox to 64-bit Firefox in the process. This latter means that<br>
we're hitting the "profile per install" transition which comes along<br>
with the install-location change inherent to Windows' install-location<br>
handling. (We are not going to override that and install the 64-bit<br>
program under the 32-bit path.) We therefore need to tell Firefox to not<br>
use profile-per-install, and continue with legacy profiles.<br>
<br>
<br>
As I understand matters, the policy settings for disabling<br>
profile-per-install in favor of legacy profiles do not work when<br>
specified in policies.json; they only work when specified via Group<br>
Policy or via the launch-time MOZ_LEGACY_PROFILES environment variable.<br>
(At least on Windows, I haven't investigated other platforms recently<br>
enough to recall.)<br>
<br>
For reasons which don't bear going into, I would prefer to handle as<br>
much policy configuration as possible via policies.json, rather than via<br>
Group Policy.<br>
<br>
I did all of my initial profiles- and policies-related testing with the<br>
environment variable, for convenience, and got to a point where things<br>
were working fine. I then switched to testing with the Registry entry<br>
which corresponds to the Group Policy setting [1], and rather to my<br>
surprise, all of the policy settings which I had been configuring<br>
through policies.json were suddenly being ignored.<br>
<br>
After a bit of searching, I found [2], which points out that - as I had<br>
just run into - when the Registry key where the Group Policies are to be<br>
specified exists, policies.json is ignored. I don't recall seeing that<br>
documented anywhere, but it's possible I just missed noticing it.<br>
<br>
<br>
This seems to mean we can't use a combination of these approaches; it's<br>
either all policies.json or all Group Policy. Unfortunately, that in<br>
turn seems to mean that we have to A: find a way to deploy that<br>
environment variable so that it's reliably in effect before the new<br>
Firefox version gets launched, B: abandon the use of policies.json<br>
entirely in favor of Group Policy, or C: abandon our hopes of retaining<br>
our users' existing Firefox profiles.<br>
<br>
A would be relatively impractical, given the limitations of the various<br>
methods (that I know of) for automatically deploying<br>
environment-variable settings - most prominently, that none of them seem<br>
to take effect before the next Windows logon, so we couldn't just push<br>
out the environment variable alongside the Firefox install. The same<br>
point would make it equally difficult to revert the setting later on.<br>
<br>
B would be undesirable for internal reasons, which - as I said - don't<br>
bear going into (although I can summarize them if needed).<br>
<br>
C would be problematic; it's unlikely that the existing Firefox users<br>
would be OK with their profiles disappearing from under their feet.<br>
<br>
Any suggestions for a way out of this tangle?<br>
<br>
<br>
The ideal solution would of course be to dodge around the issue, by<br>
avoiding the need for us to disable profile-per-install at all. I have a<br>
few possible design arrangements in mind that would probably make that<br>
viable, but lack the spoons to push for them in a filed bug unless I<br>
could be confident that doing so would bear fruit, and in any case they<br>
wouldn't make it into an ESR release in time for me to meet my<br>
deployment time-frames.<br>
<br>
The next best solution would be for the "legacy profiles" policy setting<br>
to work when specified via policies.json. However, if doing that were an<br>
option, it would clearly have been done that way to begin with; since it<br>
wasn't, I mention it only to be comprehensive.<br>
<br>
The third-best solution would probably be for it to be possible to<br>
mix-and-match policies.json with Group Policy configuration. However,<br>
given that it wasn't done that way to start out with, I rather doubt<br>
that's going to happen at this point - and even if it does happen at<br>
some point, the same "probably won't make it into the ESR in time"<br>
applies.<br>
<br>
If anyone can suggest any other solutions, I'd be glad to hear them.<br>
<br>
<br>
[1] HKLM\SOFTWARE\Policies\Mozilla\Firefox\LegacyProfiles REG_DWORD:1<br>
<br>
[2]<br>
<a href="https://community.spiceworks.com/topic/2247157-firefox-ignoring-policies-json-when-registry-path-is-created" rel="noreferrer" target="_blank">https://community.spiceworks.com/topic/2247157-firefox-ignoring-policies-json-when-registry-path-is-created</a><br>
<br>
- -- <br>
  Andrew J. Buehler<br>
<br>
-----BEGIN PGP SIGNATURE-----<br>
<br>
iQJJBAEBCgAzFiEEJCOqsZEc2qVC44pUBKk1jTQoMmsFAmAJ3pAVHHdhbmRlcmVy<br>
QGZhc3RtYWlsLmZtAAoJEASpNY00KDJrEhEP/3yZODmmNkAIuYPqBodFsCxGngtb<br>
Xv++JhqgctO8WuJ1XBT2j3IsWaTSYbHx05EIo6wSNTQaMJICE7TISh1Cw9xU/YXf<br>
lShbyDLj3pLnQhnUg1lmQKkbMN4aCD18w9EwuqKkx9eGwrZ4DYNDpU5HLUjZ+ms+<br>
ICBpTfCTnNbCAsosUuy+lBEhyEageju6a4KDzhgCieTB3slf5bzryaqtQ9hcjW/W<br>
0Vz+wePs1uZEyPEpDYxI0vMtkTJliAGY0Bz1fkcxZ6IXsMPu01eXd55qwfuz8mNM<br>
eJWo5a84gsBofdNeN0LwoxF5Af6Fs8cakyheQD25Ejiv98HKGnmZHbFbHDwj0y9h<br>
H5Qcud+rLA9EQPbryEOqB658vhzLOtrd/MHILcrmHbD/4rFjeTddErThKk7mGMa6<br>
SoqJulmpjrGrumT+m4TKoiLJaa1kQvGhk5LzAD0bSHbiW/SmZ4XFUrmqnTO7+SlS<br>
1E/N8mh25WNOUH+MrfCzQ3z1LCZBinAHb42z0rfqhkAErSzZS0C9UP0q8SMJ9e0a<br>
wMQ1v0idv4J+Sqp7lD/dJZ1GCsBvSU8xh0iDdWDKzL/kDTNaUSzgtlRaqg1OuLMB<br>
oTTXxEX2nOsQYZYvbGByr7Qn+/jEh+tlqiRWf+jkGPD4yXa7ytAsu7SxKjM4wmCG<br>
dYG1EAi+76/gq6He<br>
=6Z4T<br>
-----END PGP SIGNATURE-----<br>
_______________________________________________<br>
Enterprise mailing list<br>
<a href="mailto:Enterprise@mozilla.org" target="_blank">Enterprise@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/enterprise" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/enterprise</a><br>
<br>
To unsubscribe from this list, please visit <a href="https://mail.mozilla.org/listinfo/enterprise" rel="noreferrer" target="_blank">https://mail.mozilla.org/listinfo/enterprise</a> or send an email to <a href="mailto:enterprise-request@mozilla.org" target="_blank">enterprise-request@mozilla.org</a> with a subject of "unsubscribe"<br>
</blockquote></div>