Section 9.2. Connecting MOM to MOM


9.2. Connecting MOM to MOM

The MOM-to-MOM Product Connector is one type of product connector, and it is only used to send discovery and alert data between MOM 2005 management groups. There are other types of product connectors for MOM that allow bidirectional communication between a MOM management group and other management products or trouble ticketing systems. For example, Microsoft ships a MOM to a Tivoli TEC connector, a MOM to an HP OpenView connector, and a MOM to an HP Network Node Manager connector. These connectors are built on the MOM Connector Framework (MCF), which is one of the APIs that is included in the MOM SDK. There are other APIs in the MOM SDK, namely the MOM Managed Code Library (MCL) and the MOM Runtime interface.

The MMPC is a web service and runs as a service on management servers. The executable is momconn.exe . A web service is like a web page that contains a good deal of logic, but it has no interface to browse and can be accessed over a normal protocol (HTTP). It is used for passing data back and forth between applications. To make use of an MMPC, you must create a connector on the management servers in the source management groups. Because all of the configuration and operational information for a connector is stored in the OnePoint database, all of the management servers in the source management group can support the MMPC. This means that if the source management server that is hosting the MMPC fails, the MMPC function will failover to another source management server.

9.2.1. Creating a Tiered Configuration

Creating the source-to-destination relationship between two management groups requires that the MCF and MMPC are installed in the source management group, and that the MCF is installed on the management servers in the destination management group. These components can be installed when the management group is created or any time afterwards, as is the case here. The management groups used here to illustrate the installation and configuration process are in the same domain and use the same DAS account and Microsoft action account. The installation starts with the destination management group running the MOM 2005 Setup wizard. Proceed through the Welcome page to get to the Modify, Repair, Remove page as shown in Figure 9-3.

Figure 9-3. Choosing to modify an existing installation of MOM 2005


When you launch the setup wizard, the Modify, Repair, Remove page is presented because the wizard detected the previous installation. You can launch the setup wizard from the MOM 2005 CD or from the Control Panel's Add and Remove Programs feature; however, if you do the latter you may still be required to provide the source media. Select the Modify option and click Next to bring up the MOM 2005 Custom Setup page in Figure 9-4.

Under the MOM 2005 Management Server object, select to install the MOM Connector Framework with the "This component will be installed on local hard disk" option, and click Next. If you select the "This component and all dependent components" option, the MMPC will be installed as well. This doesn't hurt anything, but the MMPC is not required on the destination management group so it serves no purpose since only the MCF is required.

Click Next to proceed through the prerequisite checker, which will pass because MOM 2005 has already been successfully installed. Click Next again to bring up the Ready to Modify page where you click Install. The MMPC uses the MCF methods Connector.GetData and Connector.InsertAlert to retrieve new alerts or updated alerts from the source management group and insert them into the OnePoint database in the destination management group. To access both the source and destination OnePoint databases, the MMPC uses the DAS account from the source management group. To get access to the destination OnePoint database, the source DAS account must be placed in the MOM Service local group on all of the destination management servers. As I mentioned in Chapter 2, the MOM Service group is empty by default, so the source DAS account should be the only one in there. However, if you have created a domain-level MOM Service group, you can add the source DAS account to that and then add the domain group to the local group; either way will work. The source and destination management groups do not have to be in the same domain to set up this relationship. The only requirement is that you add the DAS account of the source management group to the MOM Service local group on the destination management servers.

Figure 9-4. Installing the MCF on the destination management group


Once the MCF installation completes, you should confirm that it is functioning correctly. On the management server where you performed the installation, open IE and browse to :1271/connectorservice.asmx">http://<computername>:1271/connectorservice.asmx where <computername> is the name of the server that you installed the MCF on. The number 1271 in the address signifies the default port that the MCF service is listening on. If everything is working correctly, you will get the page shown in Figure 9-5.

If the source-to-destination connection traverses untrusted network connections, you can SSL-secure the communication by placing a web site certificate on the destination management group's management servers.

Figure 9-5. MCF Connector Service page


Figure 9-5 shows some of the methods that are available in the MCF; by clicking on them you can bring up pages that show the code that makes up the method. For example, Figure 9-6 shows some of the code page for the Getdata method.

