Where are tasks stored?
When tasks are stored in the MOM database, they are not actually stored in a hierarchy but have their hierarchy stored as a path (in a similar way to how reports are stored in SQL Server Reporting Services). When you look in the OnePoint database, you will find that the tasks actually appear in a table called "Task2" (and not in the table called "Task" that seems to be unused!).
You will see that there is no table that maintains the hierarchy or parent/child relationships as there is for rules and rule groups. Instead, in the task2 table this hierarchy is just held in the name column, as shown below:
(click on the image to see in full size)
Cleanup of tasks
One of the consequences of how tasks are stored is when you release a update to a management pack that has some of the tasks removed. Because there is no hierarchy, when the management pack is deployed any tasks will be overwritten with their updated counterparts in the new management pack. However, if the new management pack has had some tasks removed from it, they will still be present in the deployed environment unless additional steps are taken to remove them.
The easiest way to remove them is via a SQL script. In you management pack you will no doubt have created a folder for your tasks off the root, e.g. "My Tasks". All you would have to do is to run a script that deletes the tasks before the management pack is deployed, i.e.
DELETE FROM Task2 WHERE [Name] LIKE 'My Tasks%'
The scripted deployment of management packs will form another post, but if you do a scripted deployment you can run this SQL script before you deploy the management pack and you will find that all your tasks are cleanly deployed, including any that have been removed as part of the update.
Other task issues
You will no doubt have noticed that unlike just about any other feature that you create in a management pack, tasks are one thing that you cannot copy or move. This is a right-royal pain in the butt, because as you develop your management pack you will be likely to face the following scenarios:
- You decide that you have too many tasks and you need to add more depth to your task folder structure
- You need several tasks to execute the same command-line tool or script, but with different parameters (a recent example I had of this was to resume BizTalk orchestrations in an application, with a task for each type of orchestration.
Summary
In Microsoft Operations Manager 2005, tasks are a really powerful feature for systems management, but under the skin they are not as solid as you'd hope. Also, the edit and deployment of tasks has a couple of holes. You can plug these if you know whre to hack. Enjoy!
