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

    Question

  • Why does Windows Vista not prompt for admin password when selecting "Change" in "Programs and Features"? Even a limited user is able to add or remove features from our installed product. The strange thing is that the installer prompts for elevation when installing and uninstalling.

    This appears to be a bug in Vista only (and a pretty serious one at that). On XP, only an administrator can change the set of installed features.

    Our installer has ALLUSERS set to 1 and ARPNOMODIFY set to 0.

    Mike Morrison
    Tuesday, January 16, 2007 5:47 PM

Answers

  • 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.

    Friday, January 19, 2007 6:58 PM

All replies

  • 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?

    Tuesday, January 16, 2007 8:00 PM
  • 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.
    Tuesday, January 16, 2007 8:56 PM
  • Oliver, Have you had a chance to look into this yet?

    Mike
    Friday, January 19, 2007 6:31 PM
  • 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.

    Friday, January 19, 2007 6:58 PM
  • 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

     

    Tuesday, June 19, 2007 3:05 PM
  • Are you using a Mainifest?
    Tuesday, June 19, 2007 5:50 PM
  • 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.

     

    Tuesday, June 19, 2007 6:36 PM
  • Bruce, were you able to look at this?

     

    thanks,

    Gene

     

    Friday, June 22, 2007 7:22 PM
  • Meetings. Can you mainfest the MSI?
    Friday, June 22, 2007 7:48 PM
  • Hi Bruce,

     

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

     

    >mt -manifest manifest.xml -outputresourceTongue Tiedetup.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

    Friday, June 22, 2007 9:30 PM
  • Hi Bruce,

     

    Were you able to take a look at this?

     

    thanks,

    Gene

    Thursday, June 28, 2007 8:25 PM
  •  Oliver Lundt - MSFT wrote:

    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. 

     

    I don't think so.  I have a managed installation that requires admin rights to install.  The installation has a bootstrapper EXE (standard InstallShield 12 bootstrapper properly manifested with the "requireAdministrator" setting for the security attribute as well as being digitally signed), an MSI package external to the bootstrapper (with properly authored records in the MsiDigitalCertificate, MsiDigitalSignature, and MsiPatchCertificate tables as well as being digitally signed itself), and several external CAB files (all of which are also digitally signed).  Also note that I have not set values for any of the ARP MSI properties (ARPNOMODIFY, ARPNOREPAIR, or ARPNOREMOVE).

     

    On BOTH Windows 2000 SP4 and Windows XP SP2, limited users can only repair this managed installation when it is installed by an admin user (via the "Support Information"-->Repair option in Add/Remove Programs). On both these systems, in Add/Remove Programs the "Change" and "Remove" buttons are either visible but disabled (Win2K SP4) or they are not visible at all (WinXP SP2). On these systems, only a user who is a member of the Administrators user group has the "Change" and "Remove" buttons both visible AND enabled.

    However, on Windows Vista (GA) and Windows Server 2008 (RC1) systems, the same buttons are displayed in Software Explorer for all users (Uninstall, Change, Repair).  If a limited user (standard user) clicks the Uninstall or Repair buttons, the msiexec process runs the installation and they are (eventually) prompted to elevate to Admin to continue.  The SAME is the case if they click the Change button AND they attempt to ADD an optional feature (they are eventually prompted to elevate).  However, if the limited/standard user clicks the Change button and they REMOVE an optional feature then they are never prompted to elevate.

     

    Why can a limited user remove optional features for a managed application installed by an admin on Vista/WS2K8 systems but they are not allowed to do so on Win2K/WinXP systems?  If this is intended behavior, what are my options if my managed application has such an optional feature that non-admin users should not be allowed to uninstall?

    Tuesday, February 19, 2008 9:35 PM
  •  

    Add a launch condition that will query a HKLM key prompting user for elevation
    Thursday, February 21, 2008 11:05 PM
  • Are you talking about adding an AppSearch/RegLocator query to set a property that a launch condition can then evaluate?  What registry key in HKLM should be searched for?

    Thursday, February 21, 2008 11:18 PM
  • see responses to posting on Vista Security for Applications forum at https://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2879644&SiteID=1

    Monday, March 03, 2008 4:59 PM