adTempus 4 Release Notes

An error occurred while executing a request for Agent XXX: Object reference not set to an instance of an object. Please contact technical support for assistance.

When a job has a condition on a target job, the condition may be satisfied by the wrong instance in some cases where the target job is running when the dependent job starts. See article K00000586 for more information.

Violation of UNIQUE KEY constraint 'UQ_jobStatus_Job'. Cannot insert duplicate key in object 'dbo.jobStatus'

When you try to run the Job Inventory Report or Security Configuration Report, or try to print records from the Execution History Query or Message Log Query, the Console reports an unhandled error with message "Object not set to an instance of an object". Clicking the buttons to report or save the error information causes the Console to hang.

This problem was resolved.

When a step is configured to capture console output from the program being run, you can now view the partial capture results while the step is still running. Each time you open the file from the job history, it will display the current contents of the console output. The view of the file will not refresh automatically. If the job is running on an Agent, you still will not be able to view the file until the step completes, as the file is not sent to the Master until then.

Further enhancements will be made in adTempus 5.

If a Response that uses event "Restart limit exceeded" has an action to restart the job, the response evaluator goes into an infinite loop, causing the adTempus service to crash with a stack overflow exception.

This was corrected so that Restart actions are ignored when triggered by Restart Limit Exceeded events, as this configuration doesn't make sense anyway.

For more information see Knowledge Base article K00000564.

For more information see Knowledge Base article K00000573.

For more information see Knowledge Base article K00000562.

For more information see Knowledge Base article K00000561.

In previous version of adTempus (3.x and earlier), using the Hold or Release action in a Job Control Action disabled all execution for the target job, because there was a single hold type. In adTempus 4.x, the Job Control Action only holds triggers for the target job, allowing manual and chained execution.

A new option has been added to configure this behavior globally to restore the previous capability. A future release will allow the option to be configured separately on each Job Control Action.

A new option has been added to handle cases where the Master loses communication with an Agent (because the Agent has been shut down or the network connection has failed). When this option is enabled, the Master will mark all jobs that were active on the Agent as "Abandoned." This is to assist in a scenario where a job is configured to not run if a previous instance is already running, or a queue has execution limits. Without the new auto-abandon option, in those scenarios, the Master would continue to think that the jobs on the Agent are active, until the connection to the Agent is restored and the Master receives updated status information. Thus new instances would be prevented from running.

This option currently is available only as a global configuration setting, which affects all agents, queues, and jobs.

To enable the option, go to the Advanced Server Options window in the Console and look for the option "DistributedScheduling:AbandonJobsWhenAgentLost". Set the Current Value to "true" and click OK to save the change.

In some scenarios (such as when database problems occur), adTempus may fail to record the completion of a job instance. This results in an instance that shows as active in the Console even though it is no longer running. Such a phantom instance may also disrupt job flow, in cases where other jobs depend on the state of the job, or where the job is configured to not allow multiple concurrent instances. Though the Console shows the "Terminate" command for the instance, using this command has no effect, as there is no real instance to terminate.

The adTempus server has been updated so that in situations like this the Terminate command will update the database record for the instance to show a status of "Unknown." The user can then use the "Override Status" command to set the instance to Succeeded or Failed as appropriate.

In rare cases (typically involving a corrupted user profile, or network connectivity problems), the logon process for a Windows user account may take a very long time to complete. In such cases, the job requesting the logon and any jobs subsequently triggered (even if they use a different user account) remain in "Starting" status with no indication of what the problem is.

adTempus has been updated to issue a warning message after waiting 1 minute for logon to complete and to fail the job after waiting 10 minutes. Additionally, other jobs that use different credentials are no longer delayed by the problem.

This release includes an update to the third-party component adTempus uses for FTP and SFTP, which fixes some issues with this functionality.

A new option was added to the Object Change Log report to "Exclude system-generated changes." Checking this option excludes all events where the user is shown as "System." These events come from automated actions such as Job Variable Update tasks that modify a job definition.

Note: you can prevent adTempus from generating these change log entries in the first place, as described here.

Scripts can now trigger Responses for jobs. This can be used, for example, to make it easier for a script to trigger another job in a job chain.

To use this feature, add event "Invoked by a script" to the Response, and use the "tag" field to give the event a name or description. In the script, use the adTempus.ExecuteOnDemandResponses method to invoke the Response, passing the tag value to tell adTempus which response(s) to trigger.

