June, 2007

  • Jakub@Work

    Monitoring Microsoft


    A blog about using SCOM in Microsoft IT. Thought I would share it here as a great resource on large scale enterprise use of SCOM.

  • Jakub@Work

    Tiering Management Groups in SCOM 2007


    In MOM 2005 tiering was achieved using the Mom to Mom Connector which physically copied data from lower tiers to upper tiers. While this generally worked, it certainly posed problems around performance as well as keeping the items in sync. The main scenarios this was meant to solve were:

    1. A single console for viewing data from multiple tiers
    2. No connectivity requirement from console to lower tiers

    In SCOM 2007 the approach we took for tiering was different, although accomplishes the same goals. As opposed to copying the data from tier to tier, instead we allow the upper tier console to connect and interact with the lower tiers directly, without requiring direct access to those management groups. The way we accomplish this is by connecting to those management groups via the local management group that console is connecting to.

    In order to use this feature, the first thing required is actually setting up the tiered connection from the local management group to the management group you want to connect to. This can be accomplished in the UI via the "Connected Management Groups" settings in the Administration pane, or via the SDK. Via the SDK, you would start by retrieving the TieringAdministration class off of an instance of ManagementGroup using:

    public TieringAdministration GetTieringAdministration()

    Once you have this object there are two overloaded methods for creating a TieredManagementGroup.

    public TieredManagementGroup AddMonitoringTier(string name, ManagementGroupConnectionSettings tieredConnectionSettings)
    public TieredManagementGroup AddMonitoringTier(string name, ManagementGroupConnectionSettings tieredConnectionSettings, 
     MonitoringSecureData runAs, bool availableForConnectors)

    The first gives the tiered connection a name and specifies the connection settings to use to connect to that tier; the ServerName, UserName, Domain and Password are required on the ManagementGroupConnectionSettings object. The second overload is actually much more convenient when later using the TieredManagementGroup. If you specify a RunAs account here, you can actually have the system use that account to connect instead of having to provide the username and password each time. If you specify availableForConnectors to true, the TieringAdministration method GetMonitoringTiersForConnector() will return this tier and subsequently all "tiered' MCF overloads will include this tier in their processing. You do not actually have to make the tier available for connectors to use the RunAs feature, but most likely those go together. Also note that when requesting the stored account be used to connect, the caller must be a SCOM Administrator.

    Now, in order to actually connect to the tier, you first need to retrieve the TieredManagementGroup for the tier you want to connect to. There are a few methods on TieringAdministration that allow you to do this:

    public ReadOnlyCollection<TieredManagementGroup> GetMonitoringTiers()
    public TieredManagementGroup GetMonitoringTier(Guid id)
    public TieredManagementGroup GetMonitoringTier(string name)
    public ReadOnlyCollection<TieredManagementGroup> GetMonitoringTiersForConnectors()

    Once you have the TieredManagementGroup you want to connect to you simple call the following method on that instance:

    public ManagementGroup Connect(TieredManagementGroupConnectionSettings tieredConnectionSettings)

    The TieredManagementGroupConnectionSettings are very similar to the regular ManagementGroupConnectionSettings with a single addition ConnectForConnector property. If this property is true, than the SDK service of the local tier will use the associated RunAs account to connect to the lower tier, requiring the caller to be admin. If this is false, credentials must be provided. For security reasons, we do not use the SDK Service account to connect to the lower tier.

    Once you call the Connect method above, you get a ManagementGroup back that you can work with just like a local ManagementGroup instance, only this one is connected to a different tier via the local one.

    Largely, this is the recommended approach for interacting with different tiers as it gives you full control over handling errors in each when aggregating data across multiple tiers, however, we do provider some "tiered" methods specifically for the SCOM Connector Framework. If you look at the MonitoringConnector class found in the Microsoft.EnterpriseManagement.ConnectorFramework namespace, it has several methods names with a "ForTiers" suffix. The behavior of each is roughly the same, so I won't go over all of them, instead we'll just look at one sample:

    public ReadOnlyCollection<ConnectorMonitoringAlert> GetMonitoringAlertsForTiers(out IList<ConnectorTieredOperationFailure> failures)

    The non-tiered version of this method gets all alerts for the given connector from the local management group based on the bookmark of the connector. This method does the same, only it does it for all the tiers that have been created as "Available for Connectors" as mentioned earlier. The implementation is nothing special in that it simply uses the aforementioned tiering method to retrieved tiers, connect to them and call GetMonitoringAlerts on each, subsequently aggregating the results. Exceptions will be thrown if there are connectivity problems to the local tier, otherwise errors are captured in the out parameter.

  • Jakub@Work

    Submitting Tasks with Additional Configuration


    I had a post earlier about submitting tasks, but I did not discuss how to specify additional configuration when submitting these tasks at that time. The two things that are configurable for tasks are credentials and overrides. Credentials allow you to change what user the task is executed as, while overrides allow you to change some of the configuration parameters that are defined as overrideable for the task.

    To determine what is overrideable on a particular task, you have to look at the task definition to find the module type the task in implementing. In the attached sample management pack, the module type used by the task, System.Health.ResetState, is System.Health.SetTargetStateAction. When you look at that module type in the sample management pack, you will notice it has a single overrideable parameter called MonitorId which is defined as a string.

    In order to provide the override to the task, you must specify, per overrideable parameter, the new value you would like to use within the MonitoringTaskConfiguration object. If the module type of the task has no overrideable parameters, you can't override anything. The below sample along with the attached management pack shows how to do this in the SDK.

    Note: I pulled this sample out of one of our existing management packs that are internal to SCOM. This task can be executed indirectly by calling the various ResetMonitoringState methods in the SDK. Also note that the sample will not actually "work" in the sense that the credentials are bogus and the monitor id I am passing in is also bogus, but it should illustrate how to do this process legitimately for other tasks.

    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 RunningTasksWithConfiguration() { // 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 = 'System.Health.ResetState'"); MonitoringTask resetStateTask = 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 resetStateTaskConfiguration = new MonitoringTaskConfiguration(); // Specifying credentials SecureString password = new SecureString(); password.AppendChar('p'); password.AppendChar('a'); password.AppendChar('s'); password.AppendChar('s'); password.AppendChar('w'); password.AppendChar('o'); password.AppendChar('r'); password.AppendChar('d'); resetStateTaskConfiguration.Credentials = new WindowsMonitoringTaskCredentials("Domain", "UserName", password); // Specifying the override // First we need to get the overrideable parameter that is defined // on the module type that the task uses. ManagementPackModuleType setTargetStateWriteAction = mg.GetMonitoringModuleTypes("System.Health.SetTargetStateAction")[0]; // This allows us to override the monitor id ManagementPackOverrideableParameter overrideParam = setTargetStateWriteAction.OverrideableParameterCollection[0]; // Set the value of the parameter as a string. In this case it's a Guid. resetStateTaskConfiguration.Overrides.Add( new Pair<ManagementPackOverrideableParameter, string>(overrideParam, Guid.NewGuid().ToString("B"))); // Now we need to get an instance to execute this task on. Since this task // is targeted to entity, any instance will do. MonitoringClass healthServiceClass = mg.GetMonitoringClass(SystemMonitoringClass.HealthService); // Next get the object (we'll just pick the first one) MonitoringObject healthServiceObject = mg.GetMonitoringObjects(healthServiceClass)[0]; // Now we execute the task. ReadOnlyCollection<MonitoringTaskResult> results = healthServiceObject.ExecuteMonitoringTask(resetStateTask, resetStateTaskConfiguration); } } }
Page 1 of 1 (3 items)