The JAMS environment incorporates several key components that work together to create a unique and powerful scheduling system.

JAMS Client

The JAMS Client provides the primary user controls for JAMS and includes: 

• Windows-based GUI (JAMS Client)
• PowerShell Cmdlets
• JAMS PowerShell provider
• .NET-based Class Library
• JAMS.exe command line tool

JAMS Scheduler for Windows

This is essentially the heart of the JAMS system. The scheduler provides background services that maintain, schedule and execute JAMS Jobs.

JAMS Agent for Windows

JAMS Agents provide background services that execute JAMS Jobs under the direction of a JAMS Scheduler located on a different machine.

JAMS Agent for OpenVMS

The JAMS Agent for OpenVMS provides background processes that execute JAMS Jobs under the direction of a JAMS Scheduler located on a different machine.

Permissions

To install JAMS, ensure that the user performing the installation is logged in as an account with administrator privileges to the application server. In addition, the account must have the ability to create a database on the database server. JAMS creates the database locally by default.

Prerequisites

Before installing JAMS, please review the following requirements detailing the prerequisite software and minimum hardware requirements.

The JAMS self-extracting setups checks for and installs all prerequisites.

.NET Framework v. 4.5

The JAMS Client and Scheduler require .NET Framework v. 4.5 (or higher). Once the JAMS setup begins, it checks if this version of .Net Framework is installed. If v. 4.5 is not installed, the setup will ask to accept Microsoft's license agreement. Once the agreement is accepted, the software will then download and install the framework.

Note: Installing v.4.5 of the .NET Framework will require a system reboot.

.NET Framework v. 2.0

The JAMS Agent requires v.2.0 (or higher) of the .NET Framework.

Microsoft Message Queue (MSMQ)

The JAMS Scheduler requires the Microsoft Message Queue (MSMQ). When installing the JAMS Scheduler, the setup will check for the MSMQ and, if it's not installed, will ask you to confirm that you want to install it. For more details, go the MSMQ section in this topic.

Note: MSMQ is included with Microsoft Windows, but it is optional and not installed by default.

Microsoft SQL Server

The JAMS Scheduler requires Microsoft SQL Server 2005, 2008, 2012, 2014, or 2016. JAMS does not support SQL 2000. The SQL Server does not need to be installed on the same machine as the JAMS Scheduler.

If you or your DBA choose to install the JAMS Scheduler component, the setup will first check for a connection to an SQL Server. If the server not installed, the setup will ask to install the SQL Server 2012 Express Edition.

You also have the option of using an SQL Server on a different machine. Please note, when the installer checks for the SQL Server, it only looks for the default instance names of MSSQLSERVER and SQLEXPRESS.

If you have a different instance preference, decline the SQL Express installation and specify your preferred instance when the JAMS installer asks for the SQL server name and instance.

NOTE: To run SQLStoredProc Execution Method Jobs, Shared Management Objects for your version of SQL will be needed. Shared Management Objects can be found in the appropriate Microsoft Feature Pack version, or in the install for SQL Management Studio.

NOTE: To run SSISDirect Execution Method Jobs, the Client Tools Backwards Compatibility and Client Tools SDK Shared Features are required.

PowerShell

The JAMS Client component includes a PowerShell Snap-In that contains a number of JAMS cmdlets and a JAMS Provider. PowerShell is not required, but in order to use the Snap-In you must install PowerShell before installing JAMS. If you happened to install PowerShell after installing the JAMS Client, just reinstall the JAMS Client to pick up the JAMS Snap- In.

Note: JAMS supports PowerShell v. 2 and higher

Hardware Server Specifications for the JAMS Scheduler

• Processor: 2.5 GHZ (x86 or x64)
• Memory: 8 GB
• Disk Space: 10 GB, in addition to the disk space required by the OS.

These are the minimum system requirements that can support running thousands of jobs per day. Heavy loads, for example, over 100,000 jobs per day, will require more resources.

For database planning, the JAMS test lab runs approximately 1,000 jobs per day using one instance of JAMS. Retaining 30 days of information generates a database approximately 110 Mb in size.

For sites running over 100,000 Jobs per day

Based upon customer implementations where more than 100,000 jobs are executed each day, the JAMS installation should consist of:

• Two Windows servers, each with Dual Quad 2.0 GHz CPUs and 32 GB of RAM (or more).
• Specifically, one of the above servers hosting the JAMS Scheduler and the second server reserved for the SQL Server with multiple high-speed SCSI drives.

Hardware Server Specs for JAMS Agents

• Processor: 1 GHZ (x86 or x64)
• Memory: 1 GB
• Disk Space: 75 MB

Hardware Server Specs for the JAMS Client

• Processor: 1 GHZ (x86 or x64)
• Memory: 1 GB
• Disk Space: 300 MB

Supporting JAMS in a Virtual Environment

MVP Systems Software, Inc. supports customers running JAMS on any supported operating system in a virtualized environment, such as VMware and HyperV.

Watch our Installing JAMS Video

Follow the steps below to install JAMS on a Windows computer.    

1. Log on to Windows using an account with administrator privileges. (NOTE: Users must also have the ability to create a database on the database server. The default database server is the local machine.)
2. Right-click and run the SetupJAMS executable as an administrator to start the JAMS setup wizard.
3. On the Welcome page verify this installation is the proper edition and version. Click the Next button.
4. On the License Terms page, review and accept the terms and conditions. Click the Next button.
5. On the Feature Selection page, check the JAMS features that you want to install or upgrade, and then click the Next button.
6. On the Select Target Directory page, navigate to a preferred target directory or accept the default and then click Next. If this is an upgrade, the target directory cannot be modified.
7. You may be presented with a page that asks you to confirm that you want to install MSMQ.
8. In addition, you may be presented with a page that asks if you want to download and install the SQL Server Express Edition.
9. On the Finish page click the Finish button to begin the installation.

 JAMS Client Installation Components

The JAMS Client installation includes the following items:

• A Start Menu shortcut to JAMSWin.exe
• The JAMSShr.dll Class Library
• The JAMS PowerShell Snap-In (only if PowerShell is installed at the time of the JAMS Client installation)
• The JAMS.exe command line tool
• JAMS Help files

JAMS Scheduler Services Installation

The JAMS Scheduler installation also contains other important JAMS components including:

• JAMS Scheduler Services
• JAMS Server Services
• JAMS Executor Services

Note: if this is the initial installation of the JAMS Scheduler, you will be prompted for additional information when the installer configures the JAMS Database.

JAMS Command Line Environment

In addition to the JAMS Client GUI, the Powershell SnapIn, and the .NET Controls, JAMS offers a command line interpreter to manage your scheduling environment.

When the JAMS Client installs, it also includes a command line tool (JAMS.EXE)

1. When started from the command line, a JAMS> prompt appears.
2. Type HELP to reveal all the supporting commands. Type HELP COMMAND to get additional assistance for a particular command (e.g., HELP EXPORT JOB).

Your first action establishes the connection to the JAMS ServerName.

Once JAMS has successfully installed, a database creation wizard launches to step you through the JAMS database generation process which is described below:

Note: cancelling the JAMS database creation wizard won’t affect the JAMS installation, but JAMS cannot function without a database. To reinstall the JAMS Database, restart the wizard as described in the Troubleshooting subsection below.

Support Contract Information

Support Contact Information page requests information to be sent to JAMS technical support in the event of a failure. This information includes the:

• Company Name
• Contact Name
• Phone Number
• E-Mail Address
• SMTP Server

Note: Populating this page is optional, but entering accurate information can help JAMS support staff improve its support capabilities. If you’re unsure about the information, leave it blank and enter it at a later time.

SQL Server Page

On this page you will specify the name of the SQL server machine and the SQL Instance. If the SQL Server is installed on the local machine, the default will be (local). If the server you want isn't listed in the pull-down control, you can enter the name and instance manually.

Database Name

This is the name of the database that will be created. The default is JAMS. However, you will need to change this to a unique name if, for example, you are running the JAMS Scheduler on two different machines but are sharing the same SQL Server machine.

Authentication

Select the type of authentication to use when creating the JAMS database. If you select SQL Server Authentication, you must also supply a database user name and password.

Location of JAMS Database Files Page

The JAMS installation allows users to specify the location of JAMS database files.

The JAMS database is divided into three data files and a log file. These paths are on the database server machine, which may not be the same machine where JAMS is being installed.

Primary File

The Primary data file holds most of the database tables. These tables store the definitions of JAMS objects. Data is inserted and deleted only when JAMS objects are created or deleted.

Volatile File

The Volatile data file contains database tables that have records inserted and deleted whenever a task executes. This could equate to hundreds or thousands of inserts/deletes per day.  

History Data File

The History data file includes historical database tables. A record is inserted into this file every time a task is executed, depending upon how much history you choose to keep. If not controlled, the data file can easily balloon in size.

Database Logs

The database log file holds transaction information that is used to recover the database in case of a failure. If possible, you should place the database log file on a separate disk from the other database files.

Default Directories

The JAMS installtion allows users to specify the location of JAMS temporary files and log files. These paths must be on the local machine.

Temporary Files

In most cases, JAMS creates a temporary script file when a Job is executed. These temporary files are created in the directory specified in this file. You can change this directory using the Configuration shortcut option in the JAMS Client.

Job Log files

When a Job is executed, JAMS keeps a log of the run. You can specify the location of the log file from the Job Definition or in the Job's Folder Definition. If the location isn't specified in one of those two places, it defaults to the value specified in the Job Log file. You can change this directory using the Configuration shortcut option in the JAMS Client.

Account Information

When the JAMS database is initially loaded, a folder named JAMS is created along with a number of Jobs. There are also a number of sample Jobs installed. These Jobs cannot run unless they have a user account to run. You will be presented with a dialog requesting a user name and password for these Jobs.

If you don't enter a user name and password, it can be added at a later time.

Troubleshooting: Restarting the JAMS Database Creation Wizard

If you encounter problems with the JAMS Database, restart the JAMS database creation wizard by following these four steps:

1. Open a command window (PowerShell or CMD.EXE)
2. Set your default directory to the JAMS Scheduler default directory (C:\Program Files\MVPSI\JAMS\Scheduler).
3. If the file Common.config file exists, delete it.
4. Enter the command: JAMSDBA INSTALL

The JAMS Web Services is a subset of the JAMS .NET Class Library. You can develop applications that call these web services which are used by JAMSWebClient command line tool.

Installing the JAMS Web Services is a two-step process:

1. Run the SetupWebServices MSI
2. Configure Internet Information Services (IIS)

Run the SetupWebServices MSI

Start the SetupWebServices MSI that is appropriate for your system (either the SetupWebServices.msi for 32-bit Windows or SetupWebServicesx64.msi for 64-bit Windows).

1. Right-click on SetupWebServices.msi and choose Install.

   

2. The JAMS WebServices Setup Wizard opens. Click the Next button to proceed.
3. Accept the terms of the license agreement and click the Next button.
4. Choose the destination folder for the WebServices installation and click Next.
5. Click the Install button to begin the installation process.
6. When the installation has completed, click the Finish button.

Configuring Internet Information Services (IIS)

The procedure for configuring IIS 7 and later is slightly different from previous versions.

• IIS 7 ships with Windows Server 2008, Windows Vista, and Windows 7.
• IIS 8 is only available for Windows Server 2012 and Windows 8.
• IIS 10 works with Windows Server 2016 and Windows 10.

Configuring IIS 7, IIS 8 and IIS 10

1. Start the Internet Information Services (IIS) Manager.
2. Right-click on the Web site that will host the JAMS Web Services and select Add Application. When the Add Application dialog opens, insert an Alias name and set the Physical path to point to the location where you just installed the JAMS Web Services.
3. Click the OK button.

Configuring IIS 6

1. Start the Internet Information Services (IIS) Manager.
2. Right-click on the Web site that will host the JAMS Web Services and pick New->Virtual Directory.
3. A wizard will start and ask for the alias name. Enter an alias for the web services; e.g., JAMSWS. Select the Next button.
4. Enter the location where you just installed the JAMS Web Services and click Next.
5. The wizard will then ask for the Virtual Directory Access Permissions. Check Read and Execute. Select Next to move to the last wizard screen.
6. Then select the Finish button.

Setting the JAMS Server

The default JAMS Web Services installation will connect to a JAMS Server on the same machine. To modify this, edit the Common.Config file in the WebServices directory. Search for a line similar to:

<add key="JAMServer" value="localhost"/>

Change "localhost" to the JAMS Server you prefer.

NOTE: Use the file Common.Sample, shipped with the base install, as a template for your Common.Config settings.

Here are some additional details you may need to know in order to continue using or evaluating JAMS.

Server Definition

If you're running the JAMS Client on the same machine as the JAMS Scheduler, the JAMS Client can automatically locate the Scheduler. 

However, if the Scheduler is running on a different machine, you must include a server definition to tell the client where to find the Scheduler. In order to add a Server definition, click on the JAMS logo in the upper left corner of the JAMS Client and select Servers.

Note: you can have many servers defined within the JAMS Client.

Access Control

The JAMS Scheduler is secure by default. However, in order to work with all JAMS functions you must be part of the administrators group. 

The Server ACL controls who may connect to a specific server. The administrators group retains full access with authenticated users granted limited access.

As an administrator, start the JAMS Client and select the Access Control button in the JAMS tab of the Ribbon Bar. From the ACL list, choose the Server command to make a server selection. The ACL can then be adjusted to define who should have access to JAMS.

When launching the JAMS Client, you will not initially be a part of the Administrators group. To gain administrator access,-click on the JAMS Client icon in the Windows start menu and select the Run as administrator command from the pop-up menu. This action will open the JAMS Client with Administrator rights giving you permissions to adjust the ACLs for other users.

JAMS natively supports automation using many leading business applications. “add-ons” for these preferred applications are selected using a checkbox during the JAMS installation process. Once an add-on for a product is enabled, users can create, manage, deploy and monitor almost any kind of JAMS Job using the following products:

• Banner
• Informatica Cloud
• J.D. Edwards
• MicroFocus
• Microsoft Dynamics AX
• NeoBatch
• Netezza
• Oracle E-Business Suite
• PeopleSoft
• SAP
• Symitar

When installing JAMS, check the product add-on option you want to include. If you have already installed JAMS without the necessary add-on, re-run the JAMS installer and check the add-ons to install.

NOTE:  In JAMS 6.4.5X and up, unchecking component boxes will uninstall those components

The JAMSDBA.exe utility is used to manage the JAMS Database and to perform other installation and management tasks. JAMSDBA is a command line utility located in the Scheduler installation directory (C:\Program Files\MVPSI\JAMS\Scheduler by default).

When starting the JAMSDBA, you will be presented with a JAMSDBA> prompt. You can enter the command you want to execute or enter HELP to access online help.

You can also start JAMSDBA with a command appending the command you want to execute; for example:

JAMSDBA UPDATE/LOG

The JAMS Client can be installed with any of the standard JAMS setup executables by selecting the JAMS Client option during installation.

With the exception of the PowerShell Client, the JAMS Client can also be deployed with an XCOPY installation. Simply copy the contents of the client directory to the client machine.

Note: the PowerShell Snap-In is installed only if PowerShell is already installed. If you install PowerShell after installing JAMS, you must reinstall the JAMS Client to pick up the PowerShell Snap-In.

There is no configuration required for the JAMS Client, but you can modify the default settings by editing the JAMSWin.exe.config, JAMS.exe.config or User.config files.

The .config files include the XML text files that can be edited with any text editor. The JAMSWin.exe.config file contains the default layout for the shortcuts contained in the JAMS Client. You can customize these defaults for your own environment.

The example below illustrates some of the shortcuts defined in the JAMSWin.exe.config file:

Users can easily customize these shortcuts, but you may want to create standard shortcuts for your users. For example, if editing the JAMSWin.exe.config file, make sure to add this text:

<subkey name="Shortcut006">
<property name="Type">4</property>
<property name="Name">JAMS Jobs</property>
<property name="Title">JAMS Job Definitions</property>
<property name="Description" />
<property name="PromptForKeys">false</property>
<property name="QueryJobName">*</property>
<property name="QuerySystemName">JAMS</property>
</subkey>

