The symptom
- Starting the SQL Server Agent service gives
Windows could not start the SQL Server Agent (MSSQLSERVER) service on Local Computer. Error 5: Access is denied. - Or it starts and stops immediately with "The service started and then stopped".
SQLAGENT.OUTis empty or is not updated.
Quick checks
| Check | Where |
|---|---|
| Which account runs Agent | SQL Server Configuration Manager → SQL Server Services → Log On As |
| Edition | Express has no Agent; the service exists but is disabled |
| SQL Server engine running | Agent can't start without the engine |
| Recent password change or account lockout | AD / Event Viewer (Security log) |
Recent change of service account done in services.msc | That skips permission grants (see below) |
The System event log (source Service Control Manager) and SQLAGENT.OUT in the instance's LOG folder usually name the failing object.
Get-WinEvent -LogName System -MaxEvents 50 |
Where-Object { $_.Message -match 'SQL Server Agent' } |
Format-List TimeCreated, Id, Message
Cause 1: account changed in services.msc
When you change the Agent account in SQL Server Configuration Manager, it grants the account the rights it needs: membership of the per-service SID, folder and registry ACLs and the Log on as a service right. services.msc only changes the account name and password.
Fix: set the account again in Configuration Manager (switch it to something else, apply, then set it back if you have to) and restart the service.
Cause 2: folder permissions
Agent writes SQLAGENT.OUT and job output files to the instance LOG folder. If someone hardened the folder or moved the error log to a new path, Agent can't write there.
$log = 'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\Log'
icacls $log
# Grant the Agent per-service SID modify rights if it is missing
icacls $log /grant "NT SERVICE\SQLSERVERAGENT:(OI)(CI)M"
For a named instance the SID is NT SERVICE\SQLAgent$INSTANCENAME. Check where Agent's error log points:
EXEC msdb.dbo.sp_get_sqlagent_properties; -- errorlog_file column
Cause 3: "Log on as a service" removed by Group Policy
A GPO that sets Log on as a service to a fixed list removes accounts it doesn't name.
secedit /export /cfg C:\Temp\secpol.cfg /areas USER_RIGHTS
Select-String -Path C:\Temp\secpol.cfg -Pattern 'SeServiceLogonRight'
If the Agent account or NT SERVICE\SQLSERVERAGENT is missing, have the GPO owner add it. A local fix is overwritten at the next policy refresh.
Cause 4: the Agent account has no sysadmin login in SQL Server
Agent connects to the engine and needs sysadmin. If someone tidied up logins and removed it, Agent starts and stops, and SQLAGENT.OUT shows a login failure.
SELECT sp.name, IS_SRVROLEMEMBER('sysadmin', sp.name) AS is_sysadmin
FROM sys.server_principals sp
WHERE sp.name LIKE 'NT SERVICE\SQLSERVERAGENT%' OR sp.name LIKE '%svc-sqlagent%';
-- Re-create if missing
CREATE LOGIN [NT SERVICE\SQLSERVERAGENT] FROM WINDOWS;
ALTER SERVER ROLE sysadmin ADD MEMBER [NT SERVICE\SQLSERVERAGENT];
Cause 5: expired or locked domain account
Get-ADUser svc-sqlagent -Properties LockedOut, PasswordExpired, PasswordLastSet, Enabled
Unlock the account or reset its password, then update it in Configuration Manager. Better still, use a gMSA so the password rotates without anyone touching it.
Cause 6: registry permissions
Agent reads its settings from HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQLxx.INSTANCE\SQLServerAgent. Hardening tools sometimes strip ACLs. Re-applying the account in Configuration Manager restores them. Compare with a healthy server if not.
Warning
Don't fix this by making the Agent account a local administrator. It hides the real cause and gives every job step admin rights on the server.
Prevent it next time
- Change service accounts only in SQL Server Configuration Manager (or
dbatoolsUpdate-DbaServiceAccount). - Use gMSAs for Engine and Agent.
- Exclude the SQL service SIDs from GPOs that overwrite user rights, or include them explicitly.
- Monitor the Agent service state, not just the engine.