This blog post is about a situation where after windows patching the SQL Server service and SQL Server Agent services will not start automatically – but will manually.
At a client site they had recently patched the servers – things went swimmingly – except the SQL Server services would not start.
Manually starting the services by right clicking | choosing start worked….
It is SQL Server 2017 with CU12 applied.
We tried a few things:
Making the services Automatic (Delayed)
Increasing the service pipeline timeout from 30 seconds to 60 seconds
But nothing worked.
Looking at the event logs I (eventually) found this:
Event ID 7000:
The MSSQLSERVER service failed to start due to the following error:
The account name is invalid or does not exist, or the password is invalid for the account name specified.
Which is bizarre – as the service account had been used for months – but after each reboot the services had to be manually started. GPO and other things had been blamed but no one could actually find out why.
Just for a laugh – I decided to “rename” the service account.
From svcSQL@<domain> to <domain>\svcSQL
Rebooted and it worked.
Just to make sure it wasn’t a false positive I left the SQL Server Agent service how it was – and it did not start.
As to why this is the case – I’m not sure. To date I had always set up my SQL Server services with <domain>\<service account> so I have never stumbled across this – until now.
But I don’t care too much – it means that the client can reboot their server and know SQL Server will come back…
Yip.
The Blog of The Hybrid DBA 
I think you will find it has to do with the time it takes the DC to be available to provide authentication services. I typically notice this when an entire location looses power or a entire rack goes down or the Vm Host crashes (it also hosts the Local DC). Yes, UPS do fail and when power is restored all the servers on the Vm Host restart or try to all at once. I traced this and noticed the SQL servers were attempting to coming on line before the local DC and then forced to use the Secondary DNS to get authentication required to start the SQL Server Service. The Secondary DNS was not local (in a different country on a different continent 245 ms away) and the authentication process failed. Or the server was setup with a Secondary DNS Server – check ipconfig. Renaming the service account in this case was not an option nor is creating a new one. FYI setting the services to Delayed Start is a really bad selection and should never be used for SQL Server services.
In a patching cycle the DC’s are typically patched independently to of the rest of the Servers and this condition should not present itself. when an entire rack goes down – boom ! perfect storm. This is what I have found any way – hope it helps.
LikeLike
Sorry missed a word here – “Or the server was setup with a Secondary DNS Server – check ipconfig.” should read “Or the server was not setup with a Secondary DNS Server – check ipconfig.”
LikeLike