![]() ![]() Click Active Directory Users and Computers.Type Administrative tools and select it. ![]() Here’s how to do this if the user is in an Active Directory domain: How to restore user’s right on a Domain Controller If the right to log on as a service is revoked for the user account, restore it on a domain controller or a member server (standalone) depending on your situation. In my case (Windows Server 2019 and SQL Server 2019), this was due to the fact that the user responsible for running as a service does not have the right to log on as a service.įrom Fix: The service did not start due to a logon failure by Milan Stanojevic: Once I changed the "OriginalMachineName" value in the registry, problem solved! This is obviously a workaround for me so I am still researching.Īctually, my problem was rooted in the machine having been renamed previously. Switched back to autologon as the built-in Administrator account et voila! SQL Server service is now starting automatically. Nothing worked.Įven uninstalled SQL Server 2014 Express, rebooted, manually removed all leftover files/folders and rebooted again and reinstalled under the new administrator user. I tried delayed start, tried Local Service, tried Network Service, tried the new administrator user, tried the Always Wait. I wanted to create a new user that wasn't the built-in local Administrator so I created a new user, added it to the Administrators group, set that user to autologon upon boot et voila! SQL Server service fails to start automatically. I have been having this exact same problem with SQL 2014 Express on Windows 10. Have you tried logging on as the local Administrator? Subkey: \Software\Policies\Microsoft\Windows NT\CurrentVersion\Winlogon\ If the following registry value doesn’t exist or its value is not set to 1, then this is a finding: The policy value for Computer Configuration -> Administrative Templates -> System -> Logon “Always Wait for the Network at Computer Startup and Logon” will be set to “Enabled”. ![]() I found this in some article I saved long ago when I had a similar issue with an AD home directory (not via login script) to map home directory for a workstation PC: Not sure if that's exactly applicable in your case but this is something to at least simply investigate and try to test at least just in case. Just in case you notice this when you log onto the server after reboots, it actually logs onto the OS with the cached credential before it can reach the domain controllers to authenticate (network connectivity not fully established) with the login credential if it's a domain credential the SQLExpress service account is running as. You may want to check for either local or domain level group policy settings to not allow logon or OS startup until full network connectivity is established. Just a quick thought on something to look into, in a domain type environment, some operating systems allow you to logon to the server before full network connectivity is established. ![]()
0 Comments
Leave a Reply. |