0

We have a software package that our customers install on their user's laptops.

Part of the installer runs MS's Sql Server Express 2014.

We're passing the command-line options to to the installer that are supposed to enable the SA login, and to grant sqladmin rights to the Windows BUILTIN\Administrators group.

The installer command line we run:

SETUP.EXE /QS /IACCEPTSQLSERVERLICENSETERMS /ACTION=Install /FEATURES=SQL /INSTANCENAME=SQLEXPRESS /SQLSYSADMINACCOUNTS="BUILTIN\Administrators" /SECURITYMODE=SQL /SAPWD="ASecretPassword"

AIUI, /SECURITYMODE=SQL is supposed to enable SA logun, and /SQLSYSADMINACCOUNTS= is supposed to grant sqladmin rights to a Windows group.

Documentation on these arguments is here:

Install SQL Server from the Command Prompt

And on every machine I try, and on the customer's machines, I can see exactly that command line in our installer log.

But on the customer's machine, these arguments don't seem to be taking effect.

When I run the following query:

SELECT name, is_disabled
    FROM master.sys.server_principals sp
    JOIN master.sys.server_role_members sr
    ON sr.member_principal_id = sp.principal_id
    WHERE sr.role_principal_id = 3

On a machine I've installed the software on, I see:

name                           type_desc        is_disabled
sa                             SQL_LOGIN        False
BUILTIN\Administrators         WINDOWS_GROUP    False
NT SERVICE\SQLWriter           WINDOWS_LOGIN    False
NT SERVICE\Winmgmt             WINDOWS_LOGIN    False
NT Service\MSSQL$SQLEXPRESS    WINDOWS_LOGIN    False
DESKTOP1\KT Developer          WINDOWS_LOGIN    False

Which is what I would expect.

But when the user runs that same query on a machine in his domain, after installing our software, he sees:

name                           type_desc        is_disabled
sa                             SQL_LOGIN        True

This despite our having passed arguments to the Sql Server Express install telling it to enable the SA login and to add authorization for BUILTIN/Administrators. Not only are we not seeing SA enabled, or admin rights granted to BUILTIN/Administrators, we're not seeing rights given to standard Windows Services.

At this point, I'm ready to tell the customer that the problem is with their own security group policies, and to tell them that they'll need to change the policies, there's nothing that we can do.

But before I do, I was looking for confirmation that the only reason that the installed Sql Express database doesn't have the administrative users we'd told it's installers to create is that the customer's own group policies are preventing it.

Can anyone think of any other reason why this might be happening?

Some additional clarifications.

This is an application and installer that have been working for many customers for many years. It stopped working for one customer after the Windows 1809 upgrade.

The install is failing on a clean laptop, with a fresh install of Windows 10, and no additional software installed.

jdege
  • 193
  • 9
  • 3
    `the only reason that the installed Sql Express database doesn't have the administrative users we'd told it's installers to create is that the customer's own group policies are preventing it`. Unlikely. Also, I suspect the 'we don't understand [insert something here] so it must be group policies' conjecture would not be received well. I don't see anything here about the SQL setup logs. Or the platform that the setup is running on. This question as it exists isn't answerable. For all we know they already have an instance named 'SQLEXPRESS', which is probably not the best choice for a name. – Greg Askew Nov 09 '18 at 17:24
  • 2
    Try checking the SQL Express install logs. `%programfiles%\Microsoft SQL Server\nnn\Setup Bootstrap\Log` https://docs.microsoft.com/en-us/sql/database-engine/install-windows/view-and-read-sql-server-setup-log-files?view=sql-server-2017 – Clayton Nov 09 '18 at 20:03

1 Answers1

0

Well, it turns out in this case, as in so many others, when what user reports as happening after he does something doesn't make any sense, it's because either the user isn't telling you what is happening or he isn't telling you what he's doing.

In this case, when the user was installing onto a "clean" machine, he was installing onto one which had the app installed and then uninstalled, but which had not had SQL Server Express uninstalled.

My changes to the Sql Server Express install to enable SA and BUILTIN\Administrators wasn't taking effect not because of security policies but because the SQL Server Express installer wouldn't run if it was already present.

jdege
  • 193
  • 9