Patching on Vista

[Blake_W]

I am doing a release of our software on Vista and I am having an issue. We released a BETA of our product a few months ago and was code signed. We require admin access for the setup.

I was reading the documentation and it says as long as you code sign the base installation and the patch with the same certificate, the patch will run with amdin access without giving it credentials. This is not the case for our patch we created to move our customers to the final release of our product. Unless you specifically run the Update.exe with admin privileges, the patch will fail.

One thing I noticed is that the patch must have an MsiDigitalCertificate table but I opened the MSP in Orca and no such table exists, even though InstallShield code signed it for me. From what I understand, InstallShield is supposed to author that table for me and I am not sure how else I can do this or if this is a bug? Any ideas?

[MichaelU]

I think there are two issues here that might be confusing things.

1) If the package requires administrative privileges when launching setup.exe, this indicates that it is probably not UAC compliant. Perhaps it has actions that require administrative privileges but are not scheduled for deferred execution in the system context. While this works out when launched elevated, proper MSI+UAC elevation will not provide privileges outside of that scheduling option. UAC Patching is generally done as an MSI+UAC elevation, so would encounter this.

2) The MsiDigitalCertificate table stores certificate thumbprints; the MsiPatchCertificate table references them and indicates that patches signed with that certificate are eligible for credential-free UAC Patching. The patch itself need only be signed with it, but could also patch those tables to change the list of allowed certificates. Note that even if the patch does change those tables, they will not show up as the raw tables in the patch if you open it directly with a tool like Orca; they're only part of the included transforms.

[Blake_W]

I'm not sure if I understand where you are coming from.

1) As far as I know, every installation package needs administrative privileges on Vista if they install files into C:\Program Files\ as this is "locked down" on Vista (only administrator's can manipulate files in this folder and subfolders). Also during the our installation, we write values to the HKLM\Software\ registry key, which also rquires admin privileges to write to on Vista. So inside the InstallShield project, I have the Require Administive Privileges (in General Information\Summary Information Stream) set to Yes and also Required Execution Level (in Releases\Setup.exe tab) set to Adminostrator.

2) As for actually patching, I am signing the patch with the same certificate as the original installation package so why does the patch still require me to run as an administrator to get it to succeed. I noticed when viewing the resources of my patch (using a resource hacker) that the application manifest only has the requestedExecutionLevel set to "asInvoker" while my main installation has it set to requireAdministor. Is this the way it is supposed to be and the patch will still assume admin privileges? What am I doing wrong?

[#4]

If the Require Administrative Privileges option is set to "Yes" in General Information\Summary Information Stream then Windows Installer will automatically attempt to elevate the Deferred script in the Execute sequence without further prompting. Marking the Setup.exe as requiresAdministrator ensures that the entire setup process from start to finish is elevated and not just the deferred script.

Installations should generally be authored in such a way that only the deferred script will require administrative privileges. As long as that is the case then you can leave the setup.exe set to asInvoker and not change it to requiresAdministrator.

In order to view the patch transform as Windows Installer will apply it, with Orca, you would want to go to Transform -> View Patch.

[Blake_W]

So say I leave my setup.exe as Require Administive Privileges set to Yes and also Required Execution Level set to Adminostrator and I sign both the setup.exe and my update.exe with the same code signing certificate. Isn't the patch supposed to assume admin privileges without having to enter in a admin user name and password (and the prompt for the user name and password not appear)? This does not seem to be the case in my testing.

I gathered this information from the InstallShield User Guide, Chapter 24, Non-Administrator Patches.

[#6]

Assuming all the rules for UAC patching were followed, that would be my expectation.

Do you happen to have a log of an install reproducing the issue?

[Blake_W]

I have attached log files from my MSI patch for both Standard user and Administrator (this was split into 2 files as a result of forum limitations).

It seems that the standard user log states that none of my components are marked for installation and the entire patch fails when it tries to execute an EXE in a custom action that is new to the patch but was not installed. The Admin patch log installs everything that it should and run fine. Why would this be?

[Blake_W]

I have done some further tests and it consistently does not mark any of my components to be installed and marks the feature as advertise. I have included this part of the log:

Standard User executing patch (many other components that have the same log):
Action start 8:39:43: InstallValidate.
MSI (s) (68:3C) [08:39:43:062]: PROPERTY CHANGE: Deleting MsiRestartManagerSessionKey property. Its current value is 'bec53b1705f0a3428bc452ba3406132c'.
MSI (s) (68:3C) [08:39:43:062]: Feature: Star_Plus_Files; Installed: Advertise; Request: Reinstall; Action: Reinstall
MSI (s) (68:3C) [08:39:43:062]: Component: __AboutStarPlus.exe65; Installed: Null; Request: Null; Action: Null
MSI (s) (68:3C) [08:39:43:077]: Component: AboutStarPlus.exe; Installed: Absent; Request: Null; Action: Null
MSI (s) (68:3C) [08:39:43:062]: Component: DataFilesNRGT; Installed: Absent; Request: Null; Action: Null
MSI (s) (68:3C) [08:39:43:062]: Component: DataFilesConfig; Installed: Absent; Request: Null; Action: Null

Administrator executing patch (many other coponents that have the same log):
Action start 8:41:09: InstallValidate.
MSI (s) (68:D8) [08:41:09:898]: PROPERTY CHANGE: Deleting MsiRestartManagerSessionKey property. Its current value is '8c915a82f9e32147954843f2078df631'.
MSI (s) (68:D8) [08:41:09:898]: Feature: Star_Plus_Files; Installed: Local; Request: Reinstall; Action: Reinstall
MSI (s) (68:D8) [08:41:09:898]: Component: __AboutStarPlus.exe65; Installed: Null; Request: Local; Action: Local
MSI (s) (68:D8) [08:41:09:913]: Component: AboutStarPlus.exe; Installed: Local; Request: Local; Action: Local
MSI (s) (68:D8) [08:41:09:898]: Component: DataFilesNRGT; Installed: Local; Request: Local; Action: Local
MSI (s) (68:D8) [08:41:09:898]: Component: DataFilesConfig; Installed: Local; Request: Local; Action: Local

Why would this be happening?? And I'm not sure why there is a __AbouStarPlus65 component. I only created the AboutStarPlus component and the patch just has a higher version of the file in it (and that is the only file updated in this patch).

The patch does not "fail" until it hits a custom action after installing the files and the custom action executes an installed file. An error occurs here (Error 2753.The File 'setstarpluspermissions.exe' is not marked for installation.) and the MSI fails.

Any help would be appreciated.

[#9]

Based on your log file, I think your issue is related to the bug addressed in the following hotfix:
http://kb.acresso.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=Q113652&sliceId=1&docTypeID=DT_HOTFIX_1_1&dialogID=20689108&stateId=0%200%2020687265

Please apply that, rebuild your latest release and rebuild your patch. After doing that, try to reproduce the issue.

[Blake_W]

That seems to have fixed it. Thanks alot!