This blog post is intended for developers and people doing advanced customizations in Service Manager.
Tasks are a key component of the Service Manager user experience and infrastructure. There are two different kinds of tasks:
- Console Tasks
- Tasks (we usually call these “Runtime Tasks” to differentiate them from Console Tasks)
All the links that you see on the right hand side of the console or forms are Console Tasks.
Console Tasks run locally on the same computer as the console and run under the security context of the user that the console is running as. They also run in the same process as the Service Manager console (Microsoft.EnterpriseManagement.ServiceManager.UI.Console.exe).
Runtime Tasks are tasks which are submitted to the Management Server to process. These are typically used in background workflows, but occasionally can be submitted when a user clicks on a Console Task. An example of this is the Synchronize Now task in the Connectors view.
When the user clicks on the Console Task, the code that runs actually submits a request to run a Runtime Task to the management server which then triggers a synchronization job for the selected connector.
Both Console Tasks and Runtime Tasks are defined in management packs. Console Tasks are defined as MP elements <ConsoleTask> and Runtime Tasks are defined as <Tasks>.
You can control which Console Tasks and Runtime Tasks are available for users to run using User Roles.
Security footnote intended primarily for developers: We don’t control security access by granting/denying visibility to console tasks. Permission to do things is centrally controlled at the Data Access Service. Because a Console Task runs under the security context of the console user and runs locally on the console computer, the user could write a custom program that directly accessed the Data Access Service that does the same thing as the Console Task. If the user has permission to do the action at the Data Access Service then he will be allowed to do it using the custom program (even if the Console Task is not granted that does the equivalent action). Granting/denying visibility to console tasks is really only intended to improve the user experience by removing actions that you don’t want people to run or that you know they can’t do anyways. Runtime Tasks on the other hand are secured at the Data Access Service because they run in an elevated security context and on the central management server. If you do not grant someone access to a Runtime Task, they will not be able to submit it. Further, the user must have permission to submit the Runtime Task against the target object .
So – in summary:
| Console Tasks | Runtime Tasks | |
| Management Pack XML Element | <ConsoleTask> | <Task> |
| Run Location | Console | Management Server |
| Security Context | Console user | Run As Account defined per task |
| User Roles | Scoped for hide/show purposes only | Scoped for security purposes |
| Shown in Console? | Yes, in the Tasks pane of the main console or in forms windows. | No. They are typically run by background workflows. In some rare cases, a Console Task may submit a request to run a Runtime Task. |
| Display Output in Console? | Optionally, yes, output is shown immediately when the task runs. In some cases it makes sense to show output like a Ping task. In other cases it doesn’t make sense like a Remote Desktop task which has no output to show. | Since these tasks typically run in the background as part of workflows, you can see the results of the tasks in various places in the UI, especially in the Workflows Status view. |
| Can Create in the Console? | Yes, in the Tasks view using the Create Task wizard. | No. |
Next in this series, we’ll dive into Console Tasks in more detail.
Tasks Part 2 – Custom Console Tasks for Create, Edit, Delete