MSI for Group Policy School Computers

Hi. I’m an IT staff at a school. We’d like to have Python latest version deployed to all our computers via group policy. To do this, you need an MSI. But I can’t find an up-to-date version of Python MSI. Can anyone make one or show me how to make an MSI please? I have 0 idea

Thank you

You do not need an msi, you can run the python setup .exe to install unattended. See 4. Using Python on Windows — Python 3.12.3 documentation

1 Like

I’m not sure what CPython uses, nor what open source installer tools are out there, but Caphyon supply a free tier of Advanced Installer that can build an .msi

What are you using to manage your deployments? You may not need an MSI, but it all depends on your use case.

Using group policy to deploy msi software onto machine(?)

I’ve tried using that, but can’t seem to get it to work. Thank you

You need to ask your microsoft windows support people how to do installs of .exe unattended apps.

There seems to be a bunch of MSI files in a subdirectory on the download server: Index of /ftp/python/3.12.3/amd64/

I’m guessing the installer is an exe file because it needs to bundle multiple MSI packages (e.g. Tcl/Tk) but you can probably install the MSI files separately as well.

None of them seemed to have installed Python? :confused:

Not sure if we have that, sorry

Does anyone have an MSI they created?

I question your school IT department’s security if it disallows official, verified .exes, but permits random .msi installers someone on an internet forum has built.

Nonetheless, there are third party repackagers, e.g.:
GitHub - indygreg/python-build-standalone: Produce redistributable builds of Python but they dropped Windows support altogether, and I don’t know of anyone who builds .msis.

To try to build one yourself, I did stumble across this, and lots of other helpful things in the official Python repo:

Structure of the Installer

The installer is structured as a ‘layout’, which consists of a number of
CAB and MSI files and a single EXE.

The EXE is the main entry point into the installer. It contains the UI
and command-line logic, as well as the ability to locate and optionally
download other parts of the layout.

Each MSI contains the logic required to install a component or feature
of Python. These MSIs should not be launched directly by users. MSIs can
be embedded into the EXE or automatically downloaded as needed.

Each CAB contains the files making up a Python installation. CABs are
embedded into their associated MSI and are never seen by users.

MSIs are only required when the related feature or component is being
installed. When components are not selected for installation, the
associated MSI is not downloaded. This allows the installer to offer
options to install debugging symbols and binaries without increasing
the initial download size by separating them into their own MSIs.

More here

and elsewhere:

If you want to build MSI installers, be aware that the build toolchain for them has a dependency on the Microsoft .NET Framework Version 3.5 (which may not be included on recent versions of Windows, such as Windows 10). If you are building on a recent Windows version, use the Control Panel (Programs ‣ Programs and Features ‣ Turn Windows Features on or off) and ensure that the entry .NET Framework 3.5 (includes .NET 2.0 and 3.0) is enabled.
Setup and building

2 Likes

You don’t need to use an MSI to install something via Group Policy.

Simplest thing to do would be to create a script that launches the Python executable with the proper switches.

1 Like

I have a similar/related problem with the installer in Windows and came here to mention the same thing. I’ve been doing unattended installations for about 20 years, and am very adept at software deployments. I, too, run a public computer lab with about 300 computers and we have Python installed on them currently. My issue is that I want to uninstall 3.11 and install 3.12, and I’m having some odd issues with both the removal of 3.11 and the installation of 3.12. To preface this, I should inform you that because this is a public computer lab, we are installing it for all users in C:\Program Files rather than the default method of installing into individual user profiles.

First, to uninstall 3.11, I have to use the specific minor version’s installer to perform the removal. For example, if 3.11.3 is installed, I have to use the installer for 3.11.3 for the “/uninstall /quiet” command line arguments to function. The uninstaller removes the files in C:\ProgramFiles\Python311, but does NOT remove the entries in the registry, so Python 3.11.3 is still listed in Programs and Features as if it were still installed. Additionally, when I re-run the installation for 3.11, it detects that it is still installed and asks me if I want to uninstall or repair. If I do not use the command line arguments to automate the uninstall, everything gets properly/cleanly removed.

When I use the command line arguments to silently deploy 3.12, it has similar issues. It successfully copies the files to C:\Program Files\Python312 but does not create the registry keys that get it listed in Programs and Features, so Windows does not see it as ‘installed.’ When I manually run the installer again on the computer, it does not pick up that it is installed. It normally would ask if you want to remove or repair if it detects it is already installed, but it acts like it is not there. If I do not use the command line arguments to perform the install, everything gets properly added to the registry and the installer detects Python 3.12 is installed when attempting to run it again.

It seems to me like the command line arguments are not properly handling removal and installation. Perhaps this is what the OP is seeing as well.