UAC and CD Access on Modify in 2008 R2

[JesseBearden]

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:



It then prompts for elevated privileges:



It then gives an Error 1706:



The installation then fails:



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.

[joshstechnij]

A log seems to indicate this is an issue with source management in Windows Installer:

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.

[JesseBearden]

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.

[joshstechnij]

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.

[JesseBearden]

I ended up going with something like this:

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?