This *not* a duplicate of bug 93606. I set that ticket's title and added some comments as it seemed to apply to me just as much as to the OP. But I was told to open a new one specific to my situation, so that's what I'm doing. As that ticket title was chosen to match my findings, I'm copying it for this new bug. Here are my comments from the other ticket again: bug 93606, comment 23 2015-08-31 22:50:41 UTC I am also experiencing this problem on an US English version of Windows 7. I am not changing the drive letter but the actual name of the installation directory (I want to remove the major version number). Also, I choose not to create a desktop shortcut, this is also ignored. I've first reported this on https://ask.libreoffice.org/en/question/56644/custom-install-options-ignored-on-windows-7/ with some more details but there were no replies. I've seen this problem on my previous installations of LibreOffice 4 as well. bug 93606, comment 24 2015-08-31 23:18:38 UTC I've now tried the command line suggested in bug 93606, comment 16, with the path changed to what I desire, so this is what I ran: msiexec.exe /i LibreOffice_5.0.1_Win_x64.msi INSTALDIR="C:\Program Files\LibreOffice" TARGETDIR="C:\Program Files\LibreOffice" INSTALLLOCATION"="C:\Program Files\LibreOffice" /L*v installLog.txt However, as soon as I chose "Custom", the wizard came up the default install location "C:\Program Files\LibreOffice 5\". I changed it back to what I wanted (leaving the trailing backslash in place). Then it worked (also the desktop shortcut, but still does not work when I double-click the .msi file. My account has the required rights to perform the installation either way, but I took care to start the command line from an administator's CMD process as requested in the previous comment. bug 93606, comment 25 2015-08-31 23:32:55 UTC I had to jump through the some hoop when installing the help package. Funnily, the dialog did pick up from somewhere that I had installed LibreOffice in "C:\Program Files\LibreOffice" and did show that path to me in the dialog. So I went ahead and clicked to install. I then found that "C:\Program Files\LibreOffice 5" had been created. Uninstalling the help package did not remove that folder either. I removed it manually after uninstalling and then ran msiexec.exe /i LibreOffice_5.0.1_Win_x64_helppack_en-US.msi INSTALDIR="C:\Program Files\LibreOffice" TARGETDIR="C:\Program Files\LibreOffice" INSTALLLOCATION"="C:\Program Files\LibreOffice" /L*v installLog3.txt I now, finally, have a working installation (with help package) in my desired target folder.
Created attachment 118676 [details] Install log corresponding to the installation attempt described at 2015-08-31 23:18:38 UTC. Times in the file are local time which is UTC+0200.
Of course I do not have a log documenting a regular installation, where I change the path and choose not to create a desktop shortcut, because that's done via simply double-clicking the MSI file.
@sebalis, Thanks for posting the install log. Looked it over and one thing that jumps out is that your command line somehow has an extra quote mark in the INSTALLLOCATION entry: INSTALLLOCATION"=C:\Program Files\LibreOffice Result is that the default is pulled from the MSI package. As you then select a custom install, you later change the INSTALLLOCATION to your preferred placement. Since you are up and working, hate to ask you to uninstall and have another go. But otherwise,if you don't want to press on, would think this issue can be resolved invalid as well.
You're right, something went wrong when I put together the command line. However, that is not so important because that install file does not document the process where the real problem occurs. Maybe my quote led to what I observed in bug 93606, comment 24 when I wrote that I had to specify the install location I wanted again as I was going through the wizard. But what I'd really like to know is how we could analyse the initial behaviour that happens when I just double-click the MSI.
(In reply to sebalis from comment #4) > ... But > what I'd really like to know is how we could analyse the initial behaviour > that happens when I just double-click the MSI. If you open the .msi package with Microsoft's ORCA MSI package editor you'll see that the settings for INSTALLLOCATION are bound to ProgramFiles64Folder--which otherwise takes its value from TARGETDIR--and its value becomes "LibreOffice 5" resulting in a default for INSTALLLOCATION of "C:\Program Files\LibreOffice 5" When running the default GUI install, i.e. double clicking the .msi (as opposed to running CLI with msiexec.exe and variables) the installer uses the defaults from the .msi package. Resulting in "C:\Program Files\LibreOffice 5" showing at the "Install to:" stanza of a Custom installation. With the GUI, the "Change" button can be manipulated immediately, or use the back button to return to it after making selections for Optional components, or Additional languages. Either way before proceeding, double check that the "Install to:" value shows the custom location you prefer. It is that string that gets written to the installation as the transform INSTALLLOCATION value.
I'm not quite sure what you are saying. You are clearly aware that my original report is about me using the "Change" button to change the install location. Are then suspecting that somehow, just before installing, the value had reverted to its default? That would be a bug in itself, but I can assure you (as an experienced user of GUIs and indeed a software developer myself) that I've observed this behaviour several times and made sure that the GUI promised it would install in C:\Program Folders\LibreOffice but then the version number (4 or 5) was added anyway. Also, don't forget that I also clicked to say I did not want a desktop shortcut and it was created anyway.
Yes, there could certainly be issues with the GUI installer. Especially for customization of the newly implemented 64-bit Windows builds. But, what I am saying is that without detailed installation logs of "custom" installations--the dev's will have no interest in even looking at it. If you still want to keep after it, we will need viable steps to reproduce. And verbose logs to review. Again, I hate to put to load back on you, but there you have it. When you can replicate the issue and capture it in a log--we'll have somewhere to start. Unfortunately it means a lot of install -> remove -> clean and repeat... Use this command to give you the full GUI and customize from there, each setp of the transform will get recorded. msiexec.exe /i LibreOffice_5.0.1.2_Win_x64.msi /qf /L*v installTestXX.log
Created attachment 118687 [details] Log for test installation 1 Happy to try a few times. This first attempt should give us material to analyse. I used the command line you suggested (except that the version number in the downloaded MSI is only 5.0.1, the .2 is missing but it is version 5.0.1.2). And the behaviour was exactly as before: I set the install location to "C:\Program Files\LibreOffice\" and verified that the GUI showed this new location right up to the point when I had selected my components and clicked to proceed. Also I chose not to create the desktop shortcut. Again, the installer used "LibreOffice 5" and the desktop shortcut was created.
OK, looking through the log, very clear that you have assigned the desired INSTALLLOCATION of C:\Program Files\LibreOffice -- believe that is what is known as the UI stage. But as it enters the Execute stage at line 5278, Machine policy value 'AlwaysInstallElevated' is 1 User policy value 'AlwaysInstallElevated' is 1 Machine policy value 'EnableUserControl' is 0 and trigger at line 5345 PROPERTY CHANGE: Adding RestrictedUserControl property. Its value is '1' and the customization settings made in the UI stage are being "disallowed". Not clear if this is UAC, or an aspect of the system being on AD with Domain GPOs applied. Is this box getting GPO? In any case, some indications browsing web of an interplay of UAC when 'AlwaysInstallElevated' is active--*requires* the "public" properties set in the UI section to be present in the MSI -> "Property" table in the "SecureCustomProperties" property stanzas. If not they are ignored and not passed into the service. Which is what seems to be happening in this case. I checked historical LO msi installers back through the 4.1.0 builds and we don't set Values other than NEWPRODUCTS; OLDPRODUCTS. Earlier builds set a few more Values for PRODUCTS--but never any of the MSI "customization" values. @Andras, thoughts? Should we be adding the below Custom Actions to the MSI Property -> SecureCustomProperties? INSTALLLOCATION TARGETDIR COMPANYNAME USERNAME ALLUSERSPROFILE USERPROFILE LANG_SELECTED APP_SELECTED FILETYPEDIALOGUSED SOURCEDIR ROOTDRIVE REGISTER_XLW REGISTER_VST REGISTER_VSD CREATEDESKTOPLINK SELECT_WORD SELECT_EXCEL SELECT_POWERPOINT SELECT_VISIO =-ref-= http://blogs.msdn.com/b/rflaming/archive/2006/09/21/765452.aspx
Yes, this computer is a work PC that is part of the company domain and subject to the company's Group Policies. But I have local admin rights and nothing in any GPOs I receive should prevent me from changing the install location. I regularly do so when installing other software.
@sebalis, One more thing I think would be helpful, unfortunately again another round of remove -> clean -> install. Sorry! For this installation launch your CMD window "Run as Administrator", you are looking for it to start with UAC acknowledgement, and open in C:\Windows\system32, not your user profile home. Then navigate to your downloaded MSI and run your install as before: msiexec.exe /i LibreOffice_5.0.1_Win_x64.msi /qf /L*v installTestXX.log We're looking to avoid trigger of RestrictedUserControl which I think is residual UAC difference between a user account in the Administrators group and the local system Administrator. Other way to test, would be to activate and log in with the local system Administrator account--but that causes IT folks great grief ;-) You might enlist their assistance if you want to try that. Let us know result and post up the install log(s).
Created attachment 118706 [details] Log for test installation 2, this time from an elevated command prompt -- changes to settings were not ignored I know it's good supporter practice to err on the side of explaining more than necessary, but you might have gleaned from my earlier comments that I am very familiar with UAC prompts. :-) Starting an elevated command prompt is quite a common activity for me. I did as you requested, made the same adjustments as always, and this time my changes were honoured. The log is attached.
@sebalis, OK, thanks for another round. So comparing the two installs--the first, AD Domain account in Administrators group run from a command window, and the second, run from a command windows "Run as Administrator", have different outcomes regards the MSI transition from UI stage to Execute stage. Public values are being disallowed for the first--even though the logs recognize you as an admin in the UI stage. It shows a EnableUserControl disabled but gets clobbered by a RestrictedUSerControl enabled. At line 5343 we get "MSI (s) (B0:3C) [02:01:39:675]: Running product '{A18CF6D8-7CE1-46F2-85B9-D87B7197B2F6}' with elevated privileges: All apps run elevated." In the latter, "Run as Administrator" at line 5044 we get: MSI (s) (2C:0C) [16:58:54:988]: Product installation will be elevated because user is admin and product is being installed per-machine. MSI (s) (2C:0C) [16:58:54:988]: Running product '{A18CF6D8-7CE1-46F2-85B9-D87B7197B2F6}' with elevated privileges: Product is assigned. And the Execute stage and actions passed to the service assert as expected. So, problem solved... sort of ;-) It is a work around--i.e. "Install from an elevated command prompt". Or one can create and merge the following registry hack which will offer a "Run as Administrator" from the Windows context menu--and accomplishes the same work around. <clip> Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\Msi.Package\shell\runas] @="" [HKEY_CLASSES_ROOT\Msi.Package\shell\runas\command] @="msiexec.exe /i \"%1\"" [HKEY_CLASSES_ROOT\Msi.Patch\shell\runas] @="" [HKEY_CLASSES_ROOT\Msi.Patch\shell\runas\command] @="msiexec.exe /p \"%1\"" </clip> Despite work around(s) I continue to see this is a UAC issue with AD managed user account, AD deployed GPO and interaction with the Windows Installer package. Suspect it is a manifestation of our legacy build scripts for Windows installer packages. Yes, we've added support for 64-bit flavors--but we are getting further away from current Windows Installer Single Package Authoring. We have been unable to do peruser installations beyond XP. We've now dropped Windows XP, perhaps we should drop Windows Vista as well and refactor the MSI packaging fully to Installer 5.0 including current ICE validation, and again support peruser as well as permachine installs and I'd hope better handling of UAC for AD "managed" machines and accounts. @Andras, @DavidO, @Jesus how do you see this? I beleive the work around should hold for folks, but going forward, e.g. VS2015 etc. the Windows install packaging may really need some attention. Restoring ability to install peruser alone might justify refactoring. But as the work falls to you--I'm just opining... Stuart =-ref-= http://blogs.msdn.com/b/windows_installer_team/archive/2009/09/02/authoring-a-single-package-for-per-user-or-per-machine-installation-context-in-windows-7.aspx https://msdn.microsoft.com/en-us/library/dd408068%28VS.85%29.aspx
I don't really have anything to add at this point, but I'd like to express my gratitude to Stuart for the competent care he has given to my bug report.
(In reply to V Stuart Foote from comment #9) It is a *good* and absolutely correct idea - and an easy hack - to add all the user-configurable properties to the secure list. You are quite right!
Changing priority back to 'medium' since the number of duplicates is lower than 5