In addition, you can add default JAMS Server definitions to the JAMSWin.exe.config file so your users don't have to worry about these details. To add default servers, edit the JAMSWin.exe.config and populate the <JAMSServer> section. Here is an example that defines two JAMS Servers, Jimmy and Joe:

<JAMSServers>
<subkey name="Server000">
<property name="Name">Jimmy</property>
<property name="Node">jimmy.yourco.com</property>
<property name="Port">773</property>
<property name="Prompt">False</property>
</subkey>
<subkey name="Server001">
<property name="Name">Joe</property>
<property name="Node">joe.yourco.com</property>
<property name="Port">773</property>
<property name="Prompt">False</property>
</subkey>
</JAMSServers>

JAMS uses Microsoft Message Queue (MSMQ) to reliably pass messages between the JAMS Services. It does this by creating a private queue named JAMSRequests.

MSMQ is included with Windows, but it is not installed by default. However, if MSMQ is not installed before installing JAMS, the JAMS installer will install MSMQ using the default minimum settings.

Note: if you want to control how MSMQ is installed it is best to install MSMQ before starting the JAMS installation.

If you want to change the way that MSMQ is installed after installing JAMS:

1. Stop the JAMS Services.
2. Reinstall MSMQ.
3. Then restart the JAMS Services.

JAMS contains a number of configuration settings. You can change these settings using the Configuration shortcut on the JAMS tab of the Ribbon Bar.

The configuration settings are described in the table below:

*The DefaultLogLocation and TimestampLogFormat settings are .NET format strings used to construct the full file specification for a Job's log file. The data values passed in the formatting operation are:

0. Directory specification

1. Filename

2. File Extension

3. Folder Name

4. Job or Setup Name

5. Run occurrence number

6. JAMS Entry Number

7. Timestamp date & time

8. Timestamp year

9. Timestamp month

10. Timestamp day

11. Timestamp hour

12, Timestamp minute

13. Timestamp second

14. Timestamp millisecond

Properties for each Configuration settings are organized in two tabs: Name and Value as described below.

Name Tab

Name

This is the unique identifier for the Configuration parameter.

Description

This property is used in menus, lists and reports to provide users with a more detailed description of the individual Configuration.

Last Changed

Indicates the date and time this Configuration property was last modified.

Value tab

Data Type

The specific data type of the Configuration parameter.

Value

Value of the Configuration parameter.

JAMS Scheduler installation includes three Windows Services:

• JAMS Scheduler Services
• JAMS Server Service
• JAMS Executor and Agent Services

Note: Installing JAMS Agents on Windows also includes the JAMS Agent Windows Service.

JAMS Scheduler Service

The JAMS Scheduler Service is responsible for automatically scheduling jobs, firing triggers, and checking dependencies, etc. The JAMS Scheduler must include access to the JAMS Database or the service will fail. However, JAMS is designed to be resilient. Job execution is handled by the JAMS Executor service, so if the JAMS Scheduler service fails, no job execution information is lost.

JAMS Server Service

The JAMS Server provides middle-tier services to all JAMS Client components (GUI, Powershell, .NET Class Library, and Web services). While the JAMS Server service is not involved in the execution of Jobs, many jobs can use the JAMS Powershell client, which does utilize this service.

JAMS Executor and Agent Services

The JAMS Executor is responsible for executing and monitoring Jobs. This service does not access the JAMS Database.

The JAMS Agent service is an extension of the JAMS Executor service. When the JAMS Executor needs to execute a Job on a different machine, it does so using the JAMS Agent running on that machine.

Troubleshooting JAMS Services

Each JAMS Service generates a ServiceName.log (e.g. JAMSScheduler.log) in the installation directory. These logs are reset every Sunday with the previous weeks log files renamed to ServiceNameArchive.log (e.g. JAMSSchedulerArchive.log).

Note: JAMS Services writes any serious errors to the Windows Event log. When troubleshooting JAMS, always check the event log and the .log files.

If you suspect there are problems with JAMS, shutting down one of the three services may resolve your issues. The list below provides some guidelines from the least to most disruptive option.

Restart the JAMS Scheduler

The JAMS Scheduler Service does the most work and is the least disruptive. Restarting the JAMS Scheduler Service does not cause any Jobs failures and all job completion information remains intact. While the JAMS Scheduler service is stopped, no new Jobs can execute.

Stop the JAMS Server Service

The JAMS Server service can also be stopped without losing any job execution information. However, the JAMS Client won’t function while the JAMS Server service is shut down.

Shut down the JAMS Executor Service

Stopping the JAMS Executor service is a last resort and won't typically help resolve these issues. This service executes and monitors Jobs. When this service is halted, completion information for any executing Jobs will be lost and some executing Jobs may fail. The JAMS Executor service does not access the JAMS database, so this service won’t be necessary during SQL service maintenance.

Service Accounts

By default, JAMS services are set to run under the LocalSystem account, although this can be modified to run on a Windows Domain based account.

In general, it is recommended that you leave the JAMS Executor and JAMS Agent services running under LocalSystem. These services require access to the database or network and require the privileges associated with the LocalSystem account.

Use the Service Control application to change the account for the JAMS Scheduler and JAMS Server services in order to control network and database access.

When modifying the account, you may need to adjust the security settings on:

