Any update on this?
Thanks,
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
