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
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.