• C:\Program Files\MVPSI\JAMS\Scheduler folder
• C:\Program Files\MVPSI\JAMS\Scheduler\JAMSScheduler.log
• MSMQ JAMSRequests private queue
• JAMS Database

You will need to modify the security on the MSMQ JAMSRequests private queue in order 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 policies 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 then create an Active Directory Group, add the user to the group and then make the following changes in the Common.config file located using the path: Program Files\MVPSI\JAMS\Scheduler<directory>

<add key=AuthorizedGroup" value="domain\YourGroup"/>

The JAMS Database provides critical features to the JAMS Scheduler and stores JAMS definitions. The following section contains information on managing the JAMS SQL database back end.

Manually Creating the JAMS Database

In most instances, the JAMS Database is created with the JAMS Scheduler during the installation process. However, in some cases, when installing the JAMS Scheduler you may prefer not to create the JAMS Database.

JAMS looks for the SQL Server connection string in the Common.config file. This file is created during the database creation process, so if it is missing the JAMS Database does not exist. Likewise, if you want to recreate the database, simply delete or rename the file.

To create a JAMS database after the JAMS Scheduler has been installed, open a command window and execute the following commands:

CD "C:\Program Files\MVPSI\JAMS\Scheduler" JAMSDBA INSTALL

During the installation process you will be required to provide SQL authentication information and use an account that has the ability to create a new database. To review these changes to the database, go to:

C:\ProgramFiles\MVSPI\JAMS\Scheduler\JAMS_DB_ERRORS.sql file

Security

JAMS supports either Windows Integrated Authentication or SQL Server Authentication. This can be modified after installation by changing the connection string found in the Common.config file. The default installation requires the JAMS Services to be running under the LocalSystem account. To facilitate this the installation executes the following SQL commands:

exec sp_grantlogin @loginame='BUILTIN\Administrators' exec sp_grantdbaccess 
@loginame='BUILTIN\Administrators', @name_in_db='JAMSService' exec 
sp_addrolemember @rolename='JAMSApp', @membername='JAMSService' 

The net effect of using Windows Integrated authentication is that anyone in the administrators group can map the JAMSService Database user and become a part of the JAMSApp Database role.

Note: You can modify the security to fit your needs, but the JAMS Services must be included in the JAMSApp Database role.

Backing up the JAMS Database

It is critical to back up the JAMS Database. Since the JAMS Database is a standard SQL Server database, simply add it to your existing SQL Server backup procedures.

Choosing the Recovery Model

Before implementing a backup plan, you will need to choose which recovery model to use with the JAMS database.

The default installation uses the Simple Recovery Model. The other option is the Full Recovery Model. The main difference between the two is in the amount of journaling performed by the database.

Simple Recovery Model

The Simple Recovery Model is the easiest to use. You periodically backup the JAMS database only, not the journal file. The downside to this model is a lack of recovery options. If the JAMS Database becomes corrupted you can recover it from a backup but, all database changes since the last backup will be lost. This includes job execution history, so Job dependencies may not work as expected.

Full Recovery Model

This model contain more robust recovery features. However, the disadvantage of this model is that you must manage the journal file for the JAMS Database. Each time a change is made to the JAMS Database it is also written to the journal file.

For example, if a hardware failure occurs or you have otherwise corrupted the JAMS Database, you can restore a backup and then recover it using the journal files up to a specific point in time.

Restoring the JAMS Database from a Backup

Restoring a JAMS Database from a backup requires a standard SQL Server restore operation, but there are some details to consider before attempting the restoration process.

The JAMS Database includes the current schedule. Often, you may not want the current schedule to be restored. For example, if the database was backed up on Monday and you restore it on Friday, you probably don’t want to start running Monday’s Jobs along with the rest of the week’s processing.

The ScheduleMaxDowntime Configuration Setting

When the JAMS Scheduler starts, it checks the database to see how up-to-date the schedule is. Specifically, it looks at the current schedule point of the database and checks that against the ScheduleMaxDowntime configuration setting. If the database is older than that setting allows, the Scheduler will take the action as specified in the ScheduleMaxDownAction configuration setting. The default setting is 48 hours and reset, which means that if the database is more than 48 hours old, the schedule then resets.

Clearing the Schedule Settings

Depending on the ScheduleMaxDown configuration settings, you may want to manually clear the schedule. To clear the schedule, open a command window and execute these commands:

CD C:\Program Files\MVPSI\JAMS\Scheduler" JAMSDBA RESET SCHEDULE

If the backup was performed on a different version of JAMS, you must use the JAMSDBA utility to update the database schema to match the installed version of JAMS.

To update the database Schedule, open a command window and execute these commands:

CD C:\Program Files\MVPSI\JAMS\Scheduler" JAMSDBA UPDATE/LOG

Moving the JAMS SQL Database

To relocate the SQL database used by JAMS:

1. Perform a normal SQL database backup and restore it to the target SQL server.
2. Edit the connection string property of the Common.config file found in: C:\Program Files\MVPSI\JAMS\Scheduler.
3. Restart the JAMS Scheduler service from the Windows control panel services applet.
4. Run JAMS_DB_ERRORS.sql on the new server. This script is found in the JAMS Scheduler directory.

Note: The process for moving a SQL/JAMS database does not require reinstalling JAMS.

The common.config file contains the connection string used by JAMS services to link to the SQL database. Below are two examples of connection strings; one for Windows Authentication models and another for SQL Authentication models.

Connection Strings for Windows Authentication

