0

When I execute my MSI with UAC ON the UAC is not prompted for some time. I am trying to read some registry entry in a custom action before "CostFinalize". My Registry read function will consider a default value if registry entry is not found. But in my case the registry entry is there but it fails to read because the key doesn't have read permission for "User". Although Admin have full permission.

Registry read seems to be happening before UAC prompt. How can i make sure UAC is prompted at start only so that registry read can be successful.

Issue explanation

We have an old installer written in WIX. Where we are writing a registry entry for install location something like this

HKLM\Software\CompanyName\Product\Install\CompInstallDir = [InstallDir]\Product\Component.

This registry entry does have permission for Admin only even user doesnt have read permission I dont know why (i didnt write that code). there are some other entries under HKLM\Software\CompanyName\Product\Install

Now I have to make changes in the installer code for upgrade. In which i have to read this install location i.e., [InstallDir]Product\Component and trim it to [InstallDir]. So I already have an existing custom action (from previous installer code only) which reads the registry and sets Property INSTALLDIR, also some other properties and do backup of some config files. This custom action is under "InstallExecuteSequence" which as per my understanding should prompt for UAC if required. This custom action is called before "CostFinalize".

The thing which should have been there in old installer is Writing a registry entry containing only [InstallDir] which wasn't in place. Due to which that custom action is in place which is not a good way of doing, but being legacy code have to maintain it :(

Hope I am able to explain my problem :)

Kamal Deka
  • 148
  • 1
  • 14
  • My guess is someone used the LockPermissions table in a previous installer to set the permissions on the key and didn't realize they were stripping out all the default permissions. I think that's the real problem you should be solvin. – Christopher Painter May 30 '14 at 12:34
  • I cannot change the previous installer its already in the field :( – Kamal Deka May 30 '14 at 12:36
  • You're are supposed to avoid that problem. See: http://msdn.microsoft.com/en-us/library/windows/desktop/bb204770(v=vs.85).aspx#servicing_strategy – Christopher Painter May 30 '14 at 14:10

2 Answers2

1

In this SO thread I explain how UAC prompts are triggered.. Basically, you need a bootstrapper, and in its manifest set the execution level accordingly.

Regarding the custom action to read the registry. Why don't you use the built in support from Windows Installer to make a registry search, using AppSearch and RegLocator tables? As a general rule, its not recommended to reinvent the wheel. A default value for the search can be specified by simply defining the property (name of the search) in Property table.

Community
  • 1
  • 1
Bogdan Mitrache
  • 10,536
  • 19
  • 34
  • I agree that's the best way to do but there are some mistakes which is being done in the past. After searching the registry we have to do some string manipulation on the result so we are not able to use the builtin support. Basically we are trying to get install location during upgrade but the problem is while writing to registry we didnt write the top level install location instead we wrote the child dir such as [Installlocation]\Product\Component. So i need to extract [InstallLocation] not the child dir. – Kamal Deka May 30 '14 at 11:39
  • Can't you use AppSearch to get the full registry key/path and then analyze the result into a n immediate custom action and extract the install path from there? (sorry. but I don't understand exactly what and how you are trying to read from the registry) – Bogdan Mitrache May 30 '14 at 11:47
  • Updated the Question to explain the problem in details. I'll try AppSearch if that can help. – Kamal Deka May 30 '14 at 12:30
  • So from what I see my recommendation is valid. You can use the search the retrieve the full content from the registry value. Then from your custom action you can parse the result of the search, get only the install path and use it as desired. This way your custom action will no require any special permissions. Basically, the first part of your custom action, i.e. the reg search, is now replaced with the functionality from Windows Installer. – Bogdan Mitrache May 30 '14 at 12:34
0

The normal best practice is for the Install UI sequence to run as standard user and for the Install Execute sequence to elevate if the MSI is built to require it. ( For example a per-user install writing to per-user locations might not ever need elevation ).

The other best practice is to use AppSearch to read registry values into properties. The AppSearch also runs in the InstallUI sequence so normally the expectation is that these reads can be performed using standard user permissions.

In your case, you require admin to do the read. In all my years writing hundreds of installers I've never had that requirement. To give you better advice I'd have to ask what is the nature of this registry value and why is it only readable by administrators? After you read it, what do you intend to do with it?

Options include a bootstrapper to elevate the entire installer including UI sequence but that's usually not advised. Otherwise you need a deferred custom action running without impersonation (SYSTEM context) to do the read but at that point you can't set a property so you'd have to use the registry value right there for whatever purpose is intended.

Very strange requirement... I'm detecting a code smell.

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
  • Updated the Question hope that will help you to understand my problem. I agree with you code is not correct. – Kamal Deka May 30 '14 at 12:30
  • By default those types of HKLM data entries can be read by limited users, so it's bizarre that the original install secured them. In any case the CA code might just be wrong. e.g. It may be failing to retrieve the data because it's confused about the 32-bit/64-bit registry hives and this error is being interpreted as a security error, or it's opening the registry item in update mode. I wouldn't like to guess at the issue without a lot more data! – PhilDW May 30 '14 at 17:08
  • I'm suspecting the original install used LockPermissions and was shipped without noticing the defect. Now they are stuck trying to design around it. – Christopher Painter May 30 '14 at 18:18
  • 32/64 registry hives are handled correctly. Actually we are finding work around the defected product which is shipped :( – Kamal Deka Jun 02 '14 at 14:14
  • I've seen it in the past you release a patch to fix the defect and then have a launch condition in the new installer that gates on the patch / defect resolution. – Christopher Painter Jun 02 '14 at 14:25