Windows 7 / Getting Started

Modifying Management Pack Objects

Although you cannot modify a sealed MP, you have quite a number of options:

  • Attribute You can create new attributes to be used by your own custom rules, monitors, tasks, or views. Unfortunately, no mechanism is available to see the contents of an existing attribute or the source from which it is obtained. The purpose of attributes is to store information about an object, such as the object's name, its Active Directory type, other objects that it may connect to, and so on. For a given object type, all attributes are stored together, effectively forming a record in the OpsMgr database for an instance of that object.
  • Monitor You can disable the monitor (for any specific computer, any group of computers, or all computers). You may also create your own monitor that applies to any specific computer, any group of computers, or all computers. The purpose of monitors is to collect data and, based on the contents of that data, generate a health report for a given object or a piece of an object. For example, you may have monitors that measure hardware availability, configuration correctness, or the performance of a system's processor.
  • Rule You can disable a rule (for any specific computer, any group of computers, or all computers) or you can override specific attributes of a rule (for any specific computer, any group of computers, or all computers). You may also create your own rule that applies to any specific computer, any group of computers, or all computers. The purpose of rules is also to collect data. However, unlike a monitor, a rule cannot be used to affect the health of an object. Rules can generate alerts. A monitor can use a rule as input to its health calculation.
  • Task Tasks are used as resources by monitors and rules; they never stand alone. Therefore, disables and overrides do not make sense in their context. However, you can create your own command-line or script-based task to use in the monitors and rules that you create. Tasks may also be executed within the Operations Console by the OpsMgr administrator to report on the current status of objects (such as the health of a domain controller or on replication health). Finally, tasks can be used to implement recovery steps, such as restarting a service.
  • View Views are created and managed in the Monitoring pane (since they represent graphical views of monitoring data), not the Authoring pane. We have no idea why they are shown in the Authoring pane other than they are stored as an MP object. Views are basically SQL queries that are based on stored attribute information.
Monitors allow you to calculate and view the health of an object and raise alerts based on that health. You can also use monitors to build a health hierarchy where the health of an upper-level object is based on the health of a lower-level object. Rules, however, do not calculate health, and while you can raise an alert based on the result of a rule, it is not related to the health of an object but simply the result of the rule. However, the result of a rule can be used by a monitor to assist in the calculation of an object's health. The difference between the two is a fine line.

If you modify a sealed MP or create new MP objects, by default the change (called an override) is saved into a system-provided MP called the Default MP. However, this can lead to many overrides, new rules, and monitors all being saved into one place. That is simply a recipe that will lead to confusion. It is considered a best practice to do the following:

  • Save modifications to a sealed MP into a new MP with a similar (but standard) name.
  • Group your new MP objects into new MPs and document why they have been created.
When you remove an MP, you must first remove all custom MPs that refer to objects within that MP, such as the overrides that you created. So, if you store all overrides within the Default MP, you would have to remove that MP before you could remove any other MP to which you have applied overrides! That could be disastrous.

Creating an Override Management Pack

As discussed previously, we recommend that you create a new MP that should be used to store all your overrides, custom rules, and monitors for each installed MP. This simplifies the process of moving customizations from one environment to another, and it removes the dependency on the Default MP from all other installed MPs.

To create a new MP to store your overrides and customizations for the Exchange Server MP, follow these steps:

  1. Open the Operations Console.
  2. Click Administration in the lower-left pane.
  3. Right-click on Management Packs in the upper-left pane and select Create Management Pack from the context menu. This will start the Create a Management Pack wizard.
  4. On the first page of the wizard, in the Name field enter a recognizable custom name for the MP, such as Local - Exchange MP Customizations.
  5. In the Description field, enter a detailed description of the types of customizations that you have entered in this MP.
  6. Click Next.
  7. On the second page of the wizard, if you have company information that you want to appear on the override, you can enter it here. Microsoft Word must be installed on the same computer as the Operations Console to edit the information on this page of the wizard.
  8. Click Create.

