February, 2007

  • Jakub@Work

    Tasks not working?

    • 2 Comments

    If you are experiencing any issue where notifications aren't working, which can manifest itself as the UI not having management pack related information updated or tasks never completing (like discovery), one thing to look at is broker settings in SQL. If you run the following command (replacing the database name with whatever you named the Operations Manager database):

    SELECT is_broker_enabled FROM sys.databases WHERE name='OperationsManager'

    The result should be 1. If it is not, you need to run the following to enable it:

    ALTER DATABASE OperationsManager SET ENABLE_BROKER WITH ROLLBACK IMMEDIATE

    Warning: WITH ROLLBACK IMMEDIATE will terminate any currently running transactions, but the command needs exclusive access to the db, and thus is required.

    Update: Dustin Hannifin also put up a post regarding this issue and running SQL Server with an account that does not have proper permissions on the SQL Brroker queue. This usually is caused by running SQL as a local user.

  • Jakub@Work

    Running Tasks

    • 4 Comments

    I've had some questions regarding how to run tasks via the SDK so I thought I would post an example here. The code below shows the various ways of executing tasks in the SDK. The underlying implementation relies on query notifications from SQL 2005 to notify us whenever the status of a particular batch changes; we actually register a new notification for every batch, but since the format of the notification is the same and only parameters change, the performance is not overly affected.

    The code is pretty self-explanatory. I don't recommend using the synchronous version of the API because if something unexpected happens to the task your application will be stuck on the call until it times out (30 minutes) OR if you actually expect your task to take longer than 30 minutes, this version will timeout prior to your task completing. Also, if you don't care about getting notified of the results immediately, you can use the SubmitTask(s) API without providing a callback and simply query for results at a later time using the batch id you get from the call and the GetMonitoringTaskResults method available on both ManagementGroup and MonitoringObject.

    using System;

    using System.Collections.ObjectModel;

    using Microsoft.EnterpriseManagement;

    using Microsoft.EnterpriseManagement.Configuration;

    using Microsoft.EnterpriseManagement.Monitoring;

     

    namespace Jakub_WorkSamples

    {

        partial class Program

        {

            static void RunningTasks()

            {

                // Connect to the local management group

                ManagementGroup mg = new ManagementGroup("localhost");

     

                // First lets get the task we are going to execute

                // Note: Indexing the result like this is not necessarily the best

                // practice here, since there could be more than one task with this

                // name.

                MonitoringTaskCriteria taskCriteria = new MonitoringTaskCriteria(

                    "Name = 'Microsoft.SystemCenter.GetAllFailedWorkflows'");

                MonitoringTask failedWorkflowTask =

                    mg.GetMonitoringTasks(taskCriteria)[0];

     

                // Configuration allows you to specify credentials to use different

                // from the default. It also allows you to specify overrides, if

                // any are available

                MonitoringTaskConfiguration failedWorkflowTaskConfiguration =

                    new MonitoringTaskConfiguration();

     

                // Now we need to get an instance of a health service

                // First get the class

                MonitoringClass healthServiceClass =

                    mg.GetMonitoringClass(SystemMonitoringClass.HealthService);

               

                // Next get the object (we'll just pick the first one)

                MonitoringObject healthServiceObject =

                    mg.GetMonitoringObjects(healthServiceClass)[0];

     

                // Object centric task execution

               

                // Synchronous

                ReadOnlyCollection<MonitoringTaskResult> results =

                    healthServiceObject.ExecuteMonitoringTask(failedWorkflowTask,

                    failedWorkflowTaskConfiguration);

     

                // Asynchronous (standard .Net implementation)

                IAsyncResult asyncTaskResult =

                    healthServiceObject.BeginExecuteMonitoringTask(

                    failedWorkflowTask,

                    failedWorkflowTaskConfiguration,

                    null, // You can specify a callback

                    null); // And additional context

     

                results = healthServiceObject.EndExecuteMonitoringTask(asyncTaskResult);

     

                // Asynchronous (more advanced SCOM specific implementation)

                Guid batchId = healthServiceObject.SubmitMonitoringTask(failedWorkflowTask,

                    failedWorkflowTaskConfiguration,

                    MyTaskCallback);

     

                // Task execution off ManagementGroup (for multiple targets)

                PartialMonitoringObject[] targets =

                    new PartialMonitoringObject[] { healthServiceObject };

     

                // Synchronous

                results = mg.ExecuteMonitoringTask(targets, failedWorkflowTask,

                    failedWorkflowTaskConfiguration);

     

                // Asynchronous (standard .Net implementation)

                asyncTaskResult =

                    mg.BeginExecuteMonitoringTask(

                    targets,

                    failedWorkflowTask,

                    failedWorkflowTaskConfiguration,

                    null, // You can specify a callback

                    null); // And additional context

     

                results = mg.EndExecuteMonitoringTask(asyncTaskResult);

     

                // Asynchronous (more advanced SCOM specific implementation)

                batchId = mg.SubmitMonitoringTask(targets,

                    failedWorkflowTask,

                    failedWorkflowTaskConfiguration,

                    MyTaskCallback);

     

                // Wait for the task to complete

                System.Threading.Thread.Sleep(5000);

            }

     

            private static void MyTaskCallback(Guid batchId,

               ReadOnlyCollection<MonitoringTaskResult> results,

               bool completed)

            {

                if (completed)

                {

                    Console.WriteLine("Batch Id {0} is done!", batchId);

                }

            }

        }

    }

     

  • Jakub@Work

    Is My Rule/Monitor Running?

    • 1 Comments

    Well, I haven't had a lot of inspiration lately in terms of questions to blog about. If nothing comes up in the next week or so, I might just start writing about various components in the SDK as it is a rather larger API, that is not particularily well documented at this point. Before I go down that route, however, I was going to give a quick tutorial on how to check if a rule/monitor is running.

    1. Open the UI :-)
    2. Go to the Monitoring Node
    3. Go to the Discovered Inventory View
    4. By default this view is scoped to Computer, you will want to change this by looking at the right Actions pane under State Actions. Hit "Change target type..."
    5. In the :Look For" text box type "Health Service" and select it from the list below. The view will now refresh.
    6. Select the health service you want to see if the rule/monitor is running for. The right pane will now change and Health Service Tasks should appear under State Actions.
    7. Select "Show Running Rules and Monitors for this Health Service" and run it.
    8. You can also run "Show Failed Rules and Monitors for this Health Service"

    The output will look something like this (exact formating is not persisted, but the data should be about right): 

       Show Running Rules and Monitors for this Health Service Task Description
    Status: Succeeded
    Scheduled Time: 2/5/2007 11:52:25 AM
    Start Time: 2/5/2007 11:52:28 AM
    Submitted By:
    Run As:
    Run Location:
    Target:
    Target Type: Health Service
    Category: Maintenance
    Task Output:
    < DataItem type =" WorkflowsReport " time =" 2007-02-05T11:52:29.2045781-08:00 " sourceHealthServiceId =" 00000000-0000-0000-0000-000000000000 " >
      < Status > Running </ Status >
      < Count > 151 </ Count >
    < Details >
    < Instance Id =" {0914A006-3C72-0E16-1B17-C542E1C6953E} " >
      < Workflow > Microsoft.Windows.Server.InstanceGroup.Discovery </ Workflow >
      </ Instance >
    < Instance Id =" {099BFE0F-FDDB-8D5A-67AF-A79317EB6E91} " >
      < Workflow > Microsoft.SystemCenter.PopulateManagementServerComputerGroup </ Workflow >
      < Workflow > Microsoft.SystemCenter.ComputerGroup.AvailabilityRollup </ Workflow >
      < Workflow > Microsoft.SystemCenter.ComputerGroup.PerformanceRollup </ Workflow >
      < Workflow > Microsoft.SystemCenter.ComputerGroup.ConfigurationRollup </ Workflow >
      < Workflow > Microsoft.SystemCenter.ComputerGroup.SecurityRollup </ Workflow >
      </ Instance >
      </ Details >
      </ DataItem >

    The Instance Id in the xml is the Id of the monitoring object that the rule/monitor is running for. The name in the Workflow node is the name of the rule/monitor as defined in the management pack. This is not the same as the display name show in the UI.

Page 1 of 1 (3 items)