This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Problem solved, but need some clarification
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Sep 22, 2009
10:00 AM
XML/INI File changes and Admin Credentials on Windows Vista & 7: Another bug?
Hi,
I am working on a Basic MSI Project with InstallShield 2010.
This project was previously built with IS 2008.
One of our requirement is that the end user can set a few parameters at installation, like the language of the application.
The implementation is pretty straightforward:
The user can then change the language at a later stage by launching the setup again, in maintenance(change) mode.
In that scenario, we set the REINSTALL property with the feature that contains the corresponding language components and the corresponding XML/INI file changes. This allows to reinstall the corresponding feature and perform the file changes in maintenance(change) mode.
Some problems have appeared since we build the setup with IS 2010, and I am wondering if we have discovered another bug.
The following scenario is an issue on both Windows Vista and Windows 7, with a test user logged with "normal" administrator credentials (ie not logged on the hidden Administrator account).
[LIST=1]
Installation with a certain language: ok. The XML and INI file changes are correctly made.
Launch the setup in maintenance(change) mode by double clicking setup.exe: ok. The corresponding components are correcly reinstalled and the XML and INI file changes are correctly applied.
Launch the setup in maintenance(change) mode by browsing to Control Panel-->Programs-->Programs and Features-->Choose the application and click "Change": FAILURE. The corresponding components are NOT reinstalled and the XML and INI file changes are NOT made.
Launch the setup in maintenance(change) mode by right clicking the MSI file and choosing "Install": FAILURE. The corresponding components are NOT reinstalled and the XML and INI file changes are NOT made.
Launch the setup in maintenance(change) as Administrator by running the command line as administrator and calling msiexec: ok. The corresponding components are correctly reinstalled and the XML and INI file changes are correctly made.
So, these installation changes only work:
I strongly believe it is another bug in IS 2010, as this used to work troublefree when we built our setup with IS 2008.
Regards
I am working on a Basic MSI Project with InstallShield 2010.
This project was previously built with IS 2008.
One of our requirement is that the end user can set a few parameters at installation, like the language of the application.
The implementation is pretty straightforward:
- The user chooses a language in a selection dialog. A property is set accordingly.
- The property defines which components are installed (ie we only install the components that correspond to the chosen language by using component conditions).
- This property is then used by an XML file change, and by an INI file change to set a value in some files that are installed by the installer.
The user can then change the language at a later stage by launching the setup again, in maintenance(change) mode.
In that scenario, we set the REINSTALL property with the feature that contains the corresponding language components and the corresponding XML/INI file changes. This allows to reinstall the corresponding feature and perform the file changes in maintenance(change) mode.
Some problems have appeared since we build the setup with IS 2010, and I am wondering if we have discovered another bug.
The following scenario is an issue on both Windows Vista and Windows 7, with a test user logged with "normal" administrator credentials (ie not logged on the hidden Administrator account).
[LIST=1]
So, these installation changes only work:
- if the maintenance is launched using setup.exe
- OR if msiexec is running as Administrator.
I strongly believe it is another bug in IS 2010, as this used to work troublefree when we built our setup with IS 2008.
- Does setup.exe allow to launch msiexec with higher Admin credentials?
- Any idea?
- Any workaround?
- Do we need to set some extra properties in the MSI package to run it with higher credentials under Vista and Win 7?
Regards
(2) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Sep 23, 2009
02:56 AM
After some more testing, it seems that the changes are only applied if the maintenance(change) is running with elevated privileges.
So some points need to be clarified:
I think Josh Stechnij worked on access rights and privileges. Josh, any chance you could point me in the right direction?
Regards
- If I launch the installer in maintenance(change) mode by double-clicking on setup.exe, a UAC confirmation dialog pops-up, the maintenance takes place, the changes are applied correctly and the SetupCompleteSuccess dialog pops up.
- If I browse to the control panel-->Programs-->Programs and Features, select the program, and click on change, msiexec is launched with the corresponding MSI package, but no UAC confirmation dialog pops-up, which means it does not even try to require elevated privileges. Then the maintenance seems to take place, but the changes are not applied. Eventually the SetupCompleteSuccess dialog pops up.
So some points need to be clarified:
- Why did that work correctly with IS 2008?
- The "Require Administrative Privileges" setting in the summary information of the installation package is set to "Yes", but I wonder if it has an effect when the setup is run in maintenance(change) mode.
- Is there any way to require elevated privileges in the MSI package itself when performing a maintenance(change)? Any function I could call from InstallScript? Any property I should set?
I think Josh Stechnij worked on access rights and privileges. Josh, any chance you could point me in the right direction?
Regards
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Sep 24, 2009
04:24 AM
Hi,
After digging a bit deeper, I managed to figure out what was going wrong:
The problem was due to some property values which weren’t carried over from UI sequence to Execute sequence.
Indeed I got some "Ignoring Disallowed Property PROPERTYNAME" in the MSI log file.
Lucky me, I found this webpage. I added the name of some properties to the SecureCustomProperties property, and it worked.
Nevertheless, I spotted one little difference between IS 2008 and IS 2010, which is related to this problem on Windows Vista and Windows 7:
See the attached images below.
In both cases, the "Show UAC Shield Icon" setting of the InstallNow button was set to "True", and the "Require Administrative Privileges" setting of the project was set to "Yes".
So, why are the results different between IS 2008 and IS 2010?
After digging a bit deeper, I managed to figure out what was going wrong:
The problem was due to some property values which weren’t carried over from UI sequence to Execute sequence.
Indeed I got some "Ignoring Disallowed Property PROPERTYNAME" in the MSI log file.
Lucky me, I found this webpage. I added the name of some properties to the SecureCustomProperties property, and it worked.
Nevertheless, I spotted one little difference between IS 2008 and IS 2010, which is related to this problem on Windows Vista and Windows 7:
- IS 2008: when launching the setup in maintenance(change) mode, either by double-clicking the MSI file, or by clicking change from Control Panel-->Programs-->Programs and Features, the InstallNow button of the ReadyToInstall dialog shows the UAC shield. When you click on it, the UAC confirmation dialog pops-up. Then the public properties are properly carried over from the UI sequence to the Execute sequence, even if they are not secured, as the maintenance is taking place with elevated privileges.
- IS 2010: when launching the setup in maintenance(change) mode, either by double-clicking the MSI file, or by clicking change from Control Panel-->Programs-->Programs and Features, the InstallNow button of the ReadyToInstall dialog does not show the UAC shield. When you click on it, no UAC confirmation dialog pops-up. Then the public properties are not properly carried over from the UI sequence to the Execute sequence, unless they are secured.
See the attached images below.
In both cases, the "Show UAC Shield Icon" setting of the InstallNow button was set to "True", and the "Require Administrative Privileges" setting of the project was set to "Yes".
So, why are the results different between IS 2008 and IS 2010?
![](/skins/images/8CE4FAD0DE6F3A6F9D0567434D2D2DAE/responsive_peak/images/icon_anonymous_message.png)