SQL SERVER – FIX: SQL Service Does Not Start After Promoting the Machine as Domain Controller

A blog reader asked for urgent help on a call. They had promoted their SQL Server 2014 machine to a domain controller, and now SQL Server would not start because of an authentication error. We got it running. But the workaround we used is one I would now describe very differently, so here is the whole story, including the part I would not repeat.

Why It Broke

Microsoft’s documentation has a clear rule here. Once SQL Server is installed, you cannot change the machine from a domain member to a domain controller. You uninstall SQL Server first, promote the machine, then install again.

The likely reason is the service accounts. When SQL Server is installed on an ordinary machine, its services usually run under per-service virtual accounts, the ones named like NT Service\MSSQLSERVER. I do not know which accounts my reader’s install used, but this is the default. You can see mine:

Get-CimInstance Win32_Service -Filter "Name LIKE 'MSSQL%'" |
    Select-Object Name, StartName

Name                   StartName
MSSQL$SQLDEV           NT Service\MSSQL$SQLDEV
MSSQLLaunchpad$SQLDEV  NT Service\MSSQLLaunchpad$SQLDEV

Those are local accounts, and the documentation says SQL Server services cannot run under a local service account on a domain controller. It does not spell out the mechanism, so here is my understanding of it. A domain controller has no ordinary local account database, because its accounts are the domain’s accounts. Promote the machine, and the identities the services were installed with, along with the permissions setup granted to them, no longer line up. The service cannot log on, and SQL Server never starts. That matches what my reader saw: an authentication error at start.

What We Did on the Call

We changed every SQL Server service to run as LocalSystem: the Database Engine, SQL Server Agent, Integration Services and Reporting Services. SQL Server started.

LocalSystem works because it has rights over everything on the machine. That includes every folder and registry key the old virtual accounts had been given. Nothing needs granting, because it already has it all. That is also exactly why I would not leave it that way.

Why That Should Only Be a Stopgap

LocalSystem is the most powerful account on a Windows machine. On a domain controller, that machine is the heart of the domain. So SQL Server running as LocalSystem there is a database engine holding the keys to the whole domain. Any flaw that lets someone run code through SQL Server now hands them the domain.

It also leaves you outside what Microsoft supports. The documented rule is not “fix the service account”, it is “uninstall before you change the role”. A server in that state may start. But when something else goes wrong, you may find support hard to get.

So LocalSystem got my reader running that day, in a hurry, and that was the right call for that hour. It should have been followed by a plan to move things properly.

The Real Fix

In order of preference:

Move SQL Server off the domain controller. Install it on a separate member server and move the databases across with backup and restore. Leave the domain controller doing its own job. This is where Microsoft’s guidance points, and it removes the risk.

If it really has to stay, follow the documented order: back up everything, uninstall SQL Server, keep the machine’s new role, install SQL Server again, and restore. During the new install, give the services a dedicated, low-privileged domain account rather than LocalSystem.

If you are stuck with the workaround for now, at least change the services from LocalSystem to a dedicated domain account using SQL Server Configuration Manager, which grants the rights the account needs. Do not use the Services applet for that, because it changes the account without granting anything.

How to Avoid It Next Time

Before anyone promotes a server, check what is installed on it. And before installing SQL Server anywhere, check what the machine is. One line tells you:

(Get-CimInstance Win32_ComputerSystem).DomainRole

4 or 5 means a domain controller. My test machine returned 0, a standalone workstation. I could not repeat the promotion itself here, since that would mean turning my machine into a domain controller.

LocalSystem is not the fix for this error, it is a way to get through the day while you plan the real one.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.