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 actions (SQL) are executed as Local System Account, not as installing user.
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
‎Mar 28, 2011
09:16 AM
Custom actions (SQL) are executed as Local System Account, not as installing user.
Hello all,
we have big issues with the installation of our product. this installer contains Custom Actions (.NET Installer Class) that execute SQL Scripts against a configurable SQL Server database.
but at a lot of customers, this fails, and we noticed this is because the script gets executed as Local System Account and not under the user that is actually performing the installation. is there a way to force this? (this was never an issue before!)
any help would be greatly appreciated!
Best regards
we have big issues with the installation of our product. this installer contains Custom Actions (.NET Installer Class) that execute SQL Scripts against a configurable SQL Server database.
but at a lot of customers, this fails, and we noticed this is because the script gets executed as Local System Account and not under the user that is actually performing the installation. is there a way to force this? (this was never an issue before!)
any help would be greatly appreciated!
Best regards
(2) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 31, 2011
10:06 AM
Any idea, someone??
This is a showstopper for us.
This is a showstopper for us.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 31, 2011
12:49 PM
The custom actions created for Installer Classes are, by default, all created as deferred in system context actions, causing the behavior you see. Since many such actions are used to register services, or other actions that require privileges, our default is unlikely to change. Here are some options that should result in what you want. Note that Installer Classes are fragile and generally not recommended.
- Use our built-in SQL support
- Statically create the custom actions that invoke the Installer Class, and change their settings
- Change the global default in
\Support\0409\settings.xml elements named IS_Action with attribute Name="{GUID}.install" (and similar), by changing the Type attribute - Use a Managed Code Custom Action to run the same code as your Installer Class
![](/skins/images/A5EADE085F77DE82FB3B14D6B307AE6A/responsive_peak/images/icon_anonymous_message.png)