☰

Python 3.8.1 kann nicht unbeaufsichtigt mit MSIEXEC deinstalliert werden

tag-icon • tag-icon windows python msi uninstall silent
Python 3.8.1 kann nicht unbeaufsichtigt mit MSIEXEC deinstalliert werden

Ich habe Python 3.8.1 zunächst in unserer Organisation bereitgestellt (ggf. über WSUS Package Publisher) und dabei die gefundenen MSIs verwendet.Hier.Ich habe diese MSIs mithilfe von WSUS Package Publisher mit dem folgenden Befehl für jedes MSI installiert:

msiexec.exe /i core.msi /qn /norestart ALLUSERS=1

Leider verursachte dies aus irgendeinem Grund eine Reihe von Problemen bei mir, die alle darauf hindeuteten, dass ALLUSERS=1 ignoriert wurde, möglicherweise aufgrund fehlender Rechte des Installationsprogramms (es erschien nicht in der Liste der installierten Anwendungen, erschien nicht in der py -0-Liste). Frustrierenderweise wurden diese versehentlich an alle verteilt, bevor wir diese Probleme bemerkten.

Um aufzuräumen, muss ich diese MSIs jetzt deinstallieren. Ein Rechtsklick auf diese MSIs auf dem betroffenen Rechner und ein Klick auf „Deinstallieren“ funktioniert – mir wird die Eingabeaufforderung „Möchten Sie wirklich deinstallieren?“ angezeigt, gefolgt von einer Erhöhungsanforderung, und dann wird die Deinstallation wie erwartet durchgeführt.

Da ich jedoch versuche, dies im Hintergrund zu tun, damit ich es ausrollen kann, ist dies der Befehl, den ich über eine Shell mit erhöhten Rechten ausführen möchte:

 msiexec.exe /x .\core.msi /qn

Es passiert nichts. Ich kann im Task-Manager sehen, dass msiexec.exe ohne Aktivität ausgeführt wird. Ich habe also das Gefühl, dass es zur Eingabeaufforderung „Sind Sie sicher?“ gelangt und dort hängen bleibt.

Wie umgehe ich diese Eingabeaufforderung während der stillen Deinstallation?

Antwort1

Nachdem mein Kollege und ich einige Zeit mit der Fehlerbehebung beschäftigt waren, haben wir die Situation und das, was tatsächlich passiert ist, besser verstanden. Dies löst zwar nicht das, was wir ursprünglich versucht haben (Python 3.8.1 MSIs über WSUS bereitstellen), aber es hilft uns zumindest beim Aufräumen. Hoffentlich hilft dies einem anderen Administrator da draußen, der möglicherweise etwas Ähnliches mit WSUS Package Publisher oder etwas anderem erlebt hat!!

Wir stellen Python über WSUS bereit, das heißt, dass alle lokalen Rechner Python als NTAUTH\SYSTEM installieren. Das erklärt, warum Python korrekt und ohne Probleme an dem von mir in der MST-Datei angegebenen Speicherort (C:\Programme\Python38) installiert wurde.

Aus irgendeinem Grund ignorieren alle Python-MSIs den Aufruf ALLUSERS=1 in der .MST, auch wenn er als Parameter angegeben wird. Keine Ahnung, warum (vielleicht kann jemand aus dem Python-Team oder jemand mit tieferem Verständnis etwas dazu sagen? :) ).

Das Ergebnis davon bedeutet nach meinem Verständnis/meinen Tests, dass das Installationsprogramm erkennt, dass es nicht als erhöhter Prozess ausgeführt wird, und daher das MSI als Benutzer NTAUTH\SYSTEM für NTAUTH\SYSTEM installiert und die Schlüssel für den Python-Launcher usw. in HKCU statt in HKLM platziert. Aber aufgrund der .MST und der Zugriffsrechte, die NTAUTH\SYSTEM hat, platziert es die Installationsdateien wie gewünscht in C:\Programme\Python38.

Dies erklärt, warum Installationen fehlschlugen, Deinstallationen auf jeden Fall unmöglich waren und warum sich unser Python Launcher merkwürdig verhielt, obwohl PATH richtig eingestellt war.

  • Installationen würden fehlschlagen, da die Schlüssel alle noch im Verzeichnis HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\ abgelegt wären.
  • Die Installationsprogramme wurden trotz erfolgreicher Installation nie in den installierten Anwendungen angezeigt, da sie für NTAUTH\SYSTEM und nicht für alle Benutzer installiert wurden.
  • Bei der Deinstallation über MSIEXEC oder durch Rechtsklick auf das MSI würde behauptet werden, es sei nicht installiert, da Python technisch gesehen weder für das System (d. h. „Alle Benutzer“ bei erhöhten Rechten) noch für den Benutzer, der es deinstallieren möchte (d. h. mein Benutzerkonto ohne erhöhte Rechte), installiert war.
  • py -0 hat die Py38-Installation nicht erkannt, obwohl andere Versionen erkannt wurden, weil der Launcher in den HKLM-Schlüsseln gesucht hat, in denen 381 nicht installiert wurde.

Um dieses riesige Durcheinander zu beseitigen, mussten wir alle Python 3.8.1 MSIs als NTAUTH\SYSTEM und ohne Rechteerhöhung deinstallieren. Dies kann auf verschiedene Weise erfolgen: Entweder indem Sie PSEXEC herunterladen und verwenden, um eine CMD oder Powershell als System zu starten (psexec64.exe -sid powershell.exe) und MSIEXEC darüber ausführen, oder (wie wir es gemacht haben) indem Sie eine geplante Aufgabe auf dem Computer erstellen, sie als NTAUTH\SYSTEM ohne die höchsten Rechte ausführen und alles deinstallieren, was die Eigenschaft „Python 3.8.1*“ hat. Ein kurzes Powershell-Skript hierfür:

$products = Get-WmiObject Win32_Product

foreach ($pkg in (
        "Python 3.8.1 Tcl*",
        "Python 3.8.1 Util*",
        "Python 3.8.1 Test*",
        "Python 3.8.1 Dev*",
        "Python 3.8.1 Documentation*",
        "Python 3.8.1 pip*",
        "Python 3.8.1 Standard*",
        "Python 3.8.1 Exe*",
        "Python 3.8.1 Core*",
        "Python 3.8.1 Add*",
        "Python Launcher*"
    )) {
    $products | Where-Object {
        ($_.Name -like $pkg)
    } | Select-Object -ExpandProperty LocalPackage | Foreach-Object {
        Start-Process -FilePath "msiexec.exe" -ArgumentList "/x $_ /QN" -Wait
    }
}

get-wmiobject Win32_Product | where-object {$_.Name -like "Python*"} | Format-Table Name, LocalPackage

verwandte Informationen