Is it really safe to leave legacy/32bit profiles and upgrade firefox to
64bit in a classroom or hotdesk environments ?
I'm worried about what happens to an upgraded environment when some
but not all machines are reinstalled, so all machines have the same
64bit version of the firefox binaries installed, but profile and
install dirs are a mixture of legacy/32bit and 64bit ?
On Fri, 13 Nov 2020, Mike Kaply wrote:
In your case, I would just set legacy profiles and leave it. For 99.9% of
users, that's fine. For technical users that use developer edition, they
can create a new profile.
Mike
On Thu, Nov 12, 2020 at 6:29 PM Verstraete, John <
extern.john.verstra...@vw.com> wrote:
I would have to agree with Andrew on this, we are also going from 32bit to
64bit and the profile migration is a real sticking point. I understand
having a different profile for different versions installed but the profile
migration piece should be a smoother process, imagine telling 10,000 users
to migrate their own profiles using about:profiles. There has to be a
better way from Mozilla to overcome this issue.
-----Original Message-----
From: Enterprise <enterprise-boun...@mozilla.org> On Behalf Of Andrew J.
Buehler
Sent: Wednesday, November 11, 2020 9:40 PM
To: enterprise@mozilla.org
Subject: [From: External] Re: [Mozilla Enterprise] Import legacy profile,
but use per-installation profiles thereafter?
On 2020-11-11 at 10:45, Mike Kaply wrote:
When we upgrade or install 64 bit Firefox, if a 32 bit Firefox is
there, we use the same directory.
So my recommendation would be that you not uninstall and then
reinstall, but simply install or let the upgrades happen.
Unfortunately, that would A: leave 64-bit Firefox installed in the 32-bit
program hierarchy, which is undesirable just on general principles, and B:
mean that machines which got a clean install would have Firefox installed
under a different path from machines which got upgraded, which is
undesirable not only from general principles but also because it would make
managing configuration and uninstalls and the like harder (which path do we
need to install distribution\policies.json under? which path do we need to
look under to trigger the uninstall helper? etc.).
I can see why people might choose to go this route, but it really does not
sit well with me.
Unfortunately Windows didn't make this situation easy.
From my perspective, at least at a glance, Windows' contribution to the
situation seems relatively minor.
It also seems to me as if it shouldn't be too difficult to implement the
behavior I'd prefer within Firefox, relative to the behaviors that already
exist; it just apparently hasn't been done. That's a moot point for the
case at hand, because my organization isn't going to wait for a new Firefox
release before upgrading even if that new release would include this
behavior, but it could still be helpful for others.
What we'll probably wind up doing is setting the "use legacy profiles"
flag, running with that for a year or three, and then eventually turning
it off and fixing up any broken profiles that get discovered after that
point manually. That's far from ideal, both because of the risk of having
those broken profiles and because we'll be locked out of
profile-per-install for that long, but it's probably the best we're going
to be able to manage.
I do also still think that a way to explicitly tell Firefox to import a
specific existing profile's contents into the current (new) profile would
be useful, including in other contexts.
--
Andrew J. Buehler
--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk
_______________________________________________
Enterprise mailing list
Enterprise@mozilla.org
https://mail.mozilla.org/listinfo/enterprise
To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise
or send an email to enterprise-requ...@mozilla.org with a subject of
"unsubscribe"
