Before adding objects to a management pack, we must first create the management pack. Create the management pack object in the Administration space of the Operations console. To create the management pack, right-click Administration and choose Create Management Pack.

For those clients we work with, our practice is to create a management pack incorporating the company name to store that company’s overrides. In general, each organization will want to create multiple override management packs, with one for each application or service it is managing overrides for.

You will want to create other management packs based on the functionality they will be providing. In this case, we will be creating the “OpsMgr Unleashed” management pack, where we will be storing many of the various management pack objects we create as we progress through this chapter. You can also create management packs as part of the process of creating objects such as monitors, tasks, and rules, which we will discuss in the next sections of this chapter.

You can delete management packs in the Administration space, from the same location where you create them. Right-click the management pack and choose Delete. If other management packs are dependent on the management pack you are attempting to delete, the interface will not allow you to delete the management pack until you remove those that are dependent on it. As an example, if you create overrides from the Exchange management pack and store them in the Default management pack, you cannot delete the Exchange management pack until you delete the Default management pack. This is a major reason why you do not want to store customizations in the Default management pack!

As a starting point for developing a management pack, we will discuss each of the different objects (Monitors, Tasks, Rules, Views, and Knowledge) and how to create them in the Operations console. For information on each of these different objects and their usage, see Chapter 14, “Monitoring with Operations Manager.” As we discuss in that chapter, there are a variety of different monitors:

In this chapter, we will first focus on providing examples of how to create the objects, and then we will discuss how to put them all together. Because Chapter 14 discussed creating a Windows Event monitor, in this chapter we will start with creating a simple monitor. This monitor will be an example of how to create a Windows Service monitor, which we will use as part of our OpsMgr Unleashed management pack.

For this particular case, we will add our monitor to the existing Windows Server 2003 Operating System target as part of the Availability monitor. In the “Using the Operations Manager Authoring Console” section of this chapter, we will show how you can create your own self-contained management pack, including monitors.

The default configuration of Operations Manager 2007 monitors a core set of services, invoking alerts if any of these services stops running. These services include the following:

Services not on this list are monitored by the management packs that specifically support them (such as the DNS management pack, which monitors the availability of the Microsoft DNS server service). So what can we do to notify (alert) if some other service is down that we want to know about?

Let’s say we have McAfee software deployed to provide antivirus functionality. Multiple McAfee services are running on our servers (McAfee Framework Service, McAfee McShield, and McAfee TaskManager), and we want to generate alerts if they are not running. Perform the following steps:

Once you have created the monitor, you can see it under the list of monitors for the Windows Server 2003 operating system, displayed in Figure 23.6.

Figure 23.6. The new monitor displayed under the Windows Server 2003 Operating System target.

For another example of how to use service monitoring functionality, you could create a monitor that checks the state of the services providing backup functionality. CommVault, for instance, installs services on the servers for which it provides backup functionality. You can use a monitor to watch the backup services, and you can configure that monitor to monitor whatever backup program you run in your environment (CA ARCserve, CommVault Galaxy, EMC Networker, Tivoli Storage Manager, Symantec NetBackup, and so on), as long as it runs a local service on the system you want to monitor.

You can create Console or Agent tasks, which run on the console or agent, respectively. The different types of tasks include the following:

We previously discussed the concepts behind tasks in Chapter 20, “Automatically Adapting your Environment,” where our discussion focused on using existing tasks as part of diagnostics and recoveries. In this chapter, we will focus on using tasks to simplify managing OpsMgr 2007. We will create a console task to resolve alerts that have not been incremented or updated in a specified timeframe. This is useful for cleaning out old alerts that have not recurred. Perform the following steps to create the task:

The section following -rootMS on the parameters is defined by browsing through the available variables (the arrow circled on Figure 23.9 is the button that displays the available variables that can be added).

Figure 23.10 gives an example of the options available. The information is added as command-line variables; when the script runs, the variables are substituted with the appropriate value. In our example, we could have typed in the name of our Root Management Server (RMS) on the parameters line after where it says rootMS:, but instead we will pass a variable that uses the DisplayName of the system where the task runs.

