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/
>
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
