Release Notes for adTempus 3.0 (March 31, 2008)

Previous versions of adTempus allowed you to "acknowledge" failed job instances shown in the failed job view by changing the filter date to exclude those instances. adTempus 3.0 introduces true acknowledgment: a user can selectively and permanently "acknowledge" the failure of any instance, and doing so removes the instance from the failed jobs view of all other users as well.

When the adTempus service cannot start due to database connectivity problems or other issues, adTempus now logs more descriptive error messages in the Application log in the Event Viewer. Previous versions often gave generic error messages that did not help the user determine the cause of the problem.

adTempus is now fully compatible with Windows Vista and Windows Longhorn. Some visible changes to support these operating systems include:

• When configuring a job that runs under an administrator account, you can specify that the job should be run "with highest privileges," which is equivalent to running the program "As Administrator" from the Windows shell. adTempus will then run the program with full administrator privileges enabled, without a user access control (UAC) prompt.
• The adTempus Console and other client tools are marked to be run with elevated privileges when run by an Administrator. Administrators will therefore see UAC prompts when running the client tools.

In previous versions of adTempus, the User ID and Password had to be entered for each new job, requiring the user creating the job to know the password for the account that is used to run the job. adTempus 3.0 introduces Credential Profiles to replace the old mechanism. Credential Profiles allow users to be given permission to run jobs under a Window user account without knowing the password for that account.

The first time a given Windows User ID is used on an adTempus job, adTempus prompts the user creating the job for the password for that User ID, and creates a Credential Profile for that User ID. Any subsequent user who tries to use that User ID is prompted for the password. If the user knows the password, she is granted permission to use the Credential Profile. Once a user has permission to use a Credential Profile, she is able to use it on any job, without needing to re-enter the password.

The "owner" of a Credential Profile (or another authorized user) can also grant usage permission for the Profile to other users, who can then use it without having to know the password for the User ID.

If the password for the account changes in Windows, the Credential Profile can be updated by any authorized user to store the new password, and the change affects all jobs that use the Profile.

The issue preventing jobs in groups from appearing in the Console on Agents has been resolved.

For more information see Knowledge Base article K00000137.

In previous versions of adTempus, a file wildcard such as "*.txt" would match "file.txt" but also "file.txt_backup". This mirrored Windows wildcard evaluation behavior, but produced unexpected results. Beginning with adTempus 3.0, wildcard evaluation has been changed to be more strict in its matching.

A new "ProcessExitCode" job variable is now set with the exit code from the program run by a Program Execution Task. This variable can be used by Response scripts that need to know the outcome of the task.

The "ConditionFileName" job variable is set with the name of the file that satisfied a file condition.

Previous versions of adTempus allowed you to specify additional environment variables to be set for Program Execution Tasks, and provided limited support for runtime variables through the use of "Script Parameters."

This version of adTempus introduces "Job Variables," which provide a more flexible way of specifying dynamic values. Job Variables may be defined at many levels within adTempus: Job Step, Job, Group, Queue, and Server-Wide. Each job inherits the variables defined at higher levels of the hierarchy.

Job Variables simplify adTempus configuration by allowing you to easily change values that are used frequently. For example, you may have a group of jobs that all process input files coming from one of your customers, so they all have command-line parameters pointing to files in the directory that you use for that customer's data. Instead of "hard-coding" that directory name in each job and job step, you would use the token "%CustomerFileLocation%". In the properties for the group that contains all the jobs, you would define the "CustomerFileLocation" Job Variable, and set it to the appropriate directory. At run-time, the token in the job is replaced with the value you have defined. If you subsequently duplicate this group of jobs to process files from another customer, you can simply change the value of the CustomerFileLocation variable to point all of the jobs to the new customer's directory.

Previously, if you wanted a job to wait until a condition was met, you were required to enter a maximum wait time. A "wait forever" option is now available.

When Job A triggers Job B through a Response, Job B will ignore any conditions that it has on Job A. Previously, conditions were enforced, resulting in situations where Job B could not be executed as desired.

An add-in framework has been added to adTempus, which allows developers and system integrators to develop their own custom adTempus components (tasks, conditions, triggers, response actions).

