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