3

I initially deployed Python 3.8.1 in our org (through WSUS Package Publisher if relevant) using the MSI's found here. I installed these MSI's using WSUS Package Publisher with the following command for each MSI:

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

Unfortunately for some reason this was causing a number of issues for me which all seemed to point to the ALLUSERS=1 being ignored, possibly due to lack of elevation of the installer (not appearing in the Installed Applications list, not appearing through the py -0 list). Frustratingly these were all accidentally deployed to everyone before we realised these issues.

To clean up, I now need to uninstall these MSI's. Right clicking these MSI's on the affected machine and clicking "Uninstall" works - I get presented a "Are you sure you want to uninstall?" prompt, followed by elevation request, and then it uninstalls as expected.

However, as I'm trying to do this silently so that I can roll this out. This is the command I'm trying to run through an elevated shell:

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

Nothing happens. I can see in Task Manager that msiexec.exe is running with no activity, so my feeling is that it's reaching the "Are you sure?" prompt and getting stuck on that prompt.

How do I bypass this prompt during silent uninstallation?

2
  • you could try the solutions given here Jan 30, 2020 at 19:55
  • Using the command - msiexec.exe /x 913F572C-BF38-4E44-9065-7E1B024D43FB /qn - I experience the exact same behaviour - msiexec appearing in task manager, but stuck. The Product Code value is from dev.msi 64bit and obtained with Orca through the Property table.
    – Joe Smith
    Jan 31, 2020 at 9:20

1 Answer 1

1

So after some time of me and my colleague troubleshooting this, we gained a better understanding of the situation and what actually happened. This doesn't solve what we were trying to do originally (deploy Python 3.8.1 MSI's through WSUS), but it at least helps us clean up. Hopefully this helps another admin out there who may have experienced something similar to this with WSUS Package Publisher or something else!!

We're deploying Python through WSUS, so that means that all local machines install Python as NTAUTH\SYSTEM. This explains why Python was installing correctly, without complaints, in the location I specified in the .MST (C:\Program Files\Python38).

For some reason, the Python MSI's all ignore the ALLUSERS=1 call in the .MST, and by specifying it as a parameter. No idea why (maybe someone from the Python team or someone with a deeper understanding could chime in? :) ).

The result of this means, from my understanding/testing, that the installer detects that it's not running as an elevated process, and therefore installs the MSI as user NTAUTH\SYSTEM, for NTAUTH\SYSTEM, placing the keys for Python launcher etc in HKCU instead of HKLM. But because of the .MST and the access rights that NTAUTH\SYSTEM has, it places the installation files in C:\Program Files\Python38 as requested.

This explains why installations would fail, uninstallation was impossible no matter what, and why our Python Launcher was behaving weirdly despite PATH being set correctly.

  • Installations would fail because the keys would all still be placed in the HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\
  • The installers never appeared in Installed Applications despite successful installation, because it was installed for the NTAUTH\SYSTEM and not All Users
  • The uninstallation through MSIEXEC or by right clicking the MSI would claim that it wasn't installed, because Python was technically not installed for either the system (aka All Users when elevated), nor the user trying to uninstall it (aka my user account, without elevation).
  • py -0 wasn't picking up the Py38 installation despite picking up other versions, because the launcher was searching in the HKLM keys, which 381 wasn't installing in.

So to clean this huge mess up, we needed to uninstall all of the Python 3.8.1 MSI's as NTAUTH\SYSTEM, and without elevation. There are several ways to do this - either by downloading and using PSEXEC to launch a CMD or Powershell as System (psexec64.exe -sid powershell.exe) and running MSIEXEC through that, or (the approach we took) create a Scheduled Task on the machine, have it run as NTAUTH\SYSTEM, without the highest privilages, and uninstall anything which had "Python 3.8.1*" property. A quick Powershell script for this:

$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
2
  • 1
    I had to replace the command msiexec.exe /x $_ /QN with a Start-Process -Wait -FilePath 'C:\Windows\System32\msiexec.exe' -ArgumentList "/x $_ /quiet" This waits before starting the next uninstall process.
    – JPX
    Feb 22, 2022 at 12:59
  • Thanks. You're right, as my previous script would sometimes throw up "General Failures" requiring me to run it multiple times for a complete removal. Updated my post.
    – Joe Smith
    Jan 25 at 14:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .