How to Resolve an Agent XPs Disabled Error in SQL Server

If you've opened SQL Server Management Studio and found that SQL Server Agent is unavailable, or you're seeing an error message that reads something like "SQL Server Agent XPs component is turned off as part of the security configuration," the fix is straightforward. You need to enable the Agent XPs configuration option using sp_configure, which takes less than a minute to execute. This article walks you through exactly how to do that, explains why the error occurs, and covers a few things worth checking before and after you run the fix.

What Is the Agent XPs Error?

Agent XPs is a SQL Server surface area configuration option that controls whether the SQL Server Agent extended stored procedures are available. When it's disabled, SQL Server Agent cannot start or function through Management Studio, and any jobs, alerts, or maintenance plans that depend on the Agent will be unavailable.

The full error message typically looks like this:

SQL Server blocked access to procedure 'dbo.sp_get_sqlagent_properties'
of component 'Agent XPs' because this component is turned off as part
of the security configuration for this server. A system administrator
can enable the use of 'Agent XPs' by using sp_configure.

This isn't a bug. It's a deliberate security feature introduced as part of Microsoft's surface area reduction policy, which aims to minimise the attack surface of a SQL Server instance by disabling features that aren't explicitly needed. The problem is that Agent XPs can sometimes end up disabled after a fresh installation, a security hardening script, or a server migration where configuration settings weren't carried across correctly.

Why Does Agent XPs Get Disabled?

There are a few common scenarios where you'll encounter this error:

  • Fresh SQL Server installations where the default security configuration leaves Agent XPs disabled, particularly if the SQL Server Agent service account wasn't configured during setup.
  • Security hardening scripts run by your IT team or a third-party tool that disable non-essential surface area options as a blanket policy.
  • Server migrations or restores where the source instance had Agent XPs enabled but the destination instance defaults were applied instead of the source configuration.
  • Policy-based management enforcing a baseline that includes disabling Agent XPs, which then gets applied to an instance where you actually need the Agent running.

In any of these cases, the SQL Server Agent service itself may be running at the Windows service level, but SSMS still shows it as unavailable because the extended procedures it depends on are blocked at the SQL layer.

How to Fix the Agent XPs Disabled Error

The fix requires enabling two configuration options in sequence. First, you need to expose the advanced options (Agent XPs is an advanced option), then you enable Agent XPs itself, and finally you can optionally hide the advanced options again to return the configuration to its previous state.

Run the following T-SQL in SSMS or sqlcmd, connected to the affected instance with sysadmin privileges:

-- Step 1: Enable access to advanced configuration options
sp_configure 'show advanced options', 1
GO
RECONFIGURE WITH OVERRIDE
GO

-- Step 2: Enable Agent XPs
sp_configure 'Agent XPs', 1
GO
RECONFIGURE WITH OVERRIDE
GO

-- Step 3: Restore show advanced options to 0 (optional but recommended)
sp_configure 'show advanced options', 0
GO
RECONFIGURE WITH OVERRIDE
GO

That's it. No restart required. The change takes effect immediately after the RECONFIGURE statement runs.

Once you've executed this, refresh the SQL Server Agent node in SSMS. If the Agent service itself is stopped, right-click and start it. You should see the green arrow and all your jobs and alerts will be accessible again.

What Does RECONFIGURE WITH OVERRIDE Actually Do?

Standard RECONFIGURE validates the new value against certain checks before applying it. RECONFIGURE WITH OVERRIDE bypasses some of those validation checks and applies the value regardless. For Agent XPs, either form works, but WITH OVERRIDE is commonly used in scripts like this because it's more reliable across different SQL Server versions and configurations. Microsoft documents this behaviour in the sp_configure reference in SQL Server Books Online.

It's worth noting that RECONFIGURE WITH OVERRIDE does not skip all safety checks. It won't let you set values that are genuinely out of range. It simply allows values that might otherwise be flagged as suspicious by the standard validation logic.

Do You Need sysadmin to Run This?

Yes. Modifying server-level configuration options with sp_configure requires membership in the sysadmin fixed server role. If you're getting a permissions error when running this script, you'll need to either escalate to a login that has sysadmin rights or have your DBA run it on your behalf.

This is by design. Configuration changes at this level affect the entire SQL Server instance, not just a single database, so they're appropriately restricted.

What to Check After Enabling Agent XPs

Once you've re-enabled Agent XPs and confirmed SQL Server Agent is running, take a few minutes to verify the following:

  1. Check Agent job history - Confirm whether any scheduled jobs missed their execution windows while the Agent was down. Jobs that run maintenance tasks like index rebuilds, backups, or integrity checks may need to be run manually if they were skipped.
  2. Review Agent error logs - Open SSMS, expand SQL Server Agent, and check the Error Logs node. Look for any errors that occurred before or around the time Agent XPs was disabled.
  3. Verify alerts and operators - If you have database mail alerts configured, confirm they're still active and that the Agent is picking them up correctly.
  4. Check SQL Server error log - Run EXEC xp_readerrorlog or review the log in SSMS to confirm there are no related errors after the configuration change.
  5. Document the change - Log the change in your change management system with the date, time, who made the change, and why. This matters for audits and for diagnosing future issues.

Should Agent XPs Be Disabled by Default?

This is a reasonable question. Microsoft's surface area configuration guidance does recommend disabling features that aren't in use, and Agent XPs is listed as one of the options that can be turned off if SQL Server Agent isn't needed. On a dedicated reporting server or a read-only replica that doesn't run scheduled jobs, disabling Agent XPs is a legitimate hardening measure.

But on any instance that relies on SQL Server Agent for backups, maintenance plans, ETL jobs, or monitoring, Agent XPs must be enabled. Disabling it on a production instance without understanding the downstream impact is a common mistake made during security reviews by teams who aren't familiar with how SQL Server Agent works.

If your organisation runs automated security hardening scripts, make sure Agent XPs is explicitly whitelisted on instances where the Agent is actively used. Discovering that your overnight backup jobs haven't run because a hardening script disabled Agent XPs is not a situation you want to be in.

Key Takeaways

  • The Agent XPs disabled error occurs when SQL Server's surface area configuration has blocked the extended stored procedures that SQL Server Agent depends on.
  • The fix is a three-step sp_configure script that takes effect immediately without requiring a SQL Server restart.
  • You need sysadmin rights to run the fix. Standard logins cannot modify server-level configuration options.
  • After re-enabling Agent XPs, check job history to identify any maintenance tasks that were missed while the Agent was unavailable.
  • Agent XPs should remain enabled on any instance that uses SQL Server Agent for backups, maintenance, or scheduled jobs. Disabling it is only appropriate on instances where the Agent is genuinely not in use.

If you're seeing configuration issues like this regularly, it's often a sign that your SQL Server environment lacks consistent baseline monitoring. DBA Services provides SQL Server health checks and managed support for organisations across Australia, helping teams identify misconfigured settings, close security gaps, and keep their SQL Server instances running reliably. Get in touch if you'd like a second set of eyes on your environment.