Thursday, June 22, 2006

Task storage and cleanup in MOM 2005

Just taking a few moments to log some thoughts on task storage in Microsoft Operations Manager 2005 (MOM 2005).

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.
With the knowledge of the table structure above, you can get round this by either changing the name of the task to add a folder to the path, or you can copy task rows in the database, refresh the Admin Console and then edit them to change the parameters.

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!

Wednesday, June 21, 2006

BizTalk Queue Depth Queries

I have been looking at monitoring Microsoft BizTalk Server 2004 using Microsoft Operations Manager 2005 (MOM), and in particular the queue depths and internal performance of BizTalk that is not exposed by performance counters.

I will be writing a post in the near future to explain a little about how to get this information into MOM in an elegant way, but for the moment you could do with reading this article on BizTalk queries "Working with Biztalk Database".

You can also look at the article "Advanced Microsoft BizTalk Server 2004 and Microsoft Operations Manager 2005 Scenarios".