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?

  • Note that if, logged in as Administrator, I run c:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Binn\sqlservr.exe -s MSSQLSERVER I get a running server, but I had to use OSQL to reset SA password as the MS SQL installer did NOT set it. I can not get the service to start up when I have it log in with its default account, nor if I make it start up with my own user account which is a local administrator for this machine. If I start it up using my User Account, it fails with Error 1067, The process terminated unexpectedly. – Warren P Oct 29 '15 at 20:46
  • Okay really really weird: I am able to get it to start once I used OSQL to reset the SA password, and change the Service login to NT AUTHORITY\LOCALSERVICE. Is it okay to leave it like that on my workstation? – Warren P Oct 29 '15 at 21:00
  • More help on getting past Microsoft's inability to build a rugged installer and deployment tools for SQL 2014, and SQL 2016: blog.brankovucinec.com/2015/04/08/… – Warren P Nov 3 '15 at 21:52
  • A link to the Error Help link which Microsoft currently has NO HELP at. error 50000 Source: setup.rll go.microsoft.com/… – Warren P Nov 4 '15 at 14:37

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/ .

  • It is interesting that the installer (at least on Server OS) won't let me select NT AUTHORITY\LOCALSERVICE during the installer's page where it lets you select your logon accounts. It says this is not allowed. I am not sure why. Clearly not good for production, but why would it be bad for a DBA or Developer's own local test/eval workstation instances. – Warren P Oct 30 '15 at 15:20
  • In later builds SQL Server 2016 installer behaviour was changed. – Warren P Aug 30 '16 at 16:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.