SQL Server Error 14274

Error number

14274

Severity

16 (user-correctable error)

State

1

Product

Microsoft SQL Server Database Engine

Versions

SQL Server editions that include SQL Server Agent (2016 to 2025)

Category

SQL Server Agent

Last reviewed

24 October 2026

What it means

Error 14274 means you tried to change, locally, a SQL Server Agent job (or its steps or schedules) that belongs to a multiserver master (MSX), or you passed your own @job_id to sp_add_job, which only SQL Server Agent may do.

In multiserver administration a master server (MSX) owns jobs and target servers (TSX) download copies of them. On a target, msdb.dbo.sysjobs.originating_server_id points to the master, and the msdb procedures only let SQL Server Agent itself, applying instructions downloaded from the master, change those jobs. A local sp_update_job, sp_delete_job, sp_add_jobstep or schedule change on such a job stops with 14274.

The second way to get it has nothing to do with a master server: sp_add_job accepts a caller-supplied @job_id only from SQL Server Agent, because that is how Agent inserts downloaded master jobs. A script that passes a fixed job id (for example to keep the same id on every server) gets 14274 from sp_add_job, as in the message above, and no job is created. The header names the procedure that refused the change.

Common causes

• The server is a target server in multiserver administration and the job was created on the master server, so it can only be changed there.
• A job script passes a fixed @job_id to sp_add_job instead of letting the procedure generate one and return it through an OUTPUT parameter.
• The server was restored or copied from a target server (msdb included), so it still holds jobs whose originating server is the old master.
• A schedule attached to the job came from the master server, so changing or removing it locally is refused.

Diagnose it

Read-only These queries only read metadata and dynamic management views. They do not change data, permissions or configuration, so they are safe to run first.

SELECT j.name, j.enabled, j.originating_server_id, s.originating_server, s.master_server, j.date_modified
FROM msdb.dbo.sysjobs AS j
JOIN msdb.dbo.sysoriginatingservers_view AS s ON s.originating_server_id = j.originating_server_id
ORDER BY s.master_server DESC, j.name;

SELECT originating_server_id, originating_server, master_server
FROM msdb.dbo.sysoriginatingservers;

SELECT sc.schedule_id, sc.name, sc.originating_server_id, s.originating_server
FROM msdb.dbo.sysschedules AS sc
JOIN msdb.dbo.sysoriginatingservers_view AS s ON s.originating_server_id = sc.originating_server_id
WHERE s.master_server = 1;

How to fix it

Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.

DECLARE @jobId uniqueidentifier = NULL;
EXEC msdb.dbo.sp_add_job @job_name = N'Nightly ETL', @job_id = @jobId OUTPUT;
EXEC msdb.dbo.sp_add_jobserver @job_id = @jobId;

EXEC msdb.dbo.sp_msx_defect;

Examples

Passing a fixed job id to sp_add_job

DECLARE @jobId uniqueidentifier = 'C0FFEE00-0000-4000-8000-000000000001';
EXEC msdb.dbo.sp_add_job @job_name = N'Nightly ETL', @job_id = @jobId OUTPUT;

Msg 14274, Level 16, State 1, Procedure msdb.dbo.sp_add_job, Line 143
Cannot add, update, or delete a job (or its steps or schedules) that originated from an MSX server.

Changing a multiserver job on a target server

Shown with the engine message text; not reproduced here because it needs a multiserver setup. The check is in the msdb job procedures (for example sp_update_job); no state or header is shown for this form because it was not observed. The job name is an example.

-- On a target server; the job was created on the master server
EXEC msdb.dbo.sp_update_job @job_name = N'Nightly Backup (MSX)', @enabled = 0;

Cannot add, update, or delete a job (or its steps or schedules) that originated from an MSX server.

How to prevent it

Decide per job whether it is a multiserver job managed on the master or a local job, and document it. Keep multiserver job changes on the master and do not let deployment scripts touch them on targets. In job scripts, never hard-code a job id: let sp_add_job generate it and identify jobs by name.

Common questions

Learn more on CodeWithSQL

• Stored procedures and functions

Official documentation

• Automated administration across an enterprise (multiserver administration)
• Create a multiserver environment
• sp_msx_defect (Transact-SQL)
• dbo.sysjobs (Transact-SQL)

Last technically reviewed 24 October 2026; examples and diagnostics run on SQL Server 2025 (17.0.1145.4). Message text checked against the engine's sys.messages catalogue.