I ran into an interesting situation recently that involved a SQL Agent job that would not/could not run. Looking at the job settings everything seemed fine, yet the SQL Agent deemed the job “un-runnable”.
As we can see here “My Test Job” is enabled, and scheduled, but has no “Next Run” and is deemed not “Runnable”.
Taking a closer look at the job properties, we can further see that the job is enabled:
We also see that there really is a schedule for the job:
And on further investigation I saw something that I have never really looked at before. The “Targets” properties:
There are no entries here, but more importantly, the radio button “Target local server” is not selected. This turned out to be the cause of the job not running!
If I try and exit the properties with “OK” (which you should never do unless you have intentionally changed a setting somewhere), then we are presented with a clear error message informing us about the missing Target:
“You must specify the Target Servers on which this multi server job will execute.”
The “Targets” section of a SQL Agent Job is something that I have never delved into in any detail, but is a long standing feature to allow for administration of large server environments. You can read more into Multiserver Environment Administration on MSDN.
The reason for the setting being missing was through an incomplete scripting process for the affected job. If you script out a SQL Agent Job in SQL Server Management Studio, you will see that one of the last steps in the script is a system stored procedure “msdb.dbo.sp_add_jobserver”:
EXEC msdb.dbo.sp_add_jobserver @job_id = @jobId, @server_name = N'(local)'
This stored procedure associates a job to a jobserver, which in my experience has always been “(local)”. Obviously, this will be different if you are using master servers and target servers in your environment.
As soon as I had set the target server to local for the job, everything was back to normal and the job ran again according to it’s schedule.