JAMS Scheduler Services
The JAMS Scheduler is essentially the heart of the JAMS system and is responsible for keeping track of the status of all Jobs, firing triggers, checking dependencies, and communicating that status back to the JAMS Client.
While you interact with the JAMS Scheduler through the JAMS Client, the JAMS Scheduler can be configured to operate in a centralized or decentralized fashion. In other words, you can choose to run a JAMS Scheduler on many different machines to spread the management tasks and eliminate single points of failure.
When first installing JAMS, the Scheduler creates three Windows Services that are detailed below.
- JAMS Scheduler Service
- JAMS Executor Service (JAMS Agent Service)
- JAMS Server Service
JAMS Scheduler Service
This key component provides background Services to allow for scheduling, maintaining and executing JAMS Jobs, Sequences, Tasks and Scripts on all types of systems available on your network.
The Scheduler Service prepares Scripts to run, takes action if required during Job execution or when a Job completes. A more detailed explanation of the Scheduler Service is described below.
Before a Job can run, the Scheduler Service determines if . . .
- A Job's Dependencies are satisfied.
- It can execute the Job's Pre-Check Job, if one is specified.
- The Job's Queue is started and there is a slot available.
- The Job's Resources are available.
- The Job's Scheduling Window is open.
- The Job requires parsing (based on its Execution Method). If so, then the Job's source is parsed and substitutions occurs for Parameter and Variable values.
While a Job is running, the Scheduler Service. . . .
- Reports the Job's execution details to all JAMS Clients monitoring the Schedule.
- Performs notification if the Job runs longer than its set max limit.
- Uses the Job's defined action if the Scheduling Window closes during execution.
Once a Job completes, the Scheduler Service . . .
- Reports the Job's completion to all JAMS Clients monitoring the schedule.
- Records the Job's run instance in JAMS History, which is available for query from the JAMS Client.
- Performs notification, if required.
- Sends reports, if required.
- Determines if the Job's completion satisfies Dependencies for other Jobs in the schedule.
- Determines if the Job's completion satisfies Trigger Elements so that Triggers can fire.
- Makes sure the Job's Resources are released.
Executor Service
As its name implies, the JAMS Executor Service is responsible for the actual execution of any given Job.
Jobs are prepared to run by the JAMS Scheduler. Once the Scheduler Service determines the Job is ready to run, the Executor . . .
- Is notified and begins executing the Job.
- Then writes output generated from the Script to the Job's log file.
- And notifies the Scheduler when the Job has completed.
If the Job is set to run on a different machine, JAMS Agent Services (an extension of the Executor Service) contacts the Agent on the remote machine and directs it to run the Job.
The JAMS Scheduler cannot function without access to the JAMS Database. However, JAMS is designed to be resilient. All Job execution functions are handled by the JAMS Executor Service; so if the JAMS Scheduler Service fails, all Job execution information remains secure.
Server Service
The JAMS Server Service provides middle-tier services to the JAMS Client. This includes all client components including: GUI, Powershell, .NET Class Library, and Web Services.
The JAMS Server Service is primarily responsible for maintaining database access for one to many JAMS Clients.
While the Server Service is not involved in the execution of Jobs, many Jobs may utilize the JAMS Powershell client, which requires this Service.
Troubleshooting JAMS Services
Reviewing the Event Log and .log Files
All the described JAMS Services creates a log file in the JAMS installation directory (Program Files/MVPSI/JAMS). This log file is named ServiceName.log (JAMSScheduler.log) and is reset every Sunday. The previous week's log files are then renamed to ServiceNameArchive.log (JAMSSchedulerArchive.log).
Each Service writes serious errors to the Windows Event log. When troubleshooting JAMS, you should check both the event log and the aforementioned .log files.
Stopping and Restarting a Service
If you suspect there is a problem with JAMS and want to restart the JAMS Services, begin with the JAMS Scheduler Service. The JAMS Scheduler Service does the most work and restarting it is the least disruptive to the system.
Restarting the JAMS Scheduler Service will not cause any Jobs to fail or any Job completion information to be lost. However, when the JAMS Scheduler Service is stopped, new Jobs cannot execute.
As a next step, you can stop the JAMS Server Service. This can be done without losing any Job execution information. However, JAMS Clients cannot function while the JAMS Server Service is down.
As a last resort, users can try stopping the JAMS Executor Service. Stopping the Executor Service is not recommended, as it doesn’t usually resolve most problems. When putting this Service on hold, all completion information for executing Jobs will be lost, likely causing some Jobs to fail.
When doing SQL Service maintenance, there is no need to stop the JAMS Executor Service, since it does not access the JAMS Database.
Service Accounts
JAMS Services are set to run using the LocalSystem account. However, if this needs to change this to a Windows Domain based account, JAMS Support recommends leaving the Executor and JAMS Agent Services running under LocalSystem as these Services do not need to access the database or network, but they do require privileges associated with the LocalSystem account.
You can use the Service Control application to change the account that the JAMS Scheduler and JAMS Server services run under as this could be important when controlling network and database access.
When changing the account, you may also need to adjust the security settings on:
- C:\Program Files\MVPSI\JAMS\Scheduler folder
- C:\Program Files\MVPSI\JAMS\Scheduler\JAMSScheduler.log
- MSMQ jamsrequests and jamsrequestssubmitcancel private queues
- SQL Server
- JAMS Database
For the MSMQ jamsrequests and jamsrequestssubmitcancel private queues, you must make sure to modify the security on the queue to grant the domain account full access to the queue. This may require you to "Take Ownership" of the MSMQ queue.
The following Local Security access should also be granted for the domain based account:
- Log on as a Batch job.
- Log on as a Service.
- Adjust memory quotas for a process.
- Bypass traverse checking.
- Replace a process level token.
If the domain based user account is not in the administrators group, create an Active Directory Group and add the user to the group, and then include the following:
<add key="AuthorizedGroup" value="Domain\YourGroup" />
in the Common.config file located in the Program Files\MVPSI\JAMS\Scheduler directory.