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.