3.2.1 Abstract Data Model

  • Article

This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. The described organization is provided to facilitate the explanation of how the protocol behaves. This specification does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this specification.

The primary conceptual data structure maintained by the server is a task store. The task store MUST be persistent. It MUST consist of three logical stores having the following characteristics:

  • ITaskSchedulerService servers MUST support an XML task store, which is a hierarchical store that holds XML task definitions (section 2.4.2.11). The server MUST support security descriptors on folders in the XML task store.

  • SASec servers MUST support a .JOB task store, which is a single file folder holding .JOB files (section 2.4) that MUST be accessible via a remote file-system protocol. In addition to the file folder, the .JOB task store MUST contain a Boolean value per task, which differentiates between valid and invalid tasks.

  • ATSvc servers MUST support an AT task store, which is a list of AT_ENUM task information structures (section 2.3.6).

A Task Scheduler Remoting Protocol server that implements more than one of these interfaces MAY consolidate the task store data structures, to the extent that the individual interfaces' semantics (as specified later in this section) are preserved. In particular, tasks created or modified using the ATSvc interface MUST be visible (that is, enumerable and controllable) using the ITaskSchedulerService, SASec, and ATSvc interfaces.

Tasks created or modified using the SASec interface MUST be visible using the ITaskSchedulerService and SASec interfaces. Servers that implement both the ATSvc and SASec interfaces MUST make the ATSvc tasks visible in the SASec interface using SASec task names derived from the ATSvc task ID as follows: "at%d.job" where the "%d" is replaced by the base-10 string representation of the task ID.<45>

Server implementations of the SASec interface MUST store the path name of the file-system location of the .JOB task store in a registry [MS-RRP], in a location agreed between the client and the server.<46>

Server implementations of the SASec interface MUST maintain a conceptual data structure known as the account name store. The account name store MUST be capable of mapping task names (.JOB file names) to account names. If the server implements both the ITaskSchedulerService and SASec interfaces, then the server MUST consolidate the account name store and the XML task store, as follows: the account name associated with an SASec task (supplied by the client in the pwszAccountName parameter of the SASetAccountInformation method) MUST be visible in the UserId element of the corresponding XML task definition (section 2.5.6) if it is not the empty string, and "LocalSystem" MUST be visible in the UserId element (section 2.5.6) if the account name is the empty string.

Server implementations of the SASec interface MUST maintain a conceptual data structure known as the ATSvc account name. The ATSvc account name MUST store a single string, which is the account name associated with all ATSvc tasks (supplied by the client in the pwszAccountName parameter of the SASetNSAccountInformation method). The initial value of the ATSvc account name MUST be "LocalSystem".

Server implementations of the ITaskSchedulerService and SASec interfaces MUST maintain a conceptual data structure known as the credential store. The credential store maps account names to passwords. If the server implements both the ITaskSchedulerService and SASec interfaces, the interface implementations MUST share a single credential store.

Server implementations of the ITaskSchedulerService and SASec interfaces MUST maintain a conceptual data structure known as the running task list. An entry in the running task list MUST contain an instance ID, the location of the task in the task store, sufficient information to allow the task to be stopped (including a process ID or PID), a state (section 2.3.13), a delay time, and an action Unicode string. The action string SHOULD only be valid when the state is TASK_STATE_RUNNING. The delay time MAY only be valid when the state is TASK_STATE_QUEUED.