Use this MP to store all customizations and overrides for the Exchange Server MP.

Management Pack Discoveries

Unlike the Exchange Server 2007 native-mode MP, the Exchange Server 2010 MP will automatically process all discoveries. The items specifically discovered by the Exchange Server 2010 MP include the following:

  • Which instances of Exchange are on a virtual server
  • All Client Access servers
  • All Hub Transport servers
  • All Edge Transport servers
  • All Mailbox servers
  • All Unified Messaging servers
  • All ''other'' Exchange servers (those that are not Exchange Server 2010)

However, the so-called synthetic transactions are not enabled by default. A synthetic transaction is executed by OpsMgr. This transaction is generally a PowerShell cmdlet that tests a specific function on an Exchange server, such as Test-ActiveSyncConnectivity. To see all the available synthetic transactions, follow this procedure:

  1. Open the Operations Console.
  2. In the lower-left corner, click Authoring.
  3. If it is not already expanded, expand the Management Pack Objects node.
  4. Click Rules.
  5. In the Rules pane in the middle of the window, click Change Scope.
  6. In the Scope Management Pack Objects By Target(s) dialog, click Clear All.
  7. In the Look For box, enter Exchange Server 2010 and then click Select All.
  8. Click OK.
  9. In the Look For box in the Rules pane of the window, enter Script event collection and then click Find Now.

For each synthetic transaction in this list that you want to enable, follow this procedure:

  1. Right-click on the rule.
  2. From the first fly-out menu, select Overrides.
  3. From the second fly-out menu, select Override The Rule.
  4. From the third fly-out menu, select For All Objects Of Type: <typename>.
  5. In the Override Properties dialog that opens, click the check box underneath the Override heading and change the Override Setting to True.
  6. Select the custom destination MP you created earlier (Local - Exchange MP Customizations was our suggestion).
  7. Click OK.

Going through each of these can take some time (there are 28 synthetic transactions), but we recommend you enable them all. However, be aware that each synthetic transaction will generate between five and ten Warehouse Database records for each server it is executed on each time it is executed (by default, every five minutes). This can be many records and you should plan for database growth. Note that it can take up to 24 hours for an override change to take effect, so be patient.

Over 40 reports are available from within the Operations Console:

  • Organization Status
  • Organization Performance
  • Client Access Status
  • Client Access Performance
  • ActiveSync DirectPush Latency
  • IMAP Connectivity Latency
  • Outlook HTTP Connectivity Latency
  • Outlook HTTP AutoDiscover Connectivity Latency
  • Outlook TCP Connectivity Latency
  • Outlook TCP AutoDiscover Connectivity Latency
  • OWA External Logon Latency
  • OWA Internal Logon Latency
  • POP3 Connectivity Latency
  • EWS CreateItem Latency
  • Connection Filter Agent
  • Content Filter Agent
  • Protocol Analysis Agent
  • Recipient Filter Agent
  • Sender Filter Agent
  • Sender Id Agent
  • Edge Transport Performance
  • Edge Transport DSN
  • Edge Transport Queues
  • Hub Transport Performance
  • Hub Transport DSN
  • Hub Transport Queues
  • Hub Transport SMS Agent
  • Mailbox Performance
  • Client RPC Latency (3 reports)
  • Client RPCs Succeeded
  • MAPI Connectivity Logon Latency
  • I/O Database Performance (5 reports)
  • RPC Averaged Latency
  • RPC Requests
  • Unified Messaging Performance
  • Unified Messaging Connectivity Call Latency

An additional nine reports are available from the Reporting Console:

  • Service Availability
  • Client Access Availability
  • Unified Messaging Availability
  • SMTP (Client Submission) Availability
  • Outlook Client Performance
  • Hourly Mailflow Statistics
  • Daily Mailflow Statistics
  • Distribution Group Usage
  • Top Users
[Previous] [Contents] [Next]