When installing Python using any of the following stand-alone installers:

python-2.5.2.amd64.msi
python-2.5.1.amd64.msi
python-2.5.2.msi

all the files and folders are installed in C:\ instead of C:\Python25\
as specified in the installer.  Creating C:\Python25\ before
installation, changing the folder name, and rebooting the machine did
not solve the problem.  The installation is being performed on Windows
Vista Enterprise 64 bit with an Intel Q6600 processor machine.

Please run

msiexec /i <msi> /l*v python.log

Compress the log, and attach it to this report.

log now attached

Checking Progress.  This is a big of a show-stopper as it prevents me
from using a number of python dependent packages.

No progress so far; may not proceed at all during April (IOW, I haven't
even looked at the log file yet). 

Contributions are welcome.

As a further follow-up, I have now looked at the log file, and the
problematic lines are

MSI (s) (DC:40) [10:44:39:425]: Ignoring disallowed property TARGETDIR
MSI (s) (DC:40) [10:44:39:425]: Ignoring disallowed property DLLDIR

Try setting SecureCustomProperties (through orca.exe) and report whether
that helps.

using Orca, I modified the .msi file and python now appears to be
working.  I made the following change:

Property -> SecureCustomProperty
Changed value from
REMOVEOLDSNAPSHOT;REMOVEOLDVERSION
to
REMOVEOLDSNAPSHOT;REMOVEOLDVERSION;TARGETDIR;DLLDIR

Running the modified .msi file resulted in Python being installed in
C:\Python25 (the correct location).  Currently, the installation appears
to work properly.

Apparent duplicates are at http://bugs.python.org/issue1298962 and
http://bugs.python.org/issue1565468. This bug seems to have something to
do with "power user" user privileges.

I can duplicate this problem with the MSI installers for Python 2.4.4,
2.5.2, 2.6b1, and 3.0b1. According to some of the other issues, this
problem has been around since 2005; I really, really would like to see
it fixed by the final releases of 2.6 and 3.0, because, as Ross said,
this bug can be a showstopper for many enterprise users who encounter
it. (Or, at least, it forces us to find an administrator to install
Python even though we theoretically have install privileges for it.)

I've attached two logs from a Python 2.6b1 install on Windows XP, one
for a "just me" installation and one for an "all users" installation. In
both cases, I selected all options except for registering extensions.
Since I did this on my work computer, I have search-and-replaced the
values of LogonUser, UserSID, USERNAME, and COMPANYNAME to make them
generic.

Adding at least TARGETDIR to the SecureCustomProperties with Orca allows
me to install where I want to. It may take some investigation to
determine which properties should be added to this list and which don't
need to be.

I'd be happy to provide any more information that can help get this
resolved.

> I'd be happy to provide any more information that can help get this
> resolved.

Contribution of a patch would be the best way to resolve this quickly.

I also have this problem.  (2.5 msi installer under Win2K with a non-
admin account granted admin privs).  Python installs just fine under 
C:\ (instead of C:\Python25) but then I run into problems installing 
the win32 extensions.

Searching the web I found this posting from 2005
  http://mail.python.org/pipermail/python-list/2005-
September/341874.html

That poster created an SF bug report which is now issue1298962.  He 
linked to http://tinyurl.com/82dt2 which states:

    Windows Installler has no recognition of power
    users, so these users fall into the category of 
    "non admin" when running an install. 

That describes exactly my situation.  The solution is, apparently:

    To mark certain properties as safe for configuration,
    you can add them to the SecureCustomProperties list
    in the property table of the MSI file. 

which Martin reported here.  Martin suggested using orca, but I have no 
idea of what that is (unix/mac dweeb that I am), and it doesn't exist 
on this machine.

I know this is pretty much a "me too" report.  I'm doing so to say that 
it has been an ongoing problem here at my client's site.  They are not 
software developers here, and rather than trying to track down the 
right person with full admin rights to come to each person's desktop, 
they've been installing an old pre-msi version of Python.

I would like to see this fixed before 2.6 is released.  All I can do to 
help though is to test an installer, which I will do gladly.

Please try out the file at

http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.6.14106.msi

and report whether it fixes the issue.

Yes, that installed Python 2.6 into the correct location (C:\Python26 
instead of into the root directory).

Fixed in r66305.