Beiträge von TK87

Zitat von .DeJaVu

Ach ja, Firefox aus dem Store wird in die Apps installiert.

Ok. Die Überprüfung, ob Firefox über den Store installiert wurde (Get-AppxPackage "*Firefox*") habe ich unter Todo ergänzt.

Zitat von .DeJaVu

Und ein System ohne bisherige Profile hat die Profile auch woanders liegen.

Wenn keine Profile vorhanden sind, erscheint ja bereits die Warnung: Firefox ist nicht installiert oder wurde noch nicht initialisiert.

Imho resultiert daraus ja bereits, dass Firefox nach der Installation auch zumindest einmalig werden muss. Ich denke es wäre auch nicht zielführend, die Anpassungen für das Profil durchzuführen, welches die Grundlage für alle neuangelegten Profile bildet.

Ich habe schon mal grob den Workflow für eine Linux-Version skizziert:

1. Prüfen ob und worüber Firefox installiert ist (repo/snap/flatpak) - und ob es mehrere Versionen gibt.
2. Prüfen, ob benötigte Pakete vorhanden sind:
   • Bei einer Firefox-Installation: wget oder curl für Download der Zip-Datei, sowie unzip oder p7zip zum extrahieren
   • Bei mehreren Firefox Installationen zusätzlich: whiptail oder dialog für die UI-Auswahl
3. Falls Pakete fehlen: Prüfe, um welche Distribution es sich handelt...
   1. Für Debian-basierte Distibutionen, Paketmanager apt-get setzen.
   2. Bei anderen Distributionen: WARNUNG: <Distribution> wird derzeit nicht unterstützt. ausgeben und Skript beenden.
      Unterstützung für weitere Distributionen wird sukzessive ergänzt:
      • Arch-basiert -> Paketmanager auf pacman
      • Suse-basiert -> Paketmanager auf zypper
      • Fedora-basiert -> Paketmanager auf dnf
   3. Fehlende Pakete über eingestelleten Paketmanager installieren
4. Falls mehrere Firefox installiert sind: UI-Auswahl
5. Prüfen, ob Firefox derzeit ausgeführt wird. Falls ja, Benutzer zum Schließen auffordern.
6. Zip herunterladen, entpacken und Dateien kopieren

Einwände/Ergänzungen/Änderungswünsche?

Zitat von .DeJaVu

Das ergibt keinen Sinn, gerade für die ESR nicht, weil die an Unternehmen gerichtet ist und die werden sicher nicht nur für den Benutzer installieren. Falls doch, grätscht der UAC dazwischen, wird verneint, was auch immer. Damit landet jede Software beim Benutzer.

Seltsamer weise hat er das bei mir in einer VM standardmäßig so gemacht, auch wenn ich den Installer neu gestartet habe. Nachdem ich Firefox jetzt dort erst noch deinstalliert habe, macht er es seit dem wieder nach C:\Program Files. Warum auch immer er beim ersten mal automatisch in das Nutzerprofil installiert hat.

Wie dem auch sei, ich denke die neue Version ist ohnehin sinniger und funktioniert dann eben auch, falls man keine Adminrechte besitzt und FF ins Profilverzeichnis installiert.

Zitat von .DeJaVu

Das ISE von Windows aufgemacht...

Mein gut gemeinter Rat: Finger weg von der ISE!

