Look what I found when I ran validate from Orca....
ICE68 ERROR TSAware flag (msidbCustomActionTypeTSAware) set for CustomAction
'RollbackExecuteSqlStrings'. Flag is only available for deferred,
impersonated custom actions
ICE68 ERROR TSAware flag (msidbCustomActionTypeTSAware) set for CustomAction
'ExecuteSqlStrings'. Flag is only available for deferred, impersonated
custom actions
ICE68 ERROR TSAware flag (msidbCustomActionTypeTSAware) set for CustomAction
'DropDatabase'. Flag is only available for deferred, impersonated custom
actions
ICE68 ERROR TSAware flag (msidbCustomActionTypeTSAware) set for CustomAction
'CreateDatabase'. Flag is only available for deferred, impersonated custom
actions
ICE68 ERROR TSAware flag (msidbCustomActionTypeTSAware) set for CustomAction
'RollbackCreateDatabase'. Flag is only available for deferred, impersonated
custom actions
Any clues how to fix this?
Jacob
On Sun, Mar 23, 2008 at 8:44 PM, Sajo Jacob <[EMAIL PROTECTED]> wrote:
> are you testing by running from an elevated command prompt? I believe
> this will cause impersonated actions to be elevated.
> No, Running uninstallation from an elevated command prompt is the only way
> I am able to cleanly uninstall the product along with the database. The
> uninstallation fails when I am trying to uninstall by going to Add Remove
> Programs and clicking on uninstall.
>
> If you turned impersonation *off* this would help you for the local
> installation case – as the action then runs as LocalSystem, which is a
> member of BUILTIN\Administrators
> Which immediate custom actions are you talking about here? And I am
> assuming you want me to edit the MSI with a post build event to turn off
> impersonation for these immediate actions that you mention of?
>
> My product installs a database on a local machine only, which it does
> create sucessfully without any issues even on SQLExpress. Like I mentioned
> earlier, the issue is only when I uninstall and the installer attempts to
> drop the database.
>
> Do you think I should simply do a DropOnUninstall="no" so that the
> database is not dropped by the custom actions generated by the
> WiXSQLExtension and manually drop the database from a VBScript custom action
> which is deferred?
>
> Jacob
>
>
> On Sun, Mar 23, 2008 at 2:56 AM, Mike Dimmick <[EMAIL PROTECTED]>
> wrote:
>
> > SQL Server 2005 has a very extensive security model of its own. In
> > order to drop a database, the connecting account needs CONTROL permission on
> > the database. This permission is automatically granted to the database owner
> > and implicitly to members of the *sysadmin* server role (CONTROL on a
> > database is implied by CONTROL SERVER permission on the server). The
> > BUILTIN\Administrators Windows security group is by default a member of the
> > *sysadmin* server role. On Windows Vista the membership of this group is
> > only expressed in the privileged token accessed through UAC, not in the
> > low-privilege token.
> >
> >
> >
> > The modifying SQL custom actions are all executed deferred and
> > impersonated. (As always, the custom tables built by the compiler are read
> > and turned into appropriate deferred custom action data by the immediate
> > actions, but the actual *operations* are performed by deferred actions
> > as part of the installation transaction.) My understanding of the
> > installation process under UAC was that even the create actions would not be
> > elevated – are you testing by running from an elevated command prompt? I
> > believe this will cause impersonated actions to be elevated.
> >
> >
> >
> > If you turned impersonation *off* this would help you for the local
> > installation case – as the action then runs as LocalSystem, which is a
> > member of BUILTIN\Administrators – but doesn't help for installation on a
> > remote SQL Server, which some users of WiX may need (as LocalSystem
> > authenticates as the machine on a domain network, but has no network
> > credentials in a workgroup).
> >
> >
> >
> > That really leaves specifying a SQL Server login to connect, but this is
> > turned off by default in the SQL Server Express installer and not
> > recommended in full SQL Server as the password is sent 'in the clear'. It's
> > only encrypted if the whole connection is encrypted, which requires that the
> > server has an SSL certificate installed. Many sites may not want to enable
> > SQL Server Authentication.
> >
> >
> >
> > I'm not sure there's a simple solution, because Windows Installer
> > doesn't offer a way to impersonate any other user. I'm rapidly concluding
> > that you can't reliably install SQL databases from Windows Installer. Any
> > competent DBA will want to control layout of files on the database server's
> > disks anyway. I think the best approach is to ship scripts and leave it up
> > to the DBA to create the database. That's the approach I'm taking.
> >
> >
> >
> > Another approach would be to provide the database as a separate feature,
> > so that the DBA or other administrator could run the MSI on the database
> > server itself to install the database.
> >
> >
> >
> > Microsoft's recommendation with SQL Server Express is to use the common
> > SQLEXPRESS instance and use the database attach feature, that is, specifying
> > AttachDBFilename or Initial File Name in the connection string. The database
> > file is then only associated with the database server when the connection is
> > open. This might be a good option if you don't need to support a remote SQL
> > Server.
> >
> >
> >
> > If you have a relatively low-spec database you could also consider SQL
> > Server Compact Edition, which is file-based and in-process (there is no
> > actual server). It's very limited on SQL syntax and datatype support,
> > though.
> >
> >
> >
> > Extension idea:
> >
> > There's no reason a custom action couldn't call LogonUser and
> > ImpersonateLoggedOnUser to change who it's running as. (If it's not
> > impersonated already, it's running as LocalSystem which has the TCB
> > privilege necessary to call LogonUser on Windows 2000.) It could be possible
> > to ask for alternate *Windows* login credentials to run these actions.
> > You would have to be careful to call RevertToSelf on all possible exit paths
> > to ensure that further custom actions using the same server process would
> > run with the correct credentials, however.
> >
> >
> >
> > --
> >
> > Mike Dimmick
> >
> >
> > ------------------------------
> >
> > *From:* [EMAIL PROTECTED] [mailto:
> > [EMAIL PROTECTED] *On Behalf Of *Sajo Jacob
> > *Sent:* 23 March 2008 04:46
> > *To:* Bob Arnson
> > *Cc:* wix-users@lists.sourceforge.net
> > *Subject:* Re: [WiX-users] WiXSqlExtension issue on Vista with UAC
> >
> >
> >
> > SQL Server 2005 Express. In fact this issue also causes the Repair
> > scenario to fail.
> >
> > Jacob
> >
> > On Sat, Mar 22, 2008 at 1:29 PM, Bob Arnson <[EMAIL PROTECTED]> wrote:
> >
> > Sajo Jacob wrote:
> >
> > If it is by design, then there is a problem with using WiXSqlExtension
> > for creating an installer for Vista/WS2008 because the *uninstallation*will
> > fail is you attempt to uninstall the product from Add/remove programs
> > because the custom actions to drop the database is getting executed as
> > immediate, unless you make the users use an elevated command prompt and
> > manually uninstall the product. (if you created a database using
> > WiXSqlExtension and have sqlstrings to drop the database.)
> >
> >
> >
> > Which SQL server are you using? The general case is that the server
> > itself has the permissions needed to manipulate the file system.
> >
> >
> >
> >
> > --
> >
> > sig://boB
> >
> > http://joyofsetup.com/
> >
> >
> >
>
>
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
