During install of MS SQL Server 2016, on a developer/DBA workstation client PC which is joined to a domain, the installation using all logon and other installer defaults, completes with failures, and a very generic message that just means that the main SQL Database Engine Service (MSSQLSERVER) did not start. Starting it manually from services.msc, one sees this equally generic error:
Windows could not start the SQL Server (MSSQLSERVER) on Local Computer.
For more information, review the System Event Log. If this is a
non-Microsoft service, contact the service vendor, and refer
to service-specific error code -2146885628.
In the system event viewer (eventvwr.msc) there are several failures:
#1. (1500) User Profile Service error for user NT SERVICE\MSSQLSERVER: Windows
cannot log you on because your profile cannot be loaded. Check that
you are connected to the network, and that your network is
functioning correctly.
#2. (17826) Could not start the network library because of an internal error in
the network library. To determine the cause, review the errors
immediately preceding this one in the error log.
#3. (17182) TDSSNIClient initialization failed with error 0x80092004,
status code 0x1. Reason: Initialization failed with an infrastructure
error. Check for previous errors. Cannot find object or property.
#4. (17182) TDSSNIClient initialization failed with error 0x80092004, status
code 0x80. Reason: Unable to initialize SSL support. Cannot find
object or property.
#5. (17190) Initializing the FallBack certificate failed with error
code: 1, state: 20, error number: 0.
There are hundreds of kilobytes of log files, but no clear output in any of them to indicate a root cause.
This appears to be a variant of the SSL-init-failure startup failure case, but I had this same error with CTP 2.3, and was hoping that the SQL Server installer would help me figure out why none of the Windows 10 PCs in my local office domain will accept and run MS SQL 2016 (or MS SQL 2014) without hitting some variation of these SQL errors.
SystemConfigurationCheck_Report.htm contains no errors, everything is green checkmarks, and no errors were reported during the actual installation. There were no other MS SQL services/instances on the machine previously, but there is a Visual Studio 2015 and MS SQL localdb.
Is this an SQL error, or some local profile error, or something else? I tried this in SQL 2016 CTP 2.3 and 2.4, and had the same issue. I decided to wait until SQL 2016 CTP 3, which is now out, but I have the same issue.
It seems to me that on windows 10, with the sql service logged on as NT SERVICE\MSSQLSERVER everything SHOULD just work. But it does not.
This question really boils down to "Why does MS SQL pick a service login account named NT SERVICE\MSSQLSERVERand then fail to ensure that this account is valid, and can work with SSL, or has a local profile that is valid, or whatever else sqlsrvr.exe needs to run?", and given that the installer default behaviour is unsuitable even for a DBA or SQL Developer's own private workstation (a non production environment), what should one do instead?
Best Answer
Interesting. Glad you got the SQL service to start. It should be okay to leave it as NT AUTHORITY\LOCALSERVICE for testing CTP3 on your workstation. In general for production servers on a domain it is best to provision and use domain service accounts for the SQL Server and Agent services - see https://www.simple-talk.com/sql/database-administration/provisioning-a-new-sql-server-instance-%E2%80%93-part-one/ .