Die enthält nicht nur einige Bugs, sondern Prozesse laufen dort teilweise auch ganz anders ab, als später bei der tatsächlichen Skriptausführung. Oft genug erlebt, dass Skripte entweder in der ISE funktionieren, im normalen Betrieb jedoch nicht oder umgekehrt (oder die UI's einfach völlig anders aussehen). Wozu eine IDE gut sein soll, die anders funktioniert, als das spätere Produktivsystem, weiß nur Microsoft allein...

Auch das aktuelle Skript würde z.B. in der ISE nicht fehlerfrei funktionieren, da ich am Ende die beliebige Taste zum fortsetzen über die Konsole einlese - die ISE besitzt jedoch keine Konsole.

Zitat von .DeJaVu

Ob die Taskbarids entfernt werden, müsste ich gleich noch mal testen. Ja, wird entfernt* mit der regulären Deinstallation aus demselbigen Ordner.

Ja, habe ich auch festgestellt. Allerdings benötigen wir die DisplayName-Eigenschaft ja ohnehin für die UI-Auswahl.

Zitat

Und wie gesagt, ich hab von PS keine Ahnung, für mich war da nicht mal ne Schleife zu erkennen.

Ah, ok. Dachte, weil du schon mit Powershell 7 am werkeln bist, kennst du dich damit auch ein wenig aus. Zur Info: Das % ist ein Alias für Foreach-Object.

Ich habe festgestellt, dass der Installer der Standard- und ESR-Version mittlerweile standardmäßig nicht mehr für alle Benutzer nach C:\Program Files installiert, sondern nur noch für den angemeldeten Benutzer nach Appdata\Local. Nur die Nightly installiert bislang weiterhin standardmäßig nach Program Files.

Es wird somit vermutlich nicht wenige Nutzer geben, die überhaupt keine Adminrechte benötigen. Ich habe daher den Workflow nochmal wie folgt überabeitet:

1. Überprüfung, ob Firefox installiert. Falls nicht: Warnung und Abbruch.
2. Überprüfung, ob mehrere Firefox installiert. Falls nein, wird fortgesetzt. Falls ja, startet UI-Auswahl.
3. Überprüfung, ob der Benutzer Schreibrechte in den selektierten Programmverzeichnissen besitzt. Falls ja, wird ohne Adminrechte fortgesetzt. Falls nein, wird das Skript als Admin neugestartet. Die Selektion wird hierbei an die neue Instanz übergeben und alle zuvor bereits erfolgten Überprüfungen entfallen.
4. Überprüfung, ob Firefox derzeit läuft. Falls ja, wird der Benutzer aufgefordert, diesen zu beenden.
5. Zip downloaden, entpacken und Dateien kopieren.

Irgendwelche Einwände? Firefox-JavaScript_install.zip

Zitat von .DeJaVu

Und nein, funktioniert unter Windows 11 hier nicht. Keine Meldung, PS geht einfach wieder zu.

Nachtrag: auf meinem anderen Windows 11 pro (dieser Rechner) funktioniert das Script wieder. Ist also ein spezifisches Problem.

Ist die Ausführungsrichtlinie auf dem betroffenen Gerät gesetzt? Zeige mal bitte die Ausgabe von Get-ExecutionPolicy -List.

Zitat von .DeJaVu

* wird nicht erstellt bei einer Portable, und somit auch nicht entfernt. Allerdings verewigt sich jeder Firefox hier:
HKEY_CURRENT_USER\SOFTWARE\Mozilla\Firefox\Launcher
Macht nur keinen Sinn, sowas zu berücksichtigen, weil es keine profiles.ini dazu gibt.

Für Portable-Nutzer könnte ich im Punkt 1 noch eine Pfadauswahl ergänzen, falls dort keine Installation gefunden wurde. Oder eine Überprüfung, ob Firefox im aktuellen Verzeichnis vorhanden ist - dann könnte man das Skript einfach in das Portable-Verzeichnis legen und von dort aus ausführen.

Zitat von BrokenHeart

vor allem bei TK87 , der das Skript geschrieben hat und jetzt auch in diesem Forum angemeldet ist!

Vielen Dank für die tolle Arbeit!

Zitat von .DeJaVu

Ich kann mich dem Dank von BrokenHeart nur anschliessen.

Gerne.

TODO:

• Es folgt noch eine Anpassung für Nutzer, die bereits CSS in Firefox verwenden.
• Erkennen, ob Firefox über Microsoft Store installiert wurde
• Ggfs folgt dann noch eine Linux-Version - allerdings werde ich da dann Bash statt Powershell nehmen und die UI's mit whiptail erstellen, damit das Ganze auch über SSH ausgeführt werden kann.

Zitat von .DeJaVu

Wegen "weglassen" - ganz einfach so:

$FFs = '',''|%{gp "HKLM:\Software\${_}Microsoft...

Wie ich es oben schon vermutet hatte. Dann ist natürlich auch klar, dass die Einträge hinterher doppelt sind. In der Foreach-Schleife wird ja, wie du selbst schon gesagt hast, ${_} durch die Werte aus den Zeichenketten ersetzt. Bei meiner Version also einmal mit nichts (= im 64bit Ordner gesucht), und einmal durch Wow6432Node\ (= im 32bit Ordner gesucht). Bei dir stehen da jetzt einfach 2 leere Zeichenkettem - die Schleife sucht dann natürlich für jede der beiden und ersetzt ${_} durch nichts, also werden die Einträge des 64bit-Ordners natürlich doppelt aufgelistet.

Wenn dann hättest du die Zeichenkette schon komplett entfernen müssen

$FFs = ''|%{gp "HKLM:\Software\${_}Microsoft...

oder hättest gleich die geanz Schleife entfernen können, welche ja überflüssig ist, wenn sowieso nur ein Pfad durchsucht wird.

Da es aber auch Nutzer mit 32bit Versionen (oder beidem) geben kann, sollte auch Wow6432Node durchsucht werden und eben in Z78 und Z96 jeweils das -EA SilentlyContinue ergänzt werden, damit es keinen Fehler gibt, falls einer der Pfade nicht existier.t

Zitat

Wegen TaskBarIDs und "nicht vorhanden" nochmal. Wenn es Uninstall gibt, aber nicht Taskbars, ist Firefox noch nie gestartet worden auf dem System, dann kann es auch keine installs.ini geben.

Das meinte ich nicht. Angenommen der Nutzer hat mehrerer Firefox installiert, hat auch jeden davon schon mal gestartet gehabt, es gibt also für jeden davon auch schon eine TaskbarID und und eine install.ini - wenn der Nutzer nun einen davon deinstalliert, wird die TaskBarID dann immer automatisch aus der Registry entfernt?

Falls nicht, macht es nämlich keinen Sinn, in der Registry nur nach den TaskBarID's zu suchen, da dann ja möglicherweise auch alte Installationen aufgelistet werden, die gar nicht mehr existieren. Der Eintrag unterhalb von Uninstall ist bei erfolgreicher Deinstallation in jedem Fall weg.

Moin,

Zitat von .DeJaVu

Punkt (2) sollte vor allem anderen stehen. Irgendwas zu ermitteln, um später festzustellen, dass es gar nicht anwendbar wäre?

nunja, imho wird umgekehrt eher ein Schuh draus. Den Benutzer erst dazu auffordern, Administratorrechte zu bestätigen, um dann festzustellen, dass Firefox gar nicht installiert ist?

Zitat

Und dann erst Punkt (4). Uninstall. Und dort könnte man dann auch schon die Pfade auslesen mit InstallLocation, wenn man schon nach DisplayName sucht. Kann man sich auch komplett schenken, weil jede Installation auch eine TaskBarIDs beschreibt - und das wird schon in Punkt (3) ausgelesen.

Löscht denn eine Deinstallation von Firefox automatisch die TaskBarID aus der Registry? Andernfalls könnte es ja verwaiste Einträge geben.

Zitat

Unter (integriertem) PS stört es sich beide Male (Z78/Z96) an Wow6432Node, das gibt es bei mir nicht, da steht auch nichts von Firefox.

Unter Wow6432Node werden die 32bit-Programme gespeichert. Denn Pfad HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall aus Zeile 78 sollte es eigentlich in jedem Fall geben - der Mozilla-Ordner aus Zeile 96 kann natürlich tatsächlich nicht existent sein, falls keine 32bit-Version installiert ist.

Man könnte natürlich in beiden Zeilen hinter Get-ItemProperty -EA SilentlyContinue ergänzen, um das zu ignorieren. Damit erpasrt man sich, erst mit Test-Path überprüfen zu müssen, ob der Ordner existiert.

Zitat von .DeJaVu

Lasse ich das weg, meckert es weiter

Code

Ausnahme beim Aufrufen von "ExtractAssociatedIcon" mit 1 Argument(en):  "E:\Firefox.exe"

Da fehlt der restliche Teil vom Pfad, da ist kein Firefox -> ${0}.

{0} wird durch die InstallLocation-Eigenschaft aus den Registry-Einträgen ersetzt. Aus irgendeinem Grund scheint diese hier zu fehlen, oder nur auf E:\ zu zeigen.

Zitat

Bezeichnung ist richtig, Icon auch (ist die Nightly-EXE). Aber warum doppelt?

Bei mir ist das nicht doppelt. Es wird für jeden Registry-Eintrag unterhalb des Uninstall-Ordners jeweils ein Eintrag hinzugefügt.

Wie genau hast du das WOW6432Node oben weggelassen? Komplett entfernt, oder einfach nur die Zeichenkette geleert? Bei letzterem würde er die Einträge im 64bit Pfad natürlich 2mal abrufen. In dem Fall einfach mal wie oben erwähnt so abändern.

  $FFs = '','Wow6432Node\'|%{gp -EA SilentlyContinue "HKLM:\Software\${_}Microsoft\Windows\CurrentVersion\Uninstall\*"} |?{$_.Publisher -eq 'Mozilla' -and $_.DisplayName -match 'Firefox|Nightly'}

Falls das Problem nach wie vor besteht, könnte es auch an verwaisten Registryeinträgen aus früheren Installationen liegen.

Wie sieht bei dir die Ausgabe von folgendem Befehl aus?

gp HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*|? {$_.Publisher -eq 'Mozilla' -and $_.DisplayName -match 'Firefox|Nightly'} | Select DisplayName,InstallLocation

Gruß Thomas