This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Found a solution
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 19, 2010
05:41 PM
Is it possible to enforce launching setup w/ "Run as Admin"?
Project type: Basic MSI
Target Platform: 64 bit Win7
Application type: 32 bit (running in 32 bit emulation) with 64 bit supporting USB drivers
We're installing signed USB device drivers (64 or 32 bit depending on OS) via DPInst(32 or 64).exe from a CA. Anyway, that seems to be working all well and good on all our target OSes. However, only on 64 bit OSes(Win7), the drivers only install if the setup.exe is launched with alt. click, "Run as Administrator". I'm not surprised this would be required for things like driver installs regardless of the current user having Admin rights (interestingly, this doesn't seem necessary on 32 bit Win7).
We can live with that behavior since it's probably a mandatory 64 bit OS thing. Problem is our install appears to run OK if it isn't launched this way and our device drivers silently fail to install. We'd like to address this by preventing our install from running on a 64 bit OS if not launched in the "Run as Administrator" manner.
So the question is:
Is their anyway in the msi package to detect if setup.exe bootstrapper was launched in the "Run as Administrator" manner so we can display an explanatory dialog and end the install?
Target Platform: 64 bit Win7
Application type: 32 bit (running in 32 bit emulation) with 64 bit supporting USB drivers
We're installing signed USB device drivers (64 or 32 bit depending on OS) via DPInst(32 or 64).exe from a CA. Anyway, that seems to be working all well and good on all our target OSes. However, only on 64 bit OSes(Win7), the drivers only install if the setup.exe is launched with alt. click, "Run as Administrator". I'm not surprised this would be required for things like driver installs regardless of the current user having Admin rights (interestingly, this doesn't seem necessary on 32 bit Win7).
We can live with that behavior since it's probably a mandatory 64 bit OS thing. Problem is our install appears to run OK if it isn't launched this way and our device drivers silently fail to install. We'd like to address this by preventing our install from running on a 64 bit OS if not launched in the "Run as Administrator" manner.
So the question is:
Is their anyway in the msi package to detect if setup.exe bootstrapper was launched in the "Run as Administrator" manner so we can display an explanatory dialog and end the install?
(6) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 19, 2010
08:12 PM
Since you have some CAs already you can handle this. Add another CA to launch a bat file something like below. Use the OPENFILES command to detect if the user has admin privileges. Note that we don't care about the output from the command... we only care about the error code. If it is 0, then OPENFILES worked and we obviously have admin privileges (required by OPENFILES). If it did not work, then we don't have admin privileges. Obviously you need to check the code returned in your CA. Don't use the HIDDEN option for LAUNCHAPPANDWAIT... at least until you get this working, so that you can see any error messages. You may want to put a pause in the bat file iniitially.
REM 2003 Server - If necessary
VER | FIND "Version 5.2." > nul
IF %ERRORLEVEL% == 0 (
REM Do OPENFILES to check for administrative privileges
OPENFILES > nul
IF ERRORLEVEL 1 (
COLOR CF
ECHO.You must be logged on as Administrator to run this program'.
PAUSE
EXIT /B 1
)
)
REM Vista and Newer
REM Do OPENFILES to check for administrative privileges
OPENFILES > nul
IF ERRORLEVEL 1 (
COLOR CF
ECHO.Right click and select 'Run as administrator'.
PAUSE
EXIT /B 1
)
REM 2003 Server - If necessary
VER | FIND "Version 5.2." > nul
IF %ERRORLEVEL% == 0 (
REM Do OPENFILES to check for administrative privileges
OPENFILES > nul
IF ERRORLEVEL 1 (
COLOR CF
ECHO.You must be logged on as Administrator to run this program'.
PAUSE
EXIT /B 1
)
)
REM Vista and Newer
REM Do OPENFILES to check for administrative privileges
OPENFILES > nul
IF ERRORLEVEL 1 (
COLOR CF
ECHO.Right click and select 'Run as administrator'.
PAUSE
EXIT /B 1
)
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 20, 2010
03:17 AM
You can check the Privileged Property.
The Privileged property indicates whether the installation is performed in the context of elevated privileges.
The installer does not set this property if the user is not allowed to install with elevated privileges.
The Privileged property indicates whether the installation is performed in the context of elevated privileges.
The installer does not set this property if the user is not allowed to install with elevated privileges.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 20, 2010
10:23 AM
If you're trying to detect inside the MSI whether the Install UI Sequence was launched with administrative privileges, perhaps try setting the MSIUSEREALADMINDETECTION property, and then querying the AdminUser property. You can leverage this in a launch condition or type 19 error custom action, instead of needing to write and run any custom code.
Note that requiring administrative priveleges in the Install UI Sequence is not a best practice, and may indicate that your CA calling DPinst is misconfigured. As it modifies the target system, it should be part of the execute sequence, and "deferred" (which comes with some limitations with regards to reading properties, but should be okay if this is an EXE custom action). Since it also needs administrative privileges, it should be "in system context".
Note that requiring administrative priveleges in the Install UI Sequence is not a best practice, and may indicate that your CA calling DPinst is misconfigured. As it modifies the target system, it should be part of the execute sequence, and "deferred" (which comes with some limitations with regards to reading properties, but should be okay if this is an EXE custom action). Since it also needs administrative privileges, it should be "in system context".
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 20, 2010
03:30 PM
Thanks for the tip!
Turned out I was able to set the Required Execution Level for the release to Administrator and that seems to cause the admin privileges to be in effect on the DPInst64.exe that is spawned in our differed exec CA. This install was ported from a different authoring tool and some test of prior installs indicated an similar setting like this was being used so an admin rights requirement is acceptable for us. Device drivers now install without launching via "run as administrator".
However, I do like that technique you suggested and am saving that one in my personal "bag of tricks". I could even use that as a "safety net" in case another developer (or I) forget to set this in future release configurations, since it's not a default release setting.
Turned out I was able to set the Required Execution Level for the release to Administrator and that seems to cause the admin privileges to be in effect on the DPInst64.exe that is spawned in our differed exec CA. This install was ported from a different authoring tool and some test of prior installs indicated an similar setting like this was being used so an admin rights requirement is acceptable for us. Device drivers now install without launching via "run as administrator".
However, I do like that technique you suggested and am saving that one in my personal "bag of tricks". I could even use that as a "safety net" in case another developer (or I) forget to set this in future release configurations, since it's not a default release setting.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 20, 2010
03:38 PM
Turned out I was able to set the Required Execution Level for the release to Administrator and that seems to cause the needed privileges to be in effect on the DPInst64.exe that is spawned in our CA.
Sorry, forget to mention it was a differed CA in the install execute sequence. I wasn't familiar with that property though, just looked it up in MSI help. I really need to familiarize myself with these sort of properties that pertain to security on the newer OSes.
Thanks.
MichaelU wrote:
If you're trying to detect inside the MSI whether the Install UI Sequence was launched with administrative privileges, perhaps try setting the MSIUSEREALADMINDETECTION property, and then querying the AdminUser property. You can leverage this in a launch condition or type 19 error custom action, instead of needing to write and run any custom code.
Sorry, forget to mention it was a differed CA in the install execute sequence. I wasn't familiar with that property though, just looked it up in MSI help. I really need to familiarize myself with these sort of properties that pertain to security on the newer OSes.
Thanks.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 20, 2010
03:42 PM
Roman1 wrote:
You can check the Privileged Property.
The Privileged property indicates whether the installation is performed in the context of elevated privileges.
The installer does not set this property if the user is not allowed to install with elevated privileges.
Thanks for the tip.
As indicated in my other replies, I found a different solution but I really need to familiarize myself with these security related properties.
![](/skins/images/8CE4FAD0DE6F3A6F9D0567434D2D2DAE/responsive_peak/images/icon_anonymous_message.png)