Manage SQL Server Agent Jobs with JAMS

SQL Server Agent handles job scheduling reliably within a single instance. The problem emerges when your environment grows: multiple servers, cross-platform dependencies, and no unified view of what is running, what failed, and what is waiting on what. JAMS extends SQL Server Agent with centralized scheduling, dependency management, and real-time monitoring across every server in your environment — without replacing the jobs you have already built. This guide walks through the complete setup, from prerequisites to execution.

Prerequisites: What You Need Before Starting

Before creating your first JAMS job, verify that two requirements are met on the machine where the job will execute.

SQL Server Agent Service Must Be Running

The SQL Server Agent service must be active on your target SQL instance. To verify this:

1. Open Windows Services
2. Locate SQL Server Agent
3. Confirm the status shows Running

Install Required SQL Server Client Tools

JAMS requires specific SQL Server shared features on both the JAMS client machine and the execution machine:

• Client Tools Backwards Compatibility
• Client Tools SDK

JAMS supports SQL Server 2016, 2017, and 2019 shared features.

Step 1: Create a Credential

The credential tells JAMS which account to use when connecting to SQL Server and executing jobs. You have two authentication options:

• Domain service account — works with Windows integrated security
• SQL Server username and password — for SQL authentication

Whichever method you choose, the account needs permission to connect to the target database and run the SQL Agent job.

To create the credential:

1. Give the credential a descriptive name
2. Enter the login account
3. Set the password

Note: Entering the password here does not change the account’s actual password. It tells JAMS what the password is so it can authenticate on your behalf.

Step 2: Create a Connection

The connection store holds reusable database connection definitions. You define the connection once and reference it in as many jobs as you need. If the server name or credentials ever change, you update one record instead of every individual job.

Configure the Connection

1. Give the connection a name
2. Select SQL Server as the connection type
3. On the Properties tab, open the connection string builder
4. Select the credential you just created for impersonation
5. Choose your authentication method
6. Select the server name and database where the SQL Agent job lives
7. Use the Test Connection button to confirm everything is working

Set Security Permissions

On the Security tab, confirm that the appropriate user accounts have submit permission on this connection. Then save and close.

Step 3: Create the JAMS Job Definition

The job definition tells JAMS which SQL Agent job to run, where it lives, and how to connect to it.

Basic Configuration

1. Select the folder where this job should live
2. Give it a name
3. Select SQL Agent as the execution method — JAMS ships with this execution method built in, so no additional configuration is required

Source Configuration

On the Source tab, select the SQL connection you created. JAMS will use this to query the SQL Server instance and populate the Jobs on Agent field with available SQL Agent jobs. Select the job you want JAMS to manage.

Properties Configuration

Set the Execute As credential. This is the account JAMS uses to run the job. You can set this at the individual job level or inherit it from the parent folder if your organization uses a consistent service account across jobs.

Configure any additional schedules, parameters, or notifications as needed. Then save and close.

Step 4: Submit and Monitor the Job

To run the job, right-click it in the Definitions view and select Submit.

Using Evaluate Execution History

When submitting, you will see an option called Evaluate Execution History. This tells JAMS to check the job’s previous run status in SQL Server before starting — useful if you are resuming a job that failed partway through and want to pick up from where it left off.

Real-Time Monitoring

Once submitted, navigate to the Monitor view to watch the job execute in real time. JAMS shows you the current status — Executing, Successful, or Error — alongside every other job running in your environment across every server, in a single view.

By default, completed entries stay in the monitor for 10 minutes before moving to the History view, where you can query past runs at any time.

Reviewing Job Output and History

JAMS and SQL Server Management Studio provide complementary views of job execution.

JAMS Log Files

To review output in JAMS:

1. Right-click the job
2. Select Show Detail
3. Open the Log File tab

This contains the job’s output and any script-level errors JAMS captured.

SQL Server Agent History

For step-by-step execution history inside SQL Server Agent — including individual step statuses and durations — right-click the job in SQL Server Management Studio and select View History. JAMS surfaces the high-level outcome while SSMS provides the granular step detail.

Troubleshooting Common Errors

Two errors come up most often when setting up SQL Agent jobs in JAMS.

Unable to Load the SQL Libraries

Install the Client Tools Backwards Compatibility and SDK shared features on both the JAMS client machine and the execution machine. Refer to the prerequisites section above.

SQL Server Agent Is Not Running

Open Windows Services on the target machine and start the SQL Server Agent service for that instance.

Scaling Your Implementation

Once this pattern is in place, you can apply it to as many SQL Agent jobs as your environment requires and manage all of them from a single JAMS console. The centralized approach eliminates the need to log into multiple servers, provides unified visibility across your entire environment, and simplifies maintenance when connection details change.

For environment-specific questions or implementation support, the JAMS support team is available at support.jamsscheduler.com.