Most of the work done by the MMPC is through the Setup, Initialize, GeTData, AckData, and UpdateAlerts methods:


Setup

This method is called when you are creating an instance of the connector on the source management server. It sets up the connector.


Initialize

This method starts the connector that was created when Setup was called.


GetData

This call retrieves alerts and discovery data from the source management group OnePoint database. This method is called every 30 seconds, making it the most commonly called method in the MCF.


AckData

After an alert has been inserted into the destination group OnePoint database, the destination management group acknowledges receipt of the alert back to the source management group.

Figure 9-6. Some of the code page for the GetData method


UpdateAlerts

This method updates the information in an alert in either the source or destination management group when it is changed in the connected management group.

The next step in creating the tiered configuration is to install both the MFC and the MMPC on the source management group's management servers. For a previously existing management server, launch MOM 2005 Setup and select the Modify option. On the custom setup page (see Figure 9-4), instead of selecting the "Install this component" option, select "This component, and all dependent components." Then finish the Setup wizard just as you did for the MCF setup on the destination management group management servers.

Now you are ready to create the connector between the source and destination management groups. This example uses the LKFProdMG homesqlserver as the source and a new management group called TopTier that has homemomserver3 as its management server. The TopTier management group does not monitor any servers other than its own management server and database server, in keeping with the special purpose of the destination management group.

To create an MMPC, open the Administrator console and navigate to Administration Product Connectors and right-click to bring up the context menu. From the context menu, select Create MOM-to-MOM Connection as shown in Figure 9-7.

Figure 9-7. Creating a new MOM-to-MOM product connector


This starts the Create MOM-to-MOM Connector wizard. Click through the Welcome page to get to the Connector page, shown in Figure 9-8.

Provide the connector a meaningful, distinguishing name, in this case, "LKFProdMGToTopTierConnector." In the Resolution State ID field you can accept the default of 150 or supply your own value. Each MMPC registers a specific resolution state in the configuration portions of the OnePoint database. When any alert is set to this state, which appears as the connector name in the Resolution State drop-down list, that alert is forwarded to the connector for synchronization with the destination management group. Remember from Chapter 5 that every alert exists in one of several resolution states at any given point in time and that internal to MOM, the states are represented as numerical values.

For example, the resolution states of New and Resolved are reserved and have the values of 0 and 255 respectively. When you create a new MMPC, a new resolution state is created with the default value of 150. So when you forward an alert to the destination management group, you can either manually select the MMPC name (e.g., LKFProdMGToTopTierConnector) in the Resolution State list, or you can programmatically set the resolution state to 150 via an alert rule. This way, the forwarding will occur automatically, or you can have the alerts created with the default resolution state set to the name of the connector.

The Polling Interval refers to how often synchronization bits flow across the wire between the source and destination management group. It has nothing to do with the frequency that the Connector.GetData method is called, which is every 30 seconds. This means that if you leave the default settings, it could take up to 50 seconds for an alert to be synchronized from source to destination after it appears in the source Operator console.

Figure 9-8. Setting the properties for the MOM-to-MOM connector


Click Next to bring up the Add MOM Master Management Group page; see Figure 9-9.

At this point in creating an MMPC, you only have the option to designate one management server or web service. Later in the setup, you can enter additional web services to allow for failover at the destination management group level. Click Next to open the Forwarding Properties page; see Figure 9-10.

Synchronization across an MMPC can be one way (from source to destination), or two way (starting with the source, going to the destination and then back again) when the alert has been changed in the destination management group. By selecting only the first checkbox in the Alert Forwarding Properties section, you configure one-way synchronization. Selecting "Receive alert updates from Destination back to Source" configures two-way synchronization.

In the "Forward Discovery Information from Source to Destination" section, by selecting the "Forward all Discovery information" option, you will have the richest, most congruent experience between the two Operator consoles.

Figure 9-9. Identifying the destination management group's management server that the connector will communicate with


Figure 9-10. Configuring alert forwarding properties and discovery information forwarding


The MCF exposes MOM discovery data, which can be forwarded to the destination management group. This is very valuable, because otherwise only alertsand therefore only the Alert viewwould show data from the source management group. Since the discovery data is available, the State view, Computer Groups and Computers view, and the Diagram view all work just as they do in the respective source management groups. Because the computer grouping data is forwarded to the destination management group, you can execute destination Operator console tasks against servers that are managed by the source management group.

Now picture an architecture where there are several different source management groups synchronizing their data with a single destination management group. The destination management group provides a one-stop shop where you can view all of the alerts, the state of all your monitored machines and applications, and perform troubleshooting via tasks and resolve alerts.

Not all the data types in the source management group can be forwarded to the destination management group. For example, performance and events are not forwarded over the MMPC.

Click Next to open the Failover Configuration page, as shown in Figure 9-11.

Figure 9-11. Configuring destination management group MCF web service failover


If there are multiple management servers in the destination management group, you should install the MCF on every one of them. Once the MCF is installed, each destination management group management server will have its own instance of the connector service web service. You can add the management servers here and place them in the order that you want failover to occur from the top down. When you create an MMPC on a source management server, you can set one of the destination management servers as the primary target for communication and the others in the destination management group in whatever order you choose. This is somewhat like the process for configuring which management servers are available to an agent for failover.

Click Next to bring up a summary/review page that shows all of the configuration choices that have been made, and then complete the installation.

In the Administrator console of the source management group, you should now see a functional MMPC with the name you specified (e.g., LKFProdMGToTopTierConnector) as shown in Figure 9-12. The MMPC object is only editable from the Administrator console in the source management group; however, you should see it in the destination management groups Administrator console as well.

Figure 9-12. The MMPC as viewed in the source management group's Administrator console


In Figure 9-12, the LKFProdMGToTopTierConnector MMPC has a registered resolution state ID of 150. If any alerts are assigned that resolution state they are immediately sent to the MMPC for synchronization. All the parts are now in place and the next step is to configure the management groups for synchronization.

9.2.2. Configuring and Using an MMPC

For an alert to be successfully forwarded in a tiered configuration, the management packs must be synchronized between the source and destination management groups. This enables the destination management group to recognize a forwarded alert. The destination management group must contain a match to the rule that generated it from the source management group. The rules are matched based on their rule GUID, not on the management packs' version number. This means that the matching rule in the destination management group can be a different version as long as the GUID has not been changed. The easiest way to do this is to export all of the management packs from the source management group and then import them into the destination management group. One way to do this easily would be to modify the batch file that is used to synchronize and back up the management packs from the production to the preproduction environments. A sample batch file can be found in the "Protecting Management Packs" section in Chapter 4. By adding a line that imports the management packs into the destination management group the end of the batch file, you can ensure that your source and destination management packs are always in sync. In this example line, the server homemomserver3 is in the destination management group and the current version of the Microsoft Windows Base Operating System Management Pack is in the mptransferfolder\currentmp directory on homesrv02:

     ManagementModuleUtil.exe -I homemomserver3 \\homesrv02\mptransferfolder\     currentmp\     MicrosoftWindowsBaseOperatingSystemMP%varDate%-%varTime%.akm -R 

Admittedly, since only the rule GUIDs must match, synchronizing the management packs on a daily basis is overkill. However, having this process in place only requires a small amount of work and the benefits of automating this task far outweigh any concerns of unnecessary processing overhead.


When the same management pack exists in more than one source management group, you only need to be concerned if the rule GUIDs differ between the management packs. It is fine to have a management pack Version 1.0 in one source group, Version 2.0 in another source, and Version 1.5 in the destination group.

For this example, all of the management packs have been exported from the LKFProdMG source management group and imported into the top-tier destination management group. Now alerts can be forwarded between the two groups.

One way to forward alerts is to manually set their resolution state to the name of the MMPC. The name of the MMPC will appear in the list of available resolution states, as shown in Figure 9-13.

This step actually sets that alert resolution state to be 150, which is the resolution state value associated with the connector. The alert is then sent to the MMPC and synchronized to the destination management group. The alert appears in the destination group Operator console exactly as it does in the source Operator console. This alert resolution state only exists in the source management group; you cannot forward an alert from the destination back to the source. Since two-way synchronization is in place, any changes made to the alert in one console will also be made in the other. Therefore, resolving the alert in the destination Operator console resolves it in the source Operator console.

Figure 9-13. Manually setting the resolution state to the name of the MMPC


Manually forwarding alerts from source to destination is not a scalable solution. There is a preconfigured alert rule in the MOM management pack that addresses this issue. To enable automated forwarding of alerts, you must enable the alert forwarding rule and associate its rule group with the computer groups that then forward the alert to the destination group. In the Administrator console, navigate to Management Packs Rule Groups node Microsoft Operations Manager Operations Manager 2005 Connector Framework "Mark Alerts for forwarding to MOM Master management group rule group. In the alert rules, open the "Mark Alerts for forwarding to the MOM Master management group alert" rule. Select the "This rule is enabled" checkbox on the General tab. This alert rule fires for all alerts generated in the associated computer groups with a severity more than Error, as shown in Figure 9-14.

This alert rule has a single response, which is to call a VBscript named "MOM Mark Alerts for forwarding to MOM Master management group." This is a very simple VBScript that changes the alert resolution state to 150:

     '-------------------------------------------------------------------     ' <company>Microsoft Corporation</company>     ' <copyright>Copyright (c) Microsoft Corporation 2003</copyright>     ' <name>MOM Mark alerts for forwarding to MOM Master management group</name>     '-------------------------------------------------------------------     Option Explicit     Sub Main(  )        Dim myAlert        'change resolution state        Set myAlert = ScriptContext.Alert        myAlert.ResolutionState = 150     End Sub 

Figure 9-14. Criteria for the "Mark Alerts for forwarding to MOM Master management group" alert rule


By default, this rule group is not associated with any computer groups. In the example, the alerts with a severity greater than Error are forwarded for all computers that the source management group manages to the destination management group. This is done by associating the "Mark Alerts for forwarding to MOM Master management group" rule group to all the managed computers via computer groups. The computer groups chosen here are the Microsoft Operations Manager 2005 Agents and Microsoft Operations Manager 2005 Agentless computer groups. The combined membership of these two groups represents all of the managed computers that the source group is monitoring.

To create a rule group/computer group association, open the context menu of the rule group and select the "Associate with Computer Group" option as shown in Figure 9-15.

This opens the rule group's Properties page with the Computer Groups tab on top. From here you can click Add and select the computer groups that you want to create the association with; see Figure 9-16.

Figure 9-15. Creating a rule group/computer group association


Figure 9-16. Selecting the computer groups to create the association with


Click OK, then click Apply to close the rule group properties. Don't forget to commit the configuration change so the modifications go into effect and are distributed by all of the agents.

The process an alert goes through, from the time it is generated in the source management group to its ultimate resolution, is recorded in the Alerts History tab. The text from the Alert History Tab of an Agent heartbeat failure alert is as follows. On the History tab, the events are inserted at the top rather than at the bottom so if you start reading at the top, you are seeing the most recent events first. For sake of clarity, that order has been revised here, presenting the oldest events first.

     =================================================     7/20/2005 8:09:56 PM: NT AUTHORITY\NETWORK SERVICE     Alert is created in management group LKFProdMG.     =================================================     7/20/2005 8:09:57 PM: HOMELAB\dasaccount     HOMESQLSERVER:     [Forwarding] Attempting to forward new alert to LKFProdMGToTopTierConnector.     =================================================     7/20/2005 8:09:57 PM: HOMELAB\dasaccount     HOMESQLSERVER:     [Forwarding] Successfully forwarded alert change occuring at Jul 21 2005 1:09AM     (gmt) to LKFProdMGToTopTierConnector.     =================================================     7/20/2005 8:09:58 PM: HOMELAB\dasaccount     HOMESQLSERVER:     [Forwarding] Attempting to forward updated alert to LKFProdMGToTopTierConnector     =================================================     7/20/2005 8:09:58 PM: HOMELAB\dasaccount     HOMESQLSERVER:     [Forwarding] Successfully forwarded alert change occuring at Jul 21 2005 1:09AM     (gmt) to LKFProdMGToTopTierConnector.     =================================================     7/20/2005 8:12:21 PM: NT AUTHORITY\NETWORK SERVICE     Alert is created in management group LKFProdMG.     =================================================     7/20/2005 8:12:21 PM: HOMEMOMSERVER3\Administrator     HOMEMOMSERVER3: Changed 'Resolution State' from 'New' to 'Resolved'.     ================================================= 

Although this history does not capture every change made, it does track the important changes. In the first entry, at 8:09:56 p.m., the alert is created in the source management group. At 8:09:57, MOM attempts to forward the alert to the connector and at the next timestamp (also 8:09:57), the successful forward to the connector is noted. After the event is successfully forwarded, there is an attempt to forward an update to the alert to the connector (8:09:58) and its corresponding success at the same timestamp. Next, evidence of an update coming from the destination management group is logged at 8:12:21, and the final change of the resolution state from new to resolved at the same timestamp.

9.2.3. Monitoring the MCF and MMPC

MOM will monitor the MCF and MMPC for throughput (performance rules) and general errors (event rules). There is only one performance rule provided out-of-the- box and that samples the New Alert Forwarding Rate counter from the MOM-to-MOM Connector Service object. There is another counter, the Total New Alerts Forwarded, that you can use to create a performance rule to sample and use in a custom report.

Through the MOM Connector Framework performance object, you can monitor Alert Insert Rate and Alert Update Rate. These rules measure the rate, in alerts per second, that alerts are inserted into a management group's OnePoint database. The rules are used on the destination management group or any management group that receives operational data from an outside entity.

9.2.4. Reporting from Multiple Source Management Groups

Tiered configurations don't allow for consolidated reporting because none of the event or performance data is available in the destination management groups' OnePoint databases. You'd think that Microsoft would have built some sort of reporting data consolidation feature into MOM 2005, but they haven't. To configure reporting, the MOM 2005 Reporting server must still pull data from source layer management groups.

Recall from Chapter 7 that when the MOM 2005 reporting solution is installed, a Windows scheduled task is created that runs a command line like this:

     MOM.Datawarehousing.DTSPackageGenerator.exe /silent /srcserver  :homesqlserver /srcdb  :     OnePoint /dwserver  :HOMESQLSERVER /dwdb  :SystemCenterReporting /product:"Microsoft     Operations Manager" 

To consolidate operational data from multiple source management groups , create additional scheduled tasks that run the MOM.Datawarehousing.DTSPackageGenerator.exe. Do this by creating a copy of the original task and editing the command line so that the desired srcserver (source server to connect to), srcdb (source database on the source server to pull data from), dwserver (the MOM 2005 Reporting server), and dwdb (the database into which data is inserted) flags to it. Change the time that the task will be run, because you don't want more than one DTS package running concurrently.

Combining reporting data from multiple source groups into one reporting server is not officially supported by Microsoft.


9.2.5. Connecting MOM to Other Management Frameworks

Connecting to other management frameworks can be a huge topic. The MCF API was created so that connectors could be written that would allow synchronization between MOM and any other operations management platforms. Creating a connector to a third-party product requires a detailed knowledge of the APIs available for that product. Instruction on how to write product connectors that sit between MOM and other operations management products is beyond the scope of this book. There are other alternatives though.

Microsoft has written connectors that provide two-way synchronization between MOM and HP OpenView, HP Network Node Manager, and Tivoli TEC. These connectors are written entirely on the MCF and were actually released for use with the previous version of MOM (MOM 2000, SP1). These connectors can be downloaded from the Microsoft web site.

There is also an active development community that has written a number of MCF- based connectors. Here is a partial listing of products that you can connect MOM to using these connectors:

  • Aprisma SPECTRUM

  • BMC Impact

  • BMC Patrol

  • CA Solve

  • CA Unicenter

  • HP OpenView

  • MetiLinx

  • Micromuse Netcool

  • NetIQ AppManager

  • Quest InTrust Connector for Windows

  • Remedy ARS

  • Tivoli TEC

For a more complete and current listing, see the MOM Management Pack and Product Connector Catalog at http://www.microsoft.com/management/mma/catalog.aspx.




Essential Microsoft Operations Manager
Essential Microsoft Operations Manager
ISBN: 0596009534
EAN: 2147483647
Year: N/A
Pages: 107
Authors: Chris Fox voc

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net