Taskset action.
As mentioned before, the Taskset action makes it possible to start any mode from any Taskset.
| Synchronous
The execution of the Session Event will be nested in the calling Session Event. The illustration on the left shows Session Event 1 being executed. Halfway Session Event 1 the Taskset Action is executed, resulting in the creating of a new runtime object. This object is taking care of the execution of Session Event 2 When Session Event 2 is finalized, Scense returns to Session Event 1 and the remaining part of Session Event 1 will be executed. |
 |
| Asynchronous When processing asynchronously, the completion of the second Session event is not waited for. The second Scense process will execute Session Event 2, simultaneous to the execution of Session Event 1. These two session events are run in the same security context. |
 |
OnDemand action.
The OnDemand Action offers the possibility to have a Taskset executed by Scense OnDemand Service. This can be done in two ways:
| Synchronous When processing synchronously Scense waits for the completion of the task to be executed by the OnDemand Service. The OnDemand Service will execute Session Event 2 within the security context of the service. When completed, it will continue with Session Event 1 within the user’s security context. |
 |
| Asynchronous When processing asynchronously, the completion of tasks to be executed by the OnDemand Service is not waited for. The OnDemand Service will execute the Session Event 2 within the security context of the server, while Session Event 1 is completed within the user’s security context. |
 |
Direct OnDemand
Another way of interacting with the OnDemand service is called ‘Direct OnDemand’.
This method allows administrators to indicate for each action whether it should be executed in the context of the user, -the OnDemand service or both.
The Session Event will be started normally and runs in the context of the user.
If the Scense Executive encounters an action for which the administrator has specified to be run by the OnDemand service, it will request an ‘elevated executive’ from the OnDemand service.
The OnDemand service will spawn a new instance of the Scense Executive (hosted by Scense.exe) which will then be connected to by the Scense Executive running in the context of the user.
The two Scense Executive instances will communicate directly and the ‘Elevated Executive’ will accept and execute actions from the user mode executive. Any command output such as logging will be communicated back to the user mode executive.
The actions executed by the elevated executive will be run in the security context of the OnDemand service, but it will try to execute the action with the users ‘identity’ as much as possible.
This means:
- In registry actions the HKEY_CURRENT_USER will map to the user, not to the OnDemand service.
- All internal variables and environment variables will be resolved by the user mode executive, not by the elevated executive.
- All conditions will be evaluated by the user mode executive, not by the elevated executive.
This feature provides great flexibility.