When the Job Monitor view is selected, it may not auto-refresh to show the latest status and activity for jobs. This problem was corrected.

The following Job Variables were introduced in version 4.7 but not added to the variable picker in the Console. They have been added.

In the Database Operation Task if you check the option to enter an custom connection string and later try to switch back to using basic settings, the custom connection string is still used unless you clear the connection string field before switching back to basic mode. This problem was corrected.

When duplicating a group, Job Variables, Responses, and security settings defined for the group (and sub-groups) are not copied to the new group(s). This problem was corrected.

This problem was corrected.

In some scenarios, when the Agent reported an error while processing a command sent from the Master, this caused the Master to drop the connection to the Agent and then re-establish it. When the Agent reconnected, the Master tried the same command again, producing the same error and resulting in a loop of retries. As a result, new commands were not sent to the Agent and status updates were not received from the Agent

If an Agent sends a status update for an instance step, but the instance that the step belongs to has been purged from the history on the Master, the Master logs a database error. If the Master does not have the fix for issue 7692 applied, this triggers that problem, and the Agent is no longer able to communicate status updates to the Master.

If you import jobs using the "Create new copies of all jobs" option, any Job Control Actions that target a specific step within another job included in the export will no longer point to the step after import. This problem was fixed.

You import a job with a database task that uses explicit credentials. A Credential Profile for the same database and user ID has already been created independently on the server. The import fails to match the profile in the import to the existing profile and instead creates a new one. When you attempt to save the job or Credential Profile, you get an error indicating that it is a duplicate profile. This problem was fixed to correctly match to the existing Credential Profile.

When you import a Shared Schedule that matches an existing Shared Schedule that was independently created, the import fails to match the Shared Schedule in the import to the existing Shared Schedule and instead creates a new one. When you attempt to save the new Shared Schedule you get an error indicating that it is a duplicate Shared Schedule. This problem was fixed to correctly match to the existing Shared Schedule.

The diagnostic logging framework used by adTempus was updated to eliminate a potential security vulnerability. The log4net component used by adTempus has a hypothetical security vulnerability CVE-2018-1285. Exploiting this vulnerability would require an attacker to be able to update the adTempus service configuration file, which generally requires Administrator permissions on the adTempus server. The component was updated to a version without the vulnerability.

adTempus may fail to update the Total Execution Time for jobs when they run. As a result, the Total Execution Time and Average Execution Time may be incorrect (Average Execution Time is calculated from Total Execution Time). This update fixes the problem so that the Total Execution Time is correctly updated going forward. However, the Average Execution Time will be incorrect because the Total Executions was not affected by the problem, and thus reflects more executions than are included in the Total Execution Time. To resolve this you can force adTempus to recalculate the statistics for all jobs based on the available job history. To do this, stop the adTempus service and then start it using the service startup option "-rebuildjobstatistics".

In previous versions the File Compression task failed with files (or total archive size) larger than 4GB, because this was the limit for the original ZIP format. The task has been modified to use the newer ZIP64 format when required, which supports larger files.

When configuring the adTempus database connection using adtdbconfig, if you set a custom port number for the database server this setting is not saved by the tool, so the adTempus service uses the default port and fails to connect to the database.

Previously PowerShell console output was not included when this option was selected.

When a File Trigger is configured to capture the trigger file(s) and the trigger file(s) are located on a network drive (rather than locally on the adTempus server), adTempus may fail to capture the file(s), reporting in the Job Detail Log that the file was not found. This problem was corrected so that files are captured.

The File Trigger now allows a polling interval as low as 5 seconds (the previous minimum was 30 seconds). Be aware that using a polling interval this short may cause performance issues in scenarios where there are large numbers of files for the trigger to review.

Previously the user account used to run a job was required to have "Allow log on locally" privileges for the adTempus server. adTempus has been modified to work properly if the account does not have this privilege but has "Log on as a batch job" or "Log on as a service" privileges.

When a job is resubmitted on adTempus restart (because it was running when adTempus got shut down), any options or job variable overrides set for the original instance were not used. This has been corrected so the job is run with the same options, comments, variable overrides, etc. as the original instance.

When a Job Variable is defined at the server level and overridden at a lower level, the Variable Condition may use the value from the server level rather than the value from the lower level. This problem was corrected.

When using an SFTP connection (for a File Condition, File Trigger, file operation) adTempus may convert the time zone incorrectly. This can produce unexpected behavior in some scenarios, such as when a File Trigger is configured to wait for a time to elapse after the file's Last Modification. For time zones with a positive UTC offset this issue causes the trigger to think the modification time is in the future, leading to long waits for triggering.

If a job is continued to run "with highest privileges" (as Administrator) and elevated privileges cannot be obtained for the user (i.e., because the user is not an Administrator on the computer) adTempus will now log a warning message to the Job Log. Previously adTempus gave no indication that the job was not run as administrator.