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
- :
- Re: Basic MSI, Vista, ALLUSERS property deleted during CA (InstallScript)
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
‎Aug 16, 2007
05:21 AM
Basic MSI, Vista, ALLUSERS property deleted during CA (InstallScript)
Hi.
I´ve noticed that the ALLUSERS property will be deleted during immediate InstallScript custom actions (sequenced in the UI sequence) with Windows Vista.
The msi log file reports:
PROPERTY CHANGE: Deleting ALLUSERS property. Its current value is '1'.
Why does this happen?
Can anyone reproduce this behaviour?
-Nick
I´ve noticed that the ALLUSERS property will be deleted during immediate InstallScript custom actions (sequenced in the UI sequence) with Windows Vista.
The msi log file reports:
PROPERTY CHANGE: Deleting ALLUSERS property. Its current value is '1'.
Why does this happen?
Can anyone reproduce this behaviour?
-Nick
(16) Replies
![](/skins/images/3B39CE851FDD5528C393F146EB70A2D0/responsive_peak/images/icon_anonymous_message.png)
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 16, 2007
08:42 AM
This is an issue with InstallShield 2008 and seems to occur with Immediate Execution custom actions. This issue occurs because of another issue we resolved related to determining if the user is an Administrator or not.
The issue # for this is IOC-000063216.
The following log file snippet might represent a sample of this issue:
InstallShield 15:21:01: Skipping optional support file _isuser1033.dll
InstallShield 15:21:01: Setting script cmdline...
InstallShield 15:21:01: ProductCode is {877B1166-A20F-4ACF-9BA9-D80EAD0A7D94}
MSI (s) (6C!D8) [15:21:01:492]: PROPERTY CHANGE: Deleting ALLUSERS property. Its current value is '1'.
InstallShield 15:21:01: Initializing Engine
InstallShield 15:21:01: Done Initializing...
InstallShield 15:21:01: Registering Msi Server...
InstallShield 15:21:01: Invoking script function MyFunction
MSI (s) (6C:40) [15:21:05:128]: NOTE: custom action NewCustomAction1 unexpectedly closed the hInstall handle (type MSIHANDLE) provided to it. The custom action should be fixed to not close that handle.
InstallShield 15:21:05: CallScriptFunctionFromMsiCA() ends
At this point, the best workaround may be to manifest your setup.exe to run AsAdministrator. This will mitigate the errant removal of the ALLUSERS property from what I understand of this issue.
If that doesn't work, let me know and I'll research it more.
The issue # for this is IOC-000063216.
The following log file snippet might represent a sample of this issue:
InstallShield 15:21:01: Skipping optional support file _isuser1033.dll
InstallShield 15:21:01: Setting script cmdline...
InstallShield 15:21:01: ProductCode is {877B1166-A20F-4ACF-9BA9-D80EAD0A7D94}
MSI (s) (6C!D8) [15:21:01:492]: PROPERTY CHANGE: Deleting ALLUSERS property. Its current value is '1'.
InstallShield 15:21:01: Initializing Engine
InstallShield 15:21:01: Done Initializing...
InstallShield 15:21:01: Registering Msi Server...
InstallShield 15:21:01: Invoking script function MyFunction
MSI (s) (6C:40) [15:21:05:128]: NOTE: custom action NewCustomAction1 unexpectedly closed the hInstall handle (type MSIHANDLE) provided to it. The custom action should be fixed to not close that handle.
InstallShield 15:21:05: CallScriptFunctionFromMsiCA() ends
At this point, the best workaround may be to manifest your setup.exe to run AsAdministrator. This will mitigate the errant removal of the ALLUSERS property from what I understand of this issue.
If that doesn't work, let me know and I'll research it more.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 16, 2007
09:04 AM
Thanks bryanwolf.
That matches exactly the behaviour. I also get the 'unexpectedly closed the hInstall handle' log entry for one of my CA´s.
Using 'requireAdministrator' for the requestedExecutionLevel of the Setup.exe would be a workaround but practically no reliable solution.
The elevation should be handled by MSI just to make sure that the installer has been written correctly and that it does all its system modification in deferred actions in the system context -> Best practice.
Do you know if Macrovision works on any Update or Hotfix for IS 2008?
-Nick
That matches exactly the behaviour. I also get the 'unexpectedly closed the hInstall handle' log entry for one of my CA´s.
Using 'requireAdministrator' for the requestedExecutionLevel of the Setup.exe would be a workaround but practically no reliable solution.
The elevation should be handled by MSI just to make sure that the installer has been written correctly and that it does all its system modification in deferred actions in the system context -> Best practice.
Do you know if Macrovision works on any Update or Hotfix for IS 2008?
-Nick
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 16, 2007
09:27 AM
Add my vote to a possible hotfix - I have a few InstallScript custom actions in a few different installers that I want to be Immediate Execution actions. What a bummer.
![](/skins/images/3B39CE851FDD5528C393F146EB70A2D0/responsive_peak/images/icon_anonymous_message.png)
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 16, 2007
10:42 AM
Because it was just submitted, we don't have much of any resolution for it quite yet. (clarification: it was previously submitted by another engineer, but it was literally just days ago)
Agreed - it's certainly not the optimal workaround; however, it's the only one I know that's guaranteed to work.
You could try calling MsiSetProperty on ALLUSERS at the beginning of all your immediate custom actions and see if that resolves the issue as well. Also not the best, but perhaps a superior workaround.
Sorry, I didn't test that so I can't say if it works or not. I'm just throwing out ideas.
The elevation should be handled by MSI just to make sure that the installer has been written correctly and that it does all its system modification in deferred actions in the system context -> Best practice.
Agreed - it's certainly not the optimal workaround; however, it's the only one I know that's guaranteed to work.
You could try calling MsiSetProperty on ALLUSERS at the beginning of all your immediate custom actions and see if that resolves the issue as well. Also not the best, but perhaps a superior workaround.
Sorry, I didn't test that so I can't say if it works or not. I'm just throwing out ideas.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 17, 2007
02:57 AM
bryanwolf wrote:
You could try calling MsiSetProperty on ALLUSERS at the beginning of all your immediate custom actions and see if that resolves the issue as well. Also not the best, but perhaps a superior workaround.
That seems to be a better workaround. Now my program group and shortcuts will be created for all users.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 04, 2007
07:51 AM
Hi,
"Using 'requireAdministrator' for the requestedExecutionLevel of the Setup.exe would be a workaround but practically no reliable solution. "
I'm installing with 'requireAdministrator' Level, and the installation from the Product work's fine. However, if i change the Product configuration over the Software Pannel, the CA's are working wrong and the ALLUSERS Property was still deleted. A cause can be, that does not appear the UAC Dialog while changing the software installation, cause the Maintanance Mode will not start with the Setup.exe but with the cache MSI.
"Using 'requireAdministrator' for the requestedExecutionLevel of the Setup.exe would be a workaround but practically no reliable solution. "
I'm installing with 'requireAdministrator' Level, and the installation from the Product work's fine. However, if i change the Product configuration over the Software Pannel, the CA's are working wrong and the ALLUSERS Property was still deleted. A cause can be, that does not appear the UAC Dialog while changing the software installation, cause the Maintanance Mode will not start with the Setup.exe but with the cache MSI.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 04, 2007
08:05 AM
I posted the question with Macrovision support for more info (the bug ID earlier was confirmed) and the problem is related to the modify, repair, change type installs only.
I did try the MsiSetProperty on ALLUSERS = 1 workaround at the beginning of each of my CA's and that appears to deal with the problem.
I did try the MsiSetProperty on ALLUSERS = 1 workaround at the beginning of each of my CA's and that appears to deal with the problem.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 30, 2007
10:19 AM
I see that there is a hotfix Q113652 which sounds related (search for 2008 hotfix ALLUSERS, or similar, at http://support.installshield.com/). The instructions for installing it seem a little confusing - just replicate the positions of the DLLs in folders similar to those in the zip, noting that they should replace backed-up DLLs of the same name.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 31, 2007
03:04 AM
Michael, thanks for the info. The hotfix seems to work properly.
But it looks like that the subdirectory structure inside the zip does not match the original IS2008 paths. The \Redist directory is missing for the \Language Independent directory inside the .zip file. Macrovision should fix that asap.
Question: Does this Hotfix also support the Standalone version?
-Nick
But it looks like that the subdirectory structure inside the zip does not match the original IS2008 paths. The \Redist directory is missing for the \Language Independent directory inside the .zip file. Macrovision should fix that asap.
Question: Does this Hotfix also support the Standalone version?
-Nick
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 01, 2007
10:04 AM
The files in it should be runtime files which are identical between IDE and standalone machines. I've forwarded the constructive criticism about the file paths to someone who should be able to fix it. Thanks!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 07, 2007
06:07 PM
Michael,
In the zip, the 3 ISSetup.dll should go to the following locations.
\Redist\Language Independent\i386\
\Redist\Language Independent\i386\ISP\
\System\
where is INSTALLDIR of InstallShield 2008.
On a standalone build, ISSetup.dll are found at the following locations.
\
\Redist\Language Independent\i386\
\Redist\Language Independent\i386\ISP\
where is the INSTALLDIR of InstallShield 2008 Standalone Build.
I did a binary comparison on the one in\ folder against the 3 original copies on my dev box under . It does not match any of the 3 copies. So, how should I update this one in \ folder?
In the zip, the 3 ISSetup.dll should go to the following locations.
where
On a standalone build, ISSetup.dll are found at the following locations.
where
I did a binary comparison on the one in
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 08, 2007
10:01 AM
Hi Tsung -
The ISSetup.dll in the System subfolder in the IDE case is equivalent to the root folder in the SAB case. The binary difference you are encountering is likely due to a difference in the timestamp in the signature, as I believe in IS2008 this got signed for each installation it was built into. Sheryl might be able to confirm that, or using the "IsReMan" tool to remove the signature might let you compare without this difference. (Obviously you should only do that on a copy...)
The ISSetup.dll in the System subfolder in the IDE case is equivalent to the root folder in the SAB case. The binary difference you are encountering is likely due to a difference in the timestamp in the signature, as I believe in IS2008 this got signed for each installation it was built into. Sheryl might be able to confirm that, or using the "IsReMan" tool to remove the signature might let you compare without this difference. (Obviously you should only do that on a copy...)
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 08, 2007
11:49 PM
I used IsReMan.exe (downloaded from KB Q113245) with /unsign switch to strip signature off the original copy (a backup, of course) of ISSetup.dll in \System\ and \, and compared them. They are still not identical.
The original copy of ISSetup.dll at the following locations are identical.
\Redist\Language Independent\i386\ISP\
\System\
So are these.
\Language Independent\i386\ISP\
\System
where is the location I extracted hotfix.zip to.
However, the original copy of ISSetup.dlls are not identical in the following locations.
\
\Redist\Language Independent\i386\ISP\
I would like to be sure that ISSetup.dll in\System can be safely used to replace the one in \ on a production SAB machine.
Can you get a confirmation from Sheryl? Thanks.
The original copy of ISSetup.dll at the following locations are identical.
So are these.
where
However, the original copy of ISSetup.dlls are not identical in the following locations.
I would like to be sure that ISSetup.dll in
Can you get a confirmation from Sheryl? Thanks.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 12, 2007
03:08 AM
MichaelU wrote:
Hi Tsung -
The ISSetup.dll in the System subfolder in the IDE case is equivalent to the root folder in the SAB case. The binary difference you are encountering is likely due to a difference in the timestamp in the signature, as I believe in IS2008 this got signed for each installation it was built into. Sheryl might be able to confirm that, or using the "IsReMan" tool to remove the signature might let you compare without this difference. (Obviously you should only do that on a copy...)
Michael, have you heard anything back yet? We would like to get a confirmation.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 12, 2007
09:49 AM
The files would be one-to-one from the IDE machine to the standalone machine, i.e., whatever files you replace on the IDE machine, replace the same ones on the standalone machine. The only files that really matter to this fix are the ones in the Redist\Language Independent\ folder:
i386\ISSetup.dll - this is used for InstallScript MSI projects and Basic MSI projects containing InstallScript custom actions
i386\ISP\ISSetup.dll - this is used for pure InstallScript projects
For the copy of ISSetup.dll in the System folder on the IDE machine, this corresponds to the copy of ISSetup.dll in the root standalone build folder.
i386\ISSetup.dll - this is used for InstallScript MSI projects and Basic MSI projects containing InstallScript custom actions
i386\ISP\ISSetup.dll - this is used for pure InstallScript projects
For the copy of ISSetup.dll in the System folder on the IDE machine, this corresponds to the copy of ISSetup.dll in the root standalone build folder.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 16, 2007
05:43 AM
Thanks for the confirmation.
![](/skins/images/3B39CE851FDD5528C393F146EB70A2D0/responsive_peak/images/icon_anonymous_message.png)