This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: python msi installers - silent mode
Type: behavior Stage: resolved
Components: Installation, Windows Versions: Python 3.4, Python 2.7
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: loewis Nosy List: Jason.Bray, drohm, loewis, steve.dower, zach.ware
Priority: normal Keywords:

Created on 2013-10-22 13:58 by Jason.Bray, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (15)
msg200955 - (view) Author: Jason Bray (Jason.Bray) Date: 2013-10-22 13:58
Hello, I am working in an IT group, attempting to automate our management of python. This issue applies to both Python 3.4 and Python 2.7.5 and Python 2.7.4

On a Windows machine (both 7 and 8.1 have been tested) when python msi's are installed from the command line using a quiet or passive mode, they do not appear in the "Programs and Features" panel. This leads me to believe that there are missing registry entries when installed in this mode.

When the same msi is used, but in interactive mode, everything appears to install correctly. While I am able to install and uninstall normally using the command line, this creates issues for manual uninstallation of python, as well as for managing it with automation tools like puppet.
msg220456 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2014-06-13 15:43
I've noticed this as well. I'm hoping to do a significant rework of the installer for 3.5 and will keep this in mind, but I honestly have no idea how to diagnose this in the current setup.

Windows Installer is responsible for the missing entries, and AFAIK the only way it will fail to create them is if our MSI includes invalid data (I'd expect this to show up in the verbose logs). Alternatively, there may be some obscure component flags that 'work' but sometimes don't work, I really don't know.
msg220459 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2014-06-13 15:59
This may actually be a Windows issue... the keys for uninstall are being written to the Wow6432Node of the registry (on a 64-bit machine), and apparently the Programs and Features panel does not read them from there.

The 64-bit installers should be fine (testing one now) since they probably don't redirect the registry writes.

I actually have more than twice as many entries under here than in the main view - mostly Visual Studio components - and none of them appear in the panel. I'll try and ping some people here and find out how to fix it.
msg220490 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2014-06-13 20:04
Apparently keys in Wow6432Node are actually okay, so I'm not much closer to figuring this out. As far as I can tell, the entry I have for Python 2.6.6 (which doesn't appear) has identical information to IronPython 2.7.4 (which does appear).
msg220495 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2014-06-13 20:25
Okay, now it looks to me like the install that 'works' ran under the SYSTEM account while the one that didn't work ran under my (admin) user account.

This may be caused by running the installer from an elevated command prompt. If it detects that it needs to elevate, then it changes to SYSTEM, but if it detects that it doesn't, it will use the current account.

If you can run your install scripts as SYSTEM then I suspect it will work. I'm not yet clear on why it sometimes installs through the one account instead of the other.
msg221200 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2014-06-21 20:45
Jason: can you please report how exactly you attempted to perform the installation?
msg221202 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2014-06-21 20:49
I cannot reproduce the issue. In an elevated terminal, I run

msiexec /i python-3.4.1.amd64.msi /qn /l*v python.log ALLUSERS=1

Python installs fine, and does appear in the "Remove programs" panel.
msg221364 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2014-06-23 15:32
The difference may be the "ALLUSERS=1" option. Windows Installer is supposed to auto-detect this when an installer is run as an admin, but maybe something in our authoring is preventing this detection?

When I get a chance I'll try both and see if the logs show whether this is the case.
msg221371 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2014-06-23 17:45
Steve: how is the auto-detection supposed to work, and what is the rationale? Shouldn't it be possible that even someone with administrator privileges still might want to install "just for me"? And how would they then specify that on the command line, given that ALLUSERS can only be set, not reset?
msg221372 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2014-06-23 18:01
It's described at, and frankly it is incredibly confusing.

It is possible to reset ALLUSERS on the command line by specifying ALLUSERS=""
msg221376 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2014-06-23 21:01
Much of the text refers to Installer 5.0. currently targets installer 2.0. Does the auto-detection also work on such installers?
msg221378 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2014-06-23 21:33
No idea, TBH, though I'd guess that the behaviour comes from the installed version of Windows Installer and the database schema comes from the authored version.

Nonetheless, if the solution is to add "ALLUSERS=1" to the command line when doing silent all-user installs, I'm okay with documenting that as being the fix for 2.7 and 3.4.

For Python 3.5, Windows Vista is the earliest supported platform, and so we can assume Windows Installer 4.0 or later (not that there's any need to take advantage of it) ref:
msg238375 - (view) Author: Doug Rohm (drohm) Date: 2015-03-18 04:27
I realize this hasn't been commented on for a long time, but I'm noticing the same issue trying to do a silent install with the 3.4.3 x64 windows installer.  The 3.4.2 x64 windows installer worked perfectly fine, but I can't seem to get the registry and add/remove entries to work with 3.4.3.  I tried fiddling with ALLUSERS="1" and ALLUSERS="" and the results were the same.

Were there any changes to the windows x64 installer from 3.4.2 to 3.4.3 in regards to this issue?
msg239229 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2015-03-25 06:57
I'm not exactly sure how msiexec does its parsing, but it's possible that ALLUSERS="1" may not actually be the same as ALLUSERS=1. I use the latter regularly with most versions of Python in existence and it works fine.

There may also be problems upgrading from the previous installation. If you run the old installers then they may offer to remove Python, even if it doesn't show up in Programs and Features.
msg367301 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2020-04-26 06:15
As all versions using the MSI installer are now out of support, I'm closing the issue.
Date User Action Args
2022-04-11 14:57:52adminsetgithub: 63550
2020-04-26 06:15:47zach.waresetstatus: open -> closed

nosy: + zach.ware
messages: + msg367301

resolution: out of date
stage: resolved
2015-03-25 06:57:21steve.dowersetmessages: + msg239229
versions: - Python 3.5
2015-03-18 04:27:57drohmsetnosy: + drohm
messages: + msg238375
2014-06-23 21:33:14steve.dowersetmessages: + msg221378
2014-06-23 21:01:55loewissetmessages: + msg221376
2014-06-23 18:01:46steve.dowersetmessages: + msg221372
2014-06-23 17:45:29loewissetmessages: + msg221371
2014-06-23 15:32:06steve.dowersetmessages: + msg221364
2014-06-21 20:49:26loewissetmessages: + msg221202
2014-06-21 20:45:36loewissetmessages: + msg221200
2014-06-13 20:25:26steve.dowersetmessages: + msg220495
2014-06-13 20:04:15steve.dowersetmessages: + msg220490
2014-06-13 15:59:46steve.dowersetmessages: + msg220459
2014-06-13 15:43:46steve.dowersetmessages: + msg220456
2014-06-13 00:12:47BreamoreBoysetnosy: + steve.dower

versions: + Python 3.5
2013-10-22 14:00:12christian.heimessetassignee: loewis

type: behavior
components: + Windows
nosy: + loewis
2013-10-22 13:58:52Jason.Braycreate