For example, a developer could easily create a custom task to support an in-house application that is frequently run by adTempus, giving users a more friendly user interface rather than requiring that they know the command-line parameters for the application.

Previous versions of adTempus included SQL Server Desktop Edition (MSDE) based on SQL Server 2000. The new default database is SQL Server 2005 Express. Customers still have the option of using their own SQL Server instance if they prefer.

Customers who are currently using MSDE will be given the option of upgrading to the new database engine during installation.

SQL Server Express installation has been integrated more tightly into the adTempus setup program, and no longer requires a separate download.

When the Master cannot connect to an Agent, information on the reason for the failed connection is now displayed. Previous versions only indicated whether the Agent was connected, and provided no information that could be used to diagnose a connection problem.

In some cases, modifications made on the Master to shared objects (such as shared schedules, scripts, and notification recipients) were not sent to Agents, causing Mirrored jobs to run with the wrong settings. This problem has been resolved.

System operators or other users can now add comments to a job's history. For example, if a job fails, the operator may want to record details of what caused the failure and what error resolution steps were taken. Comments for each instance are viewed and edited on the new Comments page of the Job Instance Details window (displayed when you view the details from an instance on the History page of the main job list).

When the Console is connected to an adTempus server on a remote computer, file browse dialog boxes (like the browse for target dialog for a Program Execution Task) now list files from the remote computer. Previously, file browsers listed files from the local computer.

The adTempus Console now allows you to duplicate a Job Group, which duplicates all jobs in the group.

The Tools menu of the adTempus Console now has a Search/Replace command that can be used to replace strings in various properties of jobs.

When you create or modify a job, adTempus performs a logon check to ensure that the credentials specified for the job are valid, and warns you if they are not.

When a job step fails, a message is now logged to the job log indicating the reason the step failed (e.g., because the program run by adTempus returned a failure exit code).

In Console views that show step information, the display now shows the step number, name of the step (if entered), and total number of steps. Previously, lists only showed the step number.

When editing the command-line parameters for a Program Execution Task, you can now display a larger editing box, making it easier to view and edit long command lines.

When you run a job manually or using a Job Control Action in a Response, a new option allows you to determine how Responses for the job will be executed. You can choose to execute all Responses, to execute all Responses except those that chain to other jobs, or no Responses. This option makes it easier to run only part of a job chain when necessary, e.g., when testing your chain or rerunning it due to failures.

When a step fails, adTempus now logs a message explaining why (e.g., the executed program returned an error exit code).

In previous versions of adTempus, if you attempted to delete an object that was referenced by other objects (for example, a notification recipient that was in use on one or more jobs), adTempus displayed an error message telling you that the object was in use, but did not provide any information on where the object was being used. adTempus now displays a list of all places where the object is being used, and gives the option to automatically remove those references so the object can be deleted.

In previous versions of adTempus, a job's history (execution history, log messages, and captured files) could only be purged through the automatic process controlled by the retention settings for the job. The adTempus Console now provides the option to purge the job's history complete on demand, and optionally to reset the statistics for the job as well. This new option can be found on the Statistics tab when the job is selected in the main job list.

When a job is pending execution because it is waiting for a condition, a previous instance, or a queue slot, an authorized user can now force the job to ignore the dependency or requirement and run immediately.

File name entry boxes in the Console now use auto-completion to suggest file names as you type.

Previous versions of adTempus used an undocumented binary file format for exporting and importing data. adTempus now uses XML for exports and imports, making it easier for customers to modify exported data before it is imported into adTempus.

Due to this change, this version cannot read export files produced by earlier versions. If you want to preserve data in export files, you must import it before upgrading to adTempus 3.0, then export it again in the new format after upgrading.

All jobs are now assigned to a Queue. While the Job Groups already available in adTempus are used only to organize jobs for easier administration, Queues can affect the way jobs execute.

When a job is triggered (either automatically or through manual submission) it is sent to its assigned Queue for execution. Each Queue may have a limit on the number of jobs from that queue that can execute concurrently. Once that limit is reached, additional jobs are queued (in order of submission) to be executed when execution slots come available.

