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: UAC and CD Access on Modify in 2008 R2
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
‎Apr 27, 2011
08:35 PM
UAC and CD Access on Modify in 2008 R2
I'm running in to a weird issue where "Modify" fails to work properly when UAC is enabled on Windows 2008 R2, and the installation was installed off of a CD/DVD drive. The install pops up a message asking where the CD is:
![](/legacyfs/online/vb/9050_one.jpg)
It then prompts for elevated privileges:
![](/legacyfs/online/vb/9051_two.jpg)
It then gives an Error 1706:
![](/legacyfs/online/vb/9052_three.jpg)
The installation then fails:
![](/legacyfs/online/vb/9053_four.jpg)
This only seems to happen if the installation was launched through the Add/Remove programs, but running the setup.exe from the disc works fine. (As does running the msi directly via msiexec from an elevated command prompt). I could not repeat the issue in Windows 7.
I went ahead and made a test product with 2 features that installs 2 seperate text files. If you install from the attached ISO(As a CD), then modify to add one of the files you can see the error.
I created an identical project in WiX as a comparison, and it appeared to work fine.
Attached are the project files for both installs, an ISO for each install to use for testing, the msi's, and the log file from the failed installation.
If anyone from Installshield could help with this issue, or anyone else, I'd greatly appreciate it. Our actual installation is in Installshield 2010, but I repeated the results with the test app in 2011.
![](/legacyfs/online/vb/9050_one.jpg)
It then prompts for elevated privileges:
![](/legacyfs/online/vb/9051_two.jpg)
It then gives an Error 1706:
![](/legacyfs/online/vb/9052_three.jpg)
The installation then fails:
![](/legacyfs/online/vb/9053_four.jpg)
This only seems to happen if the installation was launched through the Add/Remove programs, but running the setup.exe from the disc works fine. (As does running the msi directly via msiexec from an elevated command prompt). I could not repeat the issue in Windows 7.
I went ahead and made a test product with 2 features that installs 2 seperate text files. If you install from the attached ISO(As a CD), then modify to add one of the files you can see the error.
I created an identical project in WiX as a comparison, and it appeared to work fine.
Attached are the project files for both installs, an ISO for each install to use for testing, the msi's, and the log file from the failed installation.
If anyone from Installshield could help with this issue, or anyone else, I'd greatly appreciate it. Our actual installation is in Installshield 2010, but I repeated the results with the test app in 2011.
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 28, 2011
05:02 PM
A log seems to indicate this is an issue with source management in Windows Installer:
This seems to be the result of system MSI policy settings. Note that the above log info was obtained on a Windows 7 machine.
There shouldn't be any reason why any other MSI that is installed per-machine (ALLUSERS=1) doesn't reproduce this same behavior on the same machine. A per-user based install, which does not require any elevated privileges, will be unlikely to encounter this behavior.
It appears that enabling policies such as AllowLockdownMedia and AllowLockdownBrowse are probably the only ways to work around this behavior. However, it would seem that Windows Installer may have a bug when it rejects the UAC approved media as noted in the above log.
MSI (c) (54:EC) [16:32:21:958]: SOURCEMGMT: Trying source E:\UACAddRemoveTest.msi.
MSI (c) (54:EC) [16:32:21:959]: Entering CMsiConfigurationManager::SetLastUsedSource.
...
MSI (c) (54:EC) [16:32:21:960]: Warning: rejected media source due to system policy.
MSI (c) (54:EC) [16:32:21:960]: MSI_LUA: Attempting 'try harder' method for source that is not in the trusted list and not allowed by default by policy
...
MSI (c) (54:EC) [16:32:27:466]: MSI_LUA: Source resolution and approval provided for source 'E:\'
MSI (c) (54:EC) [16:32:27:466]: MSI_LUA: 'Try Harder' succeeded and source accepted
MSI (c) (54:84) [16:32:27:471]: SOURCEMGMT: Resolved source to: 'E:\'
...
MSI (s) (28:F0) [16:32:27:456]: Entering CMsiConfigurationManager::SetLastUsedSource.
...
MSI (s) (28:F0) [16:32:27:456]: Warning: rejected media source due to system policy.
This seems to be the result of system MSI policy settings. Note that the above log info was obtained on a Windows 7 machine.
There shouldn't be any reason why any other MSI that is installed per-machine (ALLUSERS=1) doesn't reproduce this same behavior on the same machine. A per-user based install, which does not require any elevated privileges, will be unlikely to encounter this behavior.
It appears that enabling policies such as AllowLockdownMedia and AllowLockdownBrowse are probably the only ways to work around this behavior. However, it would seem that Windows Installer may have a bug when it rejects the UAC approved media as noted in the above log.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 28, 2011
07:18 PM
joshstechnij wrote:
This seems to be the result of system MSI policy settings. Note that the above log info was obtained on a Windows 7 machine.
Weird, it only happened on a clean install of Windows 2008 R2 for me, but then neither of my VMs are attached to a domain, so it might be default settings of some sort?
joshstechnij wrote:
There shouldn't be any reason why any other MSI that is installed per-machine (ALLUSERS=1) doesn't reproduce this same behavior on the same machine.
I guess you're right, the WiX version does do the same, but defaulted to per-user. My mistake on that one. Thank you for your help and response.
joshstechnij wrote:
It appears that enabling policies such as AllowLockdownMedia and AllowLockdownBrowse are probably the only ways to work around this behavior. However, it would seem that Windows Installer may have a bug when it rejects the UAC approved media as noted in the above log.
We'd tried the AllowLockdownMedia, but it doesn't exactly behave in a normal fashion either, and changing the system policy during an install seems like bad form.
In the end, I guess this is a Microsoft bug, but a really weird one. It seems pretty bad, and you'd think someone would have noticed it by now.
I do wonder if there's a better way to handle this. One thought that springs to mind would be caching the MSI locally, but this particular install is uncompressed, and I believe that's not an option the bootstrapper in an uncompressed installation.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 29, 2011
12:06 PM
It is possible to use a custom action that runs after the RegisterProduct and PublishProduct actions that copies the source media files to a cached location, and then calls the MsiSourceListAddSource API to register the cached location as a source path. Unfortunately, the one thing the MsiSourceListAddSource docs do not clarify is whether a source added with this API is considered secure and trusted. A test using this API would help to determine if this is the case or not.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 23, 2011
04:33 PM
I ended up going with something like this:
I couldn't get the native installscript xcopy function to work because the source was in use, so I went back to good ol LaunchApp. I feel like I'm missing something there, but I don't have time to keep messing with it.
There should obviously also be an uninstall version of this, and this version with the Launch App doesn't really check for copy failure/disk space.
I'm not 100% sure how I feel about this solution for our problem, as I worry about Minor Upgrades/Patches. Off the top of my head it seems like it'd be fine as long as the conditions on the action are correct.
Any chance of you guys modifying the "Cache MSI Locally" option to support uncompressed installations?
prototype NUMBER Msi.MsiSourceListAddSourceA(BYVAL STRING, BYVAL STRING, BYVAL NUMBER, BYVAL STRING);
function MediaLocalCopy(hMSI)
NUMBER nSize, nReturn;
STRING sSrcDirectory, sDstDirectory;
begin
nSize = MAX_PATH+1;
MsiGetProperty(hMSI, "SETUPEXEDIR", sSrcDirectory, nSize);
SprintfMsiLog("Getting property SETUPEXEDIR %s", sSrcDirectory);
if (StrLength(sSrcDirectory) == 0 || !Is(PATH_EXISTS, sSrcDirectory)) then
SprintfMsiLog("SETUPEXEDIR Doesn't exist. Value: %s", sSrcDirectory);
else
//
// Get the destination directory
//
sDstDirectory = LocalAppDataFolder;
SprintfMsiLog("Got LocalAppDataFolder: %s", sDstDirectory);
if (Is(PATH_EXISTS, sDstDirectory)) then
sDstDirectory = sDstDirectory ^ "Downloaded Installations\\Repro Desk";
SprintfMsiLog("Copying. Source: %s, Destination: %s", sSrcDirectory, sDstDirectory);
LaunchApplication(WINSYSDIR ^ "Xcopy.exe", sSrcDirectory + " " + sDstDirectory + "/Y /R", " ", SW_HIDE, 10000, LAAW_OPTION_WAIT);
SprintfMsiLog("Adding Source: %s to product: %s", sDstDirectory, PRODUCT_GUID);
nReturn = MsiSourceListAddSourceA(PRODUCT_GUID, "", 0, sDstDirectory);
if (nReturn != 0) then
SprintfMsiLog("SourceListAddSource Failed with return: %d, reason %s", nReturn, FormatMessage(nReturn));
endif;
endif;
endif;
end;
I couldn't get the native installscript xcopy function to work because the source was in use, so I went back to good ol LaunchApp. I feel like I'm missing something there, but I don't have time to keep messing with it.
There should obviously also be an uninstall version of this, and this version with the Launch App doesn't really check for copy failure/disk space.
I'm not 100% sure how I feel about this solution for our problem, as I worry about Minor Upgrades/Patches. Off the top of my head it seems like it'd be fine as long as the conditions on the action are correct.
Any chance of you guys modifying the "Cache MSI Locally" option to support uncompressed installations?
![](/skins/images/D60DF682EA37BF37032955CE10F3F0BB/responsive_peak/images/icon_anonymous_message.png)