When a File Transfer task uploads a file using FTP or SFTP, it uploads the file using a temporary name, then renames the temporary file to the final name. This is done so that any existing file is not corrupted in the event that the transfer does not complete successfully. However, in some scenarios the upload/rename operation causes problems and a direct upload is preferable.

A new advanced server option, "FileTransfer:UseTempFileForUpload", was added to control this. Set this option to False to turn on direct upload.

This setting affects all file transfer operations. A future version of adTempus will allow control over this setting at the file server or task level.

For more information see Knowledge Base article K00000543.

When you select the Remote Agents view in the adTempus Console, the Console fails with error "An error occurred on the server while processing the request."

This can happen if the Windows performance counters on the Master server have been corrupted. This indirectly causes a failure in adTempus when it is generating the load metrics reports that are shown in the Agents view.

The problem was corrected so that corrupted counters will no longer cause the problem.

I you have defined a Job Variable with a name that contains certain punctuation characters (such as "\"), any job that defines or inherits that variable will fail with error 104: "An internal error occurred".

To work around this problem, remove the punctuation character from the variable name.

For more information see Knowledge Base article K00000546.

For more information see Knowledge Base article K00000557.

For more information see Knowledge Base article K00000558.

If the e-mail trigger encounters a login failure or other error that it interprets as a configuration error, it logs an Alert and stops polling the mail server until the mail connection settings have been checked and re-saved. This was intended to prevent repeated connection attempts using incorrect settings or bad credentials, but in practice sometimes causes the trigger to stop monitoring due to transient failures that are interpreted incorrectly.

The behavior has been changed so that the trigger will log an Alert on failure but will continue trying to connect.

When a File Trigger is configured to scan a folder but the job's user does not have permission for a higher-level folder in the hierarchy, the trigger ignores the folder but does not report an error.

For example, a trigger is configured to watch "d:\input files\customers\customer1\*.xml". The account that the job is running under has permission to view folders "d:\input files" and "d:\input files\customers\customer1" but does not have any permissions for "d:\input files\customers".

When scanning for trigger files, adTempus starts at the root folder and works its way down to the lowest level, one level at a time (this allows it to accommodate folder name wildcards). If it encounters a level where it does not have sufficient permission, it will either get an access error (if it does not have View permission) or will not "see" the next level of folders (if it does not have List permission). Therefore it never gets to the "d:\input files\customers\customer1" folder to look for files.

This behavior was changed so that when there are no wildcards in the path adTempus will scan the lowest-level target folder directly, so the trigger will work correctly as long as the job's user account has permission for that folder.

If you use the Run command in the Console when more than one job is selected, all selected jobs are executed, though this is easy to overlook in the Execution Options window.

A new warning message was added to prevent accidental execution of multiple jobs.

Previously, a Job would be shown in the Console with a red failure icon until the next successful run, even if all failed instances had been acknowledged.

This has been changed so that the failure icon appears "dimmed" once all failures have been acknowledged.

Consider the scenario where a Queue is configured to use Load Balancing across multiple computers, and a limit is set to restrict the number of jobs that can execute concurrently in the queue on a single computer.

In previous versions, if all available agents were at or above the limit, a job was still dispatched to an agent (generally the agent with the lowest number of active and pending jobs). The job would then be queued for execution on the agent until an execution slot was available.

This has the drawback of potentially sending a job to an agent where it will wait for a long time to execute, while jobs that get triggered later may get executed first on other agents whose jobs took less time to run.

This behavior has been changed so that jobs will only be dispatched to agents that have available execution slots. If no agent has an available slot, the job will remain queued until a slot is available. All jobs sent to the queue for execution will be dispatched to agents in the order that they were triggered.

The adTempus Console highlights jobs, groups, and queues that contain instances with an error state (such as failed) by showing an error icon next to the job, or on the group or queue icon. This feature was expanded to also highlight instances with a warning status (such as abandoned or aborted) by showing a warning icon. As with the error indicator, the warning indicator is removed when the instance's status is acknowledged.

See also related change CR00007234.

If you have objects selected in the active view (e.g., the job list, Notification Recipients list, etc.) when you open the Export window, you will now be given the option to transfer the selections to the export window so those items are selected by default in the list of object available for export.

Previously there was no such link.

Inline scripting has been updated to correct some design limitations. The updates support:

• Nested inline function calls.
• Inline function calls that use variables as arguments, when those variables evaluate to inline function calls.
  

Added preliminary support for viewing the status of Job Triggers, allowing user to see which rules have been satisfied for the trigger, and by which job instances.

To display the status, right-click the job and select the Trigger Status command at the bottom of the pop-up menu.

This option is only available if both the Console and the server are running adTempus 4.3.1.16125 or later.

Only Job Triggers currently report status.

When the adTempus Console refreshes to show the latest data while you are in a job list view, the list scrolls to keep the selected job in view. If you had paged so that job was out of view, you lose your position.

This was corrected to maintain the correct scroll position rather than scrolling to the selected job.

When setting up an incoming mail server, if you leave the Server Port box empty, the Console gives error

After closing the error window, you can enter a port number value (use 0 for the default) and successfully save the provider.

If you duplicate an object (such as a Job Step) and then click Cancel in the edit window for the object or one of its children, the Console may fail with an "unexpected error" message.

This problem was resolved.

For more information see Knowledge Base article K00000528.

When you run the Engine Mode Utility, the Reset Master option may not be enabled when it should be when the utility starts.

Workaround: Click to select a different engine mode, then click back to the original setting. This should enable the option.

When you use an inline function call, the syntax for any code or strings in the call is processed in the C# language, even if the inline function library is set to use VB.NET. This can cause unexpected errors when compiling the code.

This was corrected so that inline function calls are processed in the same language specified for the InlineFunctions library.

For more information see Knowledge Base article K00000529.

If the same block of text calls the same Inline Function more than once, job execution fails with "an unexpected internal error."

This problem was corrected.

For more information see Knowledge Base article K00000530.

A job instance was previously waiting for a condition to be met. The condition has been met, but the job is now in status "Queued for Execution" because the execution limit for the Job Queue has been reached. If you use the "Force Execution" command in the Console to override the limit and force the instance to execute immediately, nothing happens. The instance will still execute when a slot becomes available in the Queue, but immediate execution cannot be forced.

This problem was resolved.

If a job is configured to use one of the Multiple Instance options other than "Execute," multiple instances may still be started for jobs assigned to a Queue that uses Load Balancing.

This problem was corrected.

When you view a job instance from the job history, the names/descriptions for job steps are not displayed. This is occurring because adTempus is failing to save this information in the history.

The problem was corrected so the information will be stored when jobs are executed. For jobs run before the update was applied, the Console will show the current description for the step.

A change made in version 4.3 had the unintended consequence that the status for a running job instance may not be correct. For example, it may show "Queued for Execution" when it should be "Running," or "Running" when it should show "Waiting for Condition." This problem only affects display of the status, not the actual execution of the job.

The problem was corrected.

For more information see Knowledge Base article K00000526.

If you use the Job.ExecutionFinish, JobStep.ExecutionStart, or JobStep.ExecutionFinish variables in your job (for example, in notification messages set by responses), the following problems occur:

• The *.ExecutionFinish variables may not be set before Responses are executed, resulting in empty values if you use them in Responses.
  
• The JobStep.* variables are not defined when job-level Responses are executed (they are only available to step-level Responses)

Both of these problems were corrected.

When no steps within a job are executed (e.g., because they were disabled or their conditions were not met), adTempus reports the job with status "Not Run," which is misleading because this status is also used for cases where a job was aborted before it began execution.

Further, when such a job executes on an Agent, the Master continues to report the job as active even after it has finished because of a problem interpreting this status.

The behavior has been changed so that a job will be reported as "Succeeded" even if none of its steps ran. As a result of this change the Master now reflects the correct state of the job.

For more information see Knowledge Base article K00000534.

When an adTempus task runs an external PowerShell task with the option checked to capture the console output from the script, an error message is written to the adTempus diagnostic logs:

Failed to delete captured file PowerShell Output.txt
System.NullReferenceException: Object reference not set to an instance of an object.

This message does not cause any operational issues.

The underlying problem has been resolved.

When editing a Script Library, the "Included Script Libraries" list is always empty, so it is not possible to reference other Script Libraries.

This has been corrected so that a Script Library can reference other Script Libraries (so code in one library can call code in another).

For more information see Knowledge Base article K00000532.

When a user has been authenticated to adTempus using a dynamic login (based on Active Directory group membership), permissions assigned to the user may be cached until the next time the adTempus service is restarted. Therefore if the user's group membership changes, the user's permissions in the Console may not reflect that change until the next restart.

For example, user Rachel is a member of an Active Directory group that has been given permission to execute jobs in adTempus. She logs in to adTempus and is able to run jobs. She is subsequently removed from that Active Directory group, but when she logs in to adTempus she is still able to run jobs even though she should not be permitted. After the adTempus service is restarted, her permissions are correctly updated.

This problem was corrected so that cached permissions are discarded and the user's permissions are always recalculated each time she logs in to adTempus.

Note: Group membership changes won't be reflected until the user restarts the adTempus Console, as the permission assignment only happens when the user logs in. Also, it may be necessary for the user to log out of Windows for the user's login session to be updated with the group membership change.

If the target ZIP file is in a folder that does not exist, adTempus does not create it, and the compression task fails as a result.

This problem was corrected.

When a job is triggered by a Job Trigger, the Execution Reason for the instance lists the jobs and instances that satisfied the trigger. However, the instance number is always listed as 0 for all jobs.

This problem was fixed to show the correct instance number.

For more information see Knowledge Base article K00000518.

When you use one of the "{most recent|any} instance since previous [successful] execution of the current job" instance rules for a Job Trigger, adTempus may incorrectly trigger for an instance that ran prior to the most recent execution of the current job. This happens when the trigger targets more than one job. If one or more target rules was satisfied before the current execution but at least one was not, the target rules satisfied before the current execution may not be re-evaluated, causing the job to trigger without waiting for them to run again.

This problem was resolved.

When debug (diagnostic) logging is turned on for the adTempus service, File Triggers may fail if they are configured to detect modified files. An error is logged to the adTempus diagnostic log in this case: "Exception while checking monitor XXXXXX System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection."

Debug logging is turned off by default, so this problem does not affect most users.

When a Program Execution Task executes with the "Capture screen output from console-mode program" option checked, adTempus will now save a copy of the captured output in a file in the job's temporary folder, so that scripts and tasks within the job can read the file. The name of the file is stored in the "JobStep.CapturedConsoleFileName" Job Variable.

Note that the file is not available until the program being run has exited.

When you run a Database Operation Task with the "Execute SQL" or "Select a scalar value" Action, adTempus will now log each command/query executed, along with the output from the database server, to a text file, which will be included in the Captured Files for the job as "Database Results.txt".

During job execution (after the task completes), a copy of the file will be available in the job temporary directory, so that scripts and other tasks within the job can read it. The path/name of the file will be found in Job Variable "DatabaseTask.DatabaseResultFile".

The Alerts view should include job-level alerts (alerts logged for a particular job) but does not. This problem was fixed in the adTempus server and does not require an update to the Console.

Note: As a result of this fix, when you first start adTempus after applying the fix you may find a large number of old job-level alerts in the Alerts view, because these alerts were generated in the past but not visible in the view for acknowledgment

For more information see Knowledge Base article K00000442.

When you edit a Schedule within a Schedule Trigger and click the "Show Matching Dates" link, the resulting list of dates does not reflect the holiday settings configured for the Schedule Trigger. This is intentional, as the Show Matching Dates command was intended to be used to confirm that your date rule is matching the correct options.

This creates misleading results if the schedule uses a date rule with an option such as "exclude holidays" set. Therefore this command has been changed to reflect the holidays when holiday-related settings are used within the schedule.

If you install adTempus to a location other than the default location ("Program Files\Arcana Development\adTempus\4.0"), the adTempus database and other adTempus data may still be created under that folder. The problem was resolve to place data in the correct location.

Existing installations are not affected by this change. Please contact us for assistance if you need to relocate an existing data folder.

If you have configured the adTempus server to use certificate security (to accept client connections from outside the Windows domain), the server may still not accept connections that use certificate security.

This update must be applied to both the adTempus server and the remote computer(s) where the Console is run.

For more information see Knowledge Base article K00000437.

The Active Range for a Date Criterion shows date/time values for the start and end values. It should show only dates, because the time value is not used.

If a script retrieves a Job Variable value from the JobVariables collection and the value of that variable contains references to other Job Variables, the variable tokens are not expanded.

For example, Variable1 is set to "A", Variable2 is set to "B", and Variable3 is set to "%Variable1%%Variable2%". If a script retrieves the value for Variable3 using adTempus.JobVariables("Variable3"), the value is returned as "%Variable1%%Variable2%", when it should be returned as "AB".

For more information see Knowledge Base article K00000449.

The Database Operation Task does not provide a way to set the timeout value for database operations, and uses a default timeout of 30 seconds. Operations that take longer than this will fail with a timeout error.

This was resolved by increasing the default timeout to 30 minutes and adding a global configuration setting to allow the value to be changed.

A future adTempus version will allow configuration of the timeout for each task.

For more information see Knowledge Base article K00000444.

File Operation Tasks now allow you to use a Job Variable as an include file when the Source Root is set to "Specify absolute paths."

You can include multiple files in a single Job Variable by using ";" or "," to separate them. For example, you can set "MyFileList" to "c:\test\file1.txt;c:\test\file2.txt;c:\test\file3.txt". In the File Transfer task, set the Source Root to "Specify absolute paths" and enter "%MyFileList%" in the Include Files box. The task will copy all three files.

This feature can be used to copy the files found by a File Trigger: Set the Include Files to "%FileTrigger.FileName%". The "FileTrigger.FileName" is automatically set by the File Trigger to contain the names of the files matches by the trigger.

If a network (or removable) drive is unavailable, the File Trigger may treat this as though all files on the monitored drive had been deleted, resulting in erroneous file deletion triggers followed by erroneous file creation triggers when the drive is restored. The problem was fixed to correctly handle this scenario.

For more information see Knowledge Base article K00000515.

For more information see Knowledge Base article K00000511.

A new option in the Import wizard allows you to only import objects that were explicitly exported.

For example, when you export a job, the export file also includes everything the job links to, including its Job Group, Job Queue, Credential Profile, Remote Agents, Notification Recipients, etc. By default, all of these additional objects get imported on the target server if they are newer than the existing versions on the target server.

In some cases (such as copying a job from your test server to your production server) you only want to import the job itself and not overwrite the existing settings for the other objects. When the "Don't import referenced objects that already exist on this server" option is checked, these objects will not be listed on the object selection page of the wizard and will not be imported unless they do not already exist.

In all cases, adTempus imports any linked objects that do not already exist on the target server.

When capturing files for a File Capture Action, or deleting files that have been captured, adTempus may fail to use the elevated logon context, resulting in error "Access to the path is denied" if the necessary permissions are assigned only to Administrators.

When adTempus fails to delete a captured file, it logs error ADT005055 ("Could not capture file") even though the file was successfully captured to the file history. This has been replaced with error ADT005409 ("Could not delete captured file").

This problem still occurred in some cases even after fix CR00005098 in adTempus 4.2. The problem occurred only when:

• A job runs in a Queue that is configured to use Load Balance or Slave mode
• The Queue is configured to check conditions on the Master
• The job has previously been sent to an Agent for execution following a condition check.

On subsequent execution attempts, the job will get stuck in "Waiting for Condition" status.

In addition, if the job is configured to not execute if another instance is already running, the job may be skipped even though no instance is active.

When you attempt to hold or release a job, queue, or group using the right-click context menu, the Console connection to the server may fail with the following error:

Message Number: ADT005166E Message: The server connection has failed or has been closed: There was an error while trying to serialize parameter http://arcanadev.com/adTempus/4.0:value. The InnerException message was 'Enum value '2147483646' is invalid for type 'ArcanaDevelopment.adTempus.Shared.HoldType' and cannot be serialized. Ensure that the necessary enum values are present and are marked with EnumMemberAttribute attribute if the type has DataContractAttribute attribute.'. Please see InnerException for more details.: Enum value '2147483646' is invalid for type 'ArcanaDevelopment.adTempus.Shared.HoldType' and cannot be serialized. Ensure that the necessary enum values are present and are marked with EnumMemberAttribute attribute if the type has DataContractAttribute attribute.

This problem was resolved.

Workaround

This problem only occurs when using the right-click context menu. You can still change the hold type by editing the job, queue, or group and changing the hold setting in the properties window.

If a user tries to duplicate an object (e.g., a Job), they get a permission error unless they have full control for the object.

This was corrected to work properly. A user can duplicate an object if the user has permission to view the object and to create new objects of that type. For example, to duplicate a Job, the user must have permission to view the job and also permission to create new jobs in the Group where the job is found.

If the Job Monitor view is configured to show both Active and Past instances, the Job Monitor stops updating the statuses of jobs that have been running longer than the "Past" time limit.

For example, if the Job Monitor is configured to show instances from the past 12 hours, any job that runs longer than 12 hours will no longer be updated in the Job Monitor, but will still appear there as active even if it has finished.

This problem was corrected. The update must be applied to the adTempus server; the Console software is not affected.

If a non-Admin user is granted "Execute" permission for a job, user should be able to terminate an active instance of the job, and to acknowledge instances and messages for the job. However, if the permissions are assigned at the Job level (rather than at the Group or Queue level), they are not properly inherited, and these options are not available to the user.

In some situations the Console showed a red "error" icon for jobs (indicating the existence of one or more failed instances for the job) even though no instances for the job appeared in the Failed Jobs view.

This problem was partially resolved in version 4.2 under CR00003058 but the problem remained in some scenarios.

The "Total Executions" count tracked for each job and shown on the Statistics page is double the actual execution count.

This problem was fixed so that executions are not double-counted going forward, but the existing (incorrect) count is not adjusted.

With adTempus 4.2 installed, when adTempus purges old history data from the database, records are left behind in some tables when they shouldn't be.

This update fixes the problem.

When you hold (disable triggers for) a Job Group, all jobs within the group should be dequeued (should no longer be triggered). Conversely, when you release (enable triggers for) a Job Group, all jobs within the group should resume executing based on their schedules or other triggers. However, in some cases this does not happen after you change the hold settings for a group.

If you subsequently edit and save a job, that job will then be queued or dequeued as expected. If you restart the adTempus service, all jobs will behave as expected.

This issue was resolved so jobs are queued/dequeued when the change is made to the group.

If you have defined an Alert Notification Rule, adTempus interprets the Minimum Interval setting incorrectly and sends alerts before the minimum interval as elapsed, but not after it has elapsed. This is the reverse of the expected behavior.

This problem was corrected.

If you have defined nested job variables, the nested variable(s) are not expanded when the environment block is set for programs run by adTempus.

For example, you have the following job variables:

• "VariableA" is set to "Value A"
• "VariableB" Is set to "The value is: %VariableA%"

VariableB is configured to be added to the environment for programs run by adTempus. If the program retrieves "VariableB" from the environment, it should get "The value is: Value A". However, it gets "The value is: %VariableA%" instead. This occurs even though the variable expansion works correctly elsewhere within adTempus and appears correctly in the debug log for the job.

When upgrading from adTempus 2 to adTempus 4, if a Messaging Service Provider has the maximum message size set to 0 (which indicates "no limit" in adTempus 2), adTempus does not include any attachments on notification messages.

Workaround: Edit Messaging Service Provider and click OK to update the limit to the default of 10MB.

When you run the Security Configuration Report, it may not show any data. This problem was corrected.

This problem was resolved. The update must be applied to the adTempus server; the Console software is not affected.

When a Program Execution Task has a Response configured to send notification on success or failure, the default notification message is a generic message: "The program has completed with exit code {0}". The message should indicate whether this is being treated as a success or failure.

The generic message ADT005003 has been replaced with the appropriate status message:

• ADT005252: Task ended with exit code {0}, which indicates failure according to the exit code rules for the step
• ADT005410: Task completed successfully with exit code {0}. 

When you execute a File Operation Task you can configure Responses based on the number of files processed. The following problems were corrected for those Responses:

• When you select "Affected file count matches a value," there was no way to specify the file count
• The responses for "No files affected" and "One or more files affected" were reversed
  

A user who has been granted Hold/Release permission for a job, group, or queue is unable to change the hold settings for the object unless the user also has Modify permission, which should not be required.

This problem has been corrected.

In the adTempus Database Utility, if you use the File/Set Connection command and cancel out of the connection dialog, subsequent attempts to open a new query tab result in error "SQL Server does not exist or access denied" because the tool has lost the database connection information.

If you use a Script Execution Task to run a script stored outside adTempus, and the path/filename of the script to execute contains Job Variables, adTempus does not expand the variables, and task execution fails because script file cannot be found. This problem was resolved to expand the job variables.

A File Trigger may not trigger for a file if all of the following are true:

• The target file is on a remote (network) drive.
• The trigger is configured to wait until x seconds after the last modification timestamp for the file.
• adTempus initially detects the file before the x seconds have elapsed.

In this scenario, adTempus may not "see" the file when it subsequently tries to check the modification timestamp, and therefore does not trigger the job.

The Job Control Action has been modified so that a Response (run at the Job or Job Step level) can terminate itself. For example, this can be used to allow a job to terminate itself if it exceeds a specified run time.

When the Job Control Action is configured to terminate "The current job," it will terminate only the instance of the job that runs the Response, not any other executing instances.

When you duplicate a Job Group (which makes a copy of the Group and all its subgroups and jobs), adTempus will now transfer links among jobs (i.e., Job Conditions, Job Control Actions, and Job Triggers) within the group hierarchy to the new jobs.

Previously these links were not updated and remained pointing to the original jobs rather than the new copies.

For example, suppose "Group 1" contains "Job 1," which has a Job Condition on "Job 2". When you duplicate "Group 1" to "Group 1 Copy", "Group 1 Copy\Job 1" will now have a condition on "Group 1 Copy\Job 2". In previous versions the link was not updated, and "Group 1 Copy\Job 1" ended up with a condition on "Group 1\Job 2."

The connection property windows for Remote Agents and Peer connections have been enhanced to make it easier to connect to non-default port numbers and named instances, and to enter overrides for servers using untrusted server certificates (see CR00003003).

When adTempus prunes job history based on history retention settings, by default it will no longer purge any instances that failed if the failure has not been acknowledged.

This behavior can be changed using the advanced server option "MaintenanceThread:RetainUnacknowledgedFailures".

Database output file produced by Database Operation Task modified to:

• Fix problem with output column formatting when data from database contains tabs or newlines. 
• Show better delineation between result sets for commands that produce multiple result sets.
• Show better information when database errors occur
• When error is reported, write output generated before error (previously, error from database caused only error message to be written; any result sets generated by previous commands were not written)

Notification messages can now be formatted using HTML, though there is not yet support for editing messages using an HTML editor in the user interface. To use HTML formatting, paste in the HTML source for the notification message. The message body must begin with an "<html>" tag for adTempus to recognize it as an HTML message.

The same automatic conversion will be applied for message bodies set through code or Job Variables.

The step-level Job Variables are defined only when a Step is executing, and therefore cannot be used in a job-level Response. For example, you might want a job-level Response to run when the job fails, indicating which step failed. Presently there is no variable available to supply this information. adTempus has been modified so the following variables can be used in job-level responses; they will contain information about the most recent step executed:

• ADTStepNumber
• ADTStepDescription
• ADTStepName
• StepStatus
• ADTTaskResult

The permission report shows the effective permissions for a particular object and user and can be used to debug problems with permission inheritance.

To display a report, right-click within the settings area on the Security page of an object properties window, and select "Show permission report for user..."

Due to a limitation of the database driver used for Oracle, stored procedures could not be executed using the "exec procname" syntax when running Database Operation Tasks. adTempus has been modified to translate "exec" statements to the required syntax.

A statement such as

exec my_proc('parm1')

is now submitted to the database as

{call my_proc('parm1')}

When you create a Response for a Job Step using the "Restart Limit Exceeded" event, adTempus applies that event any time another Response on the Step tries to restart either the Job or the Step and reaches the restart limit. Because of the ambiguity over which restart this Response should apply to, adTempus ends up invoking the Response in an endless loop once the restart limit for the job is reached.

To resolve this problem the behavior of the event has been changed so that the "Restart Limit Exceeded" event only applies to restarts of the Job Step when it is used for a Response defined for a Step.

Any Responses defined at the job level for "Restart Limit Exceeded" will be invoked for any job restart, whether invoked from job-level or step-level responses.

For more information see Knowledge Base article K00000460.

If you change the setting of the "Also show instances that completed with warnings" option in the Failed Jobs view, the view does not use the new setting right away. Therefore it continues to show jobs filtered based on the old setting. For example, if you check the box to show instances with warnings, no instances will be shown, even if some exist.

This problem has been resolved.

Added status icons to Groups and Queues to indicate whether they contain active and/or failed jobs. This behavior was present in adTempus 3 and earlier, but was omitted from version 4.

When you use the Duplicate Group command to make a copy of a Job Group, the copy may process may fail if the group has sub-groups, giving error ADT000063E: The requested object cannot be found.

If you click the "Look online for more information" link for the error message, this may fail with the error "ActiveX control cannot be instantiated because the current thread is not in a single-threaded apartment."

When you attempt to delete a job with a large amount of history (several thousand instances retained), the Console may report a timeout error or may hang indefinitely. This was caused by the adTempus server incorrectly trying to delete the job history in real-time, while the Console waited for a response.

This problem has been corrected so that history for the deleted job is purged during the normal background history cleanup process.

If you modify a job to add, remove, or reorder steps, and then execute the job manually using the Run command, the Steps page of the Execute Job window may not reflect the changes you have made. This does not affect execution of the job, only your ability to select specific steps.

This problem has been resolved.

For more information see Knowledge Base article K00000463.

If you use SQL Server security for the connection to the adTempus database, and the database password contains certain characters (semicolon, single quote, or double quote), adTempus may be unable to connect to the database, reporting the following error:

Keyword not supported: 'XXXX; application name'.

where "'XXXX" is part of the password.

For more information see Knowledge Base article K00000458.

When importing a version 3 export file into version 4, the import fails if the file contains job history, with error ADT005114E: Import failed: Invalid value "{1EC07219-59BE-4F02-A3BF-C7FDDA2AC982}:{guid value}" for field jobOID

In some scenarios, a job that is configured to skip execution if another instance is already active may be skipped even if no other instance is active. This may occur when all of the following are true:

• The job has one or more conditions.
• The job is assigned to a Queue with the following characteristics:
  • "Slave" or "Load Balance" mode
  • Check conditions on the Master
  • Run on Master not checked

 

When you submit a job for manual execution (through the Execute command in the Console or the adtexec tool) you may receive errorADT000003X: An error occurred on the server while processing the request. The job is successfully submitted for execution despite the error.

This problem was resolved.

When adTempus runs multiple jobs at the same time and all use the same Credential Profile, the jobs are run under a single logon session for the user. In cases where two jobs need to map the same drive letter to different resources, this causes the second job's mapping to fail, because the drive letter is already being used in the logon session.

This behavior was modified so that jobs that use different mappings are run under different logon sessions.

When a script run by a Script Execution Task fails with an error such as an unhandled exception, adTempus may report the status of the step as "Execution Failed" rather than "Failed." Because of this, the step is treated as a failure even if the Success Determination Rule is set to "'Report the step as Successful...'

This behavior has been changed so that "Execution Failed" is only reported if a script cannot be started, and "Failed" is used for any failures during script execution.

For more information see Knowledge Base article K00000461.

Previous behavior: when e-mail notification fails for a job, adTempus logs a warning message to the Job Log and continues to retry the notification at intervals for up to an hour. If notification is still not successful after that time, an Alert is logged.

New behavior: The initial warning message is now logged as an Alert instead of just appearing in the Job Log for the job.

Due to a problem in an earlier version of the software, the adTempus 2 or adTempus 3 database may contain records that point to data that has been deleted. This causes the database upgrade process to fail. The database conversion scripts were modified to remove the invalid data during conversion.

For more information see Knowledge Base article K00000432.

adTempus Administrators added through the Database Configuration Wizard or the Administrator Provisioning tool may not be added to adTempus on service startup.

adTempus can now automatically create logins for users based on Active Directory group membership. See Automatic Login through Group Membership in the online help for more information.

For more information see Knowledge Base article K00000428.

For more information see Knowledge Base article K00000423.

If a Program Execution Task, Script Execution Task, or Response Event has an exit code rule that tests for a value equal to 0, the "0" value is not displayed in the Console (the entry box is empty). However, the criterion is still applied correctly using a value of 0. If the criterion is set to a value other than 0, it is displayed correctly.

For more information see Knowledge Base article K00000426.

For more information see Knowledge Base article K00000427.

As a result adTempus cannot connect to the adTempus database if the LocalSystem account did not already have permissions for the database. Database wizard was fixed to ensure that LocalSystem account is granted permission for adTempus database.

For more information see Knowledge Base article K00000424.

For more information see Knowledge Base article K00000425.

For more information see Knowledge Base article K00000429.

PowerShell scripts can now reference/include other scripts.