This concurrency limit can be useful in many situations. For example, you have a set of jobs that are processor-intensive, and running more than one of them at a time degrades server performance to an unacceptable level. To avoid this problem, you can create a new Queue with an execution limit of one job, and assign these jobs to that Queue. The Queue will ensure that no more than one of these jobs ever runs at the same time.

Similarly, you may have a set of jobs that all need exclusive access to a system resource such as a data file or hardware device. A Queue can be used to prevent more than one job from trying to use that resource at the same time.

The ADTGroupName and ADTQueueName environment variables are now defined for programs run by adTempus. They hold the names of the group and queue to which the job belongs.

A new option was added to allow the adTempus service to be started without executing any jobs, e.g., if you need to start the service to modify jobs, but don't want any jobs to be run while you do so. To suppress execution of jobs, run the Registry Editor and go to (or create if necessary) the key "HKEY_LOCAL_MACHINE\Software\Arcana Development\adTempus\options". Create a new String (REG_SZ) value named "Engine:RunJobs" and set it to "0". Then start the adTempus service.

To re-enable job execution, delete the value you created above, or set it to "1", then restart the adTempus service.

Responses can now be triggered based on the length of time a task has been running. For example, you can now configure a Response to send a notification message if a program runs for more than one hour. Previously, the only action that could be taken based on task execution time was to terminate the task after a specified time had elapsed.

When the adTempus service is started, it can automatically start (or restart) jobs that were "abandoned" when adTempus was shut down or whose execution time was missed because adTempus was not running. Previously, adTempus restarted these jobs in no particular order. adTempus now determines the proper sequence for all jobs that need to be started, based on their original run time (for abandoned jobs) or scheduled run time (for missed jobs). It then restarts the jobs in that sequence. This ensures that any inter-job dependencies that depended on jobs running in a particular order will still function correctly.

adTempus also now starts the jobs sequentially at one-minute intervals rather than executing all missed or abandoned jobs simultaneously, which often resulted in an overload on the server.

Previous versions of adTempus allowed you to configure each step to run either interactively or on a hidden desktop. When the interactive option was used, the program was visible on the "console" desktop for the computer. Users connected to the computer through Remote Desktop were not able to interact with the program.

adTempus 3.0 offers three interactivity options for each job:

• Run on a hidden desktop
• Run in the "console" session (the console session is the monitor physically connected to the computer or, on Windows Vista and later, the first session to log in to the computer).
• Run in the interactive session of the job's user (i.e., if the the job is configured to run under Bob's Windows ID, the job will run in Bob's interactive session if he is logged on).

Additionally, when you run a job manually through the adTempus Console, you can override the interactivity setting and force the job to run in your session, so that it is visible to you.

To support the new options, the interactivity setting is now made on the job properties, rather than individually for each step.

When you select the interactivity settings, you give a list of "allowed" settings. For example, you can specify that the job should run in the user's session, if available, or the console session if there is no session for the user, or in a hidden session if no interactive sessions are available. Or, you may specify that the job should run in the user's interactive session, and fail if there is no session for the user.a

In some cases, the "Include captured console output" option for Notification Actions did not work unless other files were also attached. This problem was corrected.

For more information see Knowledge Base article K00000237.

By default, e-mail messages sent by adTempus have a sender name of "adTempus", with the return address specified in the notification setup window. The sender name and address can now be overridden by setting the NotificationFromName and NotificationFromAddress job variables.

Because job variables are inheritable, you can choose the best level at which to set these variables. For example, setting them for a single job will change the values only for that job. If you set them for a group, all jobs within the group will use the settings (unless they define their own values).

The "subject" field for notification messages now supports token expansion, so tokens like "%ADTJobDescription%" will be resolved before the message is sent.

When defining advanced scheduling criteria using the "Trigger on specific days" feature of the Schedule Trigger, new options allow scheduling on the nth business day, non-business day, holiday, or non-holiday.

The Schedule Trigger now allows the user to select the time zone relative to which the trigger will be evaluated. For standalone adTempus instances, the trigger can be evaluated in the local time zone or in any time zone in the world. For example, a server located in Chicago can be configure to trigger using London time. When Distributed Scheduling is in use, mirrored jobs can be run in the time zone of the Agent, the Master, or in a specified time zone.