<?xml version="1.0" encoding="utf-8" ?>
<appSettings>
<add key="ConnectionString" value="Server=SQLA\INST1; Failover Partner=SQLB\INST1; Database=JAMS; Application
Name=JAMS; Connect Timeout=600; Integrated Security=SSPI"/>
</appSettings>     

Connection Strings for SQL Account Authentication

<?xml version="1.0" encoding="utf-8" ?>
<appSettings>
<add key="ConnectionString" value="Server=SQLA\INST1; Failover Partner=SQLB\INST1; Database=JAMS; Application
Name=JAMS; Connect Timeout=600;Trusted_Connection=False;uid=YOURSQLACCOUNT;pwd=YOURPASSWORD" />
</appSettings>

JAMS can override all saved client setting at any installed locations. This can be useful when you want multiple JAMS Clients to default to the same shortcuts and themes. It also simplifies how new layouts and shortcuts changes can be standardized across-the-network with only one location needed as a template.

The “SettingsPath” can be configured for each JAMS Client by modifying the user.config file as described below:

1. Open the configuration file which by default is located at: C:\Program Files\MVPSI\JAMS\Client\User.config
2. Add a new entry within the “appSettings” tags called “CommonSettingsPath” with a value of the location where you want to save the client settings. For example: 

<appSettings file="User.config">
<add key="ClientSettingsProvider.ServiceUri" value="" />
<add key=”CommonSettingsPath" value="\\AppServer\ClientSettings\" />
</appSettings>

3. Optionally, if you want the JAMS Client to save changes back to this common location simply add an entry for WriteToCommonSettings with a value of “true”. By default, any new changes will be saved to the user-specific location.

add key="WriteToCommonSettings" value="true" />

4. Copy the desired client settings into the new common location. By default, JAMS stores the client settings by version number for each user and stores it in the .XML files found in:

%HOMEPATH%\Local Settings\Application Data\MVP Systems, Inc\JAMS\X.X.X.

<add Key="LockServer" value="true" />

<add Key="LockShortcutbar" value="true" />

JAMS encrypts password and private key information when it is stored in the database. The standard JAMS installation uses a predefined encryption key, which is adequate for many sites. For additional protection you can generate a unique encryption key but must ensure that it is properly backed up and secured.

When generating a unique encryption key, JAMS uses the Rinjndael encryption algorithm to re-encrypt all password and private key information within the database. The generated key is then encrypted and stored using the Windows Data Protection API (DPAPI). The protected key is then linked to user account associated with the JAMS Server and Scheduler services.

Use the following commands available in the JAMSDBA utility to manage encryption keys:

GENERATE KEY - Generates a new 256 bit encryption key, decrypts the password with the old key then encrypts it with the new key. The new encryption key is then stored using DPAPI.

EXPORT KEY - Pulls the encryption key from DPAPI and writes it to a text file.

Caution: it is critical that you protect the EXPORT file since this key is not encrypted.

IMPORT KEY – this is similar to the GENERATE KEY. But in this case the new key is pulled from a text file instead of being generated. If recovering from backup or configuring the secondary server in a failover configuration, you should use the /NOENCRYPT qualifier to skip the decryption and re-encryption of the current data.

For additional information on protecting/restoring a JAMS Server as well as working in failover environments, go to the complete topic: JAMS Security: Managing Encryption Keys.

Protecting a Standalone JAMS Server

To protect a standalone JAMS Server, follow the steps below:

1. Log on to the server as a user with "Execute" access to the JAMS configuration settings.
2. Set your default directory to the JAMS Scheduler installation directory. The default is:
   C:\Program Files\MVPSI\JAMS\Scheduler
3. Execute JAMSDBA.EXE to open a JAMSDBA> prompt.
4. Enter GENERATE KEY and press Return.
5. Enter EXPORT KEY YourFileName.txt and press Return.
6. Enter EXIT and press Return.
7. Then move the exported text file to a safe location.

Restoring a Standalone JAMS Server

When restoring a backup of the JAMS database to different server, the encrypted passwords cannot be decrypted because of the encryption key DPAPI protection associated with the original machine/user. To restore the encryption key from a backup, follow these steps:

1. Log on to the server as a user with "Execute" access to JAMS configuration settings.
2. Set the default directory to the JAMS Scheduler installation directory. The default is:
   C:\Program Files\MVPSI\JAMS\Scheduler
3. Copy the exported text file (YourFileName.txt) from your safe location to the current directory.
4. Execute JAMSDBA.EXE to open a JAMSDBA> prompt.
5. Enter IMPORT KEY/NOENCRYPT and press Return.
6. Enter EXIT and press Return

Failover Environments

To protect the servers in a failover environment please follow the steps listed below:

1. Make sure that your primary JAMS Server is in the running state.
2. Log on to the primary server as a user with "Execute" access to the JAMS configuration settings.
3. Execute JAMSDBA.EXE to open a JAMSDBA> prompt.
4. Enter GENERATE KEY and press Return.
5. Enter EXPORT KEY YourFileName.txt and press Return.
6. Enter EXIT and press Return.
7. Move the exported text file to a safe location.
8. Log on to the secondary server as a user with "Execute" access to the JAMS configuration settings.
9. Set your default directory to the JAMS Scheduler installation directory. The default is: C:\Program Files\MVPSI\JAMS\Scheduler
10. Copy the exported text file (YourFileName.txt) from your safe location to the current directory.
11. Execute JAMSDBA.EXE to open a JAMSDBA> prompt.
12. Enter IMPORT KEY/NOENCRYPT and press Return.
13. Enter EXIT and press Return