Figure 23.10. Sample of variables available within the parameters of a task.

Because we have set the task target to Management Server (shown in Figure 23.8), this substitutes correctly when the script runs.

Finally, we add the -Minutes parameter; this indicates the number of minutes an alert would have not been updated prior to its being resolved (1440 is the number of minutes in a day, or 60 times 24). You can change this parameter to the value you prefer for your environment, such as a value of 360 to resolve alerts that have not updated or had activity in 6 hours.

We are not selecting the check box to display the output. However, when you are debugging your scripts, it is a good idea to have this checked so that you can validate if the script fails to run.

The PowerShell script used by the task is stored in the c:scripts folder with a name of scriptresolve_alerts.ps1. The content of this script follows:

param ($rootMS,$Minutes)


#Initializing the Ops Mgr 2007 Powershell provider
     add-pssnapin "Microsoft.EnterpriseManagement.OperationsManager.Client" -ErrorVariable errSnapin;
     set-location "OperationsManagerMonitoring::" -ErrorVariable errSnapin;
     new-managementGroupConnection -ConnectionString:$rootMS -ErrorVariable errSnapin;
     set-location $rootMS -ErrorVariable errSnapin;


#Checks to see if it failed or succeeded in loading the provider
     if ($errSnapin.count -eq 0){
     Write-host "'nOpsMgr 2007 PSSnapin initialized!'n";
     }
     else{
            Write-host "'nOpsMgr 2007 PSSnapin failed initialize!' nPlease verify you are running this script on a Ops Mgr 2007 Management Server";
     Write-Host;
     }


$alerts = get-alert


foreach($alert in $alerts)
{
$timespan = new-timespan (get-date $alert.LastModified)
if ($timespan.totalMinutes -gt $Minutes)
{
Write-Host "id: " $alert.id
Write-Host "Total Minutes: " $timespan.TotalMinutes
Write-Host "Alert Resolved!"
$alert | resolve-alert -comment "Auto-Resolved Alert"
}
}

The first line of the script identifies the parameters we defined with the task. Our example passes two parameters, rootMS and Minutes. The names should exactly match the parameter name specified on the command-line task.

Now that we created a task to resolve alerts, we want to make it easy to find and use this task. We can do this by creating a State view in the OpsMgr Unleashed management pack. Perform the following steps:

The Resolve Alerts task provides us with a quick process to use for resolving alerts that have not been updated in a specified time period. There is also the Console task (Event command line), which performs a lookup on Eventid.net based on the event view of Operations Manager. Eventid.net is a website that provides information on events found within the various Windows Event logs. This task assists with debugging issues identified by OpsMgr. The Resolve Alerts and Console tasks are included on the CD for this book as part of the OpsMgr Unleashed management pack.

Chapter 14 introduced the different types of rules that are available. These are alert-generating rules, collection rules, and timed commands. Alert-generating and collection rules may be event based, performance based, or probe based. The different types of alert-generating rules include the following:

Here are the different types of collection rules:

Finally, here are the different types of timed commands available:

As we discuss in Chapter 14, the process for creating rules is very similar to the process for creating monitors. As an example, we will create a timed command rule that executes the resolve_alerts.ps1 PowerShell script we built in the “Creating Console Tasks” section of this chapter. To create a new rule, perform the following steps:

This example shows how you can use the Operations console to create rules that will perform a variety of actions, including the requirement of running tasks at a scheduled time.

These sections discussed the steps required and provided examples of management pack objects you can create with the Operations console. These objects included monitors, alerts (within the monitor), console tasks, views, and rules. You can create other components using the Operations console; these include diagnostic and recovery tasks, which we discussed in Chapter 20, and company knowledge, discussed in Chapter 14.

As with any computer language, an XML document must follow a prescribed format in order for a parser to be able to read and execute the commands in that document. In the case of Operations Manager, the XML document must follow the OpsMgr management pack schema, which in turn complies with the standard XML document format adopted by the W3C. If you would like to review the XML document standard format, the W3C website, www.w3.org, discusses it in extensive detail.

The Operations Manager management pack schema is divided into sections or elements, with each section used to define a certain aspect of the management pack. The following list includes the available sections and a brief description:

