Home / Databases / SQL Server

DatabasesTroubleshootingIntermediate

SQL Server Agent refuses to start with 'Access is denied': fixing the service account rights

SQL Server Agent fails to start with error 5 "Access is denied" or stops straight after starting. Work through the service account, folder and registry permissions, the sysadmin login, and the Configuration Manager change that fixes most cases.

Deepak Bhardwaj4 min read

Applies toSQL Server 2016–2025 on Windows (Agent is not available in Express edition)

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.OUT is 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 dbatools Update-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.