<div dir="ltr"><div>When we upgrade or install 64 bit Firefox, if a 32 bit Firefox is there, we use the same directory.</div><div><br></div><div>So my recommendation would be that you not uninstall and then reinstall, but simply install or let the upgrades happen.</div><div><br></div><div>Unfortunately Windows didn't make this situation easy.</div><div><br></div><div>Mike<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 10, 2020 at 6:19 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>
(TL:DR; How to use LegacyProfiles only for the initial run, to migrate<br>
the old profile's data into the new install, and let people use<br>
profile-per-install after that?)<br>
<br>
<br>
For reasons which don't bear going into, my organization is only now<br>
initiating the upgrade process from Firefox ESR 52 to a newer version<br>
(ESR 78). We are, at the same time, also transitioning from 32-bit to<br>
64-bit Firefox - or at the very least, we would like to do so.<br>
<br>
However, this combination - plus Windows' segregation of 32-bit and<br>
64-bit programs into different path hierarchies, and the established<br>
practice of uninstalling old Firefox versions before installing new<br>
ones, as I understand is recommended - means that we're also hitting the<br>
"profile per install" transition, and without further action our users<br>
will lose access to the contents of their established Firefox profiles.<br>
<br>
Our users do not necessarily have Firefox accounts, and cannot<br>
reasonably be expected to create them for the purpose of upgrading<br>
(never mind what happens if they didn't create one before the upgrade<br>
went through), so restoring data from a previous Firefox via Firefox<br>
Sync - as is suggested by the "Important News" page that appears on<br>
first launching Firefox after the upgrade - is not an option.<br>
<br>
- From what I've read (both documentation and conversations), I gather<br>
that the established way to move forward on this for enterprises is the<br>
MOZ_LEGACY_PROFILES environment variable and/or the LegacyProfiles<br>
policy setting, to continue using the established single profile.<br>
However, it also looks as if the "profile per install" functionality<br>
won't be available for as long as we keep that setting in place; that<br>
wouldn't be ideal, because I can think of scenarios where being<br>
able to have two versions installed and used side-by-side could be<br>
extremely helpful, and I'd hate for us to be locked out of that<br>
indefinitely.<br>
<br>
Testing also seems to indicate that if we launch the new Firefox install<br>
for the first time using that "legacy profiles" setting, and then later<br>
launch the same install without it, the old install's profile will be<br>
retained and the generated new profile from the upgrade won't happen. In<br>
theory, that could let us thread the needle, and bring the old profile<br>
across to the profile-per-install world.<br>
<br>
<br>
However, in order to safely drop this setting and start letting people<br>
use profile-per-install, we'll have to first be sure that every profile<br>
which will need to be imported in this way has been so imported - and<br>
that will take us at least a year and another Firefox ESR upgrade, if<br>
indeed we can ever become sufficiently certain of it at all.<br>
<br>
It looks as if what I want is to have Firefox use the "import legacy<br>
profile" behavior for the first-ever run (per Windows user profile) with<br>
a version that supports profile-per-install, but not use it after that.<br>
I can imagine a contrived configuration to make sure the environment<br>
variable is set and unset properly for that, but every time I try to<br>
figure out how to create one, it quickly turns into an obvious fragile<br>
hard-to-maintain error-prone kludge.<br>
<br>
<br>
Are there any established solutions here? What are my options?<br>
<br>
I'm assuming that it would at least work to replace the contents of the<br>
new profile's directory with a copy of the contents of one from an old<br>
profile, for manual handling of special cases or backfilling if we turn<br>
off LegacyProfiles after a while and then discover profiles which hadn't<br>
been brought forward - but of course that's not a viable first default<br>
approach for an organization of any nontrivial size.<br>
<br>
<br>
I suspect I could avoid the problem for now by sticking with 32-bit<br>
Firefox (and therefore with the same installation path as before), which<br>
wouldn't be so bad at present - but that would only mean that I'd have<br>
the problem again when we eventually do migrate to 64-bit, and I expect<br>
it would be even worse at that point, because the fact that the<br>
transition to the new profile-handling model would already have been<br>
made could very plausibly mean Firefox wouldn't pick up and handle the<br>
correct profiles with the LegacyProfiles setting.<br>
<br>
Really, the ability to import a profile from another installation would<br>
be useful for that 32-bit-to-64-bit transition even more than from older<br>
to newer Firefox; it sounds to me as if it would be useful for other<br>
scenarios as well, including especially for various types of developers.<br>
I'm a little startled that I haven't found mention of any apparent<br>
established solution for doing this more generally (short of manually<br>
copying profile contents around and/or editing profiles.ini /<br>
installs.ini, which seem unwieldy and failure-prone).<br>
<br>
- -- <br>
  Andrew J. Buehler<br>
-----BEGIN PGP SIGNATURE-----<br>
<br>
iQJJBAEBCgAzFiEEJCOqsZEc2qVC44pUBKk1jTQoMmsFAl+rLgYVHHdhbmRlcmVy<br>
QGZhc3RtYWlsLmZtAAoJEASpNY00KDJrjQMP/0R1NPI9RdsiBb+B3ID4nnIy4sK5<br>
nGQDexbqnKZhQ8HSp4vNMoausjWbh87kczYBAx/fQIt8hT1eyRPnhyx6Wadi1uEN<br>
0xH9PAlQny4Z5xZT7TRxn0jOdTIE5XpcFjcVBOHLiBbc+9jeUaOUSSbZB+OtliUQ<br>
oH6R5Q1ttRTh0RLASR3xyDrObq1bOaGPHN71e8HYDnsk1sLDuJ7WAgtrmXXwhF0A<br>
hm4BIn1Zsf5vbx83KP4Iq/YMXJS1Afg07if2fxVQFtw3PoJJLZpYueb7CFiHoMLF<br>
NgS7aIziamtGye/fliBhJkPt8NMR/07mbns6tmJEZa7+96vrRhpb2EGnIQ5Mq2wL<br>
mnqY6YmHHoaUXTPmH7ZBY8qKPNaFEvScRu88PCOo9gjeENh0OO9jQqM8hHdJRd4X<br>
xwrlfS06S7sD2gUgai5Oh4cbdjfPXMmfRHBOWduni2Srhb56hJO/ZqGiism508M3<br>
QWm4Mor6obJACu5J8IZYX3VBxwpmvjDS3E2YTmuBuSqK6pXNMs6GOxjFD10tJePE<br>
IXOwQRNdJB7/mik58P98SBq84MaGU7iNHYb6zPQwa8SuQZnh0ZSMxu7z7inoaoF4<br>
EDbojfsDZpt9bWGFX740sflEgboD1gMS+2NoGlb0vMJyZTTbf17hSsaW+QqF+aMa<br>
K4vRFy+xOh7Wbhmn<br>
=m1v6<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>