During setup you are asked which Windows accounts the SQL Server services should run as — and the default answer is actually a good one. Here is what those accounts do and the one choice you must never make.
Every SQL Server component is a Windows service, and every service runs as some account. That account's permissions become the engine's permissions when it reads files, writes backups and talks to the network. Setup's Server Configuration page is where you choose, and the choice is a security decision, not a formality — it decides how much damage is possible if the database service is ever misused or attacked.
Since SQL Server 2012, setup defaults to virtual accounts such as NT SERVICE\MSSQLSERVER for the engine and NT SERVICE\SQLSERVERAGENT for the Agent. They have three virtues: each service is isolated from the others, Windows manages them with no password for you to set, expire or forget, and setup automatically grants exactly the rights each service needs on its own folders. For a stand-alone machine — a learning PC, a small office server — the honest advice is: leave these defaults alone. Most service-account trouble comes from people 'improving' them.
Virtual accounts present the machine's identity on the network. That is fine until the engine needs something across the network: writing backups to a shared folder on another server, or running linked operations under a consistent identity. Then the professional pattern is a dedicated domain account per service — an ordinary user account, created only for SQL Server, with no mailbox, no admin rights and a long password. Give that account rights only where it needs them: the backup share, and nothing else. The principle is least privilege: the account should be useless for anything except running this one service.
The weakness of hand-made domain accounts is the password: it expires, or somebody changes it, and the service fails to start at 2 AM. Group Managed Service Accounts (gMSA) solve exactly that — Active Directory creates and rotates a long, unknowable password automatically, and no human ever types it. SQL Server 2022 supports gMSA for its services on domain-joined machines. If your server is in a domain and a domain account is justified, ask for a gMSA instead of a hand-made account; it is the same idea with the weakest link removed.
First, never a domain administrator — if the SQL service is compromised, the attacker inherits the keys to the whole network. Second, never Local System for the engine on a shared server; it is far more powerful locally than the service needs and it muddies network identity. Third, never your own login or a shared human account — the day that person changes their password or leaves the company, the database stops, and the audit trail points at a person who did nothing. These are not theoretical risks; they are the most common service-start failures in small offices.
If you must change an account after installation, do it through SQL Server Configuration Manager, never through the Windows Services panel. Configuration Manager re-applies all the file, registry and rights assignments the new account needs; the Services panel changes the login and leaves the permissions behind, which is why engines changed that way refuse to start or cannot read their own data files. And plan the change: the engine restarts when its account changes, so it belongs in a maintenance window, not in the middle of the billing run.
Watch the install video for the Server Configuration screen — service accounts on the first tab, collation on the second, both decided in one visit.
▶️ Watch Full VideoThe Windows Services panel changes the logon but not the NTFS and registry permissions SQL Server requires. Open SQL Server Configuration Manager, set the account there instead — it re-applies the permissions automatically — and the service should start. Always make account changes through Configuration Manager.
Yes, and setup already gives it one — NT SERVICE\SQLSERVERAGENT. The Agent runs scheduled jobs, and jobs can execute operating-system commands and scripts. Keeping the Agent's identity separate from the engine's means you can grant job-related rights (like writing backups to a share) without widening the engine's own reach.
The default virtual accounts are the right answer on a stand-alone server. They need no password management and are isolated per service. If the engine must write backups to another machine, the receiving share will see the server's machine account — grant that machine account access to the share, or copy backups with a scheduled task under a normal user instead.