It is always beneficial when a secondary Failover environment can be configured as part of your JAMS installation. The Failover provides a completely redundant instance of JAMS residing on a secondary server that relies on a heartbeat connection between the two. By default, this heartbeat is set to a 60 second interval. In the event the Failover does not get a response from the Primary sever within 3 consecutive beats, the Failover will “takeover” as the Primary scheduler in order to maintain the integrity of the scheduler system.  

JAMS Failover Architecture

The JAMS Failover Architecture should consist of at least three servers:

• JAMS Primary Scheduler Server
• JAMS Failover Scheduler Server
• JAMS Agent Server(s), where Jobs are run

In the event of a failure, the Failover Scheduler will take over for the Primary Scheduler, ensuring the schedule of Jobs remains intact. If Jobs are executing locally on the Primary Scheduler Server, a failure would result in the failure of all Jobs executing on the Scheduler server. Running Jobs on JAMS Agent Server(s) insulates those Jobs from Primary Scheduler Server failure. To further insulate the executing JAMS Jobs from server failure, the JAMS Agent can be configured in a cluster. 

Installing and Configuring the JAMS Failover

The JAMS Failover Engine provides automatic failover for the JAMS Scheduler without using a Microsoft Cluster. Note that the JAMS Failover should NOT be configured in a cluster.

Follow the instructions below to install a JAMS Failover Server:

1. Begin by stepping through the normal installation of the JAMS Primary Engine.
2. For redundancy of the JAMS Database, you can configure AlwaysOn Availability (which replaced Database Mirroring starting with SQL Server 2012), after you complete these steps.
3. At this point, make sure to stop the JAMS Scheduler service on the Primary Engine machine.
4. Next, begin by installing the JAMS Scheduler on the second node. When prompted for the database server, specify the same SQL Server, Instance and Database Name as you did with the Primary JAMS Engine. After choosing Next, a dialog will appear stating “Database already exists”. Be sure to select “Use Database.”
5. At this point, make sure to stop the JAMS Scheduler service on the secondary server, just as you did in the previous step with the Primary Server.
6. Create/Edit a Failover.config file (a sample is displayed below) in the \MVPSI\JAMS\Scheduler directory on the Primary server - by default the path is: C:\Program Files\MVPSI\JAMS\Scheduler\
7. Copy the completed Failover.config from the Primary Engine to the Secondary Failover server. Make sure the Failover.config is identical on both servers.
8. Next, start the JAMS Scheduler server on both the Primary and Failover machines.
9. Lastly, if the Primary and Failover share a database, it will be necessary to add a user to the JAMS database to allow the Secondary engine to connect. This can be done by running the following SQL statements on the JAMS database.

Note: Make sure to replace the login name with your machine name as shown below:

exec sp_grantlogin @loginame='YourDomain\YourMachineName$'
exec sp_grantdbaccess @loginame='YourDomain\YourMachineName$',
@name_in_db='JAMSMachine2'
exec sp_addrolemember @rolename='JAMSApp', @membername='JAMSMachine2'

A Sample Failover config

<FailoverConfig>
<Primary>Server1</Primary>
<Secondary>Server2</Secondary>
<Port>4773</Port>
<Interval>60</Interval>
</FailoverConfig>

Common Log Output Location

If you choose to have a common log output location on network share for both Primary and Secondary schedulers, please review the following article.

Setting a common log output location for JAMS in a Failover Environment

Clustering

JAMS Supports Windows Clustering. There are many ways to configure a Windows Cluster and your options can vary depending on whether you are configuring the JAMS Scheduler or the JAMS Agent.

JAMS Scheduler

The JAMS Scheduler can be configured in an active/passive mode. The JAMS Services should be included in the same cluster resource group to enable failover as a unit.

JAMS Agent using an Active/Passive Configuration

The JAMS Agent can be configured using an “active/active” or “active/passive mode”. The key is the IP address cluster resource. When directing Jobs or Queues to a clustered agent you can specify a DNS name that resolves to an IP address that fails over in a cluster to execute a Job on whichever node in the cluster is currently serving that IP address. This is considered an active/passive configuration.

JAMS Agent using an Active/Active Configuration

You could also specify a DNS name that resolves to an IP address that does not failover. In this way, you are directing the Job to a specific machine in the cluster. This is considered an active/active configuration.

In addition, you can create multiple IP address resources that normally runs on different nodes in the cluster, but fails over if a machine stops. This is also considered to be an active/active configuration.

SQL Server Mirroring

JAMS supports database mirroring. Please consult the SQL Server documentation for information on configuring and creating a mirrored database.

Once the JAMS Database has been successfully created, you should edit the connection string located in the Common.config file to add the "Failover Partner= OtherServer." This isn't strictly required, but if JAMS starts and the primary database server isn't available, JAMS won't know where the secondary server is located.

Recommended DR Model

The JAMS Server and Agents should have DR equivalents, named differently than the production servers. This will ensure the boxes are not seen on the network with the same name as their Production equivalents.

With the JAMS DR architecture set up as outlined above, the DR Process will consist of:

• Restoring the Production JAMS database to the DR Server and running any necessary database SQL scripts
• Replacing references to the JAMS Production nodes with DR equivalents

Disaster Recovery Process

Before beginning the DR Process

On the DR Server, ensure the following are true:

