I am not a powershell person and this piece of the script was created by a
co-worker. It almost works but there is something missing and we are having an
issue getting it to work completely, I have posted it below but to be honest it
would be nice if Mozilla provided an automated way to do this themselves other
than instructing users to go to about:profiles or for admins to hokey pokey
install Firefox to get it to work and when I say hokey pokey it includes
running the environment variable or group policy for legacy profiles. If
someone perfects this script let me know it would be handy to accomplish the
task at hand to migrate profiles from 32bit to 64 bit installations. It may
have to do with multiple profiles from past installations, I show 3 in my
profiles.ini and those same three under the profiles folder.
In our testing it most of the time migrates the profile, other time it will not
and we have to remote in and go to about:profiles to get their profile back and
sometimes it will prompt the user on opening Firefox to choose their default
profile. This is why I say it is not perfect but gets most of the way there.
$users = Get-ChildItem -Path "C:\Users" -Exclude 'Administrator','Public'
# Loop through users and delete the file
$users | ForEach-Object {
If (Test-Path "C:\Users\$($_.Name)\AppData\Roaming\\Mozilla\Firefox\"){
Get-Content -Path
"C:\Users\$($_.Name)\AppData\Roaming\Mozilla\Firefox\installs.ini" |
ForEach-Object {
if ($_.StartsWith('Default=Profiles/')) {
$profilePath =
"\Mozilla\Firefox\Profiles\$($_.Replace('Default=Profiles/', ''))"
}
}
$fullprofilepath = "C:\Users\$($_.Name)\AppData\Roaming$profilePath"
#test of datestime string write host
$DateStringF1 = (Get-Date).ToString('dd_MM_yyyy mm')
write-host $DateStringF1 datestring test
write-host Checking for folder at C:\Users\$($_.Name)\FirefoxBackup
-ForegroundColor Cyan
if (!(Test-Path -path C:\Users\$($_.Name)\FirefoxBackup)) {New-Item
C:\Users\$($_.Name)\FirefoxBackup -Type Directory}
#If it already has Firefox folder, then rename with date stamp and
create new folder
Else {Rename-Item -Path C:\Users\$($_.Name)\FirefoxBackup -NewName
"FirefoxBackup $DateStringF1"} & New-Item C:\Users\$($_.Name)\FirefoxBackup
-Type Directory -ErrorAction SilentlyContinue
start-sleep -s 2
#start of copy to $fullprofilepath
write-host Copying files from $fullprofilepath to
C:\Users\$($_.Name)\FirefoxBackup -ForegroundColor White
Copy-Item $fullprofilepath -Destination
C:\Users\$($_.Name)\FirefoxBackup -Force -Recurse
#import profile
write-host Import new profile files C:\Users\$($_.Name)\FirefoxBackup
$fullprofilepath!!!!! -ForegroundColor Green
if (!(Test-Path -path "$fullprofilepath 64bit")) {New-Item
"$fullprofilepath 64bit" -Type Directory}
$New64BitProfile = "$fullprofilepath 64bit"
write-host new path $New64BitProfile
<#
cert9.db (cer8.db in Firefox 57 and below) (pkcs11.txt has replaced
secmode.db; do not transfer)
chromeappsstore.sqlite (deprecated)
content-prefs.sqlite
cookies.sqlite
favicons.sqlite (Firefox 55 and above)
formhistory.sqlite
handlers.json (mimeTypes.rdf in Firefox 54 and below; bug 1287658)
key4.db (key3.db in Firefox 57 and below)
logins.json (Firefox 32 and above)
permissions.sqlite
persdict.dat
places.sqlite
sessionstore.js (Firefox 55 and below; can be used as a fallback)
sessionstore.jsonlz4 (Firefox 56 and above)
webappsstore.sqlite
signons.sqlite (Firefox 31 and below; can be used as a fallback,
signon.importedFromSqlite; bug 1013947)
signons3.txt (Firefox 26 and below; bug 717490; bug 925101)
Folders:
bookmarkbackups
chrome (if it exists)
searchplugins (Firefox 44 and below)
sessionstore-backups folder
#>
Copy-Item $fullprofilepath\cert9.db -Destination
$New64BitProfile -ErrorAction SilentlyContinue
Copy-Item $fullprofilepath\cert8.db -Destination
$New64BitProfile -ErrorAction SilentlyContinue
Copy-Item $fullprofilepath\chromeappsstore.sqlite -Destination
$New64BitProfile -ErrorAction SilentlyContinue
Copy-Item $fullprofilepath\content-prefs.sqlite -Destination
$New64BitProfile -ErrorAction SilentlyContinue
Copy-Item $fullprofilepath\cookies.sqlite -Destination
$New64BitProfile -ErrorAction SilentlyContinue
Copy-Item $fullprofilepath\favicons.sqlite -Destination
$New64BitProfile -ErrorAction SilentlyContinue
Copy-Item $fullprofilepath\formhistory.sqlite -Destination
$New64BitProfile -ErrorAction SilentlyContinue
Copy-Item $fullprofilepath\handlers.json -Destination
$New64BitProfile -ErrorAction SilentlyContinue
Copy-Item $fullprofilepath\key4.db -Destination
$New64BitProfile -ErrorAction SilentlyContinue
Copy-Item $fullprofilepath\key3.db -Destination
$New64BitProfile -ErrorAction SilentlyContinue
Copy-Item $fullprofilepath\logins.json -Destination
$New64BitProfile -ErrorAction SilentlyContinue
Copy-Item $fullprofilepath\permissions.sqlite -Destination
$New64BitProfile -ErrorAction SilentlyContinue
Copy-Item $fullprofilepath\persdict.dat -Destination
$New64BitProfile -ErrorAction SilentlyContinue
Copy-Item $fullprofilepath\places.sqlite -Destination
$New64BitProfile -ErrorAction SilentlyContinue
Copy-Item $fullprofilepath\sessionstore.js -Destination
$New64BitProfile -ErrorAction SilentlyContinue
copy-Item $fullprofilepath\sessionstore.jsonlz4 -Destination
$New64BitProfile -ErrorAction SilentlyContinue
Copy-Item $fullprofilepath\webappsstore.sqlite -Destination
$New64BitProfile -ErrorAction SilentlyContinue
Copy-Item $fullprofilepath\bookmarkbackups -Destination
$New64BitProfile -Force -Recurse -ErrorAction SilentlyContinue
Copy-Item $fullprofilepath\chrome -Destination $New64BitProfile
-Force -Recurse -ErrorAction SilentlyContinue
Copy-Item $fullprofilepath\sessionstore-backups -Destination
$New64BitProfile -Force -Recurse -ErrorAction SilentlyContinue
Copy-Item $fullprofilepath\pkcs11.txt -Destination
$New64BitProfile -ErrorAction SilentlyContinue
$InstallfilePath =
"C:\Users\$($_.Name)\AppData\Roaming\Mozilla\Firefox\installs.ini"
$ProfilefilePath =
"C:\Users\$($_.Name)\AppData\Roaming\Mozilla\Firefox\profiles.ini"
$cut = "\Mozilla\Firefox\Profiles\"
$zero = ""
$shortprofilename = $profilepath.Replace($cut, $zero)
write-host shortprofilename = $shortprofilename
-ForegroundColor Red
$64bit_Add_To_Install = "
[308046B0AF4A39CB]
Default=Profiles/$shortprofilename 64bit
Locked=1
"
$64bit_Add_To_Profile = "
[Install308046B0AF4A39CB]
Default=Profiles/$shortprofilename 64bit
Locked=1
[Profile2]
Name=default-esr-1
IsRelative=1
Path=Profiles/$shortprofilename 64bit
"
start-sleep -s 2
Add-Content -Path $InstallFilePath -Value $64bit_Add_To_Install
start-sleep -s 2
Add-Content -Path $ProfileFilePath -Value $64bit_Add_To_Profile
}
From: Mike Kaply <mka...@mozilla.com>
Sent: Friday, November 13, 2020 12:48 PM
To: Andrew C Aitchison <and...@aitchison.me.uk>
Cc: Verstraete, John <extern.john.verstra...@vw.com>; enterprise@mozilla.org
Subject: Re: [Mozilla Enterprise] [From: External] Re: Import legacy profile,
but use per-installation profiles thereafter?
On Fri, Nov 13, 2020 at 11:28 AM Andrew C Aitchison
<and...@aitchison.me.uk<mailto:and...@aitchison.me.uk>> wrote:
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 ?
There's no difference in the profile data between 32 bit and 64 bit Firefox.
The only reason we consider them different profiles in the newer versions of
Firefox is that we key off the directory name where Firefox was installed, and
on Windows 64 bit and 32 bit are different directories.
Mike
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<mailto: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<mailto:enterprise-boun...@mozilla.org>> On
>> Behalf Of Andrew J.
>> Buehler
>> Sent: Wednesday, November 11, 2020 9:40 PM
>> To: enterprise@mozilla.org<mailto: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<mailto: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"