When editing a Schedule Trigger, the list of Shared Schedules now includes all defined Holiday Sets as well. This allows you to easily define jobs that run on holidays. Previously, Holiday Sets could only be used to exclude execution on holidays.

For more information see Knowledge Base article K00000106.

Previously, if a holiday set or shared schedule was updated, adTempus did not immediately recalculate the execution schedule for all affected jobs, causing the changes to be temporarily ignored in some cases. This issue has been resolved.

Previous versions of adTempus had built-in support for Windows Scripting Host (WSH) scripts, such as VBScript and JScript. adTempus 3.0 adds native support for scripts written in VB.NET and C#, with full support for referencing external .NET assemblies.

The scripting user interface has been improved, with a new syntax-highlighting script editor, and improved script validation.

In previous versions, there was no inheritance of object security. You could set “default” security for jobs, groups, etc., but these were simply the settings applied to new objects when they were created, and changing the defaults had no effect on existing objects. Thus if you wanted to grant a new group of users access to jobs, you had to modify the security settings for every affected job.

This version introduces security inheritance similar to folder and file security in Windows. This allows you to easily manage the permissions for all jobs or for groups of jobs, while still giving the flexibility to fine-tune settings for individual jobs.

The security hierarchy roughly follows the hierarchy of objects in the server tree of the adTempus Console. At the top of the hierarchy, the server security settings are inherited by all objects on the server. To modify these settings, go to the Tools menu and select Server Options, then General Options and go to the Security Settings tab.

The “Jobs” node under the server node is actually a job group—the root job group, which is the top of the job tree. Thus security settings applied to this group affect all groups and jobs in adTempus. To modify the security settings for the root group, right-click the “Jobs” node, select Edit Group… and go to the Security tab.

Note that when you edit the security for a group, you choose which objects each access entry applies to: the permissions can apply to any combination of the group itself, child groups, and jobs within the group and its subgroups.

Also beneath the server level are security settings for Queues, Notification Recipients and Providers, Shared Schedules, and Scripts and Script Libraries. To modify the security settings for these levels, right-click the appropriate node in the server tree and select the Security option.

In a new adTempus installation, there is only one access entry defined: in the server security settings, the computer’s Administrators group is granted full control for the server and all adTempus objects.

Upgrading Existing Security

Users upgrading from previous versions of adTempus may have permissions individually assigned to jobs and other objects due to the limitations of the earlier security model. For ease of administration, users will in most cases want to remove object-level permissions in favor of inherited permissions. For example, if all your jobs have the same security settings, earlier versions of adTempus required you to make those settings on each job. With security inheritance, you can make those settings at the root job level and have all jobs inherit them.

Therefore you may need to remove the existing explicit permissions from the individual objects, so that they can inherit all of their security settings. Rather than edit each object individually, you can modify a higher level of the security hierarchy and tell adTempus to remove the non-inherited permissions on each lower level.

For example, if you want all jobs to have the same security settings, edit the settings for the root group (the “Jobs” node in the server tree). After setting the permissions you want your jobs to inherit, check the “Remove explicit permissions on all child objects” box. This will remove all permissions that have been set on individual groups and jobs, forcing them to use only the settings you have defined at the root level. If you now need to tailor the security of certain group and jobs, you can then edit them to override the inherited security.

In previous versions, the Service Control Task required that you select the target service from a list of services installed on the computer. The user interface now allows you to enter a service name that is not on the list if necessary.

In previous versions of adTempus, the Job Wizard could be used to generate a script that could run and monitor SQL Server Agent jobs. In adTempus 3.0 this has been replaced by a full-fledged task that offers the same functionality but is easier to configure.

The Computer Monitor now supports sending authentication information to the Web server it is monitoring.

In previous versions of the adTempus API, collections used "one-based" indexing, consistent with Visual Basic practices. In this version the API has been modified so that all collections use "zero-based" indexing, consistent with modern C++ and .NET practices. As a result, all customer code that manipulates collections exposed by the API must be modified to use the new zero-based indexing.

The collections now expose enumerators, so customers may wish to change to enumerator access to the collections rather than index-based access.

The Application Exception Trigger has been removed.

Support for sending SMS notification through phones and modems attached to the computer has been removed. SMS messages can still be sent through SMS network gateways.