• The JAMS Services are disabled (Includes the JAMS Executor, JAMS Scheduler, and JAMS Server)
• Host files on the JAMS Server and Agent Nodes are pointing to the DR Servers
• Common.config is pointing to the local SQL Server (located at C:\Program Files\MVPSI\JAMS\Scheduler\Common.config by default)

1. Restore the SQL Database

First, create a backup of the JAMS Production Database, then restore the JAMS Production Database in DR.

2. Truncate the Failover Table

Truncate the failover table on the DR Server.

NOTE: The failover table details the GUID of the JAMS server that is running against this database. This GUID should match the Installed GUID found in the Server Configuration file (located at C:\Program Files\MVPSI\JAMS\Scheduler\Server.config by default).

3. Backup the current Monitor View state

On the JAMS DR Server:

• Start the "JAMS Server" Service
• Within the JAMS DR Client, go to the Monitor View and take screenshots of the current Jobs within the Monitor View
• Stop the "JAMS Server" service

NOTE: The Failover table on the DR Server must be truncated before the JAMS Server is started. The JAMS Server will then automatically add the required entries to the table.

4. Update the JAMS Server Agents/Nodes to point to the DR Servers

The JAMS Nodes must be updated to point to the DR Servers instead of Production Servers. In this example, all Setups and Jobs within JAMS refer to a JAMS Queue, rather than point to an Agent Node directly. With this Queue configuration, re-directing the Nodes will be a simple case of updating the Production Queues to point to the DR Nodes.

JAMS will not allow existing nodes to be deleted if any running or pending Jobs that point to those Queues/Nodes are within the Schedule/Monitor view. Therefore, in order to allow the nodes to be updated, all Jobs will need to be cleared from the Monitor View using the Reset Schedule process detailed below.

5. Reset the JAMS Schedule

On the JAMS DR Server

• Ensure the JAMS Scheduler Service is Stopped
  The JAMS Scheduler service should be stopped so that the Reset Schedule command (explained later) does not re-schedule Jobs before the queue nodes have been updated.
• Run the JAMSDBA executable as an Administrator
• Type RESET SCHEDULE and hit Enter

Note that when JAMS starts up against a restored database, it will check to see whether the Schedule is over 48 hours old. If it is, it will automatically rebuild the schedule from the current time, otherwise it will continue with the current schedule as-is. As the JAMS Database will likely be less than 48 hours old on DR, the 'Reset Schedule" process will have to be manually run using the JAMS DBA utility.

Once the Scheduler Service starts, the Schedule will be built based on the current time. In order to rebuild the Schedule against a different time, the /Restart switch can be specified.

6. Enable Access to the JAMS Client

Start the JAMS Server Service on the DR Server. In order to be able to successfully connect to the Server from a JAMS Client, the JAMS Server service will need to be enabled and started. The status of the JAMS Server can be seen at the bottom left hand corner of the JAMS client.

7. Update the JAMS Server Nodes

• Ensure the JAMS Client is opening against the DR Server and that all Jobs have been cleared from the Monitor View
• Run the "Update Queues" PowerShell script. This will update JAMS Queues to point to DR Nodes
  NOTE: As the JAMS Scheduler will still be disabled, the Update Queues script must be run outside of JAMS
• Ensure the Queues have been successfully re-pointed in the front end by viewing the Agents and Queue Nodes
  
• Using an "All Jobs" shortcut, view all Jobs ordered by Agent Name. For any Jobs pointing directly to Agents, update the Jobs by multi-selecting the set of Jobs pointing to a given Agent, and use the Right-Click Change All function to complete mass changes of Agents associated with Jobs.
   

8. Start the JAMS Services

On the DR Server, manually start the JAMS Scheduler Service and the JAMS Executor Service. Starting the JAMS Scheduler will result in the Schedule being rebuilt within the Monitor view, as defined by the JAMS DBA utility.

NOTE: Setups or Jobs that were scheduled before DR that were still pending when production went offline may need manual attention.

9. Run Test Processes

On the DR Server, run a test process in JAMS to validate that the Scheduler is working as expected.

Licensing DR

The JAMS DR Server requires a unique JAMS License.

Agents will be consumed as follows:
The JAMS License is on the JAMS Server and it will detail the number of available Agent licenses. When the JAMS Server is restarted, the number of allocated Agent licenses is set to zero. As Jobs consume Agents, the allocated License count is incremented.

JAMS uses the following TCP/IP Ports for both outgoing and incoming connections.

JAMSAgent.exe: The JAMS Agent listens on port 77 for requests to execute Jobs from other machines running JAMS.

JAMSServer.exe: The JAMS Server listens on port 773 for connection requests from JAMS Clients.

JAMSScheduler.exe: The JAMS Scheduler listens on port 2773 for connections from the JAMS Server and JAMS Debugger. This is usually confined to the local machine.

JAMSExecutor.exe: The JAMS Executor listens on port 3773 for connections from the JAMS Scheduler and JAMS Debugger. This is usually confined to the local machine.

JAMSScheduler.exe: The JAMS Scheduler listens on port 4773 for connections from the Failover JAMS Scheduler. This is configured in the Failover.config file. 

Common Configuration: If no port is specified in the common.config file in C:\Program Files\MVPSI\JAMS\Scheduler (default location), the default SQL port of 1433 is used.

Web Interface HTTP: The JAMS Web Interface uses port 80 by default for HTTP.

Web Interface HTTPS: The JAMS Web Interface uses port 443 by default for HTTPS.

Installing and Deploying JAMS Agents

JAMS Security

Upgrading JAMS