Although the sections utilized will vary between different management packs, every management pack must have a manifest. The manifest is the only required section in an OpsMgr management pack.

Now that you have a general idea of how the management pack schema is broken down into different elements, we will dig a bit deeper into the management pack schema and take a closer look at the elements, discussing how the management pack schema relates to an XML document. Although we can accomplish this several ways, perhaps the most interesting method would be to create an unsealed management pack with the Operations console and then view the resultant XML document and discuss its sections, and how those sections relate to the management pack.

To that end, we used the Operations console to create a simple management pack that monitors the status of the print spooler service. If the print spooler service stops, it triggers an alert that appears in the Active Alerts section of the Monitoring node in the console, as displayed in Figure 23.18.

Figure 23.18. Print spooler alert.

When the print spooler service starts, the alert is auto-resolved and the alert is removed from the Active Alerts view. Again, this is a very simple management pack—but we can use it to illustrate the various elements contained in a management pack XML document.

As we discuss in Chapter 13, filenames for sealed management packs have an .MP extension. Most of the management packs that you download from the System Center Pack Catalog (http://go.microsoft.com/fwlink/?LinkId=71124) are sealed. Because we created this management pack, it is currently unsealed and therefore will be an XML document. When we use the Operations console to create a management pack, OpsMgr does the work for us and automatically creates the XML document containing the structure of our management pack. We can find the XML documents on disk in the Health Service StateManagement Packs folder, under the folder used to store the OpsMgr binary files. The default location for the binary files is %ProgramFiles%System Center Operations Manager 2007. We could also use the Export Management Pack feature in the Operations console to export our management pack to a different XML file, but for this example, we will use the XML file OpsMgr has already created.

When you create or import a management pack, OpsMgr creates a unique identifier for the management pack and assigns it to the management pack. Operations Manager appends this unique identifier to the filename of the management pack. In our example, the friendly name of the management pack is Sample: Monitor Print Spooler Service but the actual .XML filename in the HealthServiceStateManagement Packs folder is Sample.Monitor.Print.Spooler.Service.{F16AD92A-81DA-4586-95DE-F0E3D37E1E11}.{843447D6-DB8D-AB9E-3FA5-5F09A09F69F2}.xml.

Now let’s look at our management pack XML document. You can use a variety of tools to view and edit XML documents. If we open our XML file in Windows Notepad, it would look something like what you see in Figure 23.19.

Figure 23.19. A management pack XML file in Windows Notepad.

If we were experienced XML programmers, we might be able to view an XML document like the one in Windows Notepad and make perfect sense out of the commands and the element structure that is defined. In fact, if we were highly skilled XML programmers and if we had extensive experience with the management pack XML format, we could create the entire management pack using Windows Notepad!

However, for most of us, using Windows Notepad to view the contents of an XML document is not especially helpful—Windows Notepad is not an XML parser, and the element structure inherent in a properly formatted XML document is not particularly obvious to us as we view it in Windows Notepad. The element structure is there because this is a valid XML document, but it is hard to identify that structure using this particular tool.

Microsoft’s Internet Explorer has been able to parse XML documents since version 4.0, released in 1997. Viewing our sample XML document with Internet Explorer (see Figure 23.20) we should get a view of the management pack that is easier to understand.

Figure 23.20. Viewing an XML file in Internet Explorer.

Using Internet Explorer, we are able to view the data in a more structured format than we saw when we used Windows Notepad. We can see the various elements that are defined and some of the management pack schema sections we discussed previously (Manifest, Monitoring, and so on), which you may notice we circled in Figure 23.20.

Internet Explorer is useful if we want to view the structure of the elements in an XML document, but is not very helpful if we want to make changes directly to the XML document. To easily edit a XML document, we need an XML editor (or there is always Notepad). An XML editor can obviously parse XML documents, and it also provides the ability to edit directly the document as needed.

Although several different XML editors are available, we will use XML Notepad. XML Notepad 2007 provides great functionality and is available at no cost from Microsoft at http://www.microsoft.com/downloads/details.aspx?familyid=72d6aa49-787d-4118-ba5f-4f30fe913628&displaylang=en. (This location is included on the CD accompanying this book in Appendix E, “Reference URLs.”)

Using XML Notepad 2007 to open our sample XML document, we get a vastly different view of our document, as shown in Figure 23.21.

Figure 23.21. Viewing an XML file in XML Notepad.

In Figure 23.21, we can clearly see the structure of the XML document, and we have the ability to expand (or collapse) specific sections if we want to view additional data in those sections. We also have the ability to edit the contents of the document if necessary.

We will now dig a bit deeper into our sample XML document and discuss some of the elements.

If we look at the top section of this XML document, we can see some standard preamble information for an XML document, including links to the XML schema and the XSL (eXtensible Stylesheet Language) transform. We also see a revision ID, which is the unique identifier that OpsMgr assigned to the management pack when it was created. We can see this same unique identifier appended to the filename of the management pack XML file at the top of Figure 23.22.

Figure 23.22. The revision identifier.

If we continue in XML Notepad, we see the manifest, which as you may recall is the only mandatory element in the management pack. In the manifest, we see a variety of information. First, we see the converted name of the management pack. The friendly name of the management pack is provided in the Name attribute, which is just below the Identity attribute. The friendly name for our management pack is Sample: Monitor Print Spooler Service. OpsMgr will always take the friendly name and convert it into a “dotted” name, which in this case is Sample.Monitor.Print.Spooler.Service. Operations Manager uses the dotted management pack name during internal processing, not the friendly name. When we created the management pack, we provided a version number (1.0.0.0), and this information is recorded in the Version element, under the Identity element. Figure 23.23 highlights the version number.

Figure 23.23. The version number.

The reference element is the next section of the manifest element we will look at. The reference element in a management pack is important because it contains information about the other management packs referenced in the management pack. It is worth noting that an unsealed management pack can reference only sealed management packs, and an unsealed management pack cannot be referenced by any other management pack. Whereas most management packs will reference multiple sealed management packs or libraries, every OpsMgr management pack, regardless of the purpose of the management pack, will reference Microsoft.SystemCenter.Library. This is the core library for Operations Manager, and you will always see a reference to it in a management pack.

Our sample management pack refers to three libraries, which you can also see in Figure 23.23, under the References section:

The logic for including these three libraries is as follows:

The purpose of this management pack is to monitor the print spooler service and generate an alert when the service stops. To accomplish this, we created a Unit monitor and configured it to monitor the Windows Print Server service. If we look at the Monitoring element of our XML document in Figure 23.24, we can clearly see that there is a UnitMonitor element defined and highlighted, and this element includes some additional elements related to the Unit monitor. From this information, we can determine a number of things:

Figure 23.24. Viewing the Monitoring element in XML Notepad.

This very simple management pack only has a few elements defined. Larger, more complex management packs could contain hundreds of different elements.

Now that we have discussed various methods to view and dig into XML, we will now look at a simple management pack created in XML. We can use this example to provide the framework we will use to build out a management pack that extends the existing functionality provided with the SQL Server management pack provided by Microsoft. This management pack includes the object discovery information, classes, and relationships we will use within this chapter. Figure 23.25 shows this management pack within the Operations console.

Figure 23.25. The monitor information available from the OpsMgr SQL Extension created with XML.

The XML we used to create this management pack follows, including an explanation of the various sections:

<?xml version="1.0" encoding="utf-8"?>
<ManagementPack xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                ContentReadable="true">

The code above is the Schema Definition section of XML. It defines the XML schema that will be used. The management pack file uses the standard public XML schema.

<Manifest>
 <Identity>
   <ID>OpsMgr.SQL.Extension</ID>
   <Version>1.0.0.0</Version>
 </Identity>
  <Name>OpsMgr SQL Extension</Name>
  <References>
    <Reference Alias="MicrosoftSystemCenterServiceDesignerLibrary60500028">
      <ID>Microsoft.SystemCenter.ServiceDesigner.Library</ID>
      <Version>6.0.5000.0</Version>
      <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
    </Reference>
    <Reference Alias="Windows">
      <ID>Microsoft.Windows.Library</ID>
      <Version>6.0.5000.0</Version>
      <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
    </Reference>
    <Reference Alias="Performance">
      <ID>System.Performance.Library</ID>
      <Version>6.0.5000.0</Version>
      <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
    </Reference>
    <Reference Alias="Image">
      <ID>System.Image.Library</ID>
      <Version>6.0.5000.0</Version>
      <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
    </Reference>
    <Reference Alias="MicrosoftSQLServerLibrary6050000">
      <ID>Microsoft.SQLServer.Library</ID>
      <Version>6.0.5000.0</Version>
      <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
    </Reference>
    <Reference Alias="Reporting">
      <ID>Microsoft.SystemCenter.DataWarehouse.Report.Library</ID>
      <Version>6.0.5000.0</Version>
      <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
    </Reference>
    <Reference Alias="System">
      <ID>System.Library</ID>
      <Version>6.0.5000.0</Version>
      <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
    </Reference>
    <Reference Alias="SC">
      <ID>Microsoft.SystemCenter.Library</ID>
      <Version>6.0.5000.0</Version>
      <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
    </Reference>
    <Reference Alias="Health">
      <ID>System.Health.Library</ID>
      <Version>6.0.5000.0</Version>
      <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
    </Reference>
  </References>
</Manifest>

This is the Manifest section, where the management pack name is defined as well as the version (the version number should be modified when updates are made for consistency). The section also contains the references to other management packs that this management pack will use. The minimum references we recommend for all management packs are as follows:

<TypeDefinitions>
  <EntityTypes>
    <ClassTypes>
      <ClassType ID="OpsMgr.SQL.Extension.Computer"
                 Accessibility="Public"
                 Abstract="false"
                 Base="Windows!Microsoft.Windows.ComputerRole"
                 Hosted="true"
                 Singleton="false">
      </ClassType>
    </ClassTypes>
  </EntityTypes>
</TypeDefinitions>

The TypeDefinitions section is the part of the XML code where we define and create classes. This particular example creates the OpsMgr.SQL.Extension.Computer class object, which we are basing on the Windows!Microsoft.Windows.ComputerRole role. Because we base it on that role, the class will appear under the Windows Computer role in the class list in OpsMgr.

<Monitoring>
  <Discoveries>
    <Discovery ID="OpsMgr.SQL.Extension.Discovery"
               Enabled="true"
               Target="Windows!Microsoft.Windows.Server.Computer"
               ConfirmDelivery="false"
               Remotable="true"
               Priority="Normal">
      <Category>Discovery</Category>
      <DiscoveryTypes>
        <DiscoveryClass TypeID="OpsMgr.SQL.Extension.Computer">
          <Property TypeID="System!System.Entity"
                    PropertyID="DisplayName" />
        </DiscoveryClass>
        <DiscoveryRelationship TypeID="Windows!Microsoft.Windows.ComputerHostsComputerRole" />
      </DiscoveryTypes>
      <DataSource ID="DS" TypeID="Windows!Microsoft.Windows.FilteredRegistryDiscoveryProvider">
      <ComputerName>$Target/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
        <RegistryAttributeDefinitions>
          <RegistryAttributeDefinition>
            <AttributeName>SQLInstalled</AttributeName>
            <Path>SOFTWAREMicrosoftMicrosoft SQL Server</Path>
            <PathType>0</PathType>
            <AttributeType>0</AttributeType>
          </RegistryAttributeDefinition>
        </RegistryAttributeDefinitions>
        <Frequency>300</Frequency>
        <ClassId>$MPElement[Name="OpsMgr.SQL.Extension.Computer"]$</ClassId>
        <InstanceSettings>
          <Settings>
            <Setting>
            <Name>$MPElement[Name="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Name>
              <Value>$Target/Property[Type="Windows!Microsoft.Windows.Computer"/PrincipalName$</Value>
            </Setting>
            <Setting>
              <Name>$MPElement[Name="System!System.Entity"]/DisplayName$</Name>
              <Value>SQL Server ($Target/Property[Type="Windows!Microsoft.Windows.Computer"]/NetbiosComputerName$)</Value>
            </Setting>
          </Settings>
        </InstanceSettings>
        <Expression>
          <SimpleExpression>
            <ValueExpression>
              <XPathQuery Type="Boolean">Values/SQLInstalled</XPathQuery>
            </ValueExpression>
            <Operator>Equal</Operator>
            <ValueExpression>
              <Value Type="Boolean">true</Value>
            </ValueExpression>
          </SimpleExpression>
        </Expression>
      </DataSource>
    </Discovery>
  </Discoveries>
</Monitoring>

The Monitoring section of the management pack file contains the rules, the monitors, and all the monitoring objects in the management pack. Typically, it is a large section! In this example, we simply created a discovery rule that finds computers with SQL Server installed and adds them to our newly created class. Although the section can look rather intimidating, all we are doing here is using the XML beneath TypeID="Windows!Microsoft.Windows.FilteredRegistryDiscoveryProvider"> to locate the HKLMSOFTWAREMicrosoftMicrosoft SQL Server Registry path. If the path is found, we add the computer to the class; then we discover and populate the PrincipleName and DisplayName attributes so that the object displays correctly in the Operations console.

  <LanguagePacks>
    <LanguagePack ID="ENG"
                  IsDefault="false">
      <DisplayStrings>
        <DisplayString ElementID="OpsMgr.SQL.Extension">
          <Name>OpsMgr SQL Extension</Name>
          <Description>Provides Advanced monitoring of SQL</Description>
        </DisplayString>
        <DisplayString ElementID="OpsMgr.SQL.Extension.Computer">
          <Name>OpsMgr SQL Extension Computer</Name>
        </DisplayString>
        <DisplayString ElementID="OpsMgr.SQL.Extension.Discovery">
          <Name>OpsMgr SQL Extension Computer Discovery</Name>
        </DisplayString>
        <DisplayString ElementID="OpsMgr.SQL.Extension.Discovery"
                       SubElementID="DS">
          <Name>Registry Probe</Name>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
  </LanguagePacks>
</ManagementPack>

The LanguagePacks section is extremely important and affects all objects created in the management pack file. When you create an object, it is given an ID within the management pack, such as our class OpsMgr.SQL.Extension.Computer. This is an appropriate ID to be called from within the management pack, but it is not very readable to the end user. The LanguagePacks section resolves this by mapping a user friendly DisplayString for every object in the management pack. Remember, whenever you create an object in the management pack, whether it be a monitor, a rule, or a class, it will need a corresponding entry in the LanguagePacks section. This section also contains all product knowledge—although we recommend you add this level of detail using the Operations console, not directly in XML, as this is easier to do in the Operations console.

Now that you have seen an example of how the internals of XML are used within Operations Manager 2007, we will discuss additional options that are either currently available or will soon be available for creating management packs in Operations Manager 2007.

The Authoring console has a similar look and feel to the Operations console, and provides visibility into areas not accessible from the Operations console. We will look at three of these:

Based on the current capabilities of the Operations Manager Authoring console, it appears that the majority of the requirements for using XML to create management packs will no longer be necessary once Microsoft fully supports this utility.

We will now use the Authoring console to create a custom management pack. The management pack’s functionality includes defining a new OpsMgr class, based on discovering computers with a certain Registry key. The Authoring console includes a wizard that will help us create the basic building blocks of the management pack.

The subject of this particular management pack is Microsoft Forefront Client Security (FCS). We can discover computers running FCS by examining their Registry. Therefore, before we begin, we determine what Registry key we will use to discover the presence of the FCS anti-malware (AM) application on a computer. We have determined we will look for the following key:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft ForefrontClient Security1.0AM

Now we launch the wizard by selecting File -> New. Here are the steps we followed to create the management pack:

We have now created and tested a basic custom management pack. After importing the unsealed management pack into the management group, you can create views, rules, monitors, and other OpsMgr features in the Authoring space of the Operations console. A big value-add for the Authoring console is that it created valid manifest, language pack, class definition, display strings, and discovery logic. Most critically, we have also defined a new class that we can target rules and monitors against throughout the Operations console.

We performed one additional customization to the management pack (in XML) that is not yet possible in the RC version of the Authoring console. A manual XML addition appears in the Non-Key properties (optional) section of the Discovery Mapper tab in the configuration of the discovery. See this entry highlighted in Figure 23.31. We added another setting to the InstanceSettings that defines the display name to use for objects discovered in the class. Our setting is FCS Anti-malware (<NetBIOS Computer Name>).

Figure 23.31. Discovery configuration: Custom XML added to set the display name.

After each time you save the XML file in the Authoring console, manually open the XML file in Notepad or your XML editor and increment the version number. This lets you quickly import (slipstream) the updated management pack into your test management group. Because the management pack is unsealed, you can also use the Authoring space of the Operations console to edit the XML directly, although this does not preserve a versioning trail for rollback purposes.

To deliver a simple but functional management pack, we used the Authoring console to create a new Unit monitor, of the Basic Service Monitor type (the same monitor type we previously created to monitor McAfee), targeting the Forefront Client Security class. This monitor will allow the management pack to display a meaningful health state in the Monitoring space. The monitor will confirm that the FCSAM service is running on customer computers with FCS client software installed. If the service is running, the state of the monitor is healthy. The monitor will generate alerts when the service is not running.

To add that functionality, we created a new view folder in the Monitoring space named Forefront Client Security and saved the folder to our new custom management pack. Then we created new State and Alert view folders targeted to the Forefront Client Security class. The State view populated with the computers as expected. Stop and start tests of the service confirmed the health monitor and alerting action were working. See the State view and Health Explorer for the monitor in Figure 23.32.

Figure 23.32. Anti-malware service health on computers where the software is installed.

The resultant custom management pack we created in this section is on the CD accompanying this book; the filename is Microsoft.Forefront.ClientSecurity.xml. It would be instructive to open that file in Notepad, Internet Explorer, or with an XML editor, after having read this section of the chapter to observe the XML components we discussed.

To create a report model, perform the following steps:

The next part of this process is to create a data source. Perform the following steps:

Now that we have a data source, which is a connection to the database, we need to create a data source view. The data source view is where we choose what data we will view from the database. Follow these steps:

Now that we have created the data sources, we will create the actual model itself with the following steps:

Finally, we must deploy the report model to the Reporting Server. Right-click the model file we just created from the Solution Explorer and select Deploy. Check for errors and look for the status message at the bottom of the screen for verification that the deployment was successful. The status is in the bottom left corner and is circled in Figure 23.61.

Figure 23.61. Deploy deployment status.

After creating the report model, we can create a report to display the data. The next steps document the creation of a basic alert report:

You could make this report available to other users by following the procedure we discussed in the “Publishing Reports” section of this chapter.

Perform the following steps to deliver the report to a file share:

Now that we have created the schedule, what actually makes the report run? In the background, the SQL Server Agent now lists a new job (with a GUID for a name, lots of fun to track those down!) that runs the scheduled report we created. By default, notifications are written to the Application Event log if the job fails.

To determine what subscriptions we have, you can look in the Reporting space of the Operations console. Select Scheduled Reports on the Reporting pane on the left side for the list and status of scheduled reports in the middle section of the console. The Actions section allows you to open, edit, or cancel the various schedules. If any issues occurred when the subscription ran, they will appear on this page.

Once the job runs, there should be a file in the directory specified in step 1 of the preceding list (\Quicksilver eports in our example).

Now that we have delivered a report to a file share, we also want to send it using email. Perform the following steps:

<PermittedHosts>
  <HostName>Odyssey.com</HostName>
  <HostName>ExternalDomain.com</HostName>
</PermittedHosts>

The ability to schedule the delivery of reports is a definite benefit of deploying OpsMgr 2007.

We have discussed the concept of custom reports and report models. We covered the steps to create a custom report model and deploy it to the Reporting Server. We also covered the process for creating a new custom report using Visual Studio 2005 and the new Report Builder installed with OpsMgr, and we wrapped up with a discussion on how to schedule reports in OpsMgr.

We will now tie together many of the concepts discussed in this chapter to create a sample management pack.