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
- :
- Re: Custom action in Basic MSI, in-script execution?
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
Jun 26, 2013
10:01 AM
Custom action in Basic MSI, in-script execution?
Hello,
I have a question relating to setting up a custom action and which in-script execution to use.
I am confused with the "Terminal Server Aware" option. For instance I have the following options...
- Deferred Execution
and
- Deferred Execution (Terminal Server Aware)
The custom action that runs a .bat file and will be installed both locally and by a remote desktop connection.
Is it better to use Deferred Execution (Terminal Server Aware) since the software could be installed via a remote desktop?
What are the differences between the two?
Thanks in advance!!
I have a question relating to setting up a custom action and which in-script execution to use.
I am confused with the "Terminal Server Aware" option. For instance I have the following options...
- Deferred Execution
and
- Deferred Execution (Terminal Server Aware)
The custom action that runs a .bat file and will be installed both locally and by a remote desktop connection.
Is it better to use Deferred Execution (Terminal Server Aware) since the software could be installed via a remote desktop?
What are the differences between the two?
Thanks in advance!!
(1) Reply
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Jun 27, 2013
08:10 AM
The msidbCustomActionTypeTSAware flag differentiates between the user context in which your deferred (i.e. "in-script") custom action will execute.
See http://msdn.microsoft.com/en-us/library/windows/desktop/aa368069(v=vs.85).aspx
"Executes with user impersonation. Runs with user impersonation during per-machine installs on a server running the Terminal Server role service. Normal deferred execution custom actions, without this attribute, run with no user impersonation on a terminal server during per-machine installations. This attribute has no effect if the action also has the msidbCustomActionTypeNoImpersonate attribute."
I admit that I do not have the experience launching a .bat file from a in-script custom action, but my guess is that it depends on what the CA and the .bat are doing and what the user's privileges are. When using Remote Desktop without this flag the CA will run in the context of the remote server's local system account (even if on a 'local' system it would have run using impersonation). With this flag the CA would run in the context of the user that connected to the remote server (unless the 'no impersonation' flag was also used), the same as it would run on the local system. At least that is my understanding.
See http://msdn.microsoft.com/en-us/library/windows/desktop/aa368069(v=vs.85).aspx
"Executes with user impersonation. Runs with user impersonation during per-machine installs on a server running the Terminal Server role service. Normal deferred execution custom actions, without this attribute, run with no user impersonation on a terminal server during per-machine installations. This attribute has no effect if the action also has the msidbCustomActionTypeNoImpersonate attribute."
I admit that I do not have the experience launching a .bat file from a in-script custom action, but my guess is that it depends on what the CA and the .bat are doing and what the user's privileges are. When using Remote Desktop without this flag the CA will run in the context of the remote server's local system account (even if on a 'local' system it would have run using impersonation). With this flag the CA would run in the context of the user that connected to the remote server (unless the 'no impersonation' flag was also used), the same as it would run on the local system. At least that is my understanding.