Windows Installer - "Change" action does not require admin password in "Programs and Features"

Windows Installer - "Change" action does not require admin password in "Programs and Features"

• pkr2000

  Hello,

  Vista's new UAC and the existing managed install functionality are interacting in a bad way for me. My software allows you to change some settings when you select Modify from Software Explorer. The UAC prompt doesn't appear, the install is automatically elevated, BUT the install also sets the RestrictedUserControl property that prevents any of the new settings from reaching the server side of the installation:

  MSI (s) (E4:C8) [14:30:51:473]: PROPERTY CHANGE: Adding RestrictedUserControl property. Its value is '1'.
  MSI (s) (E4:C8) [14:30:51:473]: Ignoring disallowed property INSTALLDIR
  MSI (s) (E4:C8) [14:30:51:473]: Ignoring disallowed property...

  "Elevation" is not useful here. We need full privileges for a successful re-install.

  Before Vista, we used to test if the user is an admin and give an error message if not. Vista gives us the capability to tell if the user is an admin or if the install is elevated. But how do we know in advance if RestrictedUserControl will be set We don't want to wait until the server side of the installation starts, after the user has already entered data.

  Could there be a way to force UAC elevation when the user selects Modify from add/remove programs Many ways are provided to suppress the UAC prompt, but how do we make it appear when we need it

  Thanks,

  Gene

  
  

• Gulden

  Oliver, Have you had a chance to look into this yet
  
  Mike
  
  

• HariAdu

  Hi Bruce,

  The MSI won't take a manifest. I tried using mt and here's what happened:

  >mt -manifest manifest.xml -outputresourceetup.msi
  ...

  mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "setup.msi". The binary is not a valid Windows image.

  Is there any other way to force the MSI to request elevation when you run it Maybe an app compatibilty database entry

  thanks,

  Gene

  
  

• David Törnquist

  Are you using a Mainifest
  
  

• kastanienreis

  Yes, the MSI is signed. Elevation is also not required if you run the installer and choose "modify" from the MaintenanceType dialog. I'm not exactly sure what you mean with your question about "Change" being handled by an MSI or exe. We use the InstallShield setup.exe but that just launches msiexec on the extracted msi as far as I know. It is also signed and has a requestedExecutionLevel set to asInvoker.
  
  I wonder why Vista (and not XP) would allow any user to change the installed feature set. If an administrator only wanted a certain set of features installed, I don't think anyone else should be able to change that set of features.
  
  

• Tatworth

  Thanks for coming back... and posting I did some research and have a lot of information.
  
  

  Actually, for MSI based setups, non-admins can change (add/remove features) to their hearts content w/out requiring elevated privileges.  MSI has “sticky” elevation for managed applications (installed per-machine or per-user managed).

   

  The only thing that a non-admin cannot do is completely uninstall a per-machine application.

   

  This behavior is not new to Windows Vista.  The behavior for MSI as it pertains to managed applications is the same as it was for Windows 2000 and Windows XP.  Non-admins can add/remove features and perform reinstall of the product with a managed application.  The ability to “change” which in MSI correlates to configuring features to other states (local -> absent, absent -> local, run-from-source -> local, etc.) is innate.  Additionally, you’d have to have this functionality otherwise installation on demand would not work.  It would be a lousy experience to have the user have to get credentials from an admin just to install the spell checker.

  
  HOWEVER... SQL Server requires administrator, how is that done
  
  

  There are many entrypoints after initial install to invoke an installation.  A summary list (not exhaustive) includes:

  ·         Software Explorer (or Add/Remove Programs)

  ·         Shortcut, File Extension, COM CLSID – these refer to hooks for MSI packages that use the Class, Extension, Shortcut tables in a way that enables these specialized entrypoints.  The OS handles these differently.  Take the shortcut.  The “special” shortcut (also called an advertised shortcut or darwinized shortcut) has the target grayed out when you right-click properties on it.  This is because the target is actually a tuple consisting of the ProductCode, Feature, and ComponentId to which the shortcut belongs.  When the shortcut is double-clicked, the shell actually calls into MSI (via advapi32.dll) to resolve the tuple.  In doing so, MSI checks the health of the component and feature in question.  If unhealthy (the keypath of the component is missing), MSI will actually invoke an installation to install the component (or reinstall it) and then return the path to the keyfile of the component.  Shell will then launch the file referenced in the keypath

  ·         Command line (using msiexec.exe command line interface)

  ·         API (application calling MSI API like MsiProvideComponent)
  
  

  Install on demand is the installation of a resource when requested.  In the typical case, the resource has been advertised.  That generally means that there’s a published entrypoint, but the physical resource isn’t there.  For example, consider advertising the Office product.  You’ll see shortcuts for the Office apps (like Word, Excel, etc.) but the actual files (like winword.exe) aren’t there.  When you actually use the shortcut, the files will be installed “on-demand”.

   

  The other aspect to install on demand is resiliency.  This is where the resource had previously existed but has since been deleted.  The same mechanism used for install-on-demand can be used here and the resource can be replaced (or reinstalled).

   

  Software Explorer is actually a tricky component for most.  It has different behavior depending upon how your register your application with it.  I typically divide it into “MSI” registration and “legacy” registration.  If you use the native MSI registration, then you typically have three buttons exposed to you in ARP – modify, repair, remove.   This may change somewhat with Vista – but in prior OS’s like WinXP, the “legacy” case had a combined “change/remove” button.

   

  In any case, if you use native MSI, then MSI controls when prompting occurs.  MSI won’t prompt to add/remove features (or the ‘change’ button).  It will prompt to remove an application if it’s installed per-machine.  Now you bring up an interesting scenario and we have had some isolated feedback on occasion about blocking change/remove of features by non-admins.  However, it’s not a Vista specific scenario and in fact MSI’s behavior in this respect for standard users is unchanged since Windows 2000.  (UAC isn’t really new to MSI given our prior support in the corporate space for elevated install on behalf of non-privileged users.

  
   

  Something like SQL Server may use a bootstrapper to install because they chain together a set of MSI’s that represent the product.  They turn off the individual MSI representation in Software Explorer by using the ARPSYSTEMCOMPONENT property in the package authoring and then creating their own custom legacy UNINSTALL key reference that points to their “chainer”. 

   

  Recall that with the introduction of UAC, also came an additional setting for the application (fusion) manifest for an executable.  Within the manifest, you could indicate a requestedExecutionLevel of three values: asInvoker, highestAvailable, requiresAdmin. 

   

  Other wrench to throw in here those is Software Explorer’s own behavior.  For “legacy” registered applications, it actually auto-prompts no matter what for Change and Remove.  Software Explorer actually uses the new COM elevation moniker to invoke the “elevated” process for the registered uninstall or modify string executable.  For “native MSI” registered applications, software explorer won’t prompt at all because it understands that MSI handles its own prompting and does so only when necessary. Software Explorer actually added a new registry value that apps could register under the UNINSTALL key registration. It’s a DWORD called “NoElevateOnModify” which ensures that Software Explorer won’t force the elevation prompt for the legacy app.
  
  In summary It might be hard to control all of the entry points for the app to force elevation.  From the Software Explorer prespective, all that would be required is to set the property ARPSYSTEMCOMPONENT to 1 in the MSI package and add registration of new Uninstall key registry key + values to point to a setup executable.  This would give you the SQL experience from ARP.  If the MSIEXEC command line was used directly or if the MSI API were used, you wouldn’t get this though.
  

  
  
  

• Jim Pendarvis

  Hi Bruce,

  Were you able to take a look at this

  thanks,

  Gene

  
  

• windypoint

  MSI are automatically detected as needing elevation to install, uninstall.
  
  For patches and repair the assumption is that the msi was trusted with a digital signature, so an msi with the correct product code same digital signature will also be trusted for the patch and repair. Elevation isn't required by UAC. I think the same may be true for "Change", however it appears some applications are still able to require elevation for "Change". For example SQL 2005 requires elevation to "Change" from ARP. I'll research this more and confirm my speculation.
  
  Is "Change" handled by an exe or msi Is the MSI signed

  
  
  

• ippological

  Bruce, were you able to look at this

  thanks,

  Gene

  
  

• Mark_Davies

  Meetings. Can you mainfest the MSI
  
  

• LarryETL

  I use a bootstrapper that has a manifest (the bootstrapper not installed on the system, though). There is no manifest on the MSI itself.

  The MSI can be installed without the bootstrapper, as long as you can pass the UAC prompt.

  
  
• Windows Installer - "Change" action does not require admin password in "Programs and Features"