management pack authoring guidedownload.microsoft.com/download/b/f/d/bfdd0f66-1637-4ea3... · web...

Management Pack Authoring GuideMicrosoft Corporation

Published: July 12, 2010

AuthorBrian Wren

FeedbackSend suggestions and comments about this document to [email protected]. Please include the guide name and published date with your feedback.

mailto:[email protected]?subject=MPGuide

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted in examples herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.

© 2010 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, ActiveSync, Internet Explorer, JScript, SharePoint, SQL Server, Visio, Visual Basic, Visual Studio, Win32, Windows, Windows PowerShell, Windows Server, and Windows Vista are trademarks of the Microsoft group of companies.

All other trademarks are property of their respective owners.

Revision History

Release Date Changes

January 7, 2010 Initial release of this guide including only the Service Model section.

January 29, 2010 Complete Composition section added. Basic structure and introduction to

remaining sections added. These sections are to be completed in subsequent versions.

April 16, 2010 Complete Health Model section added. Corrections made in How To topics in

Release Date Changes

Service Model and Composition sections. Corrections made in Recommended Base

Classes table.

May 28, 2010 Complete Management Pack Basics section added.

How To topics for creating diagnostics and recoveries added.

Corrections made in Probe Action Modules section.

July 12, 2010 Complete Presentation section added.

ContentsManagement Pack Authoring Guide.............................................................................................23

In This Section........................................................................................................................... 23

Management Pack Basics............................................................................................................24In This Section........................................................................................................................... 24

Authoring Tools............................................................................................................................. 25Operations Console................................................................................................................... 25

Wizards.................................................................................................................................. 26Management Pack Templates................................................................................................26Distributed Application Designer............................................................................................26

Authoring Console..................................................................................................................... 26XML Editor................................................................................................................................. 27See Also.................................................................................................................................... 27

Configuring the Authoring Console...............................................................................................27

Management Pack Formats..........................................................................................................29Management Pack Schema......................................................................................................29Sealed Management Packs.......................................................................................................29

The contents of the management pack cannot be modified...................................................30Version Control.......................................................................................................................30Enables the management pack to be referenced by other management packs.....................30

When to seal a management pack............................................................................................30Sealing a management pack.....................................................................................................31See Also.................................................................................................................................... 31

Version Control............................................................................................................................. 31Accessibility............................................................................................................................... 31Backward Compatibility.............................................................................................................32See Also.................................................................................................................................... 32

Management Pack References.....................................................................................................32Sealed Management Packs.......................................................................................................33Standard References................................................................................................................. 33Defining a reference.................................................................................................................. 34Example References.................................................................................................................35See Also.................................................................................................................................... 36

How to create a management pack reference..............................................................................36

Naming......................................................................................................................................... 37ID............................................................................................................................................... 37Display Names.......................................................................................................................... 39Language Packs........................................................................................................................ 40

Variables....................................................................................................................................... 41Using Variables..........................................................................................................................41Kinds of Variables...................................................................................................................... 41See Also.................................................................................................................................... 42

Service Model............................................................................................................................... 43In This Section........................................................................................................................... 43

Key Concepts............................................................................................................................... 43In This Section........................................................................................................................... 44

Classes......................................................................................................................................... 44Properties.................................................................................................................................. 45

Key Properties........................................................................................................................45Base Classes and Inheritance...................................................................................................45Class Types............................................................................................................................... 48

Abstract Classes.................................................................................................................... 48Singleton Classes..................................................................................................................48

See Also.................................................................................................................................... 49

Relationships................................................................................................................................ 49Hosting Relationship Type.........................................................................................................49Containment Relationship Type.................................................................................................53Reference Relationship Type.....................................................................................................54See Also.................................................................................................................................... 54

Viewing Classes in the Consoles..................................................................................................54Prerequisites............................................................................................................................. 54See Also.................................................................................................................................... 56

Discovery...................................................................................................................................... 56The Mechanics of Discovery.....................................................................................................56Discovery Data..........................................................................................................................58Discovery Data Sources............................................................................................................59

Registry.................................................................................................................................. 59WMI........................................................................................................................................ 59Scripts.................................................................................................................................... 59

Discovery Targets......................................................................................................................60Discovering Relationships.........................................................................................................60

Hosting Relationships............................................................................................................60

Containment Relationships....................................................................................................61Populating Groups................................................................................................................. 62

Proxy Discoveries......................................................................................................................62Discovery on Demand...............................................................................................................62See Also.................................................................................................................................... 63

Discovery Scripts..........................................................................................................................63Creating Discovery Scripts........................................................................................................63Required Arguments.................................................................................................................. 63MPElement Variables................................................................................................................64Basic Script Structure................................................................................................................64Script Breakdown...................................................................................................................... 65Windows PowerShell.................................................................................................................66Empty Discovery Data...............................................................................................................67See Also.................................................................................................................................... 68

Service Model Design Overview...................................................................................................68In This Section........................................................................................................................... 68

Defining Classes and Relationships.............................................................................................69Define Application Roles............................................................................................................69Define Application Components for Each Application Role........................................................71Identify Dependencies Between Classes..................................................................................72Define Application Class............................................................................................................73Groups....................................................................................................................................... 74

Health Rollups........................................................................................................................74Instance Groups.....................................................................................................................75Computer Groups...................................................................................................................75

See Also.................................................................................................................................... 76

Choosing a Base Class................................................................................................................. 76Criteria for Selecting a Base Class............................................................................................76

Inheritance............................................................................................................................. 76Properties........................................................................................................................... 77Relationships......................................................................................................................77Monitoring........................................................................................................................... 78

Logical Grouping.................................................................................................................... 78Side Effects............................................................................................................................ 78

Custom Base Classes...............................................................................................................79See Also.................................................................................................................................... 80

Recommended Base Classes.......................................................................................................80

Defining Discoveries.....................................................................................................................82Identifying Discoveries for Each Class......................................................................................82

Basic Discovery Strategy...........................................................................................................83Application Roles...................................................................................................................83Application Components........................................................................................................83Group Population................................................................................................................... 84

Discovery Intervals.................................................................................................................... 84See Also.................................................................................................................................... 85

Practices to Avoid......................................................................................................................... 85Classes...................................................................................................................................... 85

Creating Too Many Classes...................................................................................................85Creating Classes for Volatile Objects.....................................................................................86Properties that Update Too Frequently...................................................................................86

Discoveries................................................................................................................................ 86Too Frequent Discoveries......................................................................................................87Script Discoveries Targeting Broad Classes...........................................................................87

See Also.................................................................................................................................... 87

Building a Service Model..............................................................................................................87In This Section........................................................................................................................... 87

Creating Classes and Relationships.............................................................................................88In This Section........................................................................................................................... 88

How to Create a New Management Pack.....................................................................................88

How to Create a Class.................................................................................................................. 89See Also.................................................................................................................................... 91

How to Create a Group................................................................................................................. 91See Also.................................................................................................................................... 92

How to Create a Containment Relationship..................................................................................92See Also.................................................................................................................................... 94

Creating Discoveries.....................................................................................................................94In This Section........................................................................................................................... 94

How to Create a Registry Discovery.............................................................................................94

How to Create a WMI Discovery...................................................................................................96See Also.................................................................................................................................... 97

How to Create a Script Discovery.................................................................................................98

How to Create a Windows PowerShell Discovery.........................................................................99See Also.................................................................................................................................. 103

How to Populate a Group............................................................................................................103

Health Model............................................................................................................................... 105In This Section......................................................................................................................... 106

Key Concepts............................................................................................................................. 106In This Section......................................................................................................................... 106

Targets........................................................................................................................................ 107Effects of a Target....................................................................................................................107

Which agents the management pack is delivered to............................................................107Which agents the workflow will run on and how many copies of it will be loaded.................108Which target variables are available to the workflow............................................................109Which object health state, alerts, and collected data will be associated with.......................110

Targeting Groups..................................................................................................................... 110

Data Sources.............................................................................................................................. 110See Also................................................................................................................................... 111

Data Variables............................................................................................................................. 111

Events......................................................................................................................................... 113Windows Events...................................................................................................................... 114

Criteria.................................................................................................................................. 114Properties............................................................................................................................. 114Workflows Supported...........................................................................................................115

Text Logs................................................................................................................................. 115Properties............................................................................................................................. 116Workflows Supported...........................................................................................................116

WMI Events............................................................................................................................. 116Criteria.................................................................................................................................. 117Properties............................................................................................................................. 118Workflows Supported...........................................................................................................118

Syslog Events.......................................................................................................................... 118Properties............................................................................................................................. 118

Facility Values................................................................................................................... 119Workflows Supported...........................................................................................................120

Performance Data.......................................................................................................................120Windows Performance............................................................................................................121

Properties............................................................................................................................. 121Workflows Supported...........................................................................................................121

WMI Performance.................................................................................................................... 122Properties............................................................................................................................. 122Workflows Supported...........................................................................................................122

See Also.................................................................................................................................. 122

Monitoring Scripts....................................................................................................................... 122Property Bags.......................................................................................................................... 123

Typed Property Bags............................................................................................................123Basic Script Structure..............................................................................................................124Script Breakdown.................................................................................................................... 125Defining a Script...................................................................................................................... 126

Script Name......................................................................................................................... 126Script Arguments..................................................................................................................126Script Timeout...................................................................................................................... 126

Windows PowerShell...............................................................................................................127Supported Workflows..............................................................................................................128See Also.................................................................................................................................. 128

Monitors and Health State..........................................................................................................128In This Section......................................................................................................................... 129

Unit Monitors............................................................................................................................... 130In This Section......................................................................................................................... 130

Event Monitors............................................................................................................................ 131Detection Logic........................................................................................................................131

Simple Event........................................................................................................................ 132Repeated Events.................................................................................................................. 132

Trigger on Timer................................................................................................................132Trigger on Count...............................................................................................................132Trigger on Count, Sliding..................................................................................................132Repeated Events Example...............................................................................................133Properties.........................................................................................................................134

Correlated Events................................................................................................................134Correlated Events Example..............................................................................................135

Correlated Missing Events...................................................................................................136Correlated Missing Events Example.................................................................................136

Missing Event.......................................................................................................................137Missing Event Example.....................................................................................................138

Health Reset Logic.................................................................................................................. 138Event Reset..........................................................................................................................139Manual reset........................................................................................................................ 139Timer Reset.......................................................................................................................... 139

Performance Monitors.................................................................................................................140Threshold Types...................................................................................................................... 140

Simple Threshold.................................................................................................................140Double Threshold.................................................................................................................141Average Threshold...............................................................................................................142

Consecutive Samples..........................................................................................................142Delta Threshold.................................................................................................................... 143

Self-tuning Threshold Monitors................................................................................................144

Script Monitors............................................................................................................................ 144See Also.................................................................................................................................. 145

Service Monitors.........................................................................................................................145

Aggregate Monitors....................................................................................................................145Standard Aggregate Monitors..................................................................................................145Custom Aggregate Monitors....................................................................................................146Health Rollup Policy................................................................................................................147

Worst state........................................................................................................................... 147Best state............................................................................................................................. 147

Dependency Monitors.................................................................................................................148Health Rollup Policy................................................................................................................149

Worst state policy................................................................................................................. 150Best state policy................................................................................................................... 150Percentage policy.................................................................................................................151

Health Rollup between Agents................................................................................................151

Alerts from Monitors....................................................................................................................152Alert Name.............................................................................................................................. 152Alert Description...................................................................................................................... 152Priority and Severity................................................................................................................153Alert Suppression....................................................................................................................154Automatic Alert Resolution......................................................................................................154See Also.................................................................................................................................. 154

Diagnostics and Recoveries.......................................................................................................154Diagnostics.............................................................................................................................. 154Recoveries.............................................................................................................................. 155

Recalculating State..............................................................................................................156When Diagnostics and Recoveries Run..................................................................................156Modules................................................................................................................................... 156

Rules........................................................................................................................................... 157In This Section......................................................................................................................... 157

Alert Rules.................................................................................................................................. 158Event Alert Rules.....................................................................................................................158Performance Alert Rules..........................................................................................................158Scripting Alert Rules................................................................................................................159Alerts from Rules.....................................................................................................................159

Alert Name........................................................................................................................... 159Alert Description...................................................................................................................159Priority and Severity.............................................................................................................160Alert Suppression................................................................................................................. 160Automatic Alert Resolution...................................................................................................161

Collection Rules..........................................................................................................................161Collection rules described.......................................................................................................161

Event Collection Rules................................................................................................................161Script Based Event Collection.................................................................................................161See Also.................................................................................................................................. 162

Performance Collection Rules....................................................................................................162Script Based Performance Collection......................................................................................162Optimized Collection................................................................................................................163See Also.................................................................................................................................. 164

Tasks........................................................................................................................................... 164In This Section......................................................................................................................... 164

Console Tasks............................................................................................................................ 164

Agent Tasks................................................................................................................................ 165Credentials.............................................................................................................................. 166Output...................................................................................................................................... 166Kinds of agent tasks................................................................................................................166

Health Model Design Overview...................................................................................................166In This Section......................................................................................................................... 166

Failure Mode Analysis................................................................................................................. 167Basic Concept......................................................................................................................... 167Steps in Failure Mode Analysis...............................................................................................168

List what can go wrong........................................................................................................168Identify a detection strategy for each failure mode...............................................................168Add detection elements to application code.........................................................................168Plan management pack content...........................................................................................168

Operational failures.................................................................................................................169

Defining Monitors........................................................................................................................ 170Define Unit Monitors................................................................................................................171

Diagnostics and Recoveries.................................................................................................173Define Aggregate Monitors......................................................................................................173Define Dependency Monitors..................................................................................................174

Hosted Classes.................................................................................................................... 174

Health Rollups......................................................................................................................174

Defining Rules............................................................................................................................ 175Alerting Rules.......................................................................................................................... 175

Minimizing Noise.................................................................................................................. 175Collection Rules....................................................................................................................... 176See Also.................................................................................................................................. 176

Practices to Avoid....................................................................................................................... 176Focus on the easy–to-monitor instead of the required.............................................................176Running monitors and rules too frequently..............................................................................176Multiple scripts running at the same time................................................................................177Targeting classes with multiple instances................................................................................177See Also.................................................................................................................................. 177

Building a Health Model..............................................................................................................177In This Section......................................................................................................................... 178

Creating Monitors....................................................................................................................... 178In This Section......................................................................................................................... 178

How to create an event monitor..................................................................................................179See Also.................................................................................................................................. 180

How to create an event monitor targeted at class with multiple instances..................................180See Also.................................................................................................................................. 182

How to create a repeating event monitor....................................................................................182See Also.................................................................................................................................. 183

How to create a monitor based on a script..................................................................................183See Also.................................................................................................................................. 185

How to create a WMI event monitor............................................................................................185See Also.................................................................................................................................. 187

How to create a consecutive sample performance monitor........................................................187See Also.................................................................................................................................. 188

How to create a dependency monitor.........................................................................................189See Also.................................................................................................................................. 190

Creating Diagnostics and Recoveries.........................................................................................190In This Section......................................................................................................................... 190

How to create a diagnostic..........................................................................................................191See Also.................................................................................................................................. 192

How to create a recovery based on the output of a diagnostic...................................................192See Also.................................................................................................................................. 195

Creating Rules............................................................................................................................ 195In This Section......................................................................................................................... 195

How to create a delimited text log alerting rule...........................................................................196See Also.................................................................................................................................. 197

How to create a WMI performance collection rule......................................................................197See Also.................................................................................................................................. 198

How to create a script-based performance collection rule..........................................................198See Also.................................................................................................................................. 200

How to create a script-based event collection rule......................................................................200See Also.................................................................................................................................. 202

Presentation................................................................................................................................ 202In This Section......................................................................................................................... 202


Views.......................................................................................................................................... 203In This Section......................................................................................................................... 203

Types of Views............................................................................................................................ 203In This Section......................................................................................................................... 204

State Views................................................................................................................................. 204Contents.................................................................................................................................. 204

Target................................................................................................................................... 205Group................................................................................................................................... 205Criteria................................................................................................................................. 205Columns............................................................................................................................... 206

Formatting............................................................................................................................... 207See Also.................................................................................................................................. 208

Alert Views.................................................................................................................................. 209Contents.................................................................................................................................. 209


Formatting............................................................................................................................... 216

Event Views................................................................................................................................ 218Contents.................................................................................................................................. 218


Formatting............................................................................................................................... 222

Task Status View.........................................................................................................................224Contents.................................................................................................................................. 224


Formatting............................................................................................................................... 227

Performance Views..................................................................................................................... 229Contents.................................................................................................................................. 229

Target................................................................................................................................... 229Group................................................................................................................................... 229Criteria................................................................................................................................. 230

Formatting............................................................................................................................... 231

Diagram Views............................................................................................................................ 233Target...................................................................................................................................... 233Formatting............................................................................................................................... 233

Dashboard Views........................................................................................................................ 236Target...................................................................................................................................... 236Configuration........................................................................................................................... 236

Folders........................................................................................................................................ 237

Linked Reports............................................................................................................................ 237In This Section......................................................................................................................... 238

Components of a Linked Report.................................................................................................238See Also.................................................................................................................................. 239

Report Parameters.....................................................................................................................239In This Section......................................................................................................................... 240

Common Parameters.................................................................................................................. 240Date Parameters..................................................................................................................... 240

Relative Data Time Parameters...........................................................................................240Date Parameter Examples................................................................................................243

Business Relative Date Time Parameters............................................................................244ManagementGroupId...............................................................................................................244ManagementPackId.................................................................................................................244ObjectList................................................................................................................................ 245See Also.................................................................................................................................. 245

Alert Parameters......................................................................................................................... 245Severity................................................................................................................................... 245Priority..................................................................................................................................... 246See Also.................................................................................................................................. 246

Event Parameters....................................................................................................................... 246EventChannel..........................................................................................................................246EventSource............................................................................................................................ 247EventType............................................................................................................................... 247Event Category........................................................................................................................247See Also.................................................................................................................................. 247

Performance Parameters............................................................................................................247AggregationType.....................................................................................................................248DataAggregation...................................................................................................................... 248Enable3D................................................................................................................................. 248ObjectList................................................................................................................................ 249RuleId...................................................................................................................................... 252RuleInstance........................................................................................................................... 252SortOrder................................................................................................................................. 252TopCount................................................................................................................................. 252See Also.................................................................................................................................. 253

Report Controls........................................................................................................................... 253Formatting............................................................................................................................... 253Binding.................................................................................................................................... 254Prompts................................................................................................................................... 254Properties................................................................................................................................ 254In This Section......................................................................................................................... 254See Also.................................................................................................................................. 255

Common Report Controls...........................................................................................................255Boolean Picker........................................................................................................................ 255

Example............................................................................................................................... 255Checked List Box.....................................................................................................................256

Example............................................................................................................................... 256Combo Box.............................................................................................................................. 256

Example............................................................................................................................... 257Object XML Picker...................................................................................................................257

Filtering Objects...................................................................................................................257Example............................................................................................................................... 258

Numeric Up Down................................................................................................................... 259Example............................................................................................................................... 259

See Also.................................................................................................................................. 260

Date Report Controls.................................................................................................................. 260Relative Date Time Picker.......................................................................................................260

Example............................................................................................................................... 260Business Relative Date Time Picker........................................................................................261

Example............................................................................................................................... 261See Also.................................................................................................................................. 262

Performance Report Controls.....................................................................................................262Performance Chart Object Picker............................................................................................263

Example............................................................................................................................... 263Linked Performance Chart Object Picker................................................................................263

Properties............................................................................................................................. 264ValueTemplate Property....................................................................................................264Example............................................................................................................................ 266

Performance Rule Picker.........................................................................................................267Example............................................................................................................................... 268

Performance Rule Instance Picker..........................................................................................268Example............................................................................................................................... 268

See Also.................................................................................................................................. 269

Generic Reports.......................................................................................................................... 269

Alert Reports............................................................................................................................... 271Alerts....................................................................................................................................... 271

Controls and Parameters.....................................................................................................271Parameter Block................................................................................................................... 272

Alert Logging Latency..............................................................................................................274Controls and Parameters.....................................................................................................274

Threshold Parameter........................................................................................................276AggregationType Parameter.............................................................................................276

Parameter Block................................................................................................................... 276Most Common Alerts...............................................................................................................279


See Also.................................................................................................................................. 282

Event Reports............................................................................................................................. 282Event Analysis.........................................................................................................................282

Controls and Parameters.....................................................................................................282

Parameter Block................................................................................................................... 284Custom Event..........................................................................................................................286

Controls and Parameters.....................................................................................................287Columns Parameter..........................................................................................................288

Parameter Block................................................................................................................... 289Most Common Events.............................................................................................................291


See Also.................................................................................................................................. 295

Performance Reports.................................................................................................................. 295Performance............................................................................................................................ 295


Performance Detail..................................................................................................................299Controls and Parameters.....................................................................................................300Parameter Block................................................................................................................... 301

Performance Top Instances.....................................................................................................303Controls and Parameters.....................................................................................................303Parameter Block................................................................................................................... 305

Performance Top Objects........................................................................................................308Controls and Parameters.....................................................................................................308Parameter Block................................................................................................................... 309

See Also.................................................................................................................................. 312

Availability Reports.....................................................................................................................312Availability................................................................................................................................ 312

Controls and Parameters.....................................................................................................313Downtime..........................................................................................................................314Data Aggregation..............................................................................................................314

Parameter Block................................................................................................................... 314See Also.................................................................................................................................. 317

Configuration Reports.................................................................................................................317Configuration Changes............................................................................................................317


Custom Configuration..............................................................................................................319Controls and Parameters.....................................................................................................320

Columns Parameter..........................................................................................................321Parameter Block................................................................................................................... 322

See Also.................................................................................................................................. 324

Presentation Design Overview....................................................................................................324

In This Section......................................................................................................................... 324

Defining Views............................................................................................................................ 324Recommended Views..............................................................................................................324

State Views.......................................................................................................................... 324Alert Views........................................................................................................................... 325Event Views.........................................................................................................................325Performance Views..............................................................................................................325Diagram Views.....................................................................................................................325Task Status Views................................................................................................................326Dashboard Views................................................................................................................. 326

Recommended Folder Structure..............................................................................................326See Also.................................................................................................................................. 327

Defining Reports.........................................................................................................................327Determine Report Strategy......................................................................................................327

No Reports........................................................................................................................... 327Linked Reports.....................................................................................................................327Custom Reports...................................................................................................................328

Recommended Reports...........................................................................................................328Availability Reports...............................................................................................................328Configuration Reports..........................................................................................................328Performance Reports...........................................................................................................329

See Also.................................................................................................................................. 329

Building Views and Reports........................................................................................................329In This Section......................................................................................................................... 329

Creating and Editing Views.........................................................................................................330In This Section......................................................................................................................... 330

How to Create a Folder...............................................................................................................331See Also.................................................................................................................................. 331

How to Create a State View........................................................................................................331See Also.................................................................................................................................. 334

How to Create an Alert View.......................................................................................................334See Also.................................................................................................................................. 336

How to Create a Performance View............................................................................................336See Also.................................................................................................................................. 338

Creating and Editing Linked Reports..........................................................................................338In This Section......................................................................................................................... 339

How to Create a Linked Availability Report.................................................................................340See Also.................................................................................................................................. 345

How to Create a Linked Alert Report..........................................................................................346See Also.................................................................................................................................. 351

How to Create a Linked Event Report.........................................................................................351See Also.................................................................................................................................. 356

How to Create a Linked Configuration Report............................................................................356See Also.................................................................................................................................. 362

How to Create a Linked Performance Report.............................................................................362See Also.................................................................................................................................. 371

Composition................................................................................................................................ 371In This Section......................................................................................................................... 371


Module and Workflow Basics......................................................................................................372Modules................................................................................................................................... 373

Module Parameters..............................................................................................................374Data Stream......................................................................................................................... 375Data Types........................................................................................................................... 375

Workflows................................................................................................................................ 375Workflow Targets.................................................................................................................. 376

Modules Types............................................................................................................................ 376In This Section......................................................................................................................... 376

Data Source Modules.................................................................................................................377Common Data Source Modules..............................................................................................378

Probe Action Modules.................................................................................................................382Common Probe Action Modules..............................................................................................383

Condition Detection Modules......................................................................................................385Common Condition Detection Modules...................................................................................386

Write Action Modules..................................................................................................................387Common Write Action Modules...............................................................................................387

Module Implementations.............................................................................................................389Composite Module Example....................................................................................................389Sample Workflow with Composite Modules.............................................................................391

Kinds of Workflows.....................................................................................................................392Discoveries.............................................................................................................................. 393Rules....................................................................................................................................... 393Tasks....................................................................................................................................... 393Monitors................................................................................................................................... 394

Monitor Types....................................................................................................................... 394Diagnostics........................................................................................................................... 396Recoveries........................................................................................................................... 397

Cookdown................................................................................................................................... 397Overview of Cookdown............................................................................................................398

Multiple Workflows...............................................................................................................398Multiple Workflows with Cookdown......................................................................................399

Criteria for Cookdown..............................................................................................................400When to Configure for Cookdown............................................................................................401

Scripts Supporting Cookdown.....................................................................................................401Multiple Property Bags............................................................................................................401

Designing Custom Modules and Workflows................................................................................403When to Create a Custom Workflow.......................................................................................404

Functionality Not Provided with Wizard................................................................................404Custom Modules.................................................................................................................. 404Windows PowerShell...........................................................................................................404

When to Create Custom Modules............................................................................................404Share Common Logic between Different Workflows............................................................404Implement Complex Logic Not Possible with Existing Modules...........................................405Improve Override Experience...............................................................................................405

Custom Module Types................................................................................................................406Data Source Modules..............................................................................................................406Probe Action Modules..............................................................................................................406

Probe Action Module Input Data and Triggers......................................................................407Condition Detection Modules...................................................................................................407Write Action Modules...............................................................................................................407

Passing data with parameters.....................................................................................................408Values and Variables...............................................................................................................408

Explicit Values...................................................................................................................... 408$Target Variables.................................................................................................................408$Data Variables.................................................................................................................... 409$Config Variables................................................................................................................. 409

Overrideable Parameters........................................................................................................409Sample Workflow.....................................................................................................................410

Creating Custom Modules and Workflows..................................................................................417In This Section......................................................................................................................... 417

How to create a monitor based on a custom module..................................................................417

How to create a monitor based on a Windows PowerShell script...............................................423

How to create a monitor and rule that share a script supporting cookdown................................430

Management Pack Authoring GuideWelcome to the Management Pack Authoring Guide for Microsoft System Center Operations Manager 2007. This guide provides complete information about the design and implementation of management packs for System Center Operations Manager 2007.

This guide applies to IT professionals who use Operations Manager 2007 R2 and have to create a management pack that includes features beyond the basic scenarios that the Operations console provides.

In addition to experience with Operations Manager 2007 R2, you should have the following skills:

Basic familiarity with XML Familiarity with XML Path Language (XPath) Knowledge of a scripting language such as VBScript or Windows PowerShell

This guide primarily uses the System Center Operations Manager Authoring Console which is part of the System Center Operations Manager 2007 R2 Authoring Resource Kit (http://go.microsoft.com/fwlink/?LinkID=192098) to create management packs with all available elements and monitoring scenarios. The Authoring in the Operations Console section of the Operations Manager 2007 R2 Operations User's Guide describes how to create management packs by using the Operations console, which provides a more limited set of monitoring scenarios, but also requires significantly less understanding of relatively complex concepts. We recommend that you start with the Operations Manager 2007 R2 Operations User's Guide to gain experience with basic authoring concepts before reading this guide.

In This SectionManagement Pack Basics

Covers the contents and structure of a management pack and provides an overview of editing tools and general concepts required for other sections.

Service ModelCovers concepts of classes, relationships, and discovery, and provides guidance for designing a service model for an application that you have to monitor.

Health ModelDefines several methods for measuring health state and collecting monitoring information for classes defined in the service model. Provides guidance for designing a health model for an application that you have to monitor.

23

http://go.microsoft.com/fwlink/?LinkID=192098

PresentationProvides guidance for defining and creating Views and Linked Reports to display and analyze collected monitoring data in the Operations console.

CompositionDefines the underlying concepts and structure of monitoring workflows and provides guidance for creating custom workflows not available with standard Authoring Console wizards.

Management Pack BasicsAll of the elements required for monitoring an application with Operations Manager 2007 including the service model, health model, views, and reports are stored in management packs. A management pack is an .xml file that conforms to a specific schema. It is installed into an Operations Manager 2007 management group and distributed to appropriate agents that use its contents to perform monitoring activities for a particular application.

The topics in this section provide an overview of general concepts required for building a management pack. These concepts are used in the remaining sections of this guide.

In This SectionAuthoring Tools

Describes the different tools available for authoring a management pack and the characteristics of each tool.

Management Pack FormatsDescribes the format of a management pack file and the difference between unsealed and sealed management packs.

Version ControlDescribes the requirements for sealed management packs to be upgraded between versions.

Management Pack ReferencesDescribes how management packs rely on elements in other management packs and

24

how management pack references are defined.

NamingDescribes the naming requirements of management pack elements and how different languages are used.

VariablesProvides a basic overview of the different management pack variables and how they are used.

Authoring Tools This guide focuses on how to create and edit management packs by using the System Center Operations Manager Authoring Console which is part of the System Center Operations Manager 2007 R2 Authoring Resource Kit (http://go.microsoft.com/fwlink/?LinkID=192098), but there are multiple tools to create and change management packs. The particular choice of tool depends on the requirements and skill level of the user. A single management pack might be changed by using multiple different tools at different times and by different users. This section provides details about the different editing options and when to use each option.

Operations ConsoleThe Operations console is primarily intended for users of Operations Manager 2007 who have minimal knowledge of management pack authoring and have basic customization requirements. Management packs can be created and modified from the Authoring pane in the Operations console as long as the user has Author user rights.

Specific characteristics of the Operations console include the following:

Create or change a management pack in an existing management group. Changes are committed and deployed to agents immediately.

Create predefined monitoring scenarios by using templates and wizards. Cannot create custom monitoring scenarios.

Cannot create custom classes or discoveries outside specific cases that templates provide. Automatically generate names for management pack elements. Cannot implement standard

naming scheme.

The primary advantage of the Operations console is the ability to create custom monitoring scenarios with minimal complexity. The Operations console provides the following approaches for creating monitoring scenarios.

25



WizardsWizards in the Operations console let you create monitors, rules, and tasks by using a simplified user interface. These wizards require you to have a basic understanding of the monitoring scenario that they are implementing, but does not require knowledge of the structure or underlying details of the actual element that is created.

Management Pack TemplatesManagement Pack Templates provide functionality that is not accessed from wizards in the Operations console. Each template provides a particular monitoring scenario and creates one or several management pack elements based on input from the user. You are not exposed to the underlying elements, but you provide required information through simplified wizards.

Distributed Application DesignerThe Distributed Application Designer lets you create relationships between existing managed objects that participate in the same application. The relationships lets you create an overall health measurement of the application as measured by its individual components. The Distributed Application Designer does not allow for any new monitoring scenarios to be created, but relies on the health of managed objects measured through monitors created by using other tools such as wizards and templates.

Authoring ConsoleThe System Center Operations Manager Authoring Console is primarily intended for management pack authors with significant knowledge of the structure of management pack elements and enables them to create and modify all elements in a management pack. It is not limited to a specific set of scenarios, although it does require deeper technical knowledge than the Operations console.

The Authoring console provides many of the same wizards as the Operations console, except that the Authoring console wizards can specify the ID of the management pack element and can provide access to additional options. The console provides custom dialog boxes similar to the Operations console to help you configure management pack elements where they are available. For those elements where no dialog box is available, you must edit the XML code of the management pack directly. To help edit, the Authoring console starts an external editor. You use the editor to edit the XML code of the specific element and, when it is closed, the editor returns the completed element back to the management pack. You can specify the editor that the Authoring console starts.

Specific characteristics of the Operations console include the following:

Create or change a management pack on disk without requiring access to the management group. Optionally, load management packs from a management group and install them after modification.

Provide custom ID for each management pack element.

26

Create all management pack elements including custom classes, relationships, and discoveries that cannot be created in the Operations console.

Create predefined monitoring scenarios by using wizards. Create custom monitoring scenarios with the assistance of the user interface.

XML EditorExcept for requiring the XML editor for configuring particular modules, the Authoring console can create and configure all elements in a management pack. Because management packs are .xml files, any XML editor can create and modify them. This is significantly more complex than using the Authoring console because for this activity, you must know the details of the management pack schema. It is also less efficient for most scenarios because a single element might require multiple entries in the XML file. By contrast, in the Authoring console, you can configure the elements in a single dialog box or in wizards.

An XML editor is required for the following scenarios that cannot be performed in the Authoring console:

The ID of a management pack element cannot be changed with the Authoring console after it has been created. You must perform this task with an XML editor. The ID of the element cannot just be changed, but you must search for the old ID and replace it with the new ID across the management pack because the element’s ID might be used multiple times in the XML code.

Management pack elements cannot be copied by using the Authoring console. For example, you might want to create a management pack element by copying a similar element in the same management pack, or you might want to copy an element from another management pack into the current one. This functionality can only be performed with an XML editor.

The Authoring console does not let an existing management pack element be modified if it affects the configuration of another element. For example, a rule might use a custom module that requires values for one or more parameters. You might want to modify this module and add an additional parameter to it. Because the rule would not provide a value for this required parameter after the module was modified, the changed module cannot be saved. To make this change in the Authoring console, you must delete the rule and create it again after changing the module. By using an XML editor, you can change the module and rule at the same time.

See AlsoConfiguring the Authoring Console

Configuring the Authoring ConsoleIn the Authoring console, on the Tools menu, access all configuration options in the Options dialog box. The following table explains each of these options.

27

Option Details

Default Namespace When a new management pack element is created, the Authoring console automatically sets the prefix of the element ID to the name of the management pack. This is the most common naming scheme used to ensure that each element in the management pack has a unique ID for all management packs as discussed in Naming. You can set an alternate default by using this option. Whether this option is set or not, you always have the option to change the prefix when the element is created.

Use custom icons When this option is selected, any classes in the management pack with a defined custom icon have this icon displayed. Other classes use a default icon. When this option is cleared, all classes are represented with the same default icon.

Use display names When this option is selected, the display name instead of the ID of each management pack element is shown in any list view.

Auto-increment management pack version on save

With this option selected, the Authoring console increments the version number of the management pack every time it is saved. This is useful to ensure that each modification of the management pack results in a new version number.

Show warning when a sealed management pack is opened

The Authoring console can open both sealed and unsealed management packs. Sealed management packs cannot be changed, but can only be viewed. With this option set, when you open a sealed management pack, you receive a warning stating that it is read only.

Custom Editor Specifies the editor to directly edit XML. This can be a simple editor such as Notepad or a more sophisticated editor providing such features as color coding and XML formatting. If you did not select an editor, you are prompted for one the first time you attempt to start the editor.

28

Option Details

References The Authoring console requires that the sealed version of any management pack referenced by the open management pack must be located on disk. A set of reference paths specify the folders that the Authoring console searches for such files. If the file for a referenced management pack is not found in any of the paths when a management pack is opened, you are prompted to locate it.

Management Pack FormatsManagement packs are written in .xml files that follow a particular schema. You can create .xml files by using any XML editor or by using the Authoring console. You can also create and modify management packs in a management group by using the Operations console. When a management pack is exported from the management group, it is stored in the same XML format.

Management Pack SchemaThe schema for a management pack is defined in the ManagementPackSchema.xsd file that is installed in the MP Schema folder with the Authoring console. Knowledge of the schema is only required if the management pack is edited directly by using an XML editor. When you use the Authoring console, you are rarely exposed to this schema. Wizards are available for creating common elements, and custom user interface pages are available for common modules. Direct XML editing is only required for configuring modules and workflows that do not have custom UI pages. The XML for defining complex data types might be required, and the schema for these data types is provided in the Schema Type Reference (http://go.microsoft.com/fwlink/?LinkID=192053).

Sealed Management PacksWhen a management pack is sealed, it is converted to a binary file that has an MP extension. Either the sealed or the unsealed version of a management pack can be installed to a management group, but both cannot be installed at the same time.

Sealing a management pack is not a valid strategy for hiding information from users. You can export any sealed management pack from the management group giving you full

Important

29


access to its XML code. A management pack should never contain sensitive information such as passwords.

Sealed management packs have the following characteristics:

The contents of the management pack cannot be modifiedSealed management packs cannot be changed. Changes must be made to the XML version of the file which is then sealed again with the same certificate. Such an update can only be installed in the same management group if the updated management pack is backward compatible.

Version ControlOnly sealed management packs enforce version control when an updated version of the management pack is installed. If the management pack is unsealed, the new version is always installed regardless of its backward compatibility.

Enables the management pack to be referenced by other management packsManagement packs can only reference another management pack if the management pack that is referenced is sealed. This requirement ensures that a modification to a management pack cannot break other management packs that reference it. Because sealed management packs maintain version control, any referencing management packs ensures that updates to the sealed management pack are backward compatible.

When to seal a management packManagement packs do not all have to be sealed. You can install the unsealed version of a management pack in a management group. The following criteria list when a management pack must be sealed:

Management packs that are referenced by other management packs must be sealed. You might want to create common elements such as groups or modules that are used by other management packs for different applications. The application management packs do not have to be sealed, but the management packs that contain the shared elements must be.

Any management packs sent to external customers must be sealed. In addition to ensuring that the customer cannot modify the contents of the management pack, it ensures that any modifications they make are made through overrides in a different management pack. This lets you provide updates to the management pack without affecting the customer’s modifications.

Management packs that are shared by multiple groups must be sealed. This ensures that each group makes any modifications through overrides in their own management pack. Each group cannot make modifications that affect the other group.

30

Sealing a management packManagement packs are sealed by using the MPSeal tool that is located in the SupportTools folder of the Operations Manager 2007 R2 distribution media. Sealing requires a client certificate to validate the identity of the author.

You can use the Strong Name Tool (Sn.exe) included with the .NET Framework SDK to create a certificate sufficient for sealing management packs for testing. For production, use a client certificate from the correct certification authority (CA) appropriate for signing code for sealing management packs.

The process for sealing a management pack is provided in How to Seal a Management Pack.

See AlsoManagement Pack References

Version Control

Version ControlSealed management packs enforce version control when you install an updated version of the management in a management group where an earlier version of the management pack is installed. If a new version of a sealed management pack is not backward compatible, you must uninstall the earlier version of the management pack before you can install the new version. If you plan to seal a management pack, you must ensure that each updated version of the management pack will be backward compatible.

AccessibilityAny management pack element that can be used by another management pack has an accessibility setting. By default, this setting is internal, meaning that the element can only be used in the current management pack, and no other management packs can use it. If the accessibility for an element is changed to public, the element can be used by other management packs, but backward compatibility is enforced that restricts the modifications that can be made to the element.

As a best practice, keep the accessibility internal for all management pack elements unless other management packs will be using them. Setting them to internal preserves the ability to make any modifications in later version of the management pack.

Classes are typically marked as public unless they are meant to only act as a base class for classes in the current management pack. This is because a user might want to create elements such as monitors, rules, or views that apply to the class after it is installed. Because the management pack is sealed, which is required for another management pack to reference it, these elements must be created in another management pack, but this is not possible if the class

31

is internal. Classes must be marked as public to apply to management pack elements in other management packs.

Backward CompatibilityWhen a new version of a sealed management pack is installed in a management group, the version that is installed must be a version later than the installed version. If the version is the same or an earlier version than the installed version, the management pack does not install.

The content of the new management pack must also be backward compatible with the installed version, or the management pack does not install. Only management pack elements with public accessibility will be checked for backward compatibility. Elements with internal accessibility are not checked and can be removed or modified without restriction.

The requirements for all elements with public accessibility for a management pack to be backward compatible are as follows:

The element must be located in the new version of the management pack. No key properties can be added or removed from a class. No properties can be removed from a class. Properties can be added as long as they are not

a key property. No properties on a class can have their data type changed. Classes cannot have their base class modified. The number of health states on a monitor type cannot be changed. Parameters on modules and monitor types cannot be added or removed. Parameters on modules and monitor types cannot have their data type changed. Parameters on a module or monitor type configured to be overrideable cannot be changed to

prevent overrides.

See AlsoManagement Pack Formats

Classes

Management Pack ReferencesManagement packs often use elements such as base classes, monitor types, and modules in other management packs. Library management packs are automatically installed with System Center Operations Manager 2007 R2 to provide the core set of elements required by other management packs. For a management pack to use an element from another management pack, it must have a reference to that management pack.

32

Sealed Management PacksA management pack can only use elements in another management pack if the management pack with the elements is sealed. The referencing management pack can be sealed or unsealed as shown in the following diagram.

Valid management pack references

Standard ReferencesWhen a management pack is created by using the Authoring console, it automatically adds the standard set of references shown in the following table. The versions shown are for the Authoring console for Operations Manager 2007 R2 . Updates to the console can create updated versions of these references.

Alias Management Pack Version

SC Microsoft.SystemCenter.Library 6.1.7221.0

Windows Microsoft.Windows.Library 6.1.7221.0

33

Alias Management Pack Version

Health System.Health.Library 6.1.7221.0

System System.Library 6.1.7221.0

Defining a referenceEach management pack reference includes the parts shown in the following table.

Alias The alias is a short string that represents the referenced management pack throughout the current management pack. You can set the alias. It applies only to the current management pack. You can use any string of letters and numbers, although we recommend a short and descriptive string.

References that are created by the Operations Console have an alias automatically assigned. It can only be changed by exporting the management pack and editing the alias with an XML editor. References created by using the Authoring console have an alias automatically created, but it can be changed before any elements that use the alias are used in the management pack. After such elements are used, the alias can only be changed by using an XML editor because all uses of the alias must also be changed.

ID The ID of the reference is the name of the referenced management pack.

Version The version of the reference is the minimum version of the management pack required by the reference. The version of the referenced management pack installed in the management group must be the same to or a later version than the version specified in the reference.

Public Key Token The public key token is a unique character string representing the certificate that is used to seal the referenced management pack. This ensures that the management pack is provided

34

by the expected source. If a management pack with the same name as the referenced management pack, but sealed with a different certificate, is installed in the management group, the token does not match.

Example ReferencesThe diagram below shows an example of the references for the Microsoft.SQLServer.2008.Monitoring management pack 6.0.6648.0. All of the management packs listed in the references must be installed in the management group before the Microsoft.SQLServer.2008.Monitoring can be installed. The minimal version of the Microsoft.SQLServer.Library and Microsoft.SQLServer.Discovery management packs are 6.0.6648.0. The version of these management packs installed in the management group must be equal to or later than 6.0.6648.0.

The other management packs require version 6.0.5000.0 or higher. These are library management packs that are included with Operations Manager 2007. Version 6.0.5000.0 of the management packs were included with the release version of the product. The library management packs for Operations Manager 2007 Service Pack 1 are version 6.0.6278.0 whereas the library management packs for Operations Manager 2007 R2 are 6.1.7221.0. These references ensure that the management pack installs on the release version of Operations Manager 2007. If a later version of the product were required for this management pack, a later version would be specified in the references.

The key token is identical for all of the references because these are all management packs provided by Microsoft and have been sealed with the same certificate.

Sample management pack references

35

See AlsoManagement Pack Formats

How to create a management pack referenceWhen using the Operations console, references are automatically created and added to the management pack as required. There is no way to remove these references other than exporting the management pack from the management group and removing the reference in the Authoring console or an XML editor. Any management pack elements that use the reference must first be removed.

Only elements in management packs that the current management pack references are available in the Authoring console. If other elements in other management packs are required, the reference must first be added. Certain wizards in the Authoring console also automatically add

36

references, although whenever custom elements are created, you must create any references manually.

For example, a common scenario is to create a rule that collects a performance counter to the Operations Manager database and the data warehouse. The module for collecting performance data to the data warehouse is in the System.Performance.Library management pack, and this is not one of the standard references created when the management pack is created. If this rule is created by using the wizard for creating a Windows Performance Collection rule, a reference to this management pack is automatically created. If the rule is created manually by using the Custom Rule wizard, the reference must first be created manually. Without the reference, the required Microsoft.SystemCenter.DataWarehouse.PublishPerformanceData module is not available to the custom rule.

1. In the Authoring console, click File, and then click Management Pack Properties.2. Click the References tab, and then click Add Reference.3. Locate the sealed management pack file to reference, and then click Open.4. If you want to change the alias, select the new reference, and then click the alias in the

Alias column.5. Type a new alias.6. Click OK.

NamingAll elements in a management pack have an ID and at least one display name. One element can have a different display name for each language pack included in the management pack.

IDEach element in a management pack requires an ID that can only include letters and numbers and also period (.) and underscore (_) characters. The ID cannot contain spaces. The ID for an element must be unique for the whole management group that the management pack is installed in. If two elements in different management packs have the same ID, the management packs cannot be installed in the same management group.

The most common strategy to ensure that all management pack elements have a unique name is to use the name of the product or the management pack as a prefix for the name of all elements. This is often referred to as the namespace. Because two management packs with the same name cannot be installed in the same management group, elements in different management pack cannot have the same name. The Authoring console supports this strategy by providing a default name with the management pack name as the prefix for all new elements.

To create a management pack reference in the Authoring console

37

The following table shows examples of element IDs from the Windows Server 2008 Operating System (Discovery) and Windows Server 2008 Operating System (Monitoring) management packs. All these use the prefix Microsoft.Windows.Server.2008 which is the product name that these management packs monitor.

Element ID Display Name

Classes Microsoft.Windows.Server.2008.Computer Windows Server 2008 Computer

Microsoft.Windows.Server.2008.OperatingSystem Windows Server 2008 Operating System

Discoveries

Microsoft.Windows.Server.2008.Computer.Discovery Discover Windows 2008 Servers

Microsoft.Windows.Server.2008.LogicalDisk.Discovery Discover Windows Logical Disks

Rules Microsoft.Windows.Server.2008.LogicalDisk.FreeSpace.Collection % Logical Disk Free Space 2008

Microsoft.Windows.Server.2008.OperatingSystem.IPAddressConflict.Alert

Duplicate IP Address has been Detected

Monitors Microsoft.Windows.Server.2008.Processor.CPUUtilization CPU Percentage Utilization

Microsoft.Windows.Server.2008.LogicalDisk.FreeSpace Logical Disk Free Space

38

Monitoring elements created by the Operations console are automatically assigned an ID. This ID includes a GUID to ensure that it is unique. This can make management packs opened in the Authoring console difficult to read. Because the Authoring console does not let you rename elements, the only way to modify these names to make the management pack more readable is to open the .xml file in a text editor.

ID created by Operations console

Display NamesThe Operations console uses the display name for all management pack elements whenever one is available. The only time the ID is displayed to the user is if a display name is not available. The Authoring console enforces the requirement for a display name when a management pack element is created or modified, but the display name is not required if the management pack is modified with an XML editor.

The following diagram shows the ID and display name in the Authoring console and the Operations console for the Active Directory Domain Controller Server 2008 Computer Role class. In the Authoring console, you can define both, whereas the Operations console displays only the display name.

ID and Display Name in Authoring console and Operations console

39

Language PacksDisplayed text in the Operations console is stored in a language pack in the management pack. A language pack includes the following:

Display names for each management pack element String resources such as alert descriptions Product knowledge for each management pack element

40

A single management pack has one or more language packs with one specified as the default. When a display string is displayed in the Operations console, the language pack uses the language that corresponds to the language of the user’s operating system. If a language pack for this language is not available, the display string from the default language pack is displayed. If no display string is specified in the default management pack, the ID of the management pack element is displayed.

The Authoring console includes a text box for the display name and a tab for the product knowledge for each management pack element. These display and let you edit the display names in the default language pack for the management pack. You can edit other language packs from the Language Packs pane where each element in the management pack is listed.

VariablesManagement pack variables access information that is not known until either the management pack is installed or the particular workflow is running on an agent. Different variables are used in different situations, and knowledge of the different variables, their syntax, and when they are used is very important in creating different monitoring scenarios.

Using VariablesVariables in a management pack are delimited by using a dollar sign ($). When the variable is resolved, it is replaced with its calculated value. In some cases, the Authoring console provides menus that let you select a particular variable and have the appropriate syntax automatically created. In other cases though, you must create the variable yourself by using the appropriate syntax.

Kinds of VariablesThe following table lists the kinds of variables that are used in a management pack. Additional details about each kind of variable are provided in other sections of this guide where the particular variable is used.

Variable Syntax Used In Description

MPElement

$MPElement[Name="ElementName"]/SubElementName$

Discoveries

Resolves to the GUID of the specified management pack element.

Target $Target/Property[Type="ElementName"]/PropertyName$ Discoverie Retrieves

41

Variable Syntax Used In Description

$Target/Host/Property[Type="ElementName"]/PropertyName$

s

Monitors

Rules

Tasks

Diagnostics

Recoveries

Alert Descriptions

the value of a property of the target object or one of the target object’s hosts.

Data $Data/<XPath to Property>$ Monitors

Rules

Tasks

Diagnostics

Recoveries

Alert Descriptions

Retrieves a value from the data stream.

Config $Config/Parameter$ Modules

Monitor Types

Retrieves a value from a parameter on the module or monitor type.

See AlsoDiscovery Scripts

Data Variables

Passing data with parameters

42

Service ModelIn Operations Manager 2007, all hardware, software, services, and other logical components of different applications that require monitoring are described in a service model. A model is a computer-consumable representation of software or hardware components that captures the nature of the components and the relationships between them. It can be thought of as a simplified representation of the application for monitoring.

When implementing monitoring for an application that uses Operations Manager 2007, the first step is to design a service model.

The topics in this section provide an overview of the key concepts that must be understood to perform this design, a basic process for designing a service model, and walkthroughs and examples of using the Operations Manager 2007 Authoring console to build the service model..

In This SectionKey Concepts

Explains the concepts of the different components in a service model.

Service Model Design OverviewExplains the process and best practices when you design a service model for a particular application.

Building a Service ModelDemonstrates the different tasks used for building a service model for a sample application using the Authoring console.

Key ConceptsIn Operations Manager 2007, all hardware, software, services, and other logical devices that require monitoring are described in a service model. A model is a computer-consumable representation of software or hardware devices that captures the nature of the components and the relationships between them.

43

In This SectionClasses

Overview of classes and inheritance.

RelationshipsOverview of the different kinds of relationships between classes and their implications to monitoring.

Viewing Classes in the ConsolesProcedure that uses the Authoring console and Operations console to explain the concepts of classes, relationships, and inheritance.

DiscoveryOverview of the process for discovering instances of classes and relationships.

Discovery ScriptsDetails about how to write a script to perform discovery.

ClassesThe main element of a service model is a class. This represents some object being managed. It could represent a computer, a database, a service, a disk, an application, or any other kind of object that requires monitoring. A management pack may define any number of classes to represent the application it is monitoring in addition to using existing classes in other management packs and management pack libraries.

Each monitored object that appears in the Operations console is an instance of a particular class. All instances of a class have a common set of properties and a common means of being monitored. Each of these instances is created by a discovery that uses logic specific to the particular class to identify the instances and collect the values of their properties.

Like all management pack elements, classes have an ID and a Display Name. These terms may be used differently in different consoles. In this documentation, ID will refer to the unique name of the class that is only seen in the Authoring console while Name and

Note

44

Display Name will refer to the language-specific name that appears in the Operations console.

PropertiesAll instances of a particular class will share a common set of properties. The values for these properties are provided by discoveries and can vary among different instances. Properties are used to represent details of the object, such as a unique name, configuration settings, and other details that may be interesting to the user or that are required for monitoring scenarios.

Key PropertiesA key property uniquely identifies each instance of a particular class. If a property is marked as a key property, each instance of the class must have a unique value, and the value may not be null. For hosted classes, the value must only be unique for all instances of the class that have the same hosting parent. For unhosted classes, it must be unique for all instances of the class in the management group. Hosting relationships are discussed more in the Relationships section.

Classes do not always require a key property. A key property is only required if more than one instance of a class is expected for a single parent. If only a single instance is expected, a key property is not required but may still be defined.

For example, SQL Database Engine has a key property of Instance Name because a single computer can have more than one instance of SQL Server installed. When there are multiple instances on a particular computer, each instance must have a different value for Instance Name in order to clearly distinguish between the different objects. The IIS Web Server class, by contrast, does not define a key property because there can be only one instance installed on any computer.

All objects have a Path Name property that is calculated from the object’s key property or properties and those of its hosting parent(s). For unhosted objects, the Path Name will be the key property of the class itself. The Path Name can be used to uniquely identify any instance of a class in the management group.

Base Classes and InheritanceEvery class must specify a base class that identifies an existing class that the new one will specialize. The management pack libraries that are included with Operations Manager 2007 contain several classes that can be used as the base for custom classes in management packs. A management pack will typically have at least one class inheriting from a library class and potentially other classes inheriting from classes in the same management pack.

The concept of a base class can be illustrated with the Windows Server Operating System management pack. This management pack includes classes representing logical disks installed on the agent computer. The following diagram shows the classes Windows Server 2003 Logical Disk and Windows Server 2008 Logical Disk. These classes are both based on Logical Disk (Server) that is defined in the Microsoft.Windows.Server.Library mp file. Logical Disk (Server) is

45

in turn based on Logical Disk, which itself is based on Logical Device, and so on through Logical Hardware, Logical Entity, and finally Entity. All classes can trace a similar inheritance path and will always end up at Entity, which is the root of the class structure in Operations Manager. This is the only class that does not have a base class, and all other classes eventually inherit from it.

Inheritance of properties between classes

46

Entity has a single property named Display Name. This is inherited by all classes inheriting from it. All classes eventually inherit from Entity. That is why all classes have a Display Name property.

47

No other classes in this example have properties until Logical Device, which defines Name, Description, and DeviceID. DeviceID is specified as the key property. These properties are all inherited by Logical Disk and Logical Disk (Server). Logical Disk (Server) then adds the additional properties Size, Drive Type, and File System. The bottom-level classes that are specific to the version of operating system inherit the entire set of properties provided by those classes above them in the inheritance tree. This concept is illustrated in Viewing Classes in the Consoles.

System.Library cannot be opened in the Authoring console because of the Entity class. The Authoring console performs checks to make sure that a management pack is valid before it opens it. One of these checks is to make sure that all classes have a base class, and because Entity does not have one, the Authoring console considers it an invalid management pack.

In addition to inheriting its properties and relationships, any monitoring targeted at a class will be inherited by any other classes that use it as a base. Additional monitoring and discovery can be added to the new class, and any management pack objects targeted at the new class will apply only to the new class and not the base class.

Class TypesMost classes have one or more instances identified and created through the discovery process. These are also known as concrete classes because they actually have instances. Abstract classes and singleton classes are special kinds of classes that behave differently and are used for particular scenarios.

Abstract ClassesAbstract classes have no instances and exist only to act as a base class for other classes. All properties and relationships that are defined at the abstract class level are inherited by child classes and do not have to be defined again. Any monitoring objects targeted at the abstract class are similarly inherited by lower-level classes. Most of the classes that are defined in management pack libraries are abstract, since they are only provided to act as base classes for classes that are defined in custom management packs.

Abstract classes are used where there is a common set of properties, relationships, monitoring, or grouping that can be defined across all further specializations of a class. In the previous example, all of the classes shown above Windows Server 2003 Logical Disk and Windows Server 2008 Logical Disk are abstract. They exist only for the lower-level classes to inherit from.

Singleton ClassesSingleton classes are used when there is one and only one instance of a class. The class is the instance and always exists. No discoveries can be defined for singleton classes. Their single instance is instead being created when the management pack is installed. Similarly, a key property is not required for a singleton class, since it will only ever have a single instance.

Note

48

Common uses of singleton classes are for Groups and Distributed Applications, because there is only a single instance of these classes required throughout the management group.

See AlsoViewing Classes in the Consoles

Defining Classes and Relationships

Creating Classes and Relationships

RelationshipsRelationships are defined between classes to indicate an association between a particular instance of one class and the particular instance of another. There are three types of relationship as listed below and detailed in the following sections.

Hosting relationship Containment relationship Reference relationship

Hosting Relationship TypeThe most important and most restrictive relationship between classes is the hosting relationship. A class hosted by another class is called a hosted class, and an instance of the class is called a hosted object. If a class is not hosted by another, it is called an unhosted class, and an instance of the class is called an unhosted object.

When one object is hosted by another, that object relies on its hosting parent for its very existence. If the hosting parent is removed, the hosted child will also be removed. For example, a logical disk cannot exist without the computer that it is installed on. Therefore, the Logical Disk class is hosted by the Windows Computer class. This means that every instance of the Logical Disk class must have an instance of the Windows Computer class to host it. If a computer is removed from the management group, any instances of the Logical Disk class hosted by it will also be removed.

Sample Logical Disk hosting relationships

49

A hosted object can have only one hosting parent, but one parent can host multiple children. For example, a particular disk can be installed on only a single computer, but one computer can have several disks installed.

Hosted objects are affected by their hosting parents in the following ways:

Identity As described in Classes, an object is identified by its key property. If the object is unhosted, the value of its key property must be unique for the whole management group. For hosted classes however, the key property value must be unique only for all objects that have the same hosting parent. To uniquely identify a hosted object, the key property of both the object and the object’s parent are required.

For example, the key property of the Logical Disk class is Device ID. Every computer in a particular environment will have a logical disk that has a Device ID of C: and possibly several other common disk letters. Because every disk object requires a unique value for its key property, the Logical Disk class cannot be unhosted. It is hosted by the Windows Computer class that has its own key property of Principal Name, which is the computer’s name. The key property only has to be unique for the hosting parent. In this case, this means that the Device ID only has to be unique for each computer. This makes logical sense,

50

because a particular computer cannot have two disks that have the same Device ID.

The path for each Logical Disk instance will be the computer name followed by the Device ID, as shown in the previous diagram.

Managing Agent If an object is hosted, it will be managed on the same computer as its hosting parent. If it has an instance of the Windows Computer class as a hosting parent (meaning that the object’s class is either hosted directly by the Windows Computer class or has the Windows Computer class somewhere in its tree of hosting parents), the object will be managed by the health service on that computer.

For example, the Logical Disk class is hosted by the Windows Computer class. This means that each Logical Disk object will be managed on the computer where the disk is installed.

If an object is unhosted, by default it is managed by the agent on the Root Management Server.

For example, groups are unhosted classes, and any monitors or rules targeted at a group are run on the RMS.

Available Properties Any workflows targeted at a class have access to that class’s properties in addition to the properties of any of its hosting parent(s).

For example, a script in a monitor using the Logical Disk class as its target might require the name of the computer. Because an object can have only one hosting parent, we know the computer that hosts any particular instance of the Logical Disk class. The monitor can access the properties of the targeted object and the properties of that target’s hosting parent.

The SQL Server management pack provides another example of hosting relationships. The hosting relationship between the Windows Computer class, the SQL 2008 DB Engine class, and the SQL 2008 DB class is shown here.

Hosting Relationships for SQL Server 2008 Classes

51

The SQL 2008 DB Engine class represents an instance of SQL Server 2008 installed on a particular computer. Because a database can be installed on only a single database engine, the SQL 2008 DB Engine class hosts the SQL 2008 DB class. There can be several databases with the same name in a management group, but any databases installed on a particular instance of the SQL Server class must have a unique name. The database engine, in turn, is hosted by the Windows Computer class. There can be several SQL Server instances with the same name in a management group. Each one on a particular computer must have a unique name.

Because there are two hosting relationships, the path name for each database will be the computer name followed by the instance name followed by the database name. An example is shown in the following diagram.

Sample Database hosting relationships

52

Containment Relationship TypeThe containment relationship type is less restrictive than the hosting relationship. It declares that one class is related to another class, although one is not required for the other.

Containment relationships are typically used for one of two purposes:

Health rollup Dependency monitors mean that the health of one object depends on the health of another object and can be associated with either a hosting or a containment relationship. If one object depends on the health of another, but the two are not in a common hosting relationship, a containment relationship between the two should be created.

Group membership Objects are included in a group through a containment relationship between the group and the member object.

Unlike a hosting relationship, a containment relationship is many-to-many. This means that one object can contain multiple objects, and a single object can be contained by multiple other

53

objects. For example, one group can contain multiple objects, and a single object can be a member of multiple groups.

Reference Relationship TypeThe reference relationship is the most general of the available relationship types. A reference relationship is used when the parent and child classes are not dependent on one another; for example, a database could reference another database that it is replicating. One database is not dependent on the other, and the objects are discovered separately. Health rollup cannot be performed across reference relationships.

See AlsoCreating Classes and Relationships

Viewing Classes in the ConsolesThe following procedures illustrate the concepts of base classes and inheritance by using the Logical Disk classes in the Windows Server Operating System Management Pack. The first procedure inspects the definition of classes and relationships by using the Authoring console. The second uses the Operations console to view the same classes in actual operation.

The term class is not shown in the Operations console but is instead known as a target. When you are working in the Authoring console, the term class is used. Each term in its relative context refers to the same concept.

PrerequisitesThis procedure assumes that you have the System Center Operations Manager 2007 R2 Authoring console installed and that you have access to a System Center Operations Manager 2007 R2 environment. The environment must have the Windows Server Operating System management pack installed. The procedure uses Windows Server 2008. However, this can be easily replaced with Windows Server 2003 if that is the only operating system version available in the environment.

1. Start the Authoring console.2. Open the file Microsoft.Windows.Server.2008.Discovery.mp.3. In the Navigation pane, select Service Model, and then select Classes.

Note

To view a class definition in the Authoring console

54

4. In the Classes pane, right-click Microsoft.Windows.Server.2008.LogicalDisk, and select Properties.

5. On the General tab, note in the Base Class text box that base class of the selected class is Microsoft.Windows.Server.LogicalDisk. This matches the diagram shown in Classes. You could open Microsoft.Windows.Server.Library.mp that holds that class, and verify that its base class is System.Database, as shown in the diagram.

6. Click the Properties tab. Note the multiple properties on the current class that were inherited from Microsoft.Windows.Server.LogicalDisk, Microsoft.Windows.Server.LogicalDevice, and System.Entity. This shows the inheritance of properties by a class from its base class.

7. Click the Relationships tab. Note the relationships that the class is involved in. Of special note is the hosting relationship from Microsoft.Windows.ComputerHostsLogicalDevice in the Target section. This is the hosting relationship that the class inherits from its base class and matches the diagram in Relationships.

1. Start the Operations console.2. In the Navigation pane, select Monitoring, and then select Discovered Inventory.3. In the Actions pane, select Change Target Type. In the Select Items to Target dialog

box, select View all targets.

Be aware that this list, which consists of all the classes included in all the management packs currently installed in the management group. Any of these classes may be selected to view a list of all its discovered instances and their properties. Any new classes included in a management pack that is installed later in the management group will be included in this list.

4. Select Windows Server 2008 Logical Disk, and then click OK.

Notice that this is the same class as inspected in the previous procedure in the Authoring console. Windows Server 2008 Logical Disk is the Display Name that is used in the Operations console, whereas Microsoft.Windows.Server.2008.LogicalDisk is the Name or ID of the class that must be unique. The view shows a listing of all instances of logical disk on Windows Server 2008 computers that were discovered in the current environment.

5. Select one of the instances.

Take note of the properties in the Detail View pane. These are the same properties that are seen in the previous procedure viewing the definition of the class. The current view shows the values for each property that were collected by the discovery process. Notice also the Path name property that is built from the key property of the current class and its parent(s). In this case, the key properties include the computer name and the device name.

6. In the Actions pane, again select Change Target Type.7. In the Select Items to Target dialog box, select View all targets.

To view a class in the Operations console

55

8. Select Logical Disk (Server), and then click OK.

This is the Microsoft.Windows.Server.LogicalDisk class that is the base class for Microsoft.Windows.Server.2008.LogicalDisk. The view resembles the previous one, but will include objects from both Windows Server 2003 and Windows Server 2008 (assuming both are installed in the environment). The properties are identical to the previous view, because the Windows Server Logical Disk class has the same properties that are inherited by Windows Server 2008 Logical Disk.

9. In the Actions pane, again select Change Target Type. In the Select Items to Target dialog box, select View all targets.

10. Select Logical Disk, and then click OK.

This is the Microsoft.Windows.LogicalDisk class that is the base class for Microsoft.Windows.Server.LogicalDisk. The instances are identical to the previous view, but fewer properties are shown. This is because the Microsoft.Windows.Server.LogicalDisk class has only the properties directly assigned to it, and inherits only its single property from System.Entity. The other properties are not visible because they are associated with a class further down the tree.

See AlsoClasses

Relationships

DiscoveryThe discovery process lets you locate instances of classes and relationships that are defined in a management pack and create them in the Operations Manager database. A discovery is an element that runs on agents creating new objects as they appear in the environment, changing the properties on existing objects, and removing objects as applications and components are uninstalled. Each class that is defined in the service model must have at least one discovery associated with it or no instances of the class will ever be created.

Discovery does not apply to abstract or singleton classes.

The Mechanics of DiscoveryDiscoveries collect information from the local computer to determine whether one or more instances of a particular class are installed and collect values for its properties. The discovery itself is only responsible for collecting this information. It sends the collected discovery data to the agent’s management server that is responsible for processing the collected data to insert into the Operations Manager database.

Note

56

Discovery process

Discoveries are typically run on a scheduled basis. They continue to run on the agent even after instances are first discovered to determine whether changes were made. This interval will vary for different discoveries, balancing the considerations of the time until a new instance is discovered with the overhead generated from the discovery process.

The first time that a discovery runs on an agent, it sends its information to the agent’s management server. It also stores a copy of the collected data in the local cache. Each successive time that discovery runs, the data is only sent to the management server if a change is detected. Such changes could include a new instance, at least one property change to a previously discovered instance, or a previously discovered instance being removed. If any of these conditions are met, the discovery data is sent to the management server where it is processed.

When the management server receives the discovery data, it will inspect it to determine whether the data is valid. This includes checks such as verifying that all specified classes and properties are valid and that all required key properties were provided. If the discovery data is invalid, an error is generated on the management server and no discovery data is submitted. If the discovery data includes multiple instances and there is a problem with even a single instance, no data for any of the instances is submitted.

If the discovery data is valid, one of the following scenarios occurs.

If any of the instances have not previously been discovered, they are then created. If any of the instances have previously been discovered, any properties that may have

changed are replaced with the value in the discovery data. Any instances that were previously discovered but that are not in the current discovery data

are removed.

Discovery data always includes the ID of the discovery itself and the ID of the target object. These values are then stored with all discovered objects. This is how data from a discovery can be compared to previously discovered data.

57

Discovery DataThe primary responsibility of a discovery is to create discovery data. This includes the details of each class and relationship instance being discovered. A single discovery may only output a single set of discovery data. However, a single set of discovery data can include a single instance of a single class or relationship, multiple instances of the same class or relationship, or multiple instances of multiple classes and relationships.

Discovery data must include the following information.

GUID of the discovery element itself GUID of the target object that the discovery is running against GUID of each class or relationship being discovered Value for each key property of any class instances Value for each key property of any hosting parents of any class instances Source and target object for any relationship instances

In addition to this information, the discovery data can also include values for any non-key properties.

Conceptual view of discovery data

Each kind of discovery accesses this information through different means by using a combination of information that is provided by the management pack author and variables that are resolved

58

when the management pack is run. Script discoveries in particular must be aware of each of these elements and explicitly provide a value for each.

Discovery Data SourcesA discovery can access any information on the local agent to collect required information. The source of information will vary for different applications and for different classes and relationships. Because a management pack can include custom modules able to access almost any available data, there is almost no limit to the sources that a particular discovery may use. There are a common set of data sources that apply to most scenarios however, and these are supported by modules included in management pack libraries and wizards in the Authoring console.

RegistryAccessing the registry on the local computer is a preferred method of discovery because of the small overhead required. The registry frequently contains lots of easy to access configuration information for many applications. A discovery can check whether a particular key or value exists, or it can collect the data from any value. Collected values may be either only collected for a property or compared to some known value to determine whether discovery data should be created.

For example, a discovery may have to check for a particular registry key to indicate that its application is installed on the local computer. If only a particular version of that application is supported by the management pack, a registry value holding the application version may be inspected to determine whether an instance should be created. Other values in the registry may then be collected to populate properties of the discovered instance.

WMIWMI can provide lots of information about a computer or Windows operating system components. It can also be the source of information for any application that includes a WMI provider exposing parts of the application through a WMI interface. A discovery can run a WMI query to determine whether instances of a particular WMI class exist and to collect the properties from any returned instances.

For example, a particular management pack might collect information from the computer BIOS, that can be obtained by using the WMI32_BIOS WMI class.

ScriptsIf a discovery requires data inaccessible from the registry or WMI, or if the discovery needs more complex logic than those discoveries provide, a discovery script must be used. A discovery script can be written in any language that can access the MOM.ScriptAPI COM object that is installed with the Operations Manager agent. The most typical scripts are written either in a language supported by Windows Script Host (VBScript or Jscript by default) or Windows PowerShell.

59

Discovery scripts that use VBScript or Jscript can be created by using modules in management pack libraries and wizards in the Authoring console. Modules are available for discovery scripts that are written in Windows PowerShell in Operations Manager R2 but are not supported by wizards in the Authoring console. A custom discovery would have to be created by using the appropriate module.

Any management pack requiring support by Operations Manager 2007 SP1 cannot use the Windows PowerShell modules because they are only installed with the Operations Manager R2 agent. In this case, custom discoveries that use Windows PowerShell can be created by using a module that runs a command, configuring it to build the powershell.exe command line and starting the discovery script.

Discovery TargetsThe target of a discovery determines where the discovery will run. Any agent managing an instance of the target class will run the discovery. In order to minimize overhead, the target for a discovery should represent the most specific class where the class being discovered may potentially be found.

For example, a discovery determining whether an application is installed on a computer may have to target a broad class, such as the Windows Operating System class, because the application could be potentially installed on any computer in the environment. Another discovery responsible for a particular component of that application could target the newly discovered application class, because the component would presumably never be discovered on a computer where the application wasn’t installed.

Discovering RelationshipsIn addition to instances of classes, instances of relationships must also be discovered. Hosting relationships are discovered automatically as part of the discovery of hosted objects, but containment relationships must be explicitly discovered.

Hosting RelationshipsBecause a hosted object cannot exist without its hosting parent, the parent object must either already have been created before the child can be discovered or must be discovered at the same time as the child. Discovering the objects at the same time means that both classes are discovered by the same discovery with instances included in the same set of discovery data.

Instances of hosting relationships are not explicitly discovered but are created automatically when a hosted object is discovered. If the object is hosted, the discovery data must provide the key property of any of its hosting parents in addition to the key property for any instances that it includes. This is sufficient information to identify the source and target objects of the hosting relationship so that it can be automatically created.

For example, a class may be based on the Windows Computer Role class representing a particular application installed on a computer. Because the Windows Computer Role class is

60

hosted by the Windows Computer class, the application’s class is also hosted by the Windows Computer class. The discovery for the class must provide the computer name because this is the key property of the Windows Computer class, that is, the hosting parent of the object being discovered. If the class also had its own key property, this would have to be included. If it did not have a key property, the computer name would be the only key property that would have to be provided.

Conceptual view of class instance

Containment RelationshipsUnlike hosting relationships, containment relationships must be explicitly discovered. The source and target objects for the relationship instance must either already have been discovered or be included in the same discovery. Containment relationships between specific objects are usually discovered with a discovery script. The resulting discovery data specifies the GUID of the relationship in addition to the source object and target object for the relationship instance that should be created.

Conceptual view of relationship instance

61

Populating GroupsGroups are populated by creating instances of the containment relationship between the group objects and its members. You can do this by using a discovery script like other containment relationships, or a special group population module can be used. Group population is different from other kinds of discoveries because it is performed on the Root Management Server by using information from the Operations Manager database instead of running on the agent that uses data that is collected from the local computer. This process is typically easier and more efficient than manually creating the containment relationship instances.

The Authoring console does not provide a wizard for implementing group population. This kind of discovery must be created manually by using a special Group Populator module.

Proxy DiscoveriesMost discoveries discover objects managed by the local agent computer. There are scenarios where an agent may have to perform discovery of a particular object or set of objects that are either unhosted or hosted by another computer. An example of this scenario may include collecting information from a Configuration Management Database. In this case, one agent might be responsible for running a discovery that uses a script to perform queries against information that is stored in the database. This information is then used to create instances and set property values for objects that are located on other computers. The agent running the discovery is acting as a proxy for the other agents.

The proxy scenario is typically performed with a script because other kinds of discovery are typically unable to access the required data or perform the required logic. As previously discussed, discovery data requires the key property of each discovered object and any of their hosting parents. In the proxy scenario, the hosting computer will differ from the agent running the discovery, and the discovery merely needs to provide this computer name in the discovery data. The object will be discovered and managed by the specified agent.

In order to perform discovery on behalf of another agent or discovery of an unhosted object, the agent running the discovery must have its proxy setting enabled. If this proxy setting is not enabled, the discovery will generate an error, and the discovered instances will not be created. The proxy setting is configured in the Agent Properties, which are accessed from the Administration pane in the Operations console.

Discovery on DemandMost discoveries are performed on a scheduled basis. New objects or changes to existing objects are not discovered until the next time that the discovery for the particular class is scheduled to run. Discoveries with intervals that are too frequent put too great a load on the agent performing discovery, whereas discoveries that are too infrequent can take too much time to recognize such changes.

Discoveries can be designed to be executed in response to a particular event, assuming that an application generates such an event in response to a configuration change. In this case, the

62

discovery could be run immediately after the configuration change and may not have to be scheduled. A discovery could also be designed to be run on demand by a user through an Agent Task.

The Authoring console provides wizards for scheduled discoveries only. Discoveries that run on demand or in response to an event may be created by using the Authoring console, but they must be created with custom discoveries that use custom modules.

See AlsoDefining Discoveries

Creating Discoveries

Discovery ScriptsDiscovery scripts are used when complex logic is required for discovery of a particular class or relationship, or when required information cannot be accessed from the registry or WMI. The script collects data from information on the agent and creates discovery data by using the MOM.ScriptAPI object that is installed with the Operations Manager 2007 agent.

Creating Discovery ScriptsDiscovery scripts may be written in any script language that can access the MOM.ScriptAPI object. The most common languages used are VBScript, JScript, and Windows PowerShell. Discovery scripts that use VBScript or Jscript can be created by using modules in management pack libraries and wizards in the Authoring console. Modules are available for discovery scripts that are written in Windows PowerShell in Operations Manager R2 but are not supported by wizards in the Authoring console. A custom discovery would have to be created using the appropriate module.

Management packs that require support by Operations Manager 2007 SP1 cannot use the Windows PowerShell modules, because they are only installed with the Operations Manager R2 agent. Discovery scripts that use Windows PowerShell can be created by using modules that run a command and configure them to build the powershell.exe command line.

Required ArgumentsDiscovery data must include the GUID of the target object that the discovery is running against and the GUID of the discovery itself. The value for each is required when the script calls the CreateDiscoveryData method. They will be unknown when the script is written. However, they can be accessed through variables and sent into the script through arguments. The GUID of the discovery is accessed by the $MPElement$ variable, whereas the GUID of the target object is accessed with $Target/Id$.

63

Other arguments can be sent into the script as required for the particular discovery.

MPElement VariablesDiscovery data specifies the classes and relationships being discovered in addition to their properties. The data must include the GUID for these values instead of simply their names. The GUID of any management pack element can be retrieved by using an $MPElement variable, and these are used frequently in discovery scripts.

The syntax of an $MPElement variable is as follows:

$MPElement[Name="ElementName"]/SubElementName$

Example uses of the variable are as follows:

Class in the same Management Pack file.

$MPElement[Name="MyMP.MyClass"]$

Class in a different Management Pack file.

$MPElement[Name="Windows!Microsoft.Windows.Computer"]$

Class property in the same Management Pack file.

$MPElement[Name="MyMP.MyClass"]/MyProperty$

Class property in a different Management Pack file.

$MPElement[Name="Windows!Microsoft.Windows.Computer"]/PrincipalName$

Basic Script StructureThe following sample shows a discovery script with the following characteristics.

The script discovers a single instance of a class named MyMP.MyClass. The class is hosted by Windows Computer. The class has a key property named Name. The class has a non-key property named Version.

SourceId = WScript.Arguments(0)

64

ManagedEntityId = WScript.Arguments(1)

sComputerName = WScript.Arguments(2)

Set oAPI = CreateObject("MOM.ScriptAPI")

Set oDiscoveryData = oAPI.CreateDiscoveryData(0, SourceId, ManagedEntityId)

Set oInstance = oDiscoveryData.CreateClassInstance("$MPElement[Name='MyMP.MyClass']$")

oInstance.AddProperty

"$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", sComputerName

oInstance.AddProperty "$MPElement[Name='MyMP.MyClass']/Name$", "svr01.contoso.com"

oInstance.AddProperty "$MPElement[Name='MyMP.MyClass']/Version$", "1.0"

oDiscoveryData.AddInstance(oInstance)

oAPI.Return(oDiscoveryData)

Script BreakdownDetails of each section of the script are discussed here.




The first two lines of the script accept the GUID for the discovery and the target object. These lines should stay unchanged in most discovery scripts, but they will typically be followed by other variables accepting arguments specific to the particular script. The next line gets a value for the computer name that is used for the key property of the hosting Windows Computer object.



The next two lines create a discovery data object by using the provided GUIDs. These lines will also be unchanged in most discovery scripts. The main purpose of the rest of the script will be to add detail to the discovery data object by using data collected from the agent computer.

65

Set oInstance = oDiscoveryData.CreateClassInstance("$MPElement[Name='MyMP.MyClass']$")

After the discovery data object is created, it can be used to create a new class instance. This requires an $MPElement variable that uses the name of the class. This variable translates to the appropriate GUID representing the class. This line would presumably be preceded by code that would collect data from the agent computer to determine whether one or more instances should be created in addition to populating variables for the instances properties that are populated with the following lines.

oInstance.AddProperty

"$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", sComputerName

oInstance.AddProperty "$MPElement[Name='MyMP.MyClass']/Name$", sName

oInstance.AddProperty "$MPElement[Name='MyMP.MyClass']/Version$", sVersion

With the instance now created, its properties can be populated. Any key properties of the class being discovered and the key properties of any of its parents must be provided. Values for other properties are optional. In this example, the class being discovered is hosted by Windows Computer and the key property of that class is added to the instance.


After the instance is created and its properties populated, the instance is added to the discovery data object. If the script created multiple instances, a loop could be used that added each instance as it was created and configured. If this line is left out of the script, the instance is never added to the discovery data object.


After all instances are created and configured, the discovery data is returned into the workflow. This line is required, and without it the discovery data is discarded when the script ends. A discovery script may output only a single set of discovery data. If multiple instances are being discovered, the line appears only one time at the end of the script after all instances are added.

Windows PowerShellThe following script is the Windows PowerShell equivalent of the VBScript sample discovery script shown previously. Both scripts use the same MOM.ScriptAPI object and methods.

66

param($sourceId,$managedEntityId$computerName)

$api = New-Object -comObject 'MOM.ScriptAPI'

$discoveryData = $api.CreateDiscoveryData(0, $sourceId, $managedEntityId)

$instance =

$discoveryData.CreateClassInstance("$MPElement[Name='Demo.StoreApp.CentralQueue']$")

$instance.AddProperty("$MPElement[Name='Windows!Microsoft.Windows.Computer']/

PrincipalName$", $computerName)

$instance.AddProperty("$MPElement[Name='MyMP.MyClass']/Name$", "svr1.contoso.com")

$instance.AddProperty("$MPElement[Name='MyMP.MyClass']/Version$", "1.0")

$discoveryData.AddInstance($instance)

$discoveryData

Other than obvious syntax, there are two primary differences between the VBScript and Windows PowerShell scripts, as follows.

param($sourceId,$managedEntityId)

The first difference is in the means of retrieving script arguments. Windows PowerShell can accept positional arguments as VBScript does, but named parameters that use the param command better support the Windows PowerShell modules included with Operations Manager 2007 R2. These modules let parameters be separately specified in the module configuration where they are retrieved by the script as named parameters.

$discoveryData

Another important difference is the way that the discovery data is returned to the workflow. In VBScript, the Return method of the MOM.ScriptAPI object is used. In Windows PowerShell , this method will not return the data correctly. The Return method sends the discovery data to the Standard Out (StdOut) stream, whereas Windows PowerShell requires the data to be sent to the output pipeline. This is achieved by typing the discovery data variable on its own line.

Empty Discovery DataIf a discovery script does not return discovery data, an error will be generated on the agent. Even if no instances of the class are found, empty discovery data should be created and returned by the script. If no data is returned, Operations Manager cannot determine if any instances that were previously discovered have now been removed.

67

See AlsoHow to Create a Script Discovery

Service Model Design OverviewDesigning a service model for an application consists primarily of defining a set of classes to represent the different application components and relationships between those elements to support the desired monitoring functionality. Simple applications may be adequately monitored with a model as basic as a single class. An application that consists of little more than a single Windows service, for example, may have only one class that is discovered on the appropriate computers and can act as the target for rules and monitors by using information generated by the application.

More complex applications will typically require multiple classes to represent different application components. Applications that may be installed across multiple computers may also benefit from classes used for consolidated health rollups for the application itself and for different application features composed of multiple components.

In This SectionDefining Classes and Relationships

Basic process for defining a set of classes and relationships to represent the application.

Choosing a Base ClassCriteria and recommendations for selecting a base class for custom classes.

Defining DiscoveriesBasic process for defining discoveries for each class in a service model.

Practices to AvoidCommon practices to avoid when designing a service model.

68

Defining Classes and RelationshipsThe basic strategy of selecting a set of classes to provide a model for an application is to identify the application’s different components and define an appropriate class to represent each one. Each class definition will include its base class, its relationships with other classes, and a set of properties to hold the values required for the different monitoring scenarios targeted at the class.

Because a service model can be created for any kind of application on various computing platforms or even to support monitoring of physical devices, it is difficult to provide a single process that applies to all scenarios. The following guidance applies to designing a model for a typical application that is running on one or more Windows-based servers. Many applications fit into this basic architecture and can have an effective model designed with this fairly simple process. This basic strategy can also be extrapolated to other kinds of applications.

Each class listed here includes a short description of the base class that is typically used. Additional detail on the implications of the base class and criteria for selecting an appropriate one are provided in Choosing a Base Class.

Define Application RolesThe first class that should be defined is one to represent the installation of the application on a particular computer. This can be known as an application role. For many applications, a single class will be sufficient for this purpose. However, more complex applications may have multiple classes to represent different kinds of servers or different core services that require unique monitoring. This class is typically hosted by the Windows Computer class so that it can be discovered on any agent where the application is installed.

One thing to consider in this step is which application roles might be installed on separate computers. One function of a class is to act as a target for workflows specific to the application that has workflows targeted at the class running on the agent managing an instance of that class. If two components of an application will always be installed on the same computer, they can frequently be represented by a single class. If there is a potential for them to be installed separately however, they should each have their own class so that any targeted workflows will run on the appropriate agent.

The DNS 2008 Server management pack provides an example of a single class used to represent an application. An instance of the DNS 2008 Server class is discovered on any computer that is running Windows 2008 Server that has DNS installed. Any monitors and rules specific to the DNS Server class can be targeted at this class in addition to discoveries for identifying other DNS components that may be installed on the server.

DNS 2008 Server class

69

The SQL Server 2008 management pack, on the other hand, has four separate classes for its primary functions: the DB Engine class, the Analysis Services class, the Integration Services class, and the Reporting Services class. These are distinct services in SQL Server that will each have unique monitoring and can be installed separately from another. SQL Server requires a separate class for each role in order to independently measure the health state of the different components and use them as targets for unique monitoring scenarios.

Computer Role classes for SQL Server 2008

The base class used for application roles will typically be the Windows Computer Role class or the Windows Local Application class. These are both hosted by the Windows Computer class. Classes based on the Windows Computer Role class are considered a primary function of a server, and their health state will be automatically rolled up to their hosting computer. The Windows Local Application class is intended to represent smaller applications, and its health state will not roll up to the computer.

Computer role classes typically do not have a key property, because they usually have only a single instance on any given computer. There are exceptions to this standard, however, for applications that can have multiple instances installed. SQL Server, for example, can have

70

multiple instances installed on a single computer, and the class for each role has a key property for the instance name.

Define Application Components for Each Application RoleAfter each of the application’s primary roles are identified (a single role for a simple application), identify those components hosted by each role that require a distinct health state. The application role alone may be sufficient for a simple application, but more complex applications may benefit from one or more additional classes for additional components of the application. These components will typically be hosted by one of the computer role classes that are defined in the previous step or by another application component.

Application components typically share a one-to-many relationship with their hosting class. In other words, a single computer role instance will usually hold multiple instances of a single application component. If only a single instance of the application component is expected, it is frequently of minimal value to create a unique class for it.

For example, the DNS Server class hosts a class named DNS Zone. Each instance of the DNS Zone class represents the different zones that can be installed on a single DNS server. Creating a separate class lets each zone have its own health state.

DNS Server classes

Another example is the Windows Server 2008 Internet Information Services 7.0 management pack, which defines a class named IIS 7.0 Server Role that is discovered on any computer that has IIS 7.0 installed. This class hosts classes representing the different kinds of components that may be installed: Web server, FTP server, and SMTP server. Each IIS installation may have any combination of these installed. Each Web server, in turn, may have multiple Web sites that are

71

represented by the IIS 7.0 Web Site class. In this case, the server role hosts the Web server, and the Web server hosts the Web site. The same is true for FTP sites.

Application Component classes for IIS 7.0

Application component classes should typically use the Windows Application Component class for a base class. This abstract class is unhosted. This means that the class inheriting from it can create its own hosting relationship with the application’s computer role. It will typically require a key property, because multiple instances of the class are usually expected for the hosting role.

Identify Dependencies Between ClassesThe health state of any class can depend on the health state of another as long as they share a hosting or containment relationship. For example, when a monitor targeted at an application role class reports a negative health state, the computer that is hosting the object can also show a negative state. Similarly, the health of an application role can depend on any of the application components that it hosts.

Most of the health dependencies required for a service model will already exist by the time that classes and hosting relationships are defined. Containment relationships have to be defined for any additional classes whose health depends on the health of another class that it does not already share a hosting relationship with.

72

For example, in the Windows Server 2008 Internet Information Services 7.0 management pack, the IIS 7.0 Web Server class hosts classes called IIS 7.0 Web Site and IIS 7.0 Application Pool. Web sites and application pools are both components that can be created independently on a Web server, and any particular instance of one can exist without any particular instance of the other. However, one or more Web sites can be configured to use a particular application pool, and the health of the Web site will depend on the health of any application pool that it is configured to use. In order to support this dependency, the management pack includes a containment relationship between the IIS 7.0 Web Site class and the IIS 7.0 Application Pool class.

Containment relationship between IIS 7.0 classes

Define Application ClassDistributed applications typically define a top-level class to represent the application itself. Containment relationships are defined between this class and each of the application’s role classes (which in turn, host the application’s components). This provides an overall health state for the application. All applications will not have such a class. It is created only for those applications where a single consolidated health state for all the application’s roles and components in a particular environment is relevant.

For example, the Active Directory management pack includes a class named Active Directory Topology Root. This represents the overall Active Directory installation in a particular

73

environment. This class contains classes for the Active Directory Forest, Sites, and Domains so that it can provide an overall health state for the environment.

The SQL Server management pack, by contrast, does not have a class representing the whole environment. The nature of SQL Server is such that there is no concept of an overall environment but instead distinct installations on different servers. There would be minimal value in providing an overall measurement for the health of all instances of SQL Server.

The application class should typically be a singleton. Because it represents the overall application installation in the environment, there should not be a requirement for multiple instances of it. If the class is based on the Distributed Application class, it will be included in the list of Distributed Applications in the Operations console.

GroupsThe final step in the service model design is to define any required groups. Groups are singleton classes that contain a collection of other objects. They can be useful in a service model for different reasons, as detailed here.

Health RollupsGroups can be used for a health rollup for instances of a particular class. For example, a distributed application may include multiple computers that have a particular computer role installed. In addition to a health state for each computer role instance and a health state for the whole application, a health state may be required for all instances of the particular role. This functionality is supported by creating a group that contains all instances of the class to consolidate.

An effective exercise of identifying any required health rollup groups is to draw the desired diagram view for the application. This should include all the classes created in the previous steps. If these classes are insufficient to create the required diagram view, health rollup groups can be defined to complete the requirements.

Rollup of health from classes to containing group

74

Groups used for health rollups can be based on either the Instance Group class or the Computer Role class. If based on the Instance Group, they are the same as any other instance group and will appear in the Groups list in the Authoring pane of the Operations console. If they are based on the Computer Role class, they will not appear in this list.

Instance GroupsInstance groups can be used to distinguish a set of objects that do not have a unique class for monitoring. These are the same as typical instance groups that a user can create in the Operations console.

For example, the Active Directory 2008 management pack includes a group named RODC Group that contains all read-only domain controllers. These are instances of the Active Directory Domain Controller Server 2008 Computer Role class for which the Read-Only Domain Controller property is true. This group is then used for overrides that disable rules that are not relevant to a read-only domain controller. One alternative would be to create a special class for read-only domain controllers inheriting from the Domain Controller class. However, it was determined that there were not enough unique monitoring scenarios for the read-only domain controller to warrant specializing the Domain Controller class. The RODC Group is sufficient to achieve the desired functionality.

These groups are typically based on the Instance Group class. Any group based on this class will appear in the Groups list in the Authoring pane of the Operations console.

Computer GroupsComputer groups contain a collection of computer objects on which another object exists. This is distinctly different from the instance groups containing the application objects themselves. This type of group can be used to support such group functionality as views and user roles for the computers hosting a particular application.

For example, the SQL Server management pack includes a group called SQL 2008 Computers that contains all computers with at least one SQL Server 2008 component installed. This can be used to provide a database administrator access to the servers hosting SQL Server through a user role or a view of all computers that are running instances of SQL Server in a state view.

Computer groups for SQL Server 2008

75

Computer groups are based on the Computer Group class. Any group based on this class will appear in the Groups list in the Authoring pane of the Operations console.

See AlsoClasses

Relationships

Choosing a Base Class


Choosing a Base ClassEach class that is defined in the service model must have a base class, and selecting the appropriate one is important to achieve the expected operation of the class in the overall service model. The base class may be selected from a class available in a management pack library or an abstract class that is defined in your management pack.

Criteria for Selecting a Base ClassThe following should be considered when you select a base class for a particular class. For more information, see the links here.

InheritanceA class will inherit various characteristics of its base class. These characteristics affect which base classes you can use from management pack libraries and which abstract classes that you might create to have other classes inherit from.

76

PropertiesTypically, abstract classes in management pack libraries will not have properties other than the Display Name property inherited from the Entity class. Abstract classes that are defined by your own management pack may define properties that are inherited by other classes. This saves the lower level classes from each replicating the same property definition.

Conceptual view of property inheritance

RelationshipsIf a class is hosted, any class that uses it as a base class will be hosted by the same parent class. For example, the Windows Computer Role class is frequently used as a base class and is hosted by the Windows Computer class. Any classes that use the Windows Computer Role class as a base class will also be hosted by the Windows Computer class. If a class is to be hosted by a class other than the Windows Computer class, it must use another base class, such as the Windows Application Component class, which is unhosted. Because that base class is unhosted, the class will either remain unhosted or have a custom hosting relationship that is defined for it.

Conceptual view of relationship inheritance

77

MonitoringA class will inherit any monitoring targeted at its base class. This is actually how the standard set of aggregate monitors (Availability, Performance, Security, and Configuration) is applied to all classes. These monitors are applied to the Entity class in the System library. Because all classes inherit from this class, all classes inherit those aggregate monitors.

Conceptual view of workflow inheritance

Logical GroupingIn addition to inheritance, use of a custom abstract class in your management pack can help in logically grouping common classes. For example, you may have multiple kinds of computer roles in the application that will each inherit from the Windows Computer Role class. Even if there will be no common monitoring between the classes, there is still value in creating a single abstract class that will act as a base class for individual classes representing each role. This would enable such functionality as creating a single view that targets the abstract class and which would include all computer roles in the application. This also allows for easy specification of all computer roles for criteria in groups and overrides. It basically gives other management pack elements the option of directly targeting a single specific class or all the related classes, depending on the particular scenario.

Side EffectsDifferent base classes in management pack libraries may have special functionality that is specific to that class. For example, any class that uses the Distributed Application class as a base class is considered a distributed application and will be included in that view in the Operations console. Some classes in the management pack libraries are intended for internal purposes only and should not be used by custom management packs because of unintended effects.

Instead of individually documenting all classes, you should limit your use of abstract classes from the management pack libraries to the list of common base classes here. Any side effects from the particular class are described in this table.

78

Custom Base ClassesRather than using only abstract classes from management pack libraries, it is a common strategy to create abstract classes within your management pack for other classes to inherit from. Such a class can provide the previously discussed benefits of inheritance and logical grouping for similar classes in your management pack.

For example, the SQL Server management pack includes four classes for each of its primary server roles. Each should inherit from the Windows Computer Role class and be hosted by the Windows Computer class. However, instead of directly inheriting from this class, an abstract class named SQL Role is created based on the Windows Computer Role class. The individual computer role classes are then based on this custom class.

SQL Server Computer Role Classes

With this strategy, the management pack can easily include views by using the SQL Role class as a target that displays information for all SQL-related services. Also, because each of the SQL services can have multiple instances installed on a single computer, they require a key property. Instead of including this property on each class, it is defined on the SQL Server Role class and is inherited by the other classes. Each class then adds additional properties specific to that service.

79

See AlsoClasses

Relationships



Recommended Base ClassesThe following table provides the list of classes from management pack libraries that should be used as the base class for classes that are defined in your management pack. They may be used directly as the base class for concrete classes or for custom abstract classes that other classes in your management pack will inherit from. This set of classes will be sufficient to achieve almost any scenario required by any service model.

Class ID Display Name

Library Hosting Relationship

When to Use

Effects

Microsoft.Windows.ComputerRole

Windows Computer Role

Microsoft.Windows.Library Hosted by Windows Computer.

Indicates a primary role of a server.

Health automatically rolled up to computer.

Microsoft.Windows.LocalApplication

Windows Local Application

Microsoft.Windows.Library Hosted by Windows Computer.

Application that is running on a computer but not the primary server role.

Health not automatically rolled up to computer.

Microsoft.Windows.ApplicationComponent

Windows Application

Microsoft.Windows.Library Unhosted

A component of an

A hosting relationship can be created

80



When to Use

Effects

Component

application.

by using another class, typically based on ComputerRole or LocalApplication.

System.Service Distributed Application

System.Library Unhosted

Represents an application for health rollup.

Instances listed in the Distributed Applications view.

System.ApplicationComponent

Application Component

System.Library Unhosted

Used for application components not hosted by a computer that is running Windows.

Microsoft.SystemCenter.InstanceGroup

Instance Group

Microsoft.SystemCenter.InstanceGroup.Library

Unhosted

Singleton

Base class for groups of instanc

Included in the Groups list in the Operations console.

81



When to Use

Effects

es of one or more classes.

Microsoft.SystemCenter.ComputerGroup

Computer Group

Microsoft.SystemCenter.Library

Unhosted

Singleton

Base class for computer groups.

Included in the Groups list in the Operations console.

System.Group Group System.Library Unhosted

Singleton

Base class for groups used for health rollup.

Not included in the Groups list in the Operations console.

Defining DiscoveriesAfter a set of classes and relationships is defined for an application, a method of discovering each must be defined. No instances of a class will be available for monitoring in Operations Manager until they are discovered.

Identifying Discoveries for Each ClassThere are three basic questions that must be answered for each class requiring discovery.

What source or sources hold the data required to determine whether an instance should be created and to populate its properties? This defines the kind of discovery.

What agent hosts the required data source? This defines the target of the discovery. How frequently should the discovery be run? This defines the interval of the discovery.

82

Basic Discovery StrategyThe discovery process for an application model composed of multiple classes will typically be performed in multiple steps, with each step including one or multiple discoveries. A basic set of classes is first discovered to identify the agents where the application is installed. These classes act as targets for successive discovery of other classes.

For the basic model described in Defining Classes and Relationships, discovery can typically be performed in three basic steps.

1. Discover application role classes to identify those agents with the application installed. This is typically performed with registry discoveries targeting a broad class, such as Windows Operating System.

2. Discover application components hosted by each role. This is typically performed with WMI or script discoveries targeting the hosting role class.

3. Populate groups. This is typically performed with group population discoveries targeting the group classes themselves.

Application RolesThe first step in the discovery process for an application model with multiple classes is typically to identify which agents the application is installed on. Because application installations are identified by the application role classes based on the Windows Computer Role class or the Windows Local Application class, these are typically the first classes discovered.

These discoveries will typically target a broad class, such as Windows Operating System, because the application could be installed on any computer in the environment. There is no way to know which computers the application is installed on until the discovery runs. If the application can only be installed on a particular version of Windows or if it can only be installed on a server or a client operating system, a slightly more refined target could be used. Examples include the Windows Server Operating System class for an application that could only be installed on a server or the Windows Server 2008 class for an application that could only be installed on a computer that is running Windows Server 2008.

Because discoveries of application roles are targeted at such a broad class, only registry discoveries should be used because they consume minimal resources. A heavier kind of discovery, such as a script, would put an unnecessary load on multiple computers that do not have an instance of the class being discovered. For most applications, a registry key is sufficient to at least confirm that the application exists. If certain properties must use another data source, such as a script, an additional discovery for the same class could be added that targeted to the class itself. This would guarantee that the more resource-intensive process runs only on those agents where it is required.

Application ComponentsAfter the application’s roles are discovered, the newly discovered objects can be used as targets for discoveries identifying application components. These classes are typically hosted by one of the application’s roles so that the hosting parent class can be used for the target. In addition to

83

making sure that the discovery only runs on those agents where instances of the class being discovered are likely to be located, using the hosting parent as a target provides access to the hosting parent class’s properties by using $Target variables.

For example, suppose that a class named MyLocalApplication hosts a class called MyApplicationComponent. When an instance of MyApplicationComponent is discovered, it must provide a value for any key properties of MyLocalApplication because that is the class’s hosting parent. If the discovery for MyApplicationComponent targets MyLocalApplication, the discovery has access to all the properties of MyLocalApplication by using $Target variables.

Discoveries for application components typically use either WMI or script discovery. Registry discovery can be used if information about the application is stored there, but frequently another data source is required for this information. If a WMI provider for the application is available and the discovery does not require complex logic, a WMI discovery can be used. If more complex logic is required, a script can be used to access information from the registry, WMI, or any other data source that can be accessed from a script.

Group PopulationAfter all other classes are discovered, group population may be performed because this discovery uses instances and properties that have already been discovered. Group population discoveries target the group class itself. Because groups are unhosted, they are managed by the Root Management Server. Any discoveries targeted at a group class will run on the RMS. This is appropriate because this is where group population discoveries are required to run so that the discovery can access information in the Operations Manager database.

Discovery IntervalsMost discoveries are run at set intervals, and this interval must be specified when the discovery is created. If the interval is too long, the user may have to wait an extended time until new instances or changes to existing instances are discovered. For example, a particular discovery for an application may be configured to run one time every 24 hours. When a new copy of the application is installed on a computer, it may take that long until the new instance appears in Operations Manager 2007 and monitoring begins.

Too short a time interval puts too much overhead on agents while providing minimal value. Also, if instances of the discovered class are expected to change frequently enough to warrant an aggressive discovery schedule, the design of the class may violate the best practices for classes as described here.

The following table provides recommended intervals for different kinds of discoveries.

Discovery Type Minimum Interval Comments

Registry 5 minutes The interval for registry discoveries can be set very low with minimal effect, assuming

84

Discovery Type Minimum Interval Comments

that properties of the discovered objects rarely change. Because registry discoveries typically discover classes that change so rarely however, an interval of as much as 24 hours is often used.

WMI Query 4 hours Avoid the use of wildcard characters (*) in the query to return all properties. Should not be targeted at a broad class, such as Microsoft Windows Operating System.

Script 4 hours Should not be targeted at a broad class, such as Microsoft Windows Operating System.

See AlsoDiscovery

Creating Discoveries

Practices to AvoidThe following are common mistakes that are made when you design a service model for an application.

Classes

Creating Too Many ClassesCreating too many classes can result in needless complexity with minimal value. A good rule is to use the least number of classes to achieve the desired monitoring results. Other than abstract classes, if a class is not going to be the target of any rules or monitors, it probably should not be created. Also, if two application components are similar, consider modeling them with a single class, possibly by using a property that can hold the values for any differences.

85

Creating Classes for Volatile ObjectsClasses should represent objects that are fairly static. They are created and removed by administrators of the managed computers and not created frequently through automated processes. Examples include an application installed on a server, a database, and a Web site. Generally, a new instance of a class should not be expected most of the times that a discovery for that class runs. Too much volatility can result in excess load on the Root Management Server and lead to error messages from too frequent updates to the Operations Manager database. Other than performance considerations, it is also typically not useful to have health measurements for objects that appear for a short time.

For example, consider a Voice over IP application. You may want to create a class representing a telephone call. A monitor targeted at the class would measure the quality of each call and report an error state if there is a decrease in the quality level of the call. This is a questionable design, because telephone calls are constantly created and destroyed. In fact, discovery for the class would have to be run very frequently; otherwise, most of the calls would never be discovered. For those calls that were discovered, by the time that an administrator was able to respond to a message generated by a monitor, the telephone call would likely have ended.

A better solution for this scenario would be to target monitors at a class created for the application installation on the server. It might be used as a target for a monitor measuring the health of calls and detecting any error events that indicate a problem with a particular call. Any health state would be associated with the application itself, and any alerts could include an identifier for a particular call should a problem are detected.

Properties that Update Too FrequentlyProperties should change rarely after they are first discovered. After initial discovery of an object, discovery data is sent from the agent to the Root Management Server only when a configuration change is detected. If properties frequently change, discovery data is sent to the Root Management Server every time that discovery is run and results in excess load. Frequent updating can also affect configuration reports that detect changes in property values.

The most common cause of this issue is a model that stores performance data or health state in a property, which is not a recommended practice. For example, if an object performs some kind of replication, you might consider creating a property to hold the last replication time. But this kind of performance data should not be stored in a property. A better solution would be to collect a numeric value, such as the number of minutes or hours since the last replication, as performance data. This data could be collected with a rule for tracking it on a graph in the console or in a report. A monitor could also be created comparing the collected performance value with a numeric threshold to set the health state according to the time since the last successful replication.

Discoveries

86

Too Frequent DiscoveriesNew objects installed on a managed computer or changes to existing objects will not be recognized by Operations Manager until the next time that the discovery for the class runs. Frequencies of only a few minutes are sometimes used to reduce the time that is required for such additions and changes to be detected. However, a short frequency interval increases the load on the agent running the discovery and usually provides minimal value.

Even though a particular management pack may have only a few discoveries, an agent must run discoveries from multiple management packs installed in the environment in addition to the other kinds of workflows, such as rules and monitors. Because of this, care should be taken to balance the need for quick detection of changes with a minimization of overhead.

If a particular class requires a short discovery interval because of frequent changes to the application’s components, this may indicate a health model that violates the above recommendations for volatile objects and properties that update frequently.

Script Discoveries Targeting Broad ClassesDiscoveries for some classes in a management pack will need to search across all computers in an environment (or at least a large set of computers) to identify where the application is installed. These discoveries will continue to run on a regular basis even though the application may never be installed on most of these computers.

Because of their fairly small overhead, we strongly recommended that only registry discoveries target broad classes, such as the Windows Operating System class. Script discoveries that have significantly larger resource requirements should target only those classes specific to the application that were previously discovered through the registry. This strategy means that only those computers that have the application installed are required to run the scripts. Computers without the application installed must run only registry discoveries. These have minimal resource requirements.

See AlsoDefining Classes and Relationships

Defining Discoveries

Building a Service ModelThe following sections provide walkthroughs of the activities that support the implementation of a service model.

In This Section

87

Creating Classes and RelationshipsCreate different types of classes and relationships by using the Operations Manager Authoring console.

Creating DiscoveriesCreate different types of discoveries by using the Operations Manager Authoring console.

Creating Classes and RelationshipsThe following procedures provide guidance on how to create classes and relationships in the Operations Manager 2007 Authoring console.

In This SectionHow to Create a New Management Pack

Create a new management pack by using the Authoring console.

How to Create a ClassCreate an abstract class, computer role classes, and application components.

How to Create a GroupCreate different kinds of group classes.

How to Create a Containment RelationshipCreate containment relationships for health rollup and for group membership.

How to Create a New Management PackThe following procedure describes how to create a new management pack by using the Authoring console.

To create a new management pack with the Operations Manager 2007 Authoring console 88

1. Start the Authoring console.2. Select File, and then select New.3. On the Management Pack Template page, in the Select a Management Pack

Template box, select Empty Management Pack.4. In the Management Pack Identity box, type MyMP.5. Click Next.6. On the Name and Description page, in the Display Name box, type My Management

Pack.7. Click Create.8. Select File, and then click Save.9. Make sure that the File Name box has MyMP.xml, and then click Save.

How to Create a ClassThe following procedures explain how to create classes in the Operations Manager 2007 Authoring console. Before you perform these procedures, you must first complete the prerequisite procedure, How to Create a New Management Pack, in which you first create a new management pack before adding the classes shown here.

The classes created in the following procedures have these characteristics:

Abstract class based on Windows Computer Role named MyMP.MyComputerRoleBase. Class has a single non-key property named Version and no key property.

Two classes based on the abstract class named MyComputerRole1 and MyComputerRole2.

Single application component hosted by a computer role called MyApplicationComponent. Class has a single key property named ComponentName.

1. In the Authoring console, select Service Model, and then select Classes.2. Right-click in the Classes pane, select New, and then select Windows Server role.3. In the ID box, type the name MyMP.MyComputerRoleBase.4. In the Display Name box, type My Computer Role Base.5. Click Finish.6. Right click MyMP.MyComputerRoleBase and select Properties.7. On the General tab, in the Attributes pane, select Abstract.8. On the Properties tab, do the following:

a. Right-click in the navigation pane and select Add Property.b. In the Choose a unique identifier box, type Version, and then click OK.

To create an abstract class

89

c. In the Display Name box, type Version. Because you are expecting only a single instance of this class on a computer, it does not require a key property.

d. Click OK.9. Select File, and then click Save.

1. In the Authoring console, select Service Model, and then select Classes.2. Right-click in the Classes pane, select New, and then select Custom Class.3. In the Choose a unique identifier box, type the name MyMP.MyComputerRole1, and

then click OK.4. On the General tab, do the following:

a. In the Base Class box, select MyMP.MyComputerRoleBase.b. In the Display Name box, type My Computer Role 1. Click OK.

5. Right-click in the Classes pane, select New, and then select Custom Class.6. In the Choose a unique identifier box, type the name MyMP.MyComputerRole2, and


a. In the Base Class box, select MyMP.MyComputerRoleBase.b. In the Display Name box, type My Computer Role 2. Click OK.

8. Select File, and then click Save.

1. In the Authoring console, select Service Model, and then select Classes.2. Right-click in the Classes pane, select New, and then select Windows Local

Application Component.3. On the General page, do the following:

a. In the ID box, type the name MyMP.MyApplicationComponent.b. In the Display Name box, type My Application Component.c. Click Next.

4. On the Key Properties page, do the following:a. Check the Specify a key property box. You are expecting multiple instances of

MyApplicationComponent for each instance of MyApplication, which is its hosting parent. Therefore, the class requires a key property.

b. In the ID box, replace the existing text with ComponentName.c. In the Type box, select string.d. In the Name box, type Component Name. Click Next.

5. On the Hosting Class page, do the following:a. In the Hosting Class box, type MyMP.MyComputerRole1.b. In the Hosting Relationship ID box, type

To create classes based on a custom abstract class

To create an application component

90

MyMP.MyComputerRole1HostsMyApplicationComponent.c. In the Hosting Relationship Name box, type My Computer Role 1 Hosts My

Application Component. Click Finish.6. Select File, and then click Save.

See AlsoClasses

Choosing a Base Class

How to Create a GroupThe following procedures explain how to create classes for an instance group, a computer group, and a health rollup in the Operations Manager 2007 Authoring console. Before you perform these procedures, you must first complete the prerequisite procedure, How to Create a New Management Pack, in which you first create a new management pack before adding the classes shown here.

1. Select File, and then select Management Pack Properties.2. Click the References tab.3. Click Add Reference.4. Move to the folder where the Authoring console is installed, and select

Microsoft.SystemCenter.InstanceGroup.Library.mp.5. Click in the Alias box, and change the alias to SCIG. Click OK. Any alias can be used for

the alias. A short string is typically most convenient.

1. In the Authoring console, select Service Model, and then select Classes.2. Right-click in the Classes pane, select New, and then select Custom Class.3. In the Choose a unique identifier… box, type the name MyMP.MyInstanceGroup, and


a. In the Base Class box, select Browse all classes.b. In the Management Pack Class Chooser box, select

Microsoft.SystemCenter.InstanceGroup, and then click OK.c. In the Name box, type My Instance Group.

5. In the Attributes pane, select Singleton. Click OK.6. Select File, and then click Save.

To add a reference for Instance Group Library

To create an instance group

91

1. In the Authoring console, select Service Model, and then select Classes.

2. Right-click in the Classes pane, select New, and then select Computer Group.3. In the ID box, type the name MyMP.MyComputerGroup.4. In the Display Name box, type My Computer Group.5. Click Finish.6. Select File, and then click Save.

1. In the Authoring console, select Service Model, and then select Classes.2. Right-click in the Classes pane, select New, and then select Custom Class.3. In the Choose a unique identifier box, type the name MyMP.HealthRollup, and then

click OK.4. On the General tab, do the following:

a. In the Base Class box, select Browse all classes.b. In the Management Pack Class Chooser box, select System.ComputerRole.c. In the Name box, type My Health Rollup. Click OK.

5. In the Attributes pane, select Singleton. Click OK.6. Select File, and then click Save.

See Also

Classes


How to Create a Containment RelationshipThe following procedures show how to create containment relationships in the Operations Manager 2007 Authoring console. Before you perform these procedures, you must complete the following prerequisite procedures:

How to Create a New Management Pack - Create the management pack in which the relationships will be created.

How to Create a Class - Create classes that will serve as both the source and target in relationships.

How to Create a Group - Create groups class that will serve as the source in a relationship.

The relationships created in the following procedures have these characteristics.

To create a computer group

To create a group for health rollup

92

Relationship between MyHealthRollup group class and MyComputerRole1 class. This supports a health rollup of all instances of MyComputerRole1.

Relationship between MyComputerRole2 and MyComputerRole1. This supports a health dependency of MyComputerRole2 on MyComputerRole1.

Containment relationships do not have to be created for Instance Groups or Computer Groups, because the required relationships are already defined by the classes on which these classes are based.

1. In the Authoring console, select Service Model, and then select Relationships.2. Right-click in the Relationships pane, select New, and then select Containment

Relationship.3. On the General page, do the following:

a. In the ID box, type MyMP.MyHealthRollupContainsMyComputerRole1.b. In the Display Name box, type My Health Rollup Contains My Computer Role 1.c. Click Next.

4. On the Source and Target page, do the following:a. In the Class ID (Source) box, select MyMP.MyHealthRollup.b. In the Class ID (Target) box, select MyMP.MyComputerRole1.c. Click Finish.


1. In the Authoring console, select Service Model, and then select Relationships.2. Right-click in the Relationships pane, select New, and then select Containment

Relationship.3. On the General page, do the following:

a. In the ID box, type MyMP.MyComputerRole2ContainsMyComputerRole1.b. In the Display Name box, type My Computer Role 2 Contains My Computer Role

1.c. Click Next.

4. On the Source and Target page, do the following:a. In the Class ID (Source) box, select MyMP.MyComputerRole2.b. In the Class ID (Target) box, select MyMP.MyComputerRole1.c. Click Finish.


See AlsoRelationships

To create a containment relationship for a health rollup

To create a containment relationship for dependency between two classes

93

Creating DiscoveriesThe following procedures provide guidance on how to create classes and relationships in the Operations Manager 2007 Authoring console.

In This SectionHow to Create a Registry Discovery

Create a discovery based on keys and values in the registry.

How to Create a WMI DiscoveryCreate a discovery based on a WMI query.

How to Create a Script DiscoveryCreate a discovery based on a script written in VBScript.

How to Create a Windows PowerShell DiscoveryCreate a discovery based on a script written in PowerShell.

How to Populate a GroupCreate discoveries to populate different kinds of groups.

How to Create a Registry DiscoveryThe following procedure shows how to create a registry discovery in the Operations Manager 2007 Authoring console. Before you perform this procedure, you must first complete the prerequisite procedure How to Create a Class in which you create the classes to be discovered.

The registry discovery created in this procedure has the following characteristics:

Searches for the application on all computers. Discovers a class named MyComputerRole1. The class has a single non-key property

named Version and has no key property. An instance of the class should only be created if a registry key named HKLM:\SOFTWARE\

MyApp exists. If a class is created, the version should be collected from the value HKLM:\SOFTWARE\

MyApp\Version.

94

1. Select Health Model, and then select Discoveries.2. Right-click in the right-side pane, select New, and then select Registry Filtered.3. On the General page, do the following:

a. In the Element ID box, type MyMP.Discovery.MyComputerRole1.b. In the Display Name box, type Discover Computer Role 1.c. In the Target box, select Browse all classesd. In the Management Pack Class Chooser box, select

Microsoft.Windows.OperatingSystem, and then click OK.e. In the Category box, select Discovery, and then click Next.f. Click Next.

4. On the Schedule page in the Run every box, select 1 Hours, and then click Next. Do not select the box Synchronize at: box

5. On the Computer page, notice that the Computer box should already contain the following required text: $Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$. If it does not, instead of typing the text, fill it in by selecting the button to the right side of the Computer box, selecting (Host=Windows Computer), and then selecting Network Name (Windows Computer). Click Next. This option specifies the name of the computer on which the registry will be searched. The $Target variable specified refers to the network name of the computer that is hosting the target operating system object.

6. On the Registry Probe Configuration page, do the following:a. Click Add.b. In the Edit Attribute Properties dialog box, select Key for the Object Type.c. In the Name box, type AppExists.d. In the Path box, type SOFTWARE\MyApp.e. In the Attribute Type box, select Check if exists. Click OK.f. Click Add.g. In the Edit Attribute Properties dialog box, select Value for the Object Type.h. In the Name box, type AppVersion. In the Path box, type SOFTWARE\MyApp\

Version.i. In the Attribute Type box, select String. Click OK.j. Click Next.

7. On the Build Event Expression page, do the following:a. Click Insert.b. Click the … button to the right side of the Parameter Name box, and then select

AppExists.c. In the Operator box, select Equals.d. In the Value box, type True.

To create a registry discovery

95

e. Click Next.8. On the Discovery Mapper page, do the following:

a. In the Class ID box, select MyMP.ComputerRole1.b. In the Key Properties section, click the button to the right of the Value for

Microsoft.Windows.Computer/PrincipalName, select (Host=Windows Computer), and then select Principal Name (Windows Computer). This step fills in the following text for the value: $Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName. This is a $Target variable that resolves to the computer name of the target agent.

c. In the Non-Key Properties section, in the Value for MyMP.MyComputerRoleBase\Version, type $Data/Values/AppVersion$. This step uses a $Data variable to resolve to the data that is stored in the Version registry value that is defined on the Registry Probe Configuration page. It cannot be selected from a menu because the menu can only prompt for $Target variables.

d. Click the button to the right side of the Value for System.Entity/DisplayName, select (Host=Windows Computer), and then select Principal Name (Windows Computer).

e. Click Finish.9. Select File, and then click Save.

How to Create a WMI DiscoveryThe following procedure shows how to create a Windows Management Instrumentation (WMI) discovery in the Operations Manager 2007 Authoring console. Before you perform this procedure, you must first complete the prerequisite procedure How to Create a Class in which you create the classes to be discovered.

The discovery created in this procedure has the following characteristics:

Searches for the application on all computers that have an instance of MyComputerRole1. Discovers a class named MyComputerRole2. The class has a single non-key property

named Version and no key property. An instance of the class should only be created if a file named C:\MyApp\MyApp.exe exists. If a class is created, the version should be collected from the version property on the file.

1. Select Health Model, and then select Discoveries.2. Right-click in the right-side pane, select New, and then select WMI.3. On the General page, do the following:

a. In the Element ID box, type MyMP.Discovery.MyComputerRole2.b. In the Display Name box, type Discover Computer Role 2.

To create a WMI discovery

96

c. In the Target box, select MyMP.MyComputerRole1.d. In the Category box, select Discovery, and then click Next.

4. On the WMI Configuration page, do the following:a. In the WMI Namespace box, type root\cimv2.b. In the Query box, type select name, version from cim_datafile where name ='c:\\

MyApp\\MyApp.exe'.c. In the Frequency (seconds) box, type 14400. Click Next.

5. On the Discovery Mapper page, do the following:a. In the Class ID box, select MyMP.ComputerRole2.b. In the Key Properties section, click the button to the right side of the Value for

Microsoft.Windows.Computer/PrincipalName, select (Host=Windows Computer), and then select Principal Name (Windows Computer). This step fills in the following text for the value: $Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName. This is a $Target variable that resolves to the computer name of the target agent.

c. In the Non-Key Properties section, in the Value for MyMP.MyComputerRoleBase\Version, type $Data/Property[@Name='Version']$. This step uses a $Data variable to resolve to the data returned from the WMI query. It cannot be selected from a menu because the menu can only prompt for $Target variables.

d. Click the button to the right side of the Value for System.Entity/DisplayName, select (Host=Windows Computer), and then select Principal Name (Windows Computer).

e. Click Finish.6. Select File, and then click Save.

See AlsoDiscovery

How to Create a Script DiscoveryThe following procedure shows how to create a script discovery in the Operations Manager 2007 Authoring console. Before you perform this procedure, you must first complete the prerequisite procedure How to Create a Class in which you create the classes to be discovered.

The discovery created in this procedure has the following characteristics:

Searches for class on any agent with an instance of MyComputerRole1. Discovers three instances of a class named My Application Component. The class has a

single key property called ComponentName and a non-key property named Version. The discovered class is hosted by a class named MyComputerRole1 which is hosted by the

Windows Computer class. This hosting class has no key property.

97

1. Select Health Model, and then select Discoveries.2. Right-click in the Discoveries pane, select New, and then select Script.3. On the General page, do the following:

a. In the ElementID box, type MyMP.Discovery.MyApplicationComponent.b. In the Display Name box, type Discover MyApplicationComponent.c. In the Target box, select MyMP.MyComputerRole1.d. In the Category box, select Discovery. Click Next.

4. On the Schedule page, in the Run every: box, type 4 hours. Click Next.5. On the Script page, do the following:

a. In the File Name box, type DiscoverApplicationComponents.vbs.b. In the Timeout box, type 5 minutes.c. Copy the complete following script, and paste it into the Script box.






For i = 1 to 3

Set oInstance = oDiscoveryData.CreateClassInstance("$MPElement[Name='MyMP.MyApplicationComponent']$")

oInstance.AddProperty "$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", sComputerName

oInstance.AddProperty "$MPElement[Name='MyMP.MyApplicationComponent']/ComponentName$", "Component" & i


Next


To create a script discovery

98

d. Click Parameters.e. In the Parameters box, type $MPElement$, followed by a space.f. Click Target, and select Id.g. Type a space after $Target/Id$.h. Click Target, select (Host=Windows Computer), and then select Principal Name

(Windows Computer). Make sure that there is a space between the three variables in the Parameters box.

i. Click OK, and then click Finish.6. Select File, and then click Save.

How to Create a Windows PowerShell DiscoveryThe following procedure shows how to create a Windows PowerShell discovery in the Operations Manager 2007 Authoring console. Before you perform this procedure, you must first complete the prerequisite procedure How to Create a Class in which you create the classes to be discovered. This procedure implements the same discovery as in the procedure How to Create a Script Discovery by using Windows PowerShell instead of VBScript. The Operations Manager Authoring console does not include a wizard for creating this kind of discovery. Therefore, a custom discovery must be created.

The discovery has the following characteristics:

Searches for a class on any agent with an instance of MyComputerRole1. Discovers three instances of a class named MyApplicationComponent. The class has a

single key property called ComponentName and a non-key property named Version. The discovered class is hosted by a class named MyComputerRole1 which is hosted by

Windows Computer. This hosting class has no key property.

1. Select Health Model, and then select Discoveries.2. Right-click in the Discoveries pane, select New, and then select Custom Discovery.3. In the Choose a unique identifier box, type

MyMP.Discovery.MyApplicationComponent.PowerShell.4. On the General page, do the following:

a. In the Name box, type Discover Application Components with PowerShell.b. In the Target box, select MyMP.MyComputerRole1.

5. On the Discovered Classes page, do the following:a. Click Add above the Discovered classes and their attributes pane, and select Add

To create a Windows PowerShell discovery

99

discovered type.b. In the Management Pack Class Chooser box, select

MyMP.MyApplicationComponent, and then click OK.6. On the Configuration page, do the following:

a. Select Browse for a type.b. In the Choose module type box, select

Microsoft.Windows.TimedPowerShell.DiscoveryProvider.c. In the Module ID box, type PSScript. Click OK.d. In the IntervalSeconds box, type 14400. This is the equivalent of 4 hours.e. In the SyncTime box, clear the existing text.f. In the ScriptName box, type DiscoverMyApplicationComponent.ps1.g. In the TimeoutSeconds box, type 300. This is the equivalent of 5 minutes.h. Click Edit. This starts the external editor.i. Paste the complete contents of the following script between the ScriptBody tags in

the XML. Replace any text that might already exist.

<![CDATA[

param($sourceId,$managedEntityId,$computerName)

$api = new-object -comObject 'MOM.ScriptAPI'

$discoveryData = $api.CreateDiscoveryData(0, $SourceId, $ManagedEntityId)

for ($i=1; $i -le 3; $i++)

{

$instance = $discoveryData.CreateClassInstance("$MPElement[Name='MyMP.MyApplicationComponent']$")

$instance.AddProperty("$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", $computerName)

$instance.AddProperty("$MPElement[Name='MyMP.MyApplicationComponent']/ComponentName$", 'Component' + $i)


}

$discoveryData

]]>

100

j. Add the following XML after the ScriptBody tags and before the TimeoutSeconds tags:

<Parameters>

<Parameter>

<Name>sourceID</Name>

<Value>$MPElement$</Value>

</Parameter>

<Parameter>

<Name>managedEntityID</Name>

<Value>$Target/Id$</Value>

</Parameter>

<Parameter>

<Name>computerName</Name>

<Value>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Value>

</Parameter>

</Parameters>

k. The complete configuration of the discovery in the external editor should now resemble the following:

<Configuration p1:noNamespaceSchemaLocation="C:\Users\Username\AppData\Local\Temp\MyMP.Discovery.MyApplicationComponent.PowerShell.xsd" xmlns:p1="http://www.w3.org/2001/XMLSchema-instance">

<IntervalSeconds>14400</IntervalSeconds>

<SyncTime></SyncTime>

<ScriptName>DiscoverMyApplicationComponent.ps1</ScriptName>

<ScriptBody>

<![CDATA[

param($sourceId,$managedEntityId,$computerName)


$discoveryData = $api.CreateDiscoveryData(0, $SourceId, $ManagedEntityId)

for ($i=1; $i -le 3; $i++)

101

{

$instance = $discoveryData.CreateClassInstance("$MPElement[Name='MyMP.MyApplicationComponent']$")

$instance.AddProperty("$MPElement[Name='Windows!Microsoft.Windows.Computer']/PrincipalName$", $computerName)

$instance.AddProperty("$MPElement[Name='MyMP.MyApplicationComponent']/ComponentName$", 'Component' + $i)


}

$discoveryData

]]>

</ScriptBody>

<Parameters>

<Parameter>

<Name>sourceID</Name>

<Value>$MPElement$</Value>

</Parameter>

<Parameter>

<Name>managedEntityID</Name>

<Value>$Target/Id$</Value>

</Parameter>

<Parameter>

<Name>computerName</Name>

<Value>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$</Value>

</Parameter>

</Parameters>

<TimeoutSeconds>300</TimeoutSeconds>

</Configuration>

l. Close the external editor, and save the configuration in the Authoring console.7. Click OK.8. Select File, and then click Save.

102

See AlsoDiscovery Scripts

How to Populate a GroupThe following procedures show how to create a discovery to populate groups in the Operations Manager 2007 Authoring console. Before you perform these procedures, you must complete the following prerequisite procedures:

How to Create a New Management Pack - Create the management pack to contain the classes and groups.

How to Create a Class - Create classes that will be contained in the groups. How to Create a Group - Create groups that will be populated. How to Create a Containment Relationship – Create relationships that will be discovered.

1. Select Health Model, and then select Discoveries.2. Right-click in the right side pane, select New, and then select Custom Discovery.3. In the Choose a unique identifier box, type MyMP.Discovery.Populate

MyInstanceGroup.4. On the General tab, do the following:

a. In the Name box, type Populate My Instance Group.b. In the Target box, select MyMP.MyInstanceGroup.

5. On the Discovered Classes tab, do the following:a. Click Add above the Discovered relationships and their attributes pane and

select Add discovered relationship.b. In the Management Pack Relationship Chooser box, select

Microsoft.SystemCenter.InstanceGroupContainsEntities, and then click OK.6. On the Configuration tab, do the following:

a. Select Browse for a type.b. In the Choose module type box, select Microsoft.SystemCenter.GroupPopulator.c. In the Module ID box, type GroupPopulator. Click OK.d. In the Value column of the RuleId row, type $MPElement$.e. In the Value column of the GroupInstanceId row, type

$MPElement[Name="MyMP.MyInstanceGroup"]$.f. In the Value column of the >MonitoringClass row, type

$MPElement[Name="MyMP.MyComputerRole1"]$.g. In the Value column of the >>RelationshipClass row, type

$MPElement[Name="SCIG!Microsoft.SystemCenter.InstanceGroupContainsEntities"]$. If an alias other than

To populate an instance group

103

SCIG is used, this string should be replaced with the appropriate alias.7. Click OK.8. Select File, and then click Save.

1. Select Health Model, and then select Discoveries.2. Right-click in the right-side pane, select New, and then select Custom Discovery.3. In the Choose a unique identifier box, type

MyMP.Discovery.PopulateMyComputerGroup.4. On the General tab, do the following:

a. In the Name box, type Populate My Computer Group.b. In the Target box, select MyMP.MyComputerGroup.

5. On the Discovered Classes tab, do the following:a. Click Add above the Discovered relationships and their attributes pane, and

select Add discovered relationship.b. Select Microsoft.SystemCenter.ComputerGroupContainsComputer. Click OK.

6. On the Configuration page, do the following:a. Select Browse for a type.b. In the Choose module type box, select Microsoft.SystemCenter.GroupPopulator.c. In the Module ID box, type GroupPopulator. Click OK.d. Click Edit to start the external editor.e. Copy and paste the following XML code between the Configuration tags.

<RuleId>$MPElement$</RuleId>

<GroupInstanceId>$MPElement[Name="MyMP.MyComputerGroup"]$</GroupInstanceId>

<MembershipRules>

<MembershipRule>

<MonitoringClass>$MPElement[Name="Windows!Microsoft.Windows.Computer"]$</MonitoringClass>

<RelationshipClass>$MPElement[Name="SC!Microsoft.SystemCenter.ComputerGroupContainsComputer"]$</RelationshipClass>

<Expression>

<Contains>

<MonitoringClass>$MPElement[Name="MyMP.MyComputerRole1"]$</Moni

To populate a computer group

104

toringClass>

</Contains>

</Expression>

</MembershipRule>

</MembershipRules>

f. Close the external editor, and save the configuration in the Authoring console.g. Click OK.


Health ModelIn Operations Manager 2007, a health model defines the logic used to measure the operational health of the application represented by the classes defined in the service model. This includes monitors for measuring the health state of monitored objects, rules for collecting information for analysis and reporting, and tasks for users to perform on demand activities in their daily operations activities.

The health model is designed after the service model is completed. The service model defines the classes that represent the application, whereas the health model defines how to measure the health of those classes.

The topics in this section provide an overview of the different elements that comprise the health model, a basic process for designing a health model for an application represented by an existing service model, and examples of using the Operations Manager 2007 Authoring console to build different health model elements.


Explains the concepts of the different components in a health model.

Health Model Design OverviewExplains the process and best practices when you design a health model for a particular application.

Building a Health ModelDemonstrates the different tasks used for building a health model for a sample application that uses the Authoring console.

105

Key ConceptsA Health Model consists of different kinds of management pack elements that each perform a specific function to measure the overall health of an application.

In This SectionTargets

Every workflow must specify a target class. This section describes the effects of the target and provides recommendations for selecting the most appropriate target for a particular workflow.

Data SourcesMonitors and rules require a data source that they will retrieve information from. This section lists the different kinds of data sources and the information that each makes available to monitors and rules using them.

Monitors and Health StateHealth state represents the current health of the application, and the health of each class is tracked for historical analysis. Monitors measure the health state of a class in the application’s service model. This section defines the different kinds of monitors and how multiple monitors are used together to measure the overall application health.

RulesRules collect monitoring data for online analysis and reporting, generate alerts that are not associated with health state, or run a command on a schedule. This section provides the details of each kind of rule and when they should be created.

TasksTasks are commands that can be run on demand by the user to collect information or perform some action on one or more agents. This section defines the different kinds of tasks and shows how they are defined.

106

TargetsEvery monitor, rule, task, and discovery in System Center Operations Manager 2007 must have a target class. This is typically a class that is defined in the service model for the application but may be another general class such as Windows Operating System.

Effects of a TargetThe target of a workflow has the following effects:

Which agents the management pack is delivered to Which agents the workflow will run on and how many copies of it will be loaded Which target variables are available to the workflow Which object health state, alerts, and collected data will be associated with

Each of these topics is discussed in detail in the following sections:

Which agents the management pack is delivered toWhen a management pack is installed or changed, it is delivered to any agent that manages at least one instance of a class that is used as a target on at least one included workflow. Workflows targeted at classes that have instances on the agent are not loaded. However, the complete management pack must be delivered to the agent.

Management pack delivery

Which agents the workflow will run on and how many copies of it will be loadedAs soon as the management pack is deployed, the agent will load a separate copy of each workflow for each instance of its target class. This means that if there are multiple instances of the target class on the agent, then the agent will load multiple copies of the same workflow.

107

Workflows included in the management pack that are targeted at objects not managed by the agent will not be run by that particular agent.

Workflow targeted at a single instance

The number of copies of the workflow that can be expected on any given agent must be accounted for when you define the workflow. Each copy of the workflow runs independently and includes its own set of variables. If a particular rule or monitor can potentially have multiple copies running on a single agent, then it has the potential to generate multiple alerts or collect multiple pieces of data when only a single one is desired.

Workflow targeted at multiple instances

For example, a rule may be defined to generate an alert in response to a particular event in the Windows event log. A common strategy for this scenario is to target a single instance class based on Windows Computer Role or Windows Local Application and use the Event Source and Event Number to specify the desired event. This typically works as expected because there will always be only a single instance of the target class on any agent. In this case, only a single copy of the rule is loaded, and the Event Source and Event Number are sufficient criteria to uniquely identify the event. If the same rule targets a class that has multiple instances on an agent, however, a separate alert would be created for each copy of the rule in response to the single

108

event. In this second case, a $Target variable would have to be included in the rule’s expression to specify which copy of the workflow should generate the alert.

To show this example, the SQL Server 2008 Monitoring management pack includes a rule named Script : Failed to login that indicates that a monitoring script could not log on to a particular database. It determines this error has occurred by a particular event in the Operations Manager event log. This rule is targeted at the Microsoft SQL Server 2008 Database class which can have multiple instances on a particular agent – one for each database on that server. If only the Event Number and Event Source were specified, then a separate alert would be created for each database because the criteria in each copy of the rule would match the details specified for the event. In order to specify which copy of the rule should generate the alert, the expression in the rule also specifies that the Event Description must include the name of the database. It does this by using the DatabaseName property of the target object. Each copy of the rule resolves this variable when they are loaded by the agent so that only the copy of the rule matching the database name that is specified in the event will generate an alert.

Which target variables are available to the workflowA workflow has access to $Target variables for the properties of its target class and any of that class’s parent classes. If the workflow is targeted at a class based on Windows Computer Role for example, then properties of the Windows Computer class such as PrincipalName and IPAddress are available to the workflow since Windows Computer hosts Windows Computer Role.

Which object health state, alerts, and collected data will be associated withAny health state, alert, or performance data generated by a rule or monitor is associated with the object that the particular copy of the workflow was running against. In the earlier example, SQL 2008 DB Engine could have been used as the target because the rule would have been loaded on any agent running SQL Server 2008. The alert created from the rule though would be associated with the SQL Server itself has opposed to the individual database. This would have a significant affect any notifications, reports, or views specific to the particular object.

With a monitor, the target will determine which object’s health state will be affected. If a monitor measuring the health of a database were targeted at SQL 2008 DB Engine, the state of the SQL Server would be affected. However, the state of the database itself would not. An availability report would show that the server was unavailable for the period that the monitor was in a critical state, whereas the same report executed for the database itself would show no downtime. In this case, the monitor would have to be targeted at the SQL Server 2008 Database class in order to set the state for the intended object.

109

Targeting GroupsAlthough groups can be the target of a workflow, this will most likely not result in the desired functionality. The workflow will not enumerate the contents of the group but will try to run against the group object itself. Because groups are managed by the Root Management Server, any workflows targeted at them will be loaded only on that server.

If you want to have a workflow run only against the members of a particular group, you can use the following method:

1. Create the rule or monitor with a target appropriate for the objects that are contained in the group.

2. Disable the rule or monitor on the Options tab of its Properties dialog box.3. As soon as the rule or monitor is created, create an override to enable it for the group.

Data SourcesMonitors and rules are the primary elements of a health model in System Center Operations Manager 2007 and provide similar yet distinct functionality. Monitors set the state of a monitored object while rules create simple alerts and collect data for analysis and reporting. Each monitor and rule is primarily defined by the source of the data that is used to perform its required functionality and the logic used to evaluate this data.

Monitors and rules are the primary elements of a health model and provide similar functionality. Monitors set the state if a monitored object, whereas rules create simple alerts and collect data for analysis and reporting. Each monitor and rule is defined by the source of the data that was used to perform its required functionality and the logic to evaluate this data.

Conceptual view of monitors and rules

Although they provide different functionality, monitors and rules use a common set of sources that provide the data to evaluate. For example, a monitor may use a performance counter to set the state of a particular object. A rule may access the same performance counter in order to store its

110

value for analysis and reporting. The following sections provide the details of each different kind of data sources that may be used in monitors and rules.

The data sources and monitoring logic discussed in this section are those that can be created by using wizards in the Authoring console. Other data sources and logic can be implemented by creating custom modules and workflows as discussed in the Composition section of this guide.

See AlsoMonitors and Health State

Rules

Data VariablesValues of the data properties collected by a data source are accessed by $Data variables. The available properties and the syntax of $Data variables will be different for each kind of data source, and the syntax will be different for the same property in different usage. This is because all data that is used by a workflow is formatted in XML, and the syntax of the $Data variable is an XPath to a particular value. As different parts of the workflow process the data, it may be reformatted requiring a different XPath to the same value.

The following table lists common ways that $Data variables are used and the general syntax that is used to access each. The following sections provide the details of each kind of data source and the properties available for each. These sections provide additional details on the syntax that is specific to each kind of data.

Use Description Syntax

Criteria expressions Criteria expressions do not require use of the $Data prefix to the variable or the dollar sign ($) delimiters. The syntax used for the parameter name in an expression will be the XPath to the property. For some data sources this is the name of the property.

Expressions are used to evaluate data to determine whether the data meets certain criteria. This may be inspecting an event to determine whether the data matches a particular source and number. Or, the expression might be comparing a performance value to a threshold. The $Data variable is used to identify the particular

Note

111


property from the data source being evaluated.

Mapping between data types When you use them for mapping data, the syntax of the $Data variable will be the same as for a criteria expression except with the $Data prefix and the dollar sign ($) delimiters. This will typically have the following syntax:

$Data/<XPath to Property>$

A data source may create data in one type that must be mapped to another type for the next step in a workflow. For example, collection rule may run a script that collects data to be stored as performance data. The data coming from the script would be formatted in a property bag and require mapping to performance data. The mapping would require the $Data variables to refer the values from the script’s property bag.

Alert Descriptions The syntax for $Data variables in alert descriptions is different for alerts created by rules and alerts created by monitors. This is because an alert from a rule is in direct response to an expression while an alert from a monitor is response to a state change. Each may start with the same data source. However, the data is reformatted by the monitor after the state change.

$Data variables in alert descriptions from rules will typically have the following syntax:

$Data/<XPath to Property>$

$Data variables in alert descriptions from monitors will typically have the following syntax:

$Data/Context/<XPath to

$Data variables can be used in alert descriptions to provide details of the data that created the alert.

112


Property>$

EventsThe following table lists the kinds of events that can be used for monitors and rules in a System Center Operations Manager 2007 management pack:

Text Log Text log file that has a single line per entry.

Text Log (Delimited) Text log file that has a single line per entry and fields separated by a specific character.

Windows Events Events in the Windows event log matching specified criteria.

WMI Events Events created by Windows Management Instrumentation (WMI).

Syslog Events Events from Unix systems and other devices.

Details on each event data source are provided in the following sections. This includes the information that is required to retrieve the required data, properties available in the resulting data, and what workflows the event data source supports.

Windows EventsMany Windows-based applications post information to events in a Windows event log. These events follow a standard format and frequently contain detailed information about the particular issue

CriteriaIn addition to the Application log to retrieve events from, workflows using a Windows event must specify sufficient criteria to identify the particular events that relate to the issue being identified. Frequently, the Event ID and the Event Source will be sufficient for this purpose. This depends on the kind of information that the application provides in the particular event in addition to the target that is being used for the monitor. If the class being used as the target for the monitor is expected to have multiple instances on a particular agent, then these two properties are probably insufficient for uniqueness. Unless the criteria included a key property for the target class then the criteria would possibly apply to all instances.

113

For example, the SQL Server 2008 (Monitoring) management pack uses an event to detect an error in a zone transfer. This event will have a publisher name of Microsoft-Windows-DNS-Server-Service and an event number of 6002. This monitor is called Microsoft.Windows.DNSServer.2008.Monitor.ZoneTransfer.ReinitializeZoneTransfer and uses the Microsoft.Windows.DNSServer.2008.Zone class for a target. This class is expected to have multiple instances on a particular agent. If multiple zones were hosted on a single DNS server, and only the publisher name and event number were used then the single event would be recognized by each instance. Each instance would set a negative health state even though the event was intended for only one zone. In this case, the name of the zone experiencing the issue is provided in parameter 2 of the event. Criteria is added to the monitor to match the name of the zone with the value in this event parameter to ensure that the criteria for each event matches only one instance of the Microsoft.Windows.DNSServer.2008.Zone class.

PropertiesThe following table lists the properties available from Windows Events. These properties can be accessed for setting criteria in monitors and rules and can be included in alert descriptions.

Property Name Description

PublisherName Source of the event. Generally used in the criteria of the monitor or rule.

Channel Name of the event log such as Application or System.

LoggingComputer Name of the computer logging the event.

EventNumber Number of the event.

EventCategory Category of the event.

EventLevel Severity of the event that uses one of the following values.

0 - Success

1 - Error

2 - Warning

4 - Information

UserName Name of the user account that was used to create the event.

EventDescription Full event description.

Params Collection of event parameters.

114

Workflows SupportedWindows Events can be used in the following kinds of workflows:

Monitors Alerting Rules Collection Rules

Text LogsA text log is a text file that an application uses to log event information. In order to use a text log data source in a management pack, each entry in the log must be on a single line. If the log file does not fit this requirement, then a custom script has to be created to read the log. Using a standard text log, the monitor reads the whole line as a single entry. With a delimited text log, a delimiter is used to separate the fields in the entry.

Applications that use log files frequently create a new file each day or when one file reaches a certain size. To support this functionality, monitors and rules specify a Directory and a Pattern for the text logs being monitored. Directory is the path of the directory where the text logs will be located. This must be an absolute path without wildcard characters. A $Target variable could also be used if the path to the log files is stored in a property of the target class. Pattern is the name of the log file including wildcard characters as appropriate.

For example, an application might create a log file each day with the date included in the name as in log20100316.txt. A pattern for such a log might be log*.txt which would apply to any log file following the application’s naming scheme.

PropertiesThe expression for a text log monitor will include criteria that matches text in the log entry. For a standard text log this includes a search of the whole log entry treated as a single line. For a delimited text file, this will include a search of one or more of the included fields. The contents of a text log are included in the parameters of the event. For a standard text file, this is referenced by the parameter $Data/Params/Param[1]$. A delimited text file uses the same $Data variable by using the index number of the required parameter. The first field would be referenced with $Data/Params/Param[1]$, the second field would be referenced with $Data/Params/Param[2]$, and so on.

The following table lists the common properties available from text log monitors and rules:


LogFileDirectory Directory that the log file is located in.

LogFileType CSV Log File Format for a delimited text log.

Generic Log File Format for text log.

LogFileName Name of the log file that the event was taken

115


from.

Param[1] Complete entry in a standard text file.

Param[#] Specific parameter in a delimited text file. # represents the number of the field.

Workflows SupportedText Logs can be used in the following kinds of workflows:


WMI EventsWMI events are created from WMI queries that detect particular actions in the operating system or in applications that create their own WMI events. These events can be used to detect such actions as a process ending, a file being created, or a registry key being modified. WMI events are not persisted. Therefore, any WMI events that are created when the agent service is not running are lost.

This guide assumes knowledge of how to build a WMI notification query. For a an overview of this topic and sample queries see Unlocking the Mystery of WMI Events in MOM.

WMI monitors and rules require a namespace, a query, and a poll interval. The poll interval specified in the monitor or rule should match the poll interval in the query.

WMI matching poll intervals

Note

116



CriteriaBecause criteria can be specified in the WHERE clause of the WMI query, criteria is frequently not required in the monitor or rule. It is only required if the query is expected to return multiple records.

The Authoring Console wizards require that criteria be specified in WMI Event monitors and rules. If no criteria is required, then dummy criteria should be specified in the wizard and then removed by viewing the properties of the monitor or rule.

PropertiesThe properties available for a WMI event will vary, depending on the kind of event being monitored. The properties available will also vary, depending on the properties of the WMI class included in the query. The data will be in the form of a property bag that has a collection of properties for one or more WMI class instances. WMI events created by using a query that uses either __InstanceCreationEvent or __InstanceDeletionEvent will have a single collection called TargetInstance with the instance being either created or deleted. WMI events created by using __InstanceModificationEvent will have an additional collection called PreviousInstance.

The syntax for properties from a WMI event is as follows:

Collection[@Name='TargetInstance']/Property[@Name='Caption']

Note

117

For example, the following WMI query monitors for the change in a file that is named c:\MyApp\MyAppLog.txt.

SELECT * FROM __InstanceNotificationEvent WITHIN 60 WHERE TargetInstance ISA

'CIM_DataFIle' AND TargetInstance.Name = 'C:\\MyApp\\MyAppLog.txt'

Assuming that data is added to the file changing the file size and triggering the query, examples of properties from this query are shown in the following table:

Property Syntax

Original file size $Data/Collection[@Name=’PreviousInstance’]/Property[@Name=’FileSize’]$

New file size $Data/Collection[@Name=’TargetInstance’]/Property[@Name=’FileSize’]$

Workflows SupportedWMI events can be used in the following kinds of workflows:


Syslog EventsSyslog events can be used to collect messages from Unix systems and other devices. Syslog rules can be run on an agent that is the receiver of messages from one or more devices. When the rule is run, the agent will listen for messages on UDP port 514. This is the only port that can be used.

PropertiesThe Syslog data properties are shown in the following table:


Facility The facility of the event that uses one of the values from the table that follows.

Severity Numeric value that indicates the severity of the event using one of the following values:

0 - Emergency

1 - Alert

2 - Critical

118


3 - Error

4 - Warning

5 - Notice

6 - Info

7 - Debug

Priority

PriorityName

TimeStamp Time that the message was sent.

HostName Name of the device sending the message

Message Text of the message

Facility ValuesThe value for the facility property defines the part of the system that the message originated from. It will have one of the values from the following table:

Facility Description Value

0 Kernel Kernel messages

1 User User-level messages

2 Mail Mail System

3 Daemons System daemons

4 Auth Security and authorization

5 Syslog Syslog internal messages

6 LPR Line printer subsystem

7 News Network news

8 UUCP Unix-to-Unix copy program

9 Cron Cron daemon

10 Auth2 Security and authorization

11 FTP FTP daemon

12 NTP Network time subsystem

119

Facility Description Value

13 LogAudit

14 LogAlert

15 Cron2 Cron daemon

16 Local0 Local use 0








Workflows SupportedSyslog events can be used in the following kinds of workflows:

Alert Rules Collection Rules

Performance DataPerformance counters are numeric data that is used to measure the performance of some aspect of the application. The following table lists the kinds of data sources in a System Center Operations Manager 2007 management pack that produce performance data.

Windows Performance Samples a Windows performance counter at specified interval.

WMI Performance Runs a WMI query at specified interval and uses the value of a numeric property for performance data.

120

Details on each performance data source are provided in the following sections. This includes the information that is required to retrieve the required data, properties available in the resulting data, and what workflows the performance data source supports.

Windows PerformanceTo define a monitor or rule based on a Windows performance counter, the object name and counter name of the performance counter to sample must be specified with a frequency that specifies how frequently to sample the data. The instance name only has to be specified if the same counter will be collected for multiple objects on the same agent. If this is the case, a $Target variable will typically be used for the value in the instance name in order to differentiate between the performance values for different objects. The counter must be available on the agent computer that is running the monitor or rule or an error will be created in the Operations Manager event log on the agent.

PropertiesThe following table shows the properties that are available from a Windows performance counter.


Object Name Name of the performance object.

Counter Name Name of the performance counter.

Instance Name Name of the instance if it is specified.

Value Numeric value of the performance data.

TimeSampled Time that sample was performed in UTC format.

Workflows SupportedWindows performance can be used in the following kinds of workflows:

Monitors Collection Rules

WMI PerformanceWMI performance refers to numeric data that is retrieved from a WMI query. This lets performance data be retrieved that is not available from a performance counter and without using the complexity and overhead of a script. The monitor or rule runs the query on a specified

121

schedule and maps the value of the specified numeric field into the value property of the performance data.

For example, a monitor might have to track the size of a particular file. This might be a log file that indicates a particular problem when it exceeds a particular size. The name and size of the file could be retrieved from a query similar to the following:

Select Name, FileSize from CIM_DataFile Where Name = 'C:\\MyApp\\MyAppLog.txt'

The monitor could run this query regularly by using the FileSize property for the value of the performance data and the Name property for the Instance property.

PropertiesThe WMI query returns a property bag with properties returned from the query. This set of properties will vary, depending on the class returned and the properties specified in the query.

Workflows SupportedWMI performance can be used in the following kinds of workflows:


See AlsoPerformance Monitors

Performance Collection Rules

Monitoring ScriptsMonitoring scripts are used when the required data cannot be collected through other standard means such as an event or performance counter. The script collects data from information on the agent and creates a property bag by using the MOM.ScriptAPI object that is installed with the Operations Manager 2007 agent.

Monitoring scripts may be written in any script language that can access the MOM.ScriptAPI object that is installed on all Operations Manager 2007 agents. The most common languages used are VBScript, JScript, and Windows PowerShell. Scripts that use VBScript or Jscript can be created by using modules in management pack libraries and wizards in the Authoring console. Modules are available for monitoring scripts that are written in Windows PowerShell in Operations Manager 2007 R2 but are not supported by wizards in the Authoring console. A custom workflow would have to be created by using the appropriate module as described in the Composition section of this guide.

122

Property BagsMonitoring scripts send any output data as a property bag so that it can be used by the rest of workflow. A property bag is a set of values that each has a name. Any name can be assigned although it is a best practice to use a name descriptive of the particular value. A property bag only exists during the life of the workflow. The next time that the workflow runs, the script is run and creates a new property bag with new values.

One property bag can have any number values, although the whole set of data may not exceed 4 MB. Most scripts will only require some values with a total size far under this limit. There is no requirement for all the values to be used by the workflow.

Scripts create property bags by using the CreatePropertyBag method on the MOM.ScriptAPI object. The workflow uses values from a property bag with a $Data variable that uses the following syntax:

$Data/Property[@Name="PropertyName"]

For example, a script creating performance data might create a property bag with values in the following table. This table shows the name of the value created by the script and the corresponding $Data variable that would be used to map the property bag data to performance data.

Property Bag Value Name Sample Value Variable

ObjectName MyObject $Data/Property[@Name='ObjectName']$

CounterName MyCounter $Data/Property[@Name='CounterName']$

InstanceName MyInstance $Data/Property[@Name='InstanceName']$

Value 10 $Data/Property[@Name='Value']$

Typed Property BagsValues from a property bag created by using the CreatePropertyBag method may be used by the workflow to create any type of data including discovery data, performance data, and events. The CreateTypedPropertyBag method can be used to create property bags that may only be used for a particular data type. The resulting property bag is identical and is referred to with the same $Data variables.

The CreateTypedPropertyBag functions to ensure that the output of a script is only used for the specific data type that it was intended. It is typically not used in scripts created by using a wizard in the Authoring Console but instead by scripts included in custom modules that may be used in multiple workflows. This concept is discussed in the Composition section of this guide.

The syntax of the CreateTypedPropertyBag method is as follows:

123

MOMScriptAPI.CreateTypedPropertyBag(type)

The parameter type specifies the type of data that may be created from values in the property bag. Possible values are shown in the following table:

Value Data Type

0 Alert

1 Event

2 Performance

3 State

Basic Script StructureThe following sample shows a monitoring script with the following characteristics.

Accepts arguments for the name of the computer that is running the script and a path of the location of the application.

Creates a property bag with the values named ComputerName, InstanceName, and PerfValue.


sApplicationPath = WScript.Arguments(1)


Set oBag = oAPI.CreatePropertyBag()

oBag.AddValue "ComputerName", sComputerName

oBag.AddValue "InstanceName", "MyInstance"

oBag.AddValue "Value", 1.0

oAPI.Return(oBag)

Script BreakdownDetails of each section of the script are discussed here.

124


sApplicationPath = WScript.Arguments(1)

The first two lines of the script accept arguments. These values would be expected to be in the Arguments parameter of the rule or monitor running the script. The script can use any number of arguments that are required for the logic of the script.



The next two lines create a property bag. These lines will also be unchanged in most monitoring scripts. The main purpose of the rest of the script will be to add values to the property bag by using data that is collected from the agent computer.

oBag.AddValue "ComputerName", sComputerName

oBag.AddValue "InstanceName", "MyInstance"

oBag.AddValue "Value", 1.0

After the property bag is created, any number of values can be added to it. You do this with the AddValue method on the property bag object by using the name of the item followed its value. This example uses explicit values. In actual monitoring script, additional code would be expected that would collect information from the agent computer to include in these values.

oAPI.Return(oBag)

After all values are added to the property bag, it is returned into the workflow. This line is required, and without it the property bag is discarded when the script ends. This method is only used when the script creates only a single property bag. For more information about scripts that return multiple property bags and conditions when such a strategy is used, refer to the Cookdown section of this guide.

Defining a Script

Script NameScripts in a management pack must be given a name with either a .vbs or ,js extension depending on their language. This name is used to create the file in the temporary directory on the agent. There is no requirement to make this name unique because each script is provided its own temporary directory on the agent.

125

Script ArgumentsArguments are provided to the script in a single line separated by spaces. This is identical to the command line that would be provided if the script were run on a command line. This is access in the Authoring console from the Parameters button.

Each argument can be either an explicit value or a $Target variable to use the value of a property on the target object. Any $Target variables are resolved when the script is run so that the script is provided with the resolved values on the command line.

Any $Target variable that might resolve to a value that includes a space should be enclosed with quotation marks. If a value includes spaces and does not have quotation marks, then it will be seen by the script as two separate arguments. The quotation marks will ensure that the value is seen as a single argument.

For example, the sample script earlier expects two arguments for the computer name and the application path. Assuming this was part of a workflow targeted at a class hosted by the Windows Computer class, the computer name could be retrieved from the PrincipalName property. If the application path were a property on the target class, then the arguments might look similar to the following example. Notice the quotation marks around the ApplicationPath property, because this could resolve to a value that contains a space.

$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$

"$Target/Property[Type="MyApp.MyClass"]/ApplicationPath$"

Script TimeoutAll scripts are given a timeout value which indicates the number of seconds that the script can run before the agent stops it. This prevents problem scripts from running continuously and putting excess overhead on the agent computer.

The timeout value assigned to a script should allow enough time for the script to run under ordinary conditions, but should be less than the interval that the script is scheduled to run. If a script is configured to have a timeout value greater than its duration, then possibly multiple copies of the script could be running concurrently.

Windows PowerShellThe following script is the Windows PowerShell equivalent of the VBScript sample monitoring script shown previously. Both scripts use the same MOM.ScriptAPI object and methods.

param($computerName,$version)

$api = New-Object -comObject 'MOM.ScriptAPI'

Important

126

$bag = $api.CreatePropertyBag()

$bag.AddValue 'ComputerName', $computerName

$bag.AddValue 'InstanceName', '1.0'

$bag.AddValue 'Value', '1.0'

$bag

Other than obvious syntax, there are two primary differences between the VBScript and Windows PowerShell scripts, as follows.

param($computerName,$version)

The first difference is in the means of retrieving script arguments. Windows PowerShell can accept positional arguments as VBScript does, but named parameters that use the param command better support the Windows PowerShell modules included with Operations Manager 2007 R2. These modules let parameters be separately specified in the module configuration where they are retrieved by the script as named parameters.

$bag

Another important difference is the way that the property bag data is returned to the workflow. In VBScript, the Return method of the MOM.ScriptAPI object is used. In Windows PowerShell, this method will not return the data correctly. The Return method sends the discovery data to the Standard Out (StdOut) stream, whereas Windows PowerShell requires the data to be sent to the output pipeline. This is achieved by typing the property bag variable on its own line.

Monitors and rules that use PowerShell scripts cannot be created by using wizards in the Authoring Console. Custom workflows must be created by using the PowerShell modules available in Operations Manager 2007 R2. Information on custom workflows is provided in the Composition section of this guide.

For management packs that must support Operations Manager 2007 SP1, the PowerShell modules cannot be used. In this case, a custom solution running PowerShell.exe from a custom workflow would have to be employed.

Supported WorkflowsScripts can be used in the following kinds of workflows:


Collection rules based on scripts can map values in the property bag to either events or performance data. There is no difference in the scripts for either of these kinds of rules. The only difference is in the properties of the resulting data type that the property bag values are mapped into.

127

See AlsoScript Monitors

Monitors and Health StateEvery instance of each class in a System Center Operations Manager 2007 service model has a health state that represents the current health of the object. This health state is set by one or more monitors targeted at the class. The health state of each monitor changes as the health of the components of the application represented by the class change.

There are three kinds of monitors as shown in the following table:

Monitor Description

Unit Monitors Measures some aspect of the application. This might be checking a performance counter to determine the performance of the application, running a script to perform a synthetic transaction, or watch for an event that indicates an error. Classes will typically have multiple unit monitors targeted at them to test different features of the application and to monitor for different problems.

Dependency Monitors Provides health rollup between different classes. This allows the health of an object to depend on the health of another kind of object that it relies on for successful operation.

Aggregate Monitors Provides a combined health state for similar monitors. Unit and dependency monitors will typically be configured under a particular aggregate monitor. In addition to providing better general organization of the many different monitors targeted at a particular class, aggregate monitors provide a unique health state for different categories of the class.

Monitors each have either two or three states. At any time, a monitor will be in one and only one its potential states. When a monitor loaded by the agent, it is initialized to a healthy state. The state will change only if the specified conditions for another state are detected.

The overall health of a particular object is determined from the health of each of its monitors. This will be a combination of monitors targeted directly at the object, monitors target at objects rolling

128

up to the object through a dependency monitor, dependency monitors targeted at those objects, and so on. This hierarchy is illustrated in the Health Explorer of the Operations console. The policy for how health is rolled up is part of the configuration of the aggregate and dependency monitors.

The following diagram shows an example of the Health Explorer for the Windows Server class. This shows the use of the different kinds of monitors contributing to an overall health state.

Sample Health Explorer

In This SectionUnit Monitors

Details on unit monitors using different data sources.

Dependency MonitorsDetails on dependency monitors.

Aggregate MonitorsDetails on aggregate monitors.

Alerts from MonitorsDetails on alerts that are created from monitors and using variables in alert descriptions.

129

Diagnostics and RecoveriesDetails on diagnostics and recoveries that run in response to the change in a monitor’s health state.

Unit MonitorsUnit monitors measure some aspect of the health of a particular class. The may detect an event that indicate a problem, sample a performance counter for comparison against a threshold, or run a synthetic transaction to test some feature of the application.

In This SectionUnit monitors are primarily defined by data source and the logic that is used with this data to determine whether the state should be changed. The following sections provide details on each of the different kinds of unit monitor and the data sources and logic that are available for each.

Event MonitorsMonitors by using events to identify issues affecting application health.

Performance MonitorsMonitors by using values of performance counters compared to threshold values to determine a health state.

Script MonitorsMonitors by running a scheduled script to collect health information.

Service MonitorsMonitors checking the running state of a service.

Event MonitorsEvent monitors use one of the event data sources to identify a particular event that indicates an issue. As soon as the specific data source that holds the required information is identified, the logic used to determine different health states must be determined. In addition to the logic that

130

indicates whether an error condition has occurred, additional logic must be defined to determine when the state should be changed back to a healthy condition.

Detection LogicThe different kinds of logic that can be used to detect an error condition by using events are listed in the following table. As noted in the table, some logic can only be used with Windows events.

Logic Data Sources Description

Simple Event All Detects an error state from the occurrence of a single event.

Repeated Events All Detects an error state from one or more occurrences of a particular event in a specified time window.

Correlated Events Windows Events Detects an error state from the occurrence of two events in a specified time window.

Correlated Missing Events Windows Events Detects an error state from an expected event not being detected in a particular time window after the occurrence of another event.

Missing Event Windows Events Detects an error state from an expected event not being detected in a particular time window.

Simple EventSimple detection refers to a state change being triggered immediately after a single occurrence of the specified event. This is the most basic kind of detection and will apply to most scenarios.

Repeated EventsRepeated event detection uses one or more occurrences of a particular event in a time window to indicate an error condition. This typically applies to conditions in an application where a single event on its own can be ignored, but multiple occurrences of that event in a particular time window indicate a potential error. There are different algorithms that can be used for this

131

detection, depending on the logic that best identifies the specific application issue. The following are details of the different algorithms:

Trigger on TimerTrigger on timer consolidation of events uses a specified time window and is not dependent on the number of events received. A single event can trigger an error in the health state as in simple detection. Unlike simple detection which sets the health state immediately upon detection of the specified event, however trigger on timer consolidation waits until a specified time window to set the health state of the monitor. The time window can be a rotating time duration of specified length or a specific window based on day of the week.

Trigger on timer consolidation is useful for errors that should only be detected in a certain time window. Used with a time window based on a specific time of day, this disables the monitor outside that time period. It can also have the effect of delaying the change of state for a particular time during which an event that indicates a healthy state could be received. In this case, the health state would never be changed.

Trigger on CountTrigger on count consolidation of events lets a monitor require multiple occurrences of the same event in a specified time window before it changes the health state to an error. The time window can be rotating time duration of specified length or a specific window based on day of the week.

Trigger on count consolidation resembles trigger on timer consolidation except that multiple occurrences of the event are required instead of just one. When the time window is reached, the event count is returned to zero, and the specific number of events must detected before the time window expires again for the health state to be changed.

Trigger on Count, SlidingTrigger on count, sliding consolidation of events is similar to trigger on count consolidation except that the time window is reset every time that the specified event is received. The time window only expires if the time is reached after the occurrence of the last event.

Trigger on count, sliding consolidation is useful for error conditions that are detected by a certain number of events in a particular length of time. By using trigger on count consolidation, some events could be received in one time window and then other events received in the next time window with the result that the health state is never changed. Using trigger on count, sliding consolidation, the time window depends on when the event occurs preventing this condition.

Repeated Events ExampleTo help with understanding the different algorithms used for repeated event detection, the following table shows the effect on health state for monitors based on the different kinds of consolidation. This is based on a repeated event monitor that uses the following details:

Consolidation interval: 2 minutes

132

Compare count: 3 (ignored by Trigger on Timer) Health state on repeated event: Critical Reset Logic: Event reset using Event 3

Time Event Trigger on Timer Trigger on Count Trigger on Count, Sliding

00:00:00 - Healthy Healthy Healthy

00:01:00 Event 1 Healthy Healthy Healthy



00:03:00 - Critical Healthy Healthy




00:05:00 Event 1 Critical Healthy Healthy



06:30:00 Event 1 Critical Healthy Healthy

07:00:00 Event 1 Critical Healthy Critical

07:30:00 - Critical Healthy Critical

00:08:00 Event 1 Critical Healthy Critical

00:08:30 - Critical Critical Critical

00:09:00 Healthy Critical Healthy Healthy

Using trigger on timer, a critical state is set at 00:03:00 event though the event is received at 00:01:00 because the time window starts when the monitor is loaded. The start is reset to healthy at 00:03:30, but the critical state is again triggered at 00:05:00 from the time window started at 00:03:00.

Using trigger on count, the event at 00:05:00 does not trigger a critical state because the time window started by the event at 00:01:00 would have expired at 00:03:00. This event is instead part of the time window started by the event at 00:04:00 which expires at 00:06:00. The monitor triggers a critical state at 00:08:30 because of the 3 events detected in the time window started with the event at 00:06:30.

133

Using trigger on count, sliding, each occurrence of Event 1 starts its own window. The critical state is triggered at 00:07:00 from the 3 events detected in the time window started with the event at 00:05:00.

PropertiesRepeated event monitors have the following additional properties that may be used in criteria and message descriptions:

Property Description

TimeWindowStarts Time that the time window started

TimeWindowEnds Time that the time window ended

TimeFirst Time of the first event

TimeLast Time of the last event

Count Number of events that are collected in the time window

Correlated EventsA correlated event monitor uses two separate events in a particular time period to detect a single issue. This kind of monitor supports conditions where an issue cannot be identified by a single event alone.

When the first event is detected, a timer is triggered. If the second event is received within that period, the state change is triggered. If the second event is not received in the period, the timer is reset until the first event is received again. The monitor may be configured to better tune the specific conditions that must be met in order to perform correlation. These options include the following:

Whether the events must be in chronological order. One of the events may always be expected before the other one, or they may be expected in either order.

Whether the first or last occurrence of the first event should be used. If the first occurrence is specified, then each occurrence of the first event will have its own time window and search for corresponding occurrences of the second event. With the last occurrence specified, if the first event reoccurs with the time window, then the time window is extended based on the last event. The monitor can also be configured to reset the time window every time that the first event occurs. When the time window is reset, all previous occurrences of both events are ignored.

The number of occurrences of the second event that must be received to trigger the state change. Instead of changing the health state after receiving a single instance of the two events, multiple instances of the second event may be required.

134

Properties between the first and second event that must match for correlation to be performed. Instead of detecting two occurrences of each event, additional comparison may be required to determine whether the events are related. The monitor can, for example, confirm that a particular parameter matches between the two events to make sure that they match.

Correlated Events ExampleThe following table provides an example of a correlated event monitor by using the first and the last occurrence of the first event. The monitor uses the following details:

Event Log A: Event 1 Event Log B: Event 2 Correlation interval: 2 minutes Number of occurrences of Event 2: 3 Health state on correlation: Critical Reset Logic: Event reset using Event 3

Time Event First Occurrence Last Occurrence

00:00:00 - Healthy Healthy

00:01:00 Event 1 Healthy Healthy

01:30 Event 2 Healthy Healthy







00:05:00 Event 2 Critical Healthy







08:30:00 Event 2 Critical Critical

135



The First Occurrence does not trigger a critical state when Event 2 is detected at 00:03:00 because the timer was reset at 00:03:00 which is 2 minutes after the first occurrence of Event 1 at 00:01:00.

The First Occurrence triggers a critical state at 00:05:00 because Event 2 is detected 3 times within the 2 minutes since the first occurrence of Event 1 at 00:03:00. Event 1 starts a new time window at 00:03:00 because the time window from Event 1 at 00:01:00 would have expired.

The First Occurrence triggers a critical state at 00:08:00 because Event 2 is detected 3 times within 2 minutes from Event 1 at 00:06:00.

The First Occurrence resets its state to healthy at 00:05:30 and 00:09:00 because Event 3 is detected.

Correlated Missing EventsA correlated missing event monitor determines an error by the absence of a particular event after the occurrence of another. This resembles the missing event monitor except that instead of searching for the missing event in a particular time window, the monitor searches for the event in a particular time after another event is first detected.

For example, consider an application that performs a backup each evening and creates an event when it starts and a second event when it has completed successfully. A correlated missing event monitor could be created that searches for the event in a particular time window each evening. If both events are detected, then the monitor remains in a healthy state. If the first is found, then the timer starts. If the time is reached before the second event is detected, then the state change is triggered to indicate that the last backup did not occur successfully.

Correlated Missing Events ExampleThe following table provides an example of a correlated missing event monitor by using the first and the last occurrence of the first event. The monitor uses the following details:

Missing Event Log A: Event 1 Missing Event Log B: Event 2 Correlation interval: 2 minutes Number of occurrences of Event 2: 3 Health state on correlation: Critical Reset Logic: Event reset using Event 3



136



1:30 Event 2 Healthy Healthy



00:03:00 - Critical Healthy



00:04:30 - Critical Critical


The First Occurrence triggers a critical state at 00:03:00 because Event 2 has not been detected 3 times in the 2 minute interval since the first occurrence of Event 1 at 00:01:00.

The Last Occurrence does not trigger a critical state at 00:03:00 because Event 1 occurs at 00:02:30 resetting the timer. The critical state is not triggered until 00:04:30 when Event 2 has not been detected in the 2 minutes interval since the last occurrence of Event 1 at 00:02:30.

The single occurrence of Event 3 at 00:05:00 resets both monitors to healthy.

Missing EventInstead of detecting a particular event to identify an error condition, a missing event monitor uses the absence of a particular event in a particular time window to determine an error. This supports applications that are expected to generate an informational event that indicates a successful operation or the success of a particular action.

For example, consider an application that performs a scheduled data transfer each evening and creates an event when it has completed successfully. A missing event monitor could be created that searches for the event in a particular time window each evening. If the event is detected, then the monitor remains in a healthy state. If it is not found, then it enters error state that indicates that the last transfer did not occur successfully.

Missing Event ExampleThe following table provides an example of a missing event monitor by using the following details:

Event: Event 1 Fixed Schedule: Su-Sa 2:00 AM – 3:00 AM Health state on missing event: Critical Reset Logic: Event reset using Event 3

137

Time Event Health State

00:00:00 - Healthy

00:01:00 Event 1 Healthy

00:02:00 - Healthy

00:03:00 - Healthy

00:04:00 - Healthy

00:05:00 Event 3 Healthy

The critical state is triggered at 00:03:00 when Event 1 is not detected within the specified window.

Health Reset LogicThe previous detection criteria describe the conditions under which a monitor changes to a warning or critical state. In addition to detecting an error state, each monitor must have logic defined to determine when the state should be returned to healthy. The different methods for resetting state are shown in the following table:

Reset Logic Description

Event Reset A single specific event indicates that monitor should be reset.

Manual Reset The monitor is never automatically rest. The user must manually reset the monitor.

Timer Reset The monitor is automatically reset after a specified time.

Each of these methods is discussed at length in the following sections:

Event ResetWith event reset, the monitor is reset when a single occurrence of a specific event is detected. The event must be the same type as the event used for detecting the error condition. For example, a Windows event monitor might specify an event with a particular event source and number to indicate an error condition. Another Windows event with the same event source but a different number might indicate that the error in the application was corrected.

Event reset can only be used if the application provides an event indicating the particular error was corrected. Many applications create an event when an error occurs but may not create a

138

corresponding event that indicates that the error was corrected. Event reset cannot be used in this case.

Manual resetWith manual reset, the monitor never returns to a healthy state automatically. The user must determine whether the problem was corrected and then select the monitor in the Health Explorer and select Reset Health.

The advantage to this strategy is that a monitor can be used for issues that do not create an event that indicates a healthy state. The monitor can affect the health state of the managed object instead of creating a simple alert from a rule. The downtime will be recorded for the object in the State Change Events in the Operations Console and in any availability reports.

There are multiple implications of this strategy that should be considered. The first is the additional work required from the user because the monitor will never automatically reset. It can also result in too much downtime being recorded if the user waits a long time before performing the reset. The problem may have been corrected fairly quickly, but the healthy state will not be recorded until the user performs the reset.

Use of manual reset should be especially cautioned for monitors where there is a potential for a single problem to affect multiple instances of the target class. Because users cannot reset the monitor for multiple instances in the Operations Console, the user would be required to manually open the Health Explorer for each instance to perform this action. Depending on the number of instances, this could result in significant effort for the user.

Timer ResetA timer reset acts the same as a manual reset except that if the user does not manually reset the monitor after a specified time, it will reset automatically. One use of this kind of reset is for issues that continuously log error events until the problem is corrected. Instead of using another event to indicate that the problem was corrected, the previously detected error event for a specified period can be used as the success criteria.

The timer reset can be used in the place of a manual reset providing the advantage of automatically resetting after a while if the user does not perform a manual reset.

Performance MonitorsMonitors in a System Center Operations Manager 2007 management pack based on performance counters collect numeric data at set intervals and compare it to one or more threshold values. This may be a simple comparison that compares each sample to a single threshold or more complex logic, depending on the requirements of the application.

139

Threshold TypesMultiple kinds of calculations may be performed to determine the threshold for a performance monitor. These threshold types are listed in the following table:

Threshold Type Number of States Description

Average Threshold 2 Compare the average of multiple collected values to a threshold.

Consecutive Samples 2 Compare several consecutive values to a threshold. All collected values must match the threshold criteria.

Delta Threshold 2 Compare the change between two consecutive values to a threshold.

Double Threshold 3 Compare a single collected value to two thresholds with one that indicates a Warning state and the other that indicates a Critical state.

Simple Threshold 2 Compare a single collected value to a threshold.

Each kind of logic is described in detail in the following sections:

Simple ThresholdThe simple threshold type is the most basic kind of performance threshold. A single numeric value is provided for the threshold. This threshold is compared to the measured value of the performance data.

Simple threshold supports a two state monitor. One state is set by a performance value equal to or less than the threshold. The other state is set by a performance value greater than the threshold.

Double ThresholdThe double threshold type is similar to the simple threshold type but allows for two thresholds to be specified. Each threshold is compared to the measured value of the performance data.

140

Double threshold supports a three state monitor. One state is set by a performance value less than the low threshold. Another state is set by a performance value that is greater than or equal to the low threshold or one that is less than or equal to the high threshold. Another state is set by a value that is greater than the high threshold.

The following table provides an example of a double monitor by using the following details:

Sample rate: 5 minutes Low threshold value: 10 High threshold value: 15 Over Upper Threshold State: Critical Between Thresholds State: Warning Under Lower Threshold State: Healthy

Time Value State

00:00:00 5 Healthy

00:05:00 10 Warning

00:10:00 12 Warning

00:15:00 9 Healthy

00:20:00 12 Warning

00:25:00 16 Critical


00:35:00 8 Healthy

The warning threshold is first exceeded at 00:05:00, but the value does not exceed the critical threshold.

The critical threshold is first exceeded at 00:25:00 when the state is changed from warning to critical.

The state is returned to a healthy state at 00:15:00 and 00:35:00 when the sampled value is less than the warning threshold.

Average ThresholdThe average threshold type calculates the average of a specified number of consecutive samples and compares it to the specified threshold.

Average threshold supports a two state monitor. One state is set by an average performance value equal to or less than the threshold. The other state is set by an average performance value greater than the threshold.

The following table provides an example of an average threshold monitor by using the following details:

141

Sample rate: 5 minutes Threshold value: 10 Number of samples: 3 Over Threshold State: Critical Under Threshold State: Healthy

Time Value Average State

00:00:00 5 - Healthy

00:05:00 10 - Healthy

00:10:00 12 9.0 Healthy

00:15:00 9 10.3 Critical

00:20:00 12 11.0 Critical

00:25:00 14 11.7 Critical

00:30:00 11 12.3 Critical

00:35:00 4 9.7 Healthy

Because the specified number of samples for the average calculation is 3, no value is evaluated until the third sample.

The value of 12 sampled at 00:10:00 exceeds the threshold value, but the calculated average from the last 3 samples is 9.0, which is under the threshold. The state is not changed.

The value of 9 sampled at 00:15:00 does not exceed the threshold. But the calculated average from the last 3 samples is 10.3 which does exceed the threshold. The state is changed.

The monitor does not return to a healthy state until 00:35:00 when the average from the last 3 samples drops the under the threshold value.

Consecutive SamplesThe consecutive threshold type compares the threshold value to the performance counter for several consecutive samples. This supports monitors that should not be triggered by only a single value exceeding a threshold. The threshold must be exceeded multiple consecutive times to trigger a change in state.

Consecutive threshold supports a two state monitor. One state is set by the value being either greater than or less than the threshold value for each consecutive sample. The other state is set by a single sample not matching the other criteria.

The following table provides an example of a consecutive sample monitor by using the following details:

Sample rate: 5 minutes

142

Threshold value: greater than or equal to 10 Number of samples: 3 Over Threshold State: Critical Under Threshold State: Healthy

Time Value State

00:00:00 5 Healthy

00:05:00 10 Healthy

00:10:00 12 Healthy

00:15:00 9 Healthy

00:20:00 12 Healthy

00:25:00 14 Healthy


00:35:00 8 Healthy

The threshold is exceeded by the values sampled at 00:05:00 and 00:10:00, but the value at 00:15:00 is under threshold and resets the count.

The value at 0:30:00 is the first time that 3 consecutive values have been sampled that exceed the threshold, so the state is changed.

The single value at 00:35:00 is under the threshold and resets the monitor to a healthy state.

Delta ThresholdThe delta threshold type compares the threshold value to the difference between two performance values. This might be two consecutive values or two values separated by a specified number of samples.

Delta threshold supports a two state monitor. One state is set by the difference of two values being greater than the threshold value. The other state is set by the difference of two samples being equal to or less than the threshold value.

The following table provides an example of a delta threshold monitor by using the following details:

Sample rate: 5 minutes Threshold value: 10 Number of samples: 3 Over Threshold State: Critical Under Threshold State: Healthy

143

Time Value Delta

00:00:00 7 - Healthy

00:05:00 8 - Healthy

00:10:00 13 - Healthy

00:15:00 16 9 Healthy

00:20:00 21 13 Critical

00:25:00 24 11 Critical

00:30:00 25 9 Healthy

Because the specified number of samples that the delta should be calculated from the current sampled value to the value 3 samples behind, no value is evaluated until the fourth sample.

The delta calculation exceeds the threshold value at 00:20:00, and the state is changed. The monitor is reset at 00:30:00 when the delta calculation falls under the threshold.

Self-tuning Threshold MonitorsA self-tuning threshold monitor uses a learning process to determine the typical values for a specified performance counter object and automatically sets the threshold levels based on the learned values. Avoid self-tuning threshold monitors because they may not work well in most customer environments.

Script MonitorsScript monitors run a monitoring script regularly and evaluate the results to determine the state of the monitor. The script could perform such actions as running a synthetic transaction against an application, gathering performance data to be evaluated against a threshold, or retrieving a status of some aspect of the application. Script monitors incur more overhead than the other types of monitors and should be used only when one of those monitors does not provide the required functionality.

Script monitors can use either two states or three states. Criteria must be defined for each state using values from the property bag created by the script. The kinds of values in the property bag will vary depending on the particular script. A numeric value might be compared to a threshold value as in a performance monitor. In that case, the healthy state might be defined by the value being under the threshold value while the critical state is defined by the value being over the same threshold. A synthetic transaction might return a text result indicating whether the test was successful or not. In that case, the criteria for each state would be the string indicating that particular health.

144

See AlsoMonitoring Scripts

How to create a monitor based on a script

How to create a monitor based on a Windows PowerShell script

Service MonitorsService monitors measure the running state of a Windows service. There is no configuration required other than the name of the service. This is a two state monitor with the monitor sets the monitor to a healthy state if the service is running and a critical state if the service is not running. The monitor can be configured to check the startup type of the service. This ensures that the service is only monitored if its startup type is set to automatic.

Aggregate MonitorsAggregate monitors group multiple monitors to provide a single health aggregated health state. This provides an organization to all of the monitors targeted at a particular class and provides a consolidated health state for specific categories of operation.

Standard Aggregate MonitorsEvery class has four standard aggregate monitors: Availability, Configuration, Performance, and Security. These are in the System.Health.Library management pack and targeted at the Entity class. Because all classes inherit from the Entity class, all classes inherit these standard monitors. The standard set of aggregate monitors will be sufficient for most classes.

Most monitors will fall into one of the four categories represented by the standard aggregate monitors. Because of this, custom aggregate monitors will typically use one of the standard aggregate monitors as their parent instead of being positioned alongside them directly under the entity health. Unit monitors and dependency monitors will similarly use either a custom aggregate monitor or one of the standard aggregate monitors as their parent.

Standard aggregate monitors

145

Custom Aggregate MonitorsManagement packs can include custom aggregate monitors specific to the requirements of classes in a particular application. These monitors may use another aggregate monitor for their parent or the top level Entity State similar to the standard aggregate monitors use. Custom aggregate monitors can be configured underneath another aggregate monitor or attached directly to the entity state.

For example, the Windows Server 2008 Operating System (Monitoring) management pack includes an aggregate monitor called Microsoft.Windows.Server.2008.OperatingSystem.CoreServicesRollup that is used to combine the health of the different services that are monitored by this management pack. There are nine services that the management pack considers critical to the operation of a computer running Windows Server 2008. Instead of positioning these directly under the Availability aggregate monitor alongside other unit monitors, the aggregate monitor provides a combined health measurement for all the related services.

This aggregate monitor is illustrated in the following diagram.

Core Windows Services Rollup aggregate monitor

146

Health Rollup PolicyEach aggregate monitor must define a health rollup policy which is the logic that is used to determine the health of the aggregate monitor based on the health of the monitors under it. The possible health rollup policies for an aggregate monitor are as follows:

Worst stateThe state of the aggregate monitor matches the state of the child monitor with the worst health state. This is the most common policy used by aggregate monitors.

Worst state health policy

Best stateThe state of the aggregate monitor matches the state of the child monitor with the best health state.

Best state health policy

147

Dependency MonitorsDependency monitors let the health of one object be affected by the health of another object. This allows for health rollup between specific related instances of different classes.

Each dependency monitor is based on a specific hosting or containment relationship. Just creating a relationship between two objects does not alone provide rollup between their health states. A dependency monitor must be associated with the relationship for rollup of health to be performed.

The source and target class for a dependency monitor are defined by the relationship that the monitor is based on. The monitor must additionally specify a specific unit monitor or aggregate monitor on the target class and an aggregate monitor on the source class. Only the health of the target monitor is considered when calculating the health of the dependency monitor, and it only affects the health of the specified aggregate monitor on the target object.

Dependency monitor based on unit monitor

Dependency monitor based on aggregate monitor

148

Multiple dependency monitors can be created on a single relationship if the health of the source class should be affected by multiple unit or aggregate monitors on the target class. For example, a dependency monitor might be created for each standard aggregate monitor as shown in the following image.

Multiple dependency monitors for a single class

Health Rollup PolicyThere may be multiple instances of the target class, each with a different health state. Each dependency monitor must define a health rollup policy to define the logic that is used to

149

determine the health of the dependency monitor based on the health of the instances of its target monitor. The possible health rollup policies for a dependency monitor are as follows:

Worst state policyThe source object matches the state of the target object that has the worst health state. This is used when the source object should only be healthy if all the target objects are healthy. This is the most common policy used by dependency monitors.

Worst state health policy

Best state policyThe source object matches the state of the target object that has the best health state. This policy is used when only one of the source objects has to be healthy for the target object to be healthy.

For example, the Microsoft Windows Hyper-V 2008 Monitoring management pack has a dependency monitor on the hosting relationship from Microsoft.Windows.HyperV.ServerRole to Microsoft.Windows.HyperV.VirtualNetwork that uses a best state policy. This is because the Hyper-V server is functional as long as it has one functional virtual network. The logic defined by this management pack is that the server class should show an error state if no virtual networks are available.

Best state health policy

150

Percentage policyThe source object matches the worst state of a single member of a specified percentage of target objects in the best state. This policy is used when a certain percentage of target objects must be healthy for the target object to be considered healthy.

For example an application might run on a web farm that includes multiple Web servers. Because of the redundancy offered in this kind of deployment, the application might be considered healthy if a particular percentage of servers is available. The farm itself could be represented in the management pack by a health rollup class based on System.ApplicationComponent with a containment relationship to the Web servers. A dependency monitor could be created on this containment relationship with a health rollup policy specifying a percentage. Even if one or more Web servers had a problem, as long as the specified percentage were in a healthy state then the class representing the web farm would also be healthy.

Percentage health policy

Health Rollup between AgentsHealth state can only be rolled up between objects managed by the same agent unless the source object is managed by the Root Management Server. Groups and classes used for health rollup are typically unhosted. This means that they are managed by the RMS so that they can roll up health from objects managed by different agents. A relationship can be discovered between objects managed by different agents, but any dependency monitor associated with that relationship will not work as expected.

Health rollup between agents

151

Alerts from MonitorsMonitors can be configured to create an alert when they change from a healthy state to a warning state or a critical state. This alerting can be enabled on a monitor but just enabling the option, but other details of the alert should be considered.

Alert NameThe name of the alert is a single line of static text and cannot include any variables.

Alert DescriptionThe alert description may have several lines of text that includes static text or variables. The most common kind of variable in the alert description will be $Data variables to include different information from the monitor’s data source in the description of the alert. The properties that are available will depend on the kind of data source being used. Each section of Data Sources includes a list of the properties available for different data sources. The following table provides the syntax and examples of variables in monitor alerts created from different data sources:

152

Data Source

Syntax Examples

Windows Event

$Data/Context/<Property Name>$ $Data/Context/EventDescription$

$Data/Context/Params/Param[#]$ $Data/Context/Params/Param[2]$

Text Log

$Data/Context/<Property Name>$ $Data/Context/LogFileName$

$Data/Context/Params/Param[1]$ $Data/Context/Params/Param[1]$

Delimited Text Log

$Data/Context/<Property Name>$ $Data/Context/LogFileName$

$Data/Context/Params/Param[#]$ $Data/Context/Params/Param[2]$

WMI Event

$Data/Context/Collection[@Name='<TargetInstance|PreviousInstance>']/Property[@Name='<PropertyName>']$

$Data/Context/Collection[@Name=’TargetInstance’]/Property[@Name='Name']$

Windows Performance

$Data/Context/<PropertyName>]$ $Data/Context/Value$

WMI Performance

$Data/Context/<PropertyName>]$ $Data/Context/Value$

Monitoring Script

$Data/Context/Property[@Name='<PropertyName>']$

$Data/Context/Property[@Name='Result'>']$

Priority and SeverityThe Alert severity defines the alert as an Information, Warning, or Critical alert. This severity does not have to match the severity of the health state triggering the alert. The severity of the alert is identified by an icon in the Operations console and is used by views and notification subscriptions. The alert priority is inaccessible in the Operations console but is used primarily for notification subscriptions.

153

Alert Suppression

Alert suppression is not required for monitors because alerts are only created when the monitor changes state. For example, consider a monitor that samples a performance counter on a regular interval. When the threshold is exceeded, the monitor changes to a critical state and creates an alert. The next time that the monitor samples the counter its value still exceeds the threshold. The monitor does not change state because that monitor is already in a critical state. Because the monitor does not change state, no alert is created.

Automatic Alert ResolutionMonitors that create alerts can be configured to automatically resolve the alert when the monitor returns to a healthy state. This means that any unresolved alert for the monitor represents a problem that still exists. There is no configuration this requirement other than confirming the option that automatic resolution be performed.

See AlsoData Sources

Unit Monitors

Diagnostics and RecoveriesDiagnostics and recoveries are workflows that run when a monitor changes state. Diagnostics collect additional information about the detected problem. Recoveries try to resolve the problem. Each will typically run a command or script that outputs information displayed in the Health Explorer in the Operations Console.

The Operations console provides a wizard for creating both diagnostics and recoveries. The Authoring console lets both diagnostics and recoveries be created from the properties of a monitor, although the individual modules must be selected and configured. Complete details on the concepts and use of modules in a management pack are provided in the Composition section of this guide. This section will provide a simplified discussion of these concepts specific to diagnostics and recoveries.

DiagnosticsDiagnostics are workflows that run after a monitor changes state and try to collect additional information about the issue. This information is provided to the user with the state change history in the properties of the monitor. If the enabled property of the diagnostic is set to true, then it is run automatically when the monitor changes state. If the disabled property of the diagnostic is

154

set to false, then a link is provided to the user in the Operations console that they can click to run the diagnostic.

Diagnostics are not intended to make any changes to the application or system that they are running on. Because they are running a script or command, however, there is no way for Operations Manager to make sure that these changes are not being made. It is the responsibility of the management pack author to make sure that no such changes are being made. If changes to the application or system are required, then a recovery should be used.

Diagnostic

RecoveriesRecoveries are workflows that run after a monitor changes state. Recoveries try to correct the issue, and return the monitor to a healthy state. Any output from the recovery is provided to the user with the state change history in the properties of the monitor that the diagnostic is associated with. If the enabled property of the recovery is set to true, then the recovery is run automatically when the monitor changes state. If the disabled property of the recovery is set to false, then a link is provided to the user in the Operations console that they can click to run the recovery.

Recovery

Recoveries are intended to change the application or system that they are running on. Therefore, significant consideration should be taken before they are configured to run automatically. A poorly planned recovery script could actually cause more problems than it is intended to help. For example, the recovery may temporarily correct issue but not the underlying cause of the problem. In this case, the monitor may return to a healthy state because of the recovery, but then return to an error state when the issue is again detected. The recovery would then run in response, and so on, until a user is able to intervene and correct the root problem. This kind of problem can be limited by disabling the recovery so that the user must run it instead of it running automatically.

Another option is to run a recovery after a diagnostic. Using this strategy the diagnostic first collects additional information about the issue which the recovery then uses that information to determine whether it should run. This is implemented in the Authoring console by configuring

155

condition detection with the recovery. The condition detection uses output from the diagnostic to determine whether it should run.

Recovery running after a diagnostic

Recalculating StateIf a recovery is successful, then the monitor should return to a healthy state the next time that the monitor detects the required information. If the monitor runs a scheduled script for example, then the monitor will return to healthy the next time that the script runs and the monitors detects the criteria for a healthy state. If the monitor relies on an event for its healthy state, the application is expected to create the required event in response to the recovery successfully correcting the problem. If a monitor is configured to use a manual reset though, then the user will still be required to manually set it to a healthy state.

A recovery can be configured to recalculate the state of the monitor immediately after it runs. This option has the same effect as the user selecting Recalculate Health for the monitor in the Operations console. Recalculating state only has an effect on monitors that run on a schedule such as a script and that have on demand detection defined. If the monitor does not have on demand detection defined, then the option has no effect. The advantage of configuring a monitor to recalculate state is that it can return the monitor to a healthy state immediately instead of waiting for the schedule.

When Diagnostics and Recoveries RunDiagnostics and recoveries run in response to a change in a monitor’s state. They do not run every time their specified state is detected; only when the monitor changes to that state from another state. For example, a particular monitor might run a script every few minutes to test a particular feature of an application. A diagnostic could be defined to run when the monitor’s health is critical. The diagnostic will only run when the monitor changes from a healthy or a warning state to a critical state when the script first identifies a problem. Assuming the problem has not been corrected the next time that the script runs, the monitor will still be in a critical state. The diagnostic will not run though because no state change will have occurred. It will only run when the monitor returns to a healthy state and then changes again to a critical state.

ModulesThe concept of modules in a workflow is discussed in detail in the Composition section. Frequently, the Authoring console can provide wizards and other means of assistance to help the

156

author with this complexity. The wizards create workflows by using the same modules, although the user is provided with an easier interface. Recoveries and diagnostics can be configured from the Authoring console in the properties dialog box of the monitor, but their modules must be configured manually.

The following table provides a listing of common modules that are used in diagnostics and recoveries:

Module Used In Function

Microsoft.Windows.ScriptProbeAction Action Runs a script in either VBScript or Jscript.

Microsoft.Windows.PowerShellPropertyBagProbe Action Runs a script in Windows PowerShell.

System.CommandExecuter Action Runs an executable on a command line.

System.ExpressionFilter Condition Detection Evaluates output from a diagnostic to determine whether recovery should be run.

Examples of the use of these modules are provided in the Building a Health Model section of this guide.

RulesRules in System Center Operations Manager 2007 use the same Data Sources as monitors but provide different functionality. While a monitor changes state, a rule performs one of the following three functions:

Create an alert that is not related to health state. Collect performance or event data for analysis and reporting. Run a script or command.

In This SectionAlert Rules

Rules that create alerts not related to the health state of an managed object.

157

Collection RulesRules that collect event or performance data.

Alert RulesAlert rules create alerts in response to particular conditions detected in a data source. This is the same kind of alert that is created by a monitor when it changes state. Monitors and alert rules use the same data sources and typically the same kind of logic for determining whether an error has occurred.

A monitor that creates an alert is generally preferred over an alert rule identifying the same issue for the following reasons:

Monitors set a health state on the target object in addition to creating the alert. This identifies the category of the detected problem, the application component affected, and its effect on the overall health of the application. The health state is also recorded for availability reports that provide historical record of the availability of the application.

Alerts created by monitors can be automatically resolved when the application returns to a healthy state. Alerts created by rules cannot be automatically resolved because there is no method of determining the healthy state.

The situations when a rule should be used instead of a monitor to create an alert are as follows:

The problem being detected does not relate to the health of the application. For example, an application may perform an automated nightly backup. If the backup fails, then an alert should be created to inform users of this condition. The application though is still completely healthy and should not record a negative health state.

A monitor is cannot determine when the detected problem was resolved. One of the options to this condition is to use a rule to create an alert instead of a monitor. This situation is discussed with additional options in the Event Monitors section of this guide.

Event Alert RulesAlert rules can be created for each event data source. The criteria that is specified to determine when an alert should be created is the same as the criteria for a state change in the event monitors.

Performance Alert RulesThe Authoring Console provides no wizards for creating an alert rule based on a performance counter. A monitor should be used instead because a success condition is usually detectable from a performance counter and is usually related to some health state of the target class. Alert rules based on a performance counter can be created, although they must be done with a custom rule.

158

Scripting Alert RulesThe Authoring Console provides no wizards for creating an alert rule based on a script. A monitor should be used instead because a script will typically provide a return value for both and error and a healthy state in such a way that a success condition is usually detectable and related to some health state of the target class. Alert rules based on a script can be created, although they must be done with a custom rule.

Alerts from Rules

Alert NameThe name of the alert is a single line of static text and cannot include any variables.

Alert DescriptionThe alert description may have several lines of text that includes static text or variables. The most common kind of variable in the alert description will be $Data variables to include different information from the rule’s data source in the description of the alert. The properties that are available will depend on the kind of data source being used. Each section of Data Sources includes a list of the properties available for different data sources. The following table provides syntax and examples of variables in rule alerts created from different data sources:

Data Source

Syntax Variable

Windows Event

$Data/<Property Name>$ $Data/EventDescription$

$Data/Params/Param[#]$ $Data/Params/Param[2]$

Text Log

$Data/EventData/DataItem/<PropertyName>$

$Data/EventData/DataItem/LogFileName$

$Data/EventData/DataItem/Params/Param[1]$


Delimited Text Log


$Data/EventData/DataItem/LogFileName$

$Data/EventData/DataItem/Params/Param[#]$


WMI Even

$Data/EventData/DataItem/Collection[@Name='<TargetInstanc

$Data/EventData/DataItem/Collection[@Name='TargetInstance']/

159

Data Source

Syntax Variable

t e | PreviousInstance>']/Property[@Name='<PropertyName>']$

Property[@Name='Name']$

Syslog Event


$Data/EventData/DataItem/Facility$

Priority and SeverityThe Alert severity defines the alert as either Information, Warning, or Critical. This severity does not have to match the severity of the health state triggering the alert. The severity of the alert is identified by an icon in the Operations console and is used by views and notification subscriptions. The alert priority is inaccessible in the Operations console but is used primarily for notification subscriptions.

Alert SuppressionAlert suppression refers to logic that is defined on alert rules to suppress the creating an alert when a corresponding alert is still open. This prevents alert storms where multiple alerts are created for the same issue. Because the issue has already been identified with an open alert, creation of additional alert creates unnecessary noise with minimal value. When the condition for an alerting rule is met but an existing alert is already open, instead of creating an additional alert suppression will increase the repeat count of the existing alert.

In order to define suppression on an alerting rule, the fields must be specified that identify a matching alert. Before an alerting rule creates a new alert, it will check whether an open alert exists with values for the fields that are defined for suppression that match the fields of the new alert. If an alert with matching values for each of these fields is open, then a new alert is not created.

The minimum number of fields that uniquely identify the alert should be specified for alert suppression. This is typically the computer name in addition to the fields used for the criteria of the rule. For example, suppression on event rules can frequently be achieved by using the following fields:

Logging Computer Event Source

160

Event Number

If the rule is targeted at a class that has multiple instances on the agent, however, then a parameter might be required to uniquely identify the event in the criteria of the rule. If this is the case, then the same parameter should be specified in the alert suppression.

Automatic Alert ResolutionAutomatic resolution cannot be performed on alerts that are created from a rule since a rule has no mechanism for determining that

Collection RulesCollection Rules are used to collect data into the Operations Manager database and data warehouse for analysis in views and into the Data Warehouse for use in reports. Even though a particular data source might be used for a monitor or alerting rule, a collection rule is still required if its information is to be available for this analysis. For example, a monitor may sample a performance counter on a regular interval and compare the value to a threshold in order to set its state. It will not store this information however, so a collection rule is also required using the same performance counter if the data is required to be views.

Collection rules describedCollection rules store data as either events or performance data, and any data source must have its data mapped into one of these data types. Each kind of collection rule is described in the following sections:

Event Collection RulesEvents in System Center Operations Manager 2007 can be collected from any of the data sources detailed in the Events section of this guide. For most data sources, all that is required is the criteria for which events are to be collected. This criteria is specified using the properties available to the particular data source being used.

Script Based Event CollectionScript based event collection runs a monitoring script on a regular schedule and stores the results as an event. The monitoring script returns a property bag as described in the Monitoring Scripts section of this guide. The performance collection rule maps values of the property bag into properties of the event by using $Data variables referring to different values in the property bag.

Event properties that the rule may populate are listed in the following table:

161


Computer The computer logging the event. Typically uses the PrincipalName property of the target object’s host computer.

Event source The source of the event. Typically either a static string or a value from the property bag.

Event log The name of the event log. Typically either a static string or a value from the property bag.

Event ID The number of the event. Typically either a static string or a value from the property bag.

Category The category of the event.

Level The level of the event. Typically selected from the list of available options.

Parameters Multiple values that contains data that does fit into the other properties. Typically one or more values from the property bag.

See AlsoEvents

Alert Rules

How to create a script-based event collection rule

Performance Collection RulesPerformance data can be collected in System Center Operations Manager 2007 from any of the data sources detailed in the Performance Data section of this guide. This section provides the details required for specifying the source of the data and the properties available for specifying the criteria for the data to be collected.

Script Based Performance CollectionScript based performance collection runs a monitoring script on a regular schedule and stores the results as performance data. The monitoring script returns a property bag as described in the Monitoring Scripts section of this guide. The performance collection rule maps values of the property bag into properties of the performance data by using $Data variables referring to different values in the property bag.

162

Performance data properties that the rule must populate are listed in the following table:


Object Name of the performance object. This is typically a static value but may be a $Data variable to retrieve a value from the property bag returned from the script.

Counter Name of the performance counter. This is typically a static value but may be a $Data variable to retrieve a value from the property bag returned from the script.

Instance Name of the instance if it is specified. If the target of the rule has a single instance on the agent, the instance name may not be specified. If the target of the rule has multiple instances on the agent, an instance name should be specified by using a $Target variable to retrieve the value of a unique property to identify the target object.

Value The numeric value to store. This is typically a $Data variable to retrieve a value from the property bag returned from the script.

Optimized CollectionPerformance collection rules based on Windows performance counters can be configured to perform optimized collection. Optimized collection reduces the space that is required by only sampling those performance counters that differ significantly from a previously sampled counter.

When optimized collection is specified, a tolerance must be specified that indicates the value that the sampled data must differ from the previously sampled value for the data to be stored. This tolerance can be either an absolute number or a percentage. An absolute tolerance evaluates the difference between the current and the last counter. A percentage tolerance evaluates the difference as a percentage of the previously sampled value.

An example of optimized collection is the Microsoft.Windows.Server.2008.LogicalDisk.FreeMB.Collection rule in the Windows Server 2008 Operating System (Monitoring) management pack. This rule collects the free space in MB on a logical disk every 5 minutes. Free disk space is a value that typically changes gradually, and under most conditions collecting it with this frequency would create an excess number of sampled counters with minimal value. Increasing the frequency of collection though would introduce the chance of missing those periods where a sudden change in the value did occur.

163

This rule uses optimized collection specifying an absolute value of 100 MB. This means that the counter is sampled every 5 minutes, but the value is only stored if it differs from the last stored value by 100 MB. This still lets it to perform its sampling at a fairly frequent rate but significantly reduces its storage requirements by reducing the number of unnecessary data points.

See AlsoPerformance Data

TasksTasks in System Center Operations Manager 2007 are actions that can be run on demand by the user. Depending on the kind of task, the action may run either on the user’s local workstation or on one or more specified agents.

In This SectionConsole Tasks

Tasks that run on the user’s workstation using the current user’s credentials.

Agent TasksTasks that run on the agent computer using the credentials of the specified user profile.

Console TasksConsole tasks run on the workstation where the Operations Console is running and uses the same credentials as the logged on user. The application that is run by the task must be installed on the workstation.

Console task

164

Console tasks are useful for running administration consoles or other tools that remotely access application components. These will usually be executable programs that run outside the Operations console. $Target variables can be used to provide values of properties on the target object or one of its parents to be included on the command line.

For example, an administration console might require the name of the server that is running the application. The target for the task could be a class based on Windows Computer Role representing the application installation on the server. The task would only be available when an instance of the target class is selected. Because the class is hosted by Windows Computer, the PrincipalName property could be provided on the command line.

Agent TasksAgent tasks in System Center Operations Manager 2007 are run on the agent computer where the target object is managed. An agent task can be a script or an executable program run from a command line. If an executable program is used, the application must be installed on the agent computer.

Agent tasks are useful for performing actions on the agent computer or for retrieving information for the user. They provide the following capabilities:

Run a script or command locally on the agent computer without logging on to the computer interactively.

Run a script or command on multiple agents with a single action. Run a script or command by using local user credentials with permissions not available to the

user.

Agent Task

CredentialsUnless otherwise specified, tasks run under the credentials of the Default Action Account on the agent computer. This account typically has sufficient privileges for accessing most application components, even if the user running the task does not have these user rights. If the task is required to perform an action requiring other credentials, such as accessing an external data source, then a secure reference can be created in the management pack for running the task. Or, the user can be required to specify credentials when they run the task.

165

OutputAny output sent to the standard out stream (StdOut) from the script or command is provided to the user as Task Output in the Operations Console. Command line programs will typically output information to this stream. Scripts should output information by using commands such as WScript.Echo to provide this information.

Kinds of agent tasksWhether an agent task is configured to run a command or a script, it must specify whether it uses a probe action or a write action. This specifies the kind of module that is used by the task as described in the Composition section of this guide. There is no difference in the configuration or the capabilities between two. Probe action modules are intended to gather information without making any change to the agent computer, whereas write action modules are intended to make some change or perform an action on the agent.

Health Model Design OverviewDesigning a health model System Center Operations Manager 2007 for an application consists of determining the required set of monitors to accurately measure the health of each class in the service model. Dependency monitors are defined to order to roll up health between classes and provide an overall application health. Rules are added to collect valuable information for analysis and reporting.

The following sections provide a basic process to help you design a health model to monitor an application. This process is not intended to apply to all applications, although this assumes a service model that uses the basic process presented in the Service Model Design Overview section of this guide. The basic principles followed in both processes should apply to most applications monitored by a management pack.

In This SectionFailure Mode Analysis

Overview of a process for software developers to follow what they include monitoring instrumentation in an application.

Defining MonitorsBasic process for defining a set of monitors to accurately measure the health of each class in the service model.

166

Defining RulesBasic process for defining rules to augment health monitoring by collecting data for analysis and reporting.

Practices to AvoidCommon practices to avoid when you design a health model.

Failure Mode AnalysisFailure Mode Analysis is a process for identifying different issues that an application may experience and providing instrumentation within the application that may be used for monitoring. It is primarily used by software developers in designing their application, but the basic concepts may also be valuable to the management pack author designing a management pack. The process is discussed in detail in MP University which is a training program for designing and building management packs targeted at software developers. It is briefly described here, and the training program should be referenced for more information.

This topic presumes that the management pack author has no control over changes to the application itself, and the health model must be designed according to the information that the application makes available. The quality of a management pack though is directly affected by the quality this available information. If an application has features that cannot be monitored, then the management pack will be unable to provide a complete health measurement. Even if a basic failure can be detected, the management pack may be unavailable to identify the underlying cause of this failure unless the application makes that information available. If the management pack author can collaborate with software developers, then they may be able to influence modifications to the application itself that allow it to be monitored more effectively.

Basic ConceptThe basic concept of failure mode analysis is to analyze what can fail in an application and provide a means for detecting that failure. By implementing such instrumentation within the application, a management pack can accurately measure health of the application and detect any potential failures. Failure mode analysis resembles threat modeling because it is a proactive effort to identify potential weaknesses in the application. It is an attempt to identify the components of the application that are vulnerable to failure, what those failures may be, and how they might be detected.

167


Steps in Failure Mode Analysis

List what can go wrongThis list should go beyond software issues and also consider specific implementations and issues that can arise in the environment. It includes each component of the application and each component that the application relies on – such as network connectivity, server resources, and dependent software components. The underlying cause should be considered in this analysis to distinguish a failure from a symptom of that failure. For example, a database may run out of space causing other errors in the application.

As soon as a complete list is established, it should be prioritized according to the following criteria. This will assist in prioritizing instrumentation for the different scenarios.

Probably of the failure occurring Impact to overall system health Potential cost to the customer for a failure

Identify a detection strategy for each failure modeIdentifying a potential failure is useless if there is no way of detecting it. Each failure mode needs at least one means of detection, and especially high impact issues should have multiple means of detection. This detection could be a predictable error in code generating an event or may need additional code to continuously watch for a particular operation.

Add detection elements to application codeEach of the detections has to be added to the code of the application in order to expose this information to a management pack. Some of these elements may be monitors watching for particular event to occur, or they may be probes periodically performing some test or collecting some information. The result of the detection should be information that can be accessed by a management pack. This might be an event in the Windows event log or a performance counter providing a numeric measurement of the application’s health.

Plan management pack contentThe end result of failure mode analysis is to design the management pack based on the information exposed by the application. This will include defining monitors that use the events and performance counters exposed by the application in order to set appropriate health states on classes defined in the application’s service model.

Operational failuresThe following table lists a set of operational failures that impact most applications. This list can be referenced in identifying a set of potential failures for a particular application.

168

Category Failure Mode

Access Control Lists Insufficient permissions accessing resource

Run as account has expired

Run as account locked out

Run as account soon to expire

ACL on configuration resource too permissive

Capacity Disk is full

Disk utilization above threshold

Critical resource starved

Critical resource above threshold

Capacity trend predicts coming failure

Queue reads failing behind queue writes

Restart under load fails

Component is hung

Configuration Configuration file missing

Configuration file corrupt

Connection string incorrect

Critical setting missing or incorrect

Database Database offline

Login denied

Execute permission denied

Database doesn’t exist

Timeout on database connection

Index corrupt

Table or database corrupt

Transaction log full

SPID blockage

Incorrect results in configuration table

Network Access to critical network resource denied

169

Category Failure Mode

Critical network resource timing out

Average network latency exceeds tolerance

Throughput diminished causing backlog

Packet loss rate on subnet exceeds tolerance

Resend rate on subnet exceeds tolerance

Latency exceeds tolerance

Transaction Transaction rate below minimum threshold

Transaction response time above threshold

Transaction rate exceeds engineering limits

Incorrect response being returned

Failure response rate exceeds threshold

With these base causes for the failure identified, the part of the application that performs this database connection should include code to detect each failure and provide a unique event that may be accessed by monitors in the management pack. If the application just reports that the database connection failed, then the management pack cannot identify the underlying cause. Only if the application provides this detailed information can the management pack accurately detect the issue and identify the cause to the user.

Defining MonitorsThe first step in designing the health model for an application is defining monitors for each class in the service model. The goal is to provide a combination of different kinds of monitors to appropriately measure the health of each managed object. If the set of monitors are designed correctly, then any issue with the application will result in one or more monitors changing from a healthy state to warning or critical. If there are flaws in the design of the monitors, then the actual health of the application may not be accurately detected. An issue may occur in the application that is not recognized by a monitor, or a monitor may change to a negative state when the application is not actually experiencing a problem.

170

Define Unit MonitorsA combination of different kinds of monitors will frequently be required to accurately measure the health state of a particular class. The questions that can be asked for each class to define its monitors are as follows:

What functions does the object perform and how can each function be tested? Does the application provide this information or is a synthetic transaction required to test the functionality?

What information does the application create that might indicate a loss in functionality? Where is the information stored? What component of the application does it apply to? What, if any, indicators are there that the problem is corrected?

How can the performance of the application be measured? Does the application make this information available or is a synthetic transaction required to collect the information?

Are there any configuration requirements that could affect the operation of the application? Can this information be collected?

The answers to these questions will help in the definition of unit monitors to test different aspects of the application. It is important to define monitoring requirements for an application even if there is no identified ways to implement one or more of the required monitors. If a feature of an application provides no means of monitoring, then the application may experience an issue that the management pack will be unable to detect. This issue should at least be documented so that owners of the application understand the limitations of the monitoring being implemented. This information can also be used to work with developers to potentially change the application to make such monitoring possible.

As an example, the health model for the SQL Server 2008 DB class is shown here. This includes the SQL Server 2008 DB class itself in addition to the monitors for the SQL Server 2008 DB Engine class that hosts it and the SQL Server 2008 DB File class that it hosts. A diagram such as this can be useful in picturing the health of a particular class in addition to the classes directly related to it.

SQL Server 2008 DB health model

171

The database class itself is monitored by a combination of monitors by using events, scripts, and performance data to measure the health of each database. Availability status of the database cannot be retrieved through a simple method so that a script is required that connects to the database engine and validates the connection to each database. The script determines a status

172

for the database identifying whether it is available for connections. If a connection to the database cannot be made for any reason, then this monitor will change to a warning or critical state.

Configuration monitors are defined for both the SQL Server 2008 DB class and the SQL Server 2008 DB Engine class. For the database engine, the SQL Server service pack level is retrieved through WMI to determine whether it is at a required level. The user is expected to use an override to define the required level for their environment. Configuration monitors for each database are defined by using a script that retrieves different properties of the database and compares each to recommended values. Configuration of the database or database engine does not necessarily affect availability or performance, but providing monitors for these properties enables the user to identify configurations that do not match required standards for their environment and that could lead to eventual lead to issues with availability or performance.

Diagnostics and RecoveriesAs soon as monitors are defined, diagnostics and recoveries for each can be considered. Most monitors will not have either. Diagnostics are only defined if there is additional information to collect about the detected issue. Many monitors already contain all available information, or additional information must be collected manually by the user. Diagnostics should only be defined when additional information about the issue that may be useful to the user can be retrieved programmatically.

As discussed in the Diagnostics and Recoveries section of this guide, recoveries should only be defined after careful consideration. Because recoveries try to make some change to the external environment, they can cause issues in addition to the one they are responding to. The strategies discussed in that section of configuring recoveries to run manually or after a diagnostic can be used to lessen this risk. An automated recovery should only be configured in response to a monitor if the following two questions can be answered affirmatively.

Has the specific issue that the recovery is intended to correct been correctly identified? Does the recovery have a high degree of probability that it will correct the issue it is designed

to correct without causing adverse side effects.

These questions may seem common sense, but realize that there may be multiple root causes for the issue detected a monitor, and each may require a different kind of recovery. Before a recovery is configured to run automatically, it should be verified that it will only run in response to the cause that it is designed for.

One strategy for designing diagnostics and recoveries is to delay their definition until the management pack has run in production for a while. This allows monitors to change state in response to actual issues with the application. Analysis of these incidents and the manual steps that were taken to correct them can lead to automated responses defined in diagnostics and recoveries.

Define Aggregate MonitorsMost applications will be adequately managed by using the standard set of aggregate monitors. Additional aggregate monitors may be added to a management pack to group related unit

173

monitors targeted at a common class. This is performed either to make a large number of monitors more manageable or to provide a consolidated health state in a particular category.

For example, the Microsoft Windows DNS 2008 Server management pack includes an aggregate monitor called Resolution Rollup that is used for unit monitors that perform test resolutions and another called Services State Rollup used for unit monitors related to the state of DNS services. These aggregate monitors provide a combined health state for each set of related monitors and the Health Explorer for the state of the DNS Server 2008 class.

Define Dependency MonitorsAs soon as unit monitors are defined to measure the health of individual classes and each are configured underneath a standard or custom aggregate monitor, then dependency monitors can be defined to roll up health between instances of different classes.

Hosted ClassesAny classes that use Windows Computer Role as a base class will automatically have their health roll up to Windows Computer. This is because the Microsoft Windows Library management pack includes a dependency monitor for Windows Computer Role targeted at Windows Computer. No dependency monitor has to be defined in this case.

Classes that use Windows Local Application as a base class will not automatically have their health roll up to Windows Computer. If the health of these classes should rollup to the hosting computer, then a dependency monitor has to be created.

Classes that use Windows Application Component as a base class and are hosted by another class in the application’s service model require a dependency monitor if their health should be rolled up to the hosting class. The hosting relationship that is required for the dependency monitor will already be in place.

The rollup policy for these dependency monitors will typically be worst state so that any instance of the Application Component class in an error state will cause a corresponding error state on the parent object. Best state and percentage though may be used for those applications requiring different logic.

Health RollupsA dependency monitor will typically be defined for each containment relationship between any health rollup classes, if such classes are part of the application’s service model. The purpose for these classes is typically to roll up health for a set of objects, and this function is not performed without a dependency monitor. These dependency monitors will use different rollup policies based on their requirements. Worst state is the most common policy that is used, although best state and percent policies are common for health rollups.

174

Defining RulesAfter monitors and health state are defined for each class in the service model of a System Center Operations Manager 2007 management pack, rules can be defined.

Alerting RulesAlerting rules are used either when a monitor cannot reasonably be defined for a particular issue or when the issue does not relate to the health state of a particular class. The most common reason that a monitor cannot be defined is that there is no reasonable means of identifying that the issue was corrected. This is required to define the healthy state of the monitor. One strategy to address this challenge is using an alerting rule instead of a monitor.

Instead of creating an alerting rule, a monitor that uses a timer reset can be considered. We do not recommend a manual reset, especially targeted at a class that has multiple instances, because of the requirement that a user must always intervene to return the monitor to a healthy state. A timer reset monitor still influences the health state of the target object and will automatically reset to a healthy state if a user does not manually reset it in a specified time.

The other use of alert rules is to identify issues that do not relate to a health state. For example, the application might perform a data replication regularly. An alert should be created if the transfer fails, although the application is still fully functional. This issue is best identified through an alerting rule instead of a monitor.

A strategy that can be used to identify alert rules is to analyze all events created by the application that were not used in a monitor. These may be Windows events or may be provided in any of the event data sources previously discussed. Such events will typically identify errors in the application. Any events not used by a monitor are candidates for an alerting rule.

Minimizing NoiseA strategy of just creating an alerting rule for each event created by the application without analysis is not a best practice because excessive alerts can represent a source of noise in the Operations Manager environment with minimal value. Before you create any alerting rule, consideration should be given to whether the issue that is identified by the event is significant enough to create an alert. If the issue is minor, the event may just be collected for later analysis.

Analysis should also be performed to determine whether an event represents a unique issue not identified by another rule or monitor. A single application issue may have several symptoms generating multiple kinds of error events. There is minimal value in creating multiple alerts from the same root problem. Such noise can create too much work for the user and obscure alerts that identify other issues.

175

Collection RulesCollection rules augment health monitoring by collecting information for reporting and analysis in the Operations console. The most common collection rules will be those collecting performance data. This may be any Windows performance counters that are provided by the application or could be response times and other numeric data that is created by monitoring scripts.

The first data that should be considered for collection is any performance data that is used in monitors. The monitor sets health state based on comparing the numeric data to a threshold, but it does not store the data for analysis. Having trending and historical data to support the monitor will typically be useful for the end-user. Additional performance data that might be available should be defined taking into consideration storage requirements. If performance data is of minimal value in daily monitoring then it may not be worth the space that is required for its storage.

See AlsoAlert Rules

Collection Rules

Practices to Avoid

Focus on the easy–to-monitor instead of the requiredWe recognize the natural tendency to start a health model design for an application by analyzing the monitoring information made available by the application through events and other easily obtained information. However, this approach assumes that the application is proactively identifying all issues and may leave a significant potential for an application issue to go undetected. If an application has a problem that does not generate an event or other information, then the issue will require a synthetic transaction or other way of identification.

One consistent strategy is to analyze the different features and potential issues for each classe defined in the service model. A process such as Failure Mode Analysis can help in this analysis. As soon as the monitoring requirements are identified, appropriate monitors and rules can be defined to address those requirements. This strategy encourages development of synthetic transactions and other proactive monitoring techniques in order to obtain information that the application does not make available on its own.

Running monitors and rules too frequentlyMonitors and rules that use a script or WMI query that run too frequently can result in excess overhead on the agent. The overhead will vary, depending on the script or query and the number

176

of other scripts and queries in the management pack. A general guideline is not to run a script or query at any interval more frequently than 5 minutes. Even with this guidance, the script or query should not be run any more frequently than is required for needed monitoring.

For collection rules, too frequent collection can result in significantly increased storage requirements and return minimal value. Although a single performance value is fairly small, storage requirements quickly accumulate for collection targeted at multiple instances across multiple agents. We recommend that you never have a collection frequency less than 5 minutes for counters with significant volatility. A frequency of 15 minutes is effective for counters with less variance. It also a best practice to use optimized collection for any counter that is not expected to consistently have a significantly different value between consecutive samples.

Multiple scripts running at the same timeIf several monitors and rules that are running scripts are defined to run on the same interval, then there is a potential for them to consistently run at the same time. Every time that the interval arrives, all the scripts run, and a noticeable affect can be observed on the agent processor. One method to avoid this condition is to use a different synchronization time for each monitor or rule to make sure that they run at different times.

Targeting classes with multiple instancesAs is discussed in the Targets section of this guide, a workflow targeted at a class that has multiple instances on an agent will have multiple copies of the workflow running on the same agent. Such workflows will typically require additional criteria by using a $Target variable to uniquely identify the particular instance. Failure to provide unique criteria can result in multiple alerts being created for a single event, or all instances of a particular class entering an error state instead of a single instance.

See AlsoTargets

Monitoring Scripts

Health Model Design Overview

Building a Health ModelThe following sections provide walkthroughs of the activities required to implement a health model in System Center Operations Manager 2007.

177

In This Section

Creating MonitorsCreate different types of monitors by using the Operations Manager Authoring console.

Creating Diagnostics and RecoveriesCreate diagnostics and recoveries by using the Operations Manager Authoring console.

Creating RulesCreate different types of rules by using the Operations Manager Authoring console.

Creating MonitorsThe following procedures provide guidance on how to create monitors in the Operations Manager 2007 Authoring console.

In This SectionHow to create an event monitor

Create a monitor from a single Windows event.

How to create an event monitor targeted at class with multiple instancesCreate a monitor from a single Windows event monitoring a class with multiple instances.

How to create a repeating event monitorCreate a monitor from a single Windows event occurring multiple times within a specified timeframe.

How to create a monitor based on a scriptCreate a monitor from data retrieved from a script.

178

How to create a WMI event monitorCreate a monitor from a WMI event.

How to create a consecutive sample performance monitorCreate a monitor from a consecutive samples of a performance counter.

How to create a dependency monitorCreate a monitor from a consecutive samples of a performance counter.

How to create an event monitorThe following procedure shows how to create an event monitor in the Operations Manager 2007 Authoring console. Before you perform this procedure, you must first complete the prerequisite procedure How to Create a Class in which you create the target class.

The monitor created in this procedure has the following characteristics:

Runs on any computer that has an instance of MyComputerRole1. Sets the monitor to a critical state when an event in the Application event log with an event

source of MyApplication and an event number of 101 is detected. Sets the monitor to a healthy state when an event in the Application event log with an event

source of MyApplication and an event number of 102 is detected.

1. In the Authoring Console, select Health Model, and then select Monitors.2. In the Monitors pane, expand Computer Role 1, and then expand

System.Health.EntityState.3. Right-click System.Health.AvailabilityState, select New, select Windows Events,

select Simple, and then select Event Reset.4. On the General page, do the following:

a. In the ElementID box, type MyMP.Monitor.MyApplicationEventError.b. In the Display Name box, type MyApplication Event Error.c. In the Target box, select MyMP.MyComputerRole1.d. In the Parent Monitor box, select System.Health.AvailabilityState.e. In the Category box, select AvailabilityHealth. Click Next.

5. On the Event Log (Unhealthy Event) page, in the Log Name box, keep the default value of Application. Click Next.

6. On the Event Expression (Unhealthy Event) page, do the following:

To create an event monitor

179

a. For the Event ID value, type 101b. For the Event Source value, type MyApplicationc. Click Next.

7. On the Event Log (Healthy Event) page, in the Log Name box, keep the default value of Application. Click Next.

8. On the Event Expression (Healthy Event) page, do the following:a. For the Event ID value, type 102b. For the Event Source value, type MyApplicationc. Click Finish.

9. Expand System.Health.AvailabilityState.10. Right-click MyMP.Monitor.MyApplicationEventError and select Properties.11. On the Health tab, for FirstEventRaised, change the Health State to Critical.12. On the Alerting tab, check Generate alerts for this monitor.13. Click OK.

See AlsoEvents

Event Monitors

How to create an event monitor targeted at class with multiple instancesThe following procedure shows how to create an event monitor in the Operations Manager 2007 Authoring console that is targeted at a class that has multiple instances on the agent. Because multiple instances are expected, additional criteria is required that includes a property of the target object. This ensures that each copy of the monitor applies to only a single instance of the target class. Before you perform this procedure, you must first complete the prerequisite procedure How to Create a Class in which you create the target class.


Runs on any computer that has one or more instances of MyApplicationComponent. Sets the monitor to a critical state when an event in the Application event log with an event

source of MyApplication and an event number of 201 is detected. Sets the monitor to a healthy state when an event in the Application event log with an event

source of MyApplication and an event number of 202 is detected. The name of the component is included in parameter 1 of the event.

To create an event monitor

180

1. In the Authoring console, select Health Model, and then select Monitors.2. In the Monitors pane, expand My Application Component and then

System.Health.EntityState.3. Right-click System.Health.AvailabilityState, select New, select Windows Events,

select Simple, and then select Event Reset.4. On the General page, do the following:

a. In the ElementID box, type MyMP.Monitor.MyApplicationComponentEventError.b. In the Display Name box, type My Application Component Event Error.c. In the Target box, select MyMP.MyApplicationComponent.d. In the Parent Monitor box, select System.Health.AvailabilityState.e. In the Category box, select AvailabilityHealth. Click Next.

5. On the Event Log (Unhealthy Event) page, in the Log Name box, keep the default value of Application. Click Next.

6. On the Event Expression (Unhealthy Event) page, do the following:a. For the Event ID value, type 201b. For the Event Source value, type MyApplicationc. Click Insert.d. Click the button to the right side of the Parameter Name box on the new entry.e. Select Specify event specific parameter to use.f. Specify 1 for the event parameter.g. Click OK.h. In the Operator box, select equals.i. Click the button to the right side of the Value box and select ComponentName.j. Click Next.

7. On the Event Log (Healthy Event) page, in the Log Name box, keep the default value of Application. Click Next.

8. On the Event Expression (Healthy Event) page, do the following:a. For the Event ID value, type 202b. For the Event Source value, type MyApplicationc. Click Insert.d. Click the button to the right side of the Parameter Name box on the new entry.e. Select Specify event specific parameter to use.f. Specify 1 for the event parameter.g. Click OK.h. In the Operator box, select equals.i. Click the button to the right side of the Value box and select ComponentName.j. Click Finish.

9. Expand System.Health.AvailabilityState.

181

10. Right-click MyMP.Monitor.MyApplicationEventError and select Properties.11. On the Health tab, for FirstEventRaised, change the Health State to Critical.12. On the Alerting tab, check Generate alerts for this monitor.13. Click OK.

See AlsoEvents

Event Monitors

How to create a repeating event monitorThe following procedure shows how to create a repeating event monitor in the Operations Manager 2007 Authoring console. Before you perform this procedure, you must first complete the prerequisite procedure How to Create a Class in which you create the target class.


Runs on any computer that has an instance of MyComputerRole1. Sets the monitor to a critical state when an event in the Application event log with an event

source of MyApplication and an event number of 201 is detected 3 times within 5 minutes. Sets the monitor to a healthy state when an event in the Application event log with an event

source of MyApplication and an event number of 202 is detected.

1. In the Authoring console, select Health Model, and then select Monitors.2. In the Monitors pane, expand Computer Role 1 and then System.Health.EntityState.3. Right-click System.Health.AvailabilityState, select New, select Windows Events,

select Repeated, and then select Event Reset.4. On the General page, do the following:

a. In the ElementID box, type MyMP.Monitor.MyApplicationRepeatingEventError.b. In the Display Name box, type My Application Repeating Event Error.c. In the Target box, select MyMP.MyComputerRole1.d. In the Parent Monitor box, select System.Health.AvailabilityState.e. In the Category box, select AvailabilityHealth. Click Next.

5. On the Repeated Event Log page, in the Log Name box, keep the default value of Application. Click Next.

6. On the Repeated Event Log Expression page, do the following:a. For the Event ID value, type 201b. For the Event Source value, type MyApplication

To create a repeating event monitor

182

c. Click Next.7. On the Repeated Event Detection page, do the following:

a. For the Counting Mode, select Trigger on count, sliding.b. For the Compare Count, type 3.c. Select Based on items occurrence within a time interval.d. For the Interval, type 5 and select Minutes.

8. On the Repeated Event Log page, in the Log Name box, keep the default value of Application. Click Next.

9. On the Simple Event Log page, do the following:a. For the Event ID value, type 202b. For the Event Source value, type MyApplicationc. Click Finish.

10. Expand System.Health.AvailabilityState.11. Right-click MyMP.Monitor.MyApplicationRepeatingEventError and select Properties.12. On the Health tab, for RepeatedEventRaised, change the Health State to Critical.13. On the Alerting tab, check Generate alerts for this monitor.14. In the Alert description box, type Event 201 was detected $Data/Context/Count$

times between $Data/Context/TimeWindowStart$ and $Data/Context/TimeWindowEnd$. The first event was at $Data/Context/TimeWindowStart$. The last event was at $Data/Context/TimeWindowEnd$.

15. Click OK.

See AlsoEvents

Event Monitors

How to create a monitor based on a scriptThe following procedure shows how to create a monitor based on a monitoring script in the Operations Manager 2007 Authoring console. Before you perform this procedure, you must first complete the prerequisite procedure How to Create a Class in which you create the target class.


Runs on any computer with an instance of MyComputerRole1. Sets the monitor to a critical state when the script returns a status message of Bad. Sets the monitor to a healthy state when the script returns a status message of Good. The script accepts only a single argument for the computer name of the target object’s agent.

183

The script itself is only for testing and performs no real function. It simulates a script running a synthetic transaction.

1. In the Authoring Console, select Health Model, and then select Monitors.2. In the Monitors pane, expand Computer Role 1 and then System.Health.EntityState.3. Right click System.Health.AvailabilityState, select New, select Scripting and then

select Two State.4. On the General page, do the following:

a. In the ElementID box, type MyMP.Monitor.MyApplicationScriptMonitor.b. In the Display Name box, type My Application Script Monitor.c. In the Target box, select MyMP.MyComputerRole1.d. In the Parent Monitor box, select System.Health.AvailabilityState.e. In the Category box, select AvailabilityHealth. Click Next.

5. On the Schedule page, in the Run every box, type 15 minutes. Click Next.6. On the Script page, do the following:

a. For the File Name value, type MyScript.vbsb. For the Timeout value, type 1 minutesc. In the Script box, paste the complete contents of the following script.


bTestSuccessful = True


oAPI.LogScriptEvent "MyScript.vbs",10,4, "Running script on " & sComputerName


Call oBag.AddValue("ComputerName",sComputerName)

If bTestSuccessful = True Then

Call oBag.AddValue("Result","Good")

Else

Call oBag.AddValue("Result","Bad")

End If

oAPI.Return(oBag)

d. Click the Parameters button.e. Select Target, then select (Host=Windows Computer), then select Principal Name

To create a script monitor

184

(Windows Computer).f. Click OK.g. Click Next.

7. On the Unhealthy Expression page, do the following:a. Click Insert.b. In the Parameter Name box type Property[@Name='Result'].c. In the Operator box select Equals.d. In the Value box type Bad.e. Click Next.

8. On the Healthy Expression page, do the following:a. Click Insert.b. In the Parameter Name box type Property[@Name='Result'].c. In the Operator box select Equals.d. In the Value box type Good.e. Click Finish.

9. Expand System.Health.AvailabilityState.10. Right click MyMP.Monitor.MyApplicationScriptMonitor and select Properties.11. On the Health tab, for Error, change the Health State to Critical.12. On the Alerting page, do the following:

a. Check Generate alerts for this monitorb. In the Alert description box, type Result:

$Data/Context/Property[@Name='Result']$c. Click OK.


Script Monitors

How to create a WMI event monitorThe following procedure shows how to create a WMI event monitor in the Operations Manager 2007 Authoring console. Before you perform this procedure, you must first complete the prerequisite procedure How to Create a Class in which you create the target class.

In this example, criteria is included in the WMI query, so no expression is required in the monitor. The WMI event wizard in the Authoring console requires an expression for each

Note

185

event though. Because of this requirement, dummy expressions will be provided to complete the wizard and then deleted once the monitor is created.


Runs on any computer that has an instance of MyComputerRole1. Sets the monitor to a critical state when Notepad is started on the agent computer. Sets the monitor to a healthy state when Notepad is ended on the agent computer.

1. In the Authoring console, select Health Model, and then select Monitors.2. In the Monitors pane, expand Computer Role 1 and then System.Health.EntityState.3. Right-click System.Health.AvailabilityState, select New, select WMI Events, select

Simple, and then select Event Reset.4. On the General page, do the following:

a. In the ElementID box, type MyMP.Monitor.MyApplicationWMIEventError.b. In the Display Name box, type MyApplication WMI Event Error.c. In the Target box, select MyMP.MyComputerRole1.d. In the Parent Monitor box, select System.Health.AvailabilityState.e. In the Category box, select AvailabilityHealth. Click Next.

5. On the First WMI Event Provider page, do the following:a. In the WMI Namespace box, type root\cimv2.b. In the Query box, paste the following WMI query.

Select * From __InstanceCreationEvent WITHIN 60 Where TargetInstance ISA 'Win32_Process' and TargetInstance.Name = 'notepad.exe'

c. In the Poll Interval box, type 60.d. Click Next.

6. On the First Expression page, do the following:a. Click Insert.b. In the Parameter Name box type Dummy.c. In the Operator box select Equals.d. In the Value box type Dummy.e. Click Next.

7. On the Second WMI Event Provider page, do the following:a. In the WMI Namespace box, type root\cimv2.b. In the Query box, paste the following WMI query.

Select * From __InstanceDeletionEvent WITHIN 60 Where TargetInstance ISA 'Win32_Process' and TargetInstance.Name = 'notepad.exe'

To create a WMI event monitor

186

c. In the Poll Interval box, type 60.d. Click Next.

8. On the Second Expression page, do the following:a. Click Insert.b. In the Parameter Name box type Dummy.c. In the Operator box select Equals.d. In the Value box type Dummy.e. Click Finish.

9. Expand System.Health.AvailabilityState.10. Right-click MyMP.Monitor.MyApplicationWMIEventError and select Properties.11. On the Configuration tab, do the following:

a. Click Configure.b. Select the First Expression tab.c. Click Delete.d. Select the Second Expression tab.e. Click Delete.f. Click OK.

12. On the Health tab, for FirstEventRaised, change the Health State to Critical.13. On the Alerting tab, do the following:

a. Check Generate alerts for this monitorb. In the Alert description box, type Stopped process:

$Data/Context/Collection['TargetInstance']/Property[@Name='Caption']$c. Click OK.

See AlsoEvents

Event Monitors

How to create a consecutive sample performance monitorThe following procedure shows how to create a consecutive sample performance monitor in the Operations Manager 2007 Authoring console. Before you perform this procedure, you must first complete the prerequisite procedure How to Create a Class in which you create the target class.


Runs on any computer with an instance of MyComputerRole1.

187

Monitors the memory utilization on any computer with an instance of MyComputerRole1. Sets the monitor to a critical state when available memory is less than 100 MB for 4

consecutive samples. Sets the monitor to a healthy state when available memory is above 100 MB for a single

sample.

1. In the Authoring console, select Health Model, and then select Monitors.2. In the Monitors pane, expand Computer Role 1 and then System.Health.EntityState.3. Right click System.Health.PerformanceState, select New, select Windows

Performance, select Static Thresholds, and then select Consecutive Samples.4. On the General page, do the following:

a. In the ElementID box, type MyMP.Monitor.MyApplicationConsecutiveSampleMonitor.

b. In the Display Name box, type MyApplication Consecutive Sample Monitor.c. In the Target box, select MyMP.MyComputerRole1.d. In the Parent Monitor box, select System.Health.PerformanceState.e. In the Category box, select PerformanceHealth. Click Next.

5. On the Performance Counter page, do the following:a. Click Select.b. In the Object box, select Memory.c. In the Select counter from list box, select Available MBytes.d. Click OK.e. In the Interval box, type 15 and select Minutes.f. Click Next.

6. On the Threshold Comparison page, do the following:a. In the Value box, select less than and type 100.b. In the Number of samples box type 4.c. Click Finish.

7. Expand System.Health.PerformanceState.8. Right-click MyMP.Monitor.MyApplicationConsecutiveSampleMonitor and select

Properties.9. On the Health tab, for Condition True, change the Health State to Critical.10. On the Alerting tab, Check Generate alerts for this monitor.11. Click OK.


To create a consecutive sample performance monitor

188

Performance Monitors

How to create a dependency monitorThe following procedures show how to create a dependency monitor in the Operations Manager 2007 Authoring console. Before you perform these procedures, you must complete the following prerequisite procedures:

How to Create a Class - Create classes that will serve as both the source and target in relationships.

How to Create a Containment Relationship – Create containment relationship between classes that the dependency monitor will use.

The dependency monitors created in this procedure has the following characteristics:

Causes the health of instances of MyComputerRole1 to roll up to instances of MyComputerRole2 on the same agent.

One dependency monitor rolls up the health of the Availability aggregate monitor of MyComputerRole1 to the Availability aggregate monitor of MyComputerRole2.

One dependency monitor rolls up the health of the Performance aggregate monitor of MyComputerRole1 to the Performance aggregate monitor of MyComputerRole2.

Performs health rollup using worst state policy.

1. In the Authoring console, select Health Model, and then select Monitors.2. In the Monitors pane, expand MyMP.MyComputerRole2 and then

System.Health.EntityState.3. Right-click System.Health.AvailabilityState, select New, and then select Dependency

Monitor.4. In the Choose a unique identifier box, type

MyMP.MyComputerRole2DependsOnMyComputerRole1Availability. Click OK.5. On the General tab, do the following:

a. In the Display Name box, type My ComputerRole 2 Depends On My Computer Role 1 Availability.

b. In the Target box, select MyMP.MyComputerRole2.c. In the Parent Monitor box, select System.Health.AvailabilityState.

6. On the Monitor Dependency tab, do the following:a. Expand Entity Health for My Computer Role 1.b. Select Availability.

7. On the Health Rollup Policy page, select Worst state of any member.8. Click OK.

To create a dependency monitor on Availability aggregate monitor

189

1. In the Authoring console, select Health Model, and then select Monitors.2. In the Monitors pane, expand MyMP.MyComputerRole2 and then

System.Health.EntityState.3. Right-click System.Health.PerformanceState, select New, and then select

Dependency Monitor.4. In the Choose a unique identifier box, type

MyMP.MyComputerRole2DependsOnMyComputerRole1Performance. Click OK.5. On the General tab, do the following:

a. In the Display Name box, type My ComputerRole 2 Depends On My Computer Role 1 Performance.

b. In the Target box, select MyMP.MyComputerRole2.c. In the Parent Monitor box, select System.Health.PerformanceState.

6. On the Monitor Dependency tab, do the following:a. Expand Entity Health for My Computer Role 1.b. Select Performance.

7. On the Health Rollup Policy page, select Worst state of any member.8. Click OK.

See AlsoDependency Monitors

Creating Diagnostics and RecoveriesThe procedures in this section provide guidance on how to create diagnostics and recoveries in the Operations Manager 2007 Authoring console.

In This SectionHow to create a diagnostic

Create a diagnostic that runs a command.

How to create a recovery based on the output of a diagnosticCreate a diagnostic and recovery that run a script. The recovery only runs if certain output from the diagnostic is received.

To create a dependency monitor on Performance aggregate monitor

190

How to create a diagnosticThe following procedure shows how to create a diagnostic that runs a command in the Operations Manager 2007 Authoring console. Before you perform these procedures, you must complete the following prerequisite procedures:

How to Create a Class Create the target class for the monitor. How to create an event monitor Create the monitor that the diagnostic will respond to.

The diagnostic created in this procedure has the following characteristics:

Automatically runs when the MyMP.Monitor.MyApplicationEventError monitor goes to a critical state.

Runs tasklist.exe to return a list of running processes on the agent computer.

1. In the Authoring Console, select Health Model, and then select Monitors.2. In the Monitors pane, expand MyMP.MyComputerRole1, and then expand

System.Health.EntityState, and then expand System.Health.AvailabilityState.3. Right-click MyMP.Monitor.MyApplicationEventError and select Properties.4. Select the Diagnostic and Recovery tab.5. Click Add and then Diagnostic for a critical health state6. In the Choose a unique identifier box, type

MyMP.MyApplicationEventError.CommandDiagnostic and then click OK.7. On the General tab, do the following:

a. In the Name box, type Check Running Processes.b. In the Target box, make sure that MyMP.MyComputerRole1 is selected.

8. On the Configuration tab, do the following:a. In the Execute on monitor box, make sure that

MyMP.Monitor.MyApplicationEventError is selected.b. In the Execute when monitor’s health is box, make sure that Error is selected.

9. On the Modules tab, do the following:a. Under Actions, click Create.b. In the Choose Module Type box, select System.CommandExecutorProbe.c. In the Module ID box, type Command. Click OK.d. Click Edit.e. Click Configure.f. In the Full path to file box, type %windir%\system32\tasklist.exe.g. Click OK.h. Click OK.i. Click OK.j. Click OK.

To create a diagnostic that runs a command

191

See AlsoDiagnostics and Recoveries

How to create a recovery based on the output of a diagnosticThe following procedure shows how to create a recovery in the Operations Manager 2007 Authoring console that runs after a diagnostic. The recovery only runs if the output from the diagnostic meets certain criteria. Before you perform these procedures, you must complete the following prerequisite procedures.

How to Create a Class Create the target class for the monitor. How to create an event monitor Create the monitor that the diagnostic will respond to.

The diagnostic created in this procedure has the following characteristics:

Automatically runs when the MyMP.Monitor.MyApplicationEventError monitor goes to a critical state.

Runs a script that returns a single value in a property bag. The script itself is only for testing and performs no real function. This script only simulates a

script that gathers diagnostic data and returns that data in a property bag.

The recovery created in this procedure has the following characteristics:

Runs only when the value of the Result property in the property bag from the diagnostic is Positive.

Runs a script that writes an event to the OperationsManager event log on the agent and returns a message to the Operations console.

The value of the Result property in the property bag from the diagnostic is sent into the recovery script through an argument. This value is used in the event and the message created by the script.

The script itself is only for testing and performs no real function. This script only simulates a script that performs a recovery action and returns the results that are shown in an event and to the Operations console.

1. In the Authoring Console, select Health Model, and then select Monitors.2. In the Monitors pane, expand MyMP.MyComputerRole1, expand

System.Health.EntityState, and then expand System.Health.AvailabilityState.3. Right-click MyMP.Monitor.MyApplicationEventError and select Properties.4. Select the Diagnostic and Recovery tab.5. Under Configure diagnostic tasks, click Add and then Diagnostic for a critical health

state6. In the Choose a unique identifier box, type

To create a diagnostic that runs a script

192

MyMP.MyApplicationEventError.ScriptDiagnostic and then click OK.7. On the General tab, do the following:

a. In the Name box, type Run diagnostic script.b. In the Target box, make sure that MyMP.MyComputerRole1 is selected.


MyMP.Monitor.MyApplicationEventError is selected.b. In the Execute when monitor’s health is box, make sure that Error is selected.

9. On the Modules tab, do the following:a. Under Actions, click Create.b. In the Choose Module Type box, select

Microsoft.Windows.ScriptPropertyBagProbe.c. In the Module ID box, type Script. Click OK.d. Under Actions, click Edit.e. In the ScriptName box, type MyDiagnosticScript.vbs.f. In the Arguments box, clear the existing text.g. In the TimeoutSeconds box, type 300.h. Click Edit. This starts the external editor.i. Paste the contents of the following script between the ScriptBody tags in the XML.

Replace any text that might already exist.





Call oBag.AddValue("Result","Positive")

Else

Call oBag.AddValue("Result","Negative")

End If

oAPI.Return(oBag)

j. Close the external editor to save the script back to the module.k. Click OK.l. Click OK.

To create a recovery based on the output of a diagnostic

193

1. Under Configure recovery tasks, click Add and then Recovery for a critical health state

2. In the Choose a unique identifier box, type MyMP.MyApplicationEventError.ScriptRecovery and then click OK.

3. On the General tab, do the following:a. In the Name box, type Run recovery script.b. In the Target box, make sure that MyMP.MyComputerRole1 is selected.


MyMP.Monitor.MyApplicationEventError is selected.b. Select Execute after diagnostic.c. Select MyMP.MyApplicationEventError.ScriptDiagnostic.

5. On the Modules tab, do the following:a. Under Condition Detection, click Create.b. In the Choose Module Type box, select System.ExpressionFilter.c. In the Module ID box, type FilterDiagnostic. Click OK.d. Under Condition Detection, click Edit.e. Click Configure.f. Click Insert.g. In the Parameter column, type Diagnostic/DataItem/Property[@Name='Result'].h. In the Operator column, select Equals.i. In the Parameter column, type Positive.j. Click OK.k. Click OK.l. Under Actions, click Create.m. In the Choose Module Type box, select Microsoft.Windows.ScriptWriteAction.n. In the Module ID box, type Script, and then click OK.o. Click Edit.p. Click Configure.q. In the File Name box, type MyRecoveryScript.vbs.r. Paste the contents of the following script in the Script box.

sDiagnosticOutput = WScript.Arguments(0)

sMessage = "Recovery ran after diagnostic result of " & sDiagnosticOutput & "."


oAPI.LogScriptEvent "MyRecoveryScript.vbs",100,4,sMessage

194

s. Click Parameters.t. In the Parameters box, type

$Data/Diagnostic/DataItem/Property[@Name='Result']$.u. Click OK.v. Click OK.w. Click OK.x. Click OK.y. Click OK.

See AlsoDiagnostics and Recoveries

Creating RulesThe following procedures provide guidance on how to create rules in the Operations Manager 2007 Authoring console.

In This SectionHow to create a delimited text log alerting rule

Create a rule that creates an alert from a delimited text log.

How to create a WMI performance collection ruleCreate a rule that collects performance data from a WMI query.

How to create a script-based performance collection ruleCreate a performance collection rule using data from a script.

How to create a script-based event collection ruleCreate an event collection rule using data from a script.

195

How to create a delimited text log alerting ruleThe following procedure shows how to create an alert rule from a delimited text log in the Operations Manager 2007 Authoring console. Before you perform this procedure, you must first complete the prerequisite procedure How to Create a Class in which you create the target class.


Runs on any computer that has an instance of MyComputerRole1. Watches a log file that has a naming pattern of MyApp*.log located in the c:\logs directory.

The file is expected to be comma delimited. Creates an alert with a critical state when the string “error” is found in the second field. Includes the first, third, and fourth fields in the description of the alert. Suppresses alerts when the name of the logging computer and the value in the first field

match.

1. In the Authoring console, select Health Model, and then select Rules.2. Right-click in the Rules pane, select New, select Alerting, and then select Text Log

(Delimited).3. On the General page, do the following:

a. In the ElementID box, type MyMP.Rule.AlertOnDelimitedTextLog.b. In the Display Name box, type MyApplication Delimited Log Error.c. In the Target box, select MyMP.MyComputerRole1.d. In the Category box, select Alert. Click Next.

4. On the Application Log Data Source page, do the following:a. In the Directory box, type c:\logs.b. In the Pattern box, type MyApp*.log.c. In the Separator box, type a COMMA. Click Next.

5. On the Build Event Expression page, do the following:a. Click Insert.b. In the Parameter Name box type Params/Param[2].c. In the Operator box select Contains.d. In the Value box type error.e. Click Next.

6. On the Configure Alerts page, do the following:a. In the Alert name box, type Error found in MyApplication delimited text log..b. Click the button to the right side of the Alert description box.c. Clear the text in the Value box.

To create a delimited text log alert rule

196

d. Select Data, then Params, then Param.e. Replace the text <<INT>> with 1.f. Move to the end of the line and press the ENTER key.g. Select Data, then Params, then Param.h. Replace the text <<INT>> with 3.i. Move to the end of the line and press the ENTER key.j. Select Data, then Params, then Param.k. Replace the text <<INT>> with 4.l. Move to the end of the line and press the ENTER key.m. Click OK.

7. Click Finish.8. Right-click MyMP.Rule.AlertOnDelimitedTextLog and select Properties.9. On the Modules tab, do the following:

a. Click the Edit button next to the Action pane.b. Click the Configure button.c. Click the Alert Suppression button.d. Select Logging Computer and Parameter 1.

10. Click OK.11. Click OK.12. Click OK.13. Click OK.

See AlsoEvents

Alert Rules

How to create a WMI performance collection ruleThe following procedure shows how to create a WMI performance collection rule in the Operations Manager 2007 Authoring console. Before you perform this procedure, you must first complete the prerequisite procedure How to Create a Class in which you create the target class.


Runs on any computer that has an instance of MyComputerRole1. Collects the size for a file that is named C:\Logs\MyAppFile.txt.

To create a WMI performance collection rule197

1. In the Authoring console, select Health Model, and then select Rules.2. Right-click in the Rules pane, select New, select Collection, select Performance

Based, and then select WMI Performance Collection.3. On the General page, do the following:

a. In the ElementID box, type MyMP.Rule.CollectWMIPerformance.b. In the Display Name box, type My Application Collect WMI Performance.c. In the Target box, select MyMP.MyComputerRole1.d. In the Category box, select PerformanceCollection. Click Next.

4. On the WMI Configuration page, do the following:a. In the WMI Namespace box, type root\cimv2.b. In the Query box, paste the following WMI query.

Select Name,FileSize From CIM_DataFile Where Name = 'C:\\Logs\\MyAppFile.txt'

c. In the Query Interval box, type 900.d. Click Next.

5. On the Performance Mapper page, do the following:a. In the Object box, type MyApp.b. In the Counter box, type FileSize.c. In the Instance box, type $Data/Property[@Name=’Name’]$.d. In the Value box, type $Data/Property[@Name=’FileSize’]$.e. Click Finish.



How to create a script-based performance collection ruleThe following procedure shows how to create a performance collection rule by using a monitoring script in the Operations Manager 2007 Authoring console. Before you perform this procedure, you must first complete the prerequisite procedure How to Create a Class in which you create the target class.


Runs on any computer that has an instance of MyComputerRole1. The script accepts two parameters, one for computer name and another for the version of the

application that is stored as a property on the target class.

198

The script itself is only for testing and performs no real function. It simulates a script running a synthetic transaction and returning a property bag with static values.

1. In the Authoring console, select Health Model, and then select Rules.2. Right-click in the Rules pane, select New, select Collection, select Performance

Based, and then select Script Based Performance Collection.3. On the General page, do the following:

a. In the ElementID box, type MyMP.Rule.CollectScriptPerformance.b. In the Display Name box, type My Application Collect Script Performance.c. In the Target box, select MyMP.MyComputerRole1.d. In the Category box, select PerformanceCollection. Click Next.

4. On the Schedule page, in the Run every box, type 15 minutes.5. On the Script page, do the following:

a. For the File Name value, type MyPerfCollectionScript.vbsb. For the Timeout value, type 1 minutesc. In the Script box, paste the complete contents of the following script.


sVersion = WScript.Arguments(1)




Call oBag.AddValue("InstanceName","MyInstance")

Call oBag.AddValue("Value",10)

oAPI.Return(oBag)

d. Click the Parameters button.e. Select Target, select (Host=Windows Computer), and then select Principal Name

(Windows Computer).f. Type a SPACE.g. Select Target and then Version (My Computer Role Base).h. Click OK.i. Click Next.

6. On the Performance Mapper page, do the following:

To create a script based performance collection rule

199

a. In the Object box type MyApp.b. In the Counter box type MyCounter.c. In the Instance box type $Data/Property[@Name=’InstanceName’]$.d. In the Value box type $Data/Property[@Name=’Value’]$.e. Click Finish.



How to create a script-based event collection ruleThe following procedure shows how to create an event collection rule by using a monitoring script in the Operations Manager 2007 Authoring console. Before you perform this procedure, you must first complete the prerequisite procedure How to Create a Class in which you create the target class.


Runs on any computer that has an instance of MyComputerRole1. The script accepts two parameters, one for computer name and another for the version of the

application that is stored as a property on the target class. The script itself is only for testing and performs no real function. It simulates a script running a

synthetic transaction and returning a property bag with static values.

1. In the Authoring console, select Health Model, and then select Rules.2. Right-click in the Rules pane, select New, select Collection, select Event Based, and

then select Script Based Event Collection.3. On the General page, do the following:

a. In the ElementID box, type MyMP.Rule.CollectScriptEvent.b. In the Display Name box, type My Application Collect Script Event.c. In the Target box, select MyMP.MyComputerRole1.d. In the Category box, select EventCollection. Click Next.

4. On the Schedule page, in the Run every box, type 15 minutes.5. On the Script page, do the following:

a. For the File Name value, type MyEventCollectionScript.vbsb. For the Timeout value, type 1 minutes

To create a script based event collection rule

200

c. In the Script box, paste the complete contents of the following script.






Call oBag.AddValue("EventID",100)

Call oBag.AddValue("ParamValue","Param1")

oAPI.Return(oBag)

d. Click Parameters.e. Select Target, select (Host=Windows Computer), and then select Principal Name

(Windows Computer).f. Type a SPACE.g. Select Target and then Version (My Computer Role Base).h. Click OK.i. Click Next.

6. On the Event Mapper page, do the following:a. In the Computer box type $Data/Property[@Name='ComputerName']$.b. In the Event source box type MyApp.c. In the Event log box type CustomScript.d. In the Event ID box type $Data/Property[@Name='EventID']$.e. In the Category box type 0.f. In the Level box select Information.g. Click the Parameters button.h. Type $Data/Property[@Name='ParamValue']$i. Click OK.j. Click Finish.


Event Collection Rules

201

PresentationInformation collected by a management pack in Operations Manager 2007 is presented to the user through the Operations console in views and reports. Views provide detailed information from the Operations Manager database about daily operations. Reports provide aggregated information from the data warehouse about trending and historical analysis. Linked reports enable generic reports included with System Center Operations Manager 2007 to be customized for the specific requirements of an application with minimal work from the author.

The topics in this section provide background information about and recommendations for presenting data effectively and guidance for using the management pack.


Describes the concepts of how views and linked reports work, the kinds of data they include, and how they are configured in a management pack.

Presentation Design OverviewProvides guidance and best practices for designing views and linked reports to include in a management pack.

Building Views and ReportsDemonstrates how to build views and linked reports by using the Authoring console.

Key ConceptsThis section provides detailed concepts for understanding views and linked reports in Operations Manager 2007.

In This SectionViews

Describes the different views in the Operations console and provides best practices and processes for including them in a management pack.

202

Linked ReportsDescribes how linked reports work and provides details about the different reports that can be used as linked reports.

ViewsViews provide access to data that is collected in the Operations Manager database. Management packs typically include multiple views to provide access to its classes and collected operations data. Multiple views in the management pack can provide access to the same data, but relevant to different monitoring scenarios, present data in different formats.

In This SectionTypes of Views

Details on each of the different types of views.

FoldersInformation on folders that are used to organize views.

Types of Views Operations Manager 2007 provides multiple views to present data for different purposes. The following topics describe those purposes.

In This SectionState Views

Describes a listing of instances of a particular class in the management pack and their current health state.

Alert ViewsDescribes a listing of alerts matching specific criteria.

203

Event ViewsDescribes a listing of events matching specific criteria.

Task Status ViewDescribes a listing of events related to the status of running tasks.

Performance ViewsProvides a graph of performance data matching specific criteria.

Diagram ViewsProvides a graphical representation of instances of specified classes and their current health state.

Dashboard ViewsDescribes multiple, related views in a single pane.

State ViewsState views provide a tabular listing of a set of instances of a particular class. Columns in the view can include the state of the object, the value of properties of the object, or the health state of objects that the target object hosts or contains.

ContentsThe following properties determine the contents of a State view.

TargetAll State views must specify a target class. The target class specified for a State view determines which objects are displayed and what properties are available. All instances of the target class in the management group are included unless criteria or a group is specified to limit the instances that are displayed.

204

GroupA State view does not require a group. If a group is specified, only instances of the target class in the group are included. Even though the group might contain objects of different classes, only instances of the target class are displayed.

If the Entity class is used for the target class, all objects in the group are included in the view. This is because all classes inherit from the Entity class.

CriteriaA State view does not require criteria. If it is provided, criteria allows for the instances of the target class to be limited according to the values of one or more properties. To add and configure criteria , start the external editor from the Authoring console or modify the settings in the dialog box in the Operations console. The properties that you can use in criteria are provided in the following table.

You can only set criteria if the target class is not abstract. An abstract class can be the target class of a State view, but you cannot use criteria.

Condition Description Example

Severity One or more health states matching the current health state of the object. Valid values are as follows:

Red Yellow Green Unknown

<SeverityList>

<Severity>Red</Severity>

<Severity>Yellow</Severity>

</SeverityList>

InMaintenanceMode Specifies whether the object is currently in maintenance mode. Valid values are true and false.

<InMaintenanceMode>true</InMaintenanceMode>

PropertyCriteria Value of one or more properties of the targeted class. The value can

<PropertyCriteria>

<PropertyName>MyProperty1</PropertyName>

<Value>MyExplicitValue</Value>

Note

Note

205


include a wildcard. </PropertyCriteria>

<PropertyCriteria>

<PropertyName>

MyProperty2</PropertyName>

<Value>MyWildcardValue%</Value>

</PropertyCriteria>

ColumnsEach column in a State view is defined in a ColumnInfo node under the Presentation node of the view. The following XML sample shows a column definition.

<ColumnInfo Index="0" SortIndex="-1" Width="100" Grouped="false" Sorted="false"

IsSortable="true" Visible="true" SortOrder="Descending">

<Name>State</Name>

<Id>MyMP.MyClass</Id>

</ColumnInfo>

The content of each column is determined by its Id value with the title of the column defined by the Name value. The possible contents of a State view are identified in the following table.

Name ID Description

State ID of the target class Current state of the target object

Maintenance Mode InMaintenanceMode Icon indicating whether the object is currently in maintenance mode

Property value Name of the property Value for any property of the target object

Name of hosted class ID of a class that the target class hosts or contains

Current state of any objects that the target object hosts or contains

When a State view is created in the Authoring console, no columns are defined. If the management pack is installed without column definitions, the following columns are displayed with default settings:

State of the object

206

Current maintenance mode setting Display name Path name

The state of each class that the target class hosts or contains is available to the view but is not visible.

After the view is installed, you can modify the settings in the Properties dialog box for the view in the Operations console. If any modification occurs, the Operations console adds the entire set of column definitions to the view. You can load the set of column definitions into the Authoring console for detailed configuration.

FormattingTo format a State view, modify the attributes of each column definition. You can do this the external editor from the Authoring console or with by modify the settings in the Properties dialog box for the view in the Operations console. The following table lists the different characteristics of each column and their corresponding attributes.

Characteristic Description

Column Order The order of how the columns are positioned can be specified with the Index attribute for the column. You can also do this using the Display tab in the Properties dialog box for the view in the Operations console.

Column Width Each column has a Width attribute defining the width of the column in pixels. The column width in the dialog box is used the first time that you open the Operations console. If you change the width in the Operations console, the new settings are saved on the local workstation. There is no guarantee that the column width in the management pack is retained on any workstation.

Column Visibility Each column has a Visible attribute that defines whether the column is visible in the Operations console. If you do not want to display a column, still include it in the view with the Visible attribute set to false. If the column is not included in the view, it is not available as an option for the user to add it to the view in the Operations console. For this reason, all columns are typically included in the view with

207


the visibility of the columns that you do not want to display set to false.

Sorting The objects listed in a State view can be sorted by any of the included columns. The sorting configuration in the dialog box is used the first time that you open the Operations console. If you change the sort order in the Operations console, the new settings are saved on the local workstation. There is no guarantee that the sort order in the management pack is retained on any workstation.

The dialog box in the Operations console enables the view to be sorted by a single column. You can sort multiple columns by modifying the XML attributes of the view. Change the value of the Sorted attribute of the column entry to true. The SortIndex attribute defines the order in which the columns are sorted, and its value must be changed to a value of 0 or greater. The SortOrder attribute must be either Ascending or Descending depending on which sort order for the column you want.

Grouping You cannot group columns in a State view.

See AlsoHow to Create a State View

Alert ViewsAlert views provide a listing of alerts in the Operations Manager database. Columns in the view can include the value of properties of each alert.

ContentsThe following properties determine the contents of an Alert view.

208

TargetAll Alert views must specify a target class. An Alert view lists all of the alerts associated with the target class or any classes that the target class hosts. All instances of the target class in the management group are included unless criteria or a group is specified to limit the instance that is displayed. All alerts associated with these objects are included unless you specify criteria to limit them.

GroupAn Alert view does not require a group. If a group is specified, only alerts associated with instances of the target class in the group are included in the view. Even though the group might contain objects of different classes, only alerts from instances of the target class are displayed.

If the Entity class is used for the target class, all objects in the group are included in the view. This is because all classes inherit from the Entity class.

CriteriaAn Alert view does not require criteria. If it is provided, criteria allows for the included alerts to be limited according to the values of one or more properties. To add or configure criteria, start the external editor from the Authoring console or modify the settings in the view’s Properties dialog box in the Operations console. The properties that you can use in criteria are provided in the following table with a sample of the XML code in the view definition.


Severity One or more values matching the severity of the alert. Valid values are as follows:

Success Warning Error

<SeverityList>

<Severity>Warning</Severity>

<Severity>Error</Severity>

</SeverityList>

Priority One or more values matching the severity of the alert. Valid values are as follows:

Low Medium High

<PriorityList>

<Priority>Medium</Priority>

<Priority>High</Priority>

</PriorityList>

Source One or more rules or <SourceList>

Note

209


monitors that created the alert. The value for Type can be Rule or Monitor. The value for Id indicates the specific rule or monitor. If this value is selected in the Operations console, it will be the actual GUID. It should be changed to an $MPElement variable to ensure that it moved between management groups.

<Source>

<Type>Rule</Type>

<Id>$MPElement[Name='MyMP.MyRule']

$</Id>

</Source>

<Source>

<Type>Monitor</Type>

<Id>$MPElement[Name='MyMP.MyMonitor']

$</Id>

</Source>

</SourceList>

Resolution State Current resolution state of the alert. This can either be a list of numeric values for specific states or a range of values. If the StateRange element is used, it requires an Operator attribute. The possible values for this attribute are as follows:

Equals NotEquals AtMost AtLeast GreaterThan LessThan

<ResolutionState>

<State>0</State>

<State>1</State>

</ResolutionState>

<ResolutionState>

<StateRange

Operator="NotEquals">255</StateRange>

</ResolutionState>

Alert Name Name of the alert. Specified text must appear somewhere in the alert’s name.

<Name>MyAlert</Name>

Alert Description Description of the alert. Specified text must appear somewhere in the alert’s description.

<Description>Error</Description>

210


Time alert created The time that the alert was created. A time range or a relative duration from the current time can be specified. If a relative time is used, the WithinLast element requires a Unit attribute. The possible values for this attribute are as follows:

Second Minute Hour Day

<TimeCreated>

<Range>

<After>2010-05-16T12:00:00</After>

<Before>2010-05-27T18:00:00</Before>

</Range>

</TimeCreated>

<TimeCreated>

<WithinLast Unit="Hour">2</WithinLast>

</TimeCreated>

Assigned to Current owner of the alert. Specified text must appear somewhere in the alert’s owner name.

<AssignedTo>Adams</AssignedTo>

Ticket Ticket number of the alert. Specified text must appear somewhere in the ticket.

<TicketId>123456789</TicketId>

Instance Name Name of the instance that raised the alert. Specified text must appear somewhere in the alert’s instance name.

<InstanceName>srv</InstanceName>

User who last modified alert

Name of the user who last modified the alert. Specified text must appear somewhere in the alert’s user name.

<LastModifiedBy>Adams</LastModifiedBy>

Last time any property of alert was modified

The time that the alert was last modified. A time range or a relative duration from the current

<LastModifiedTime>

<Range>

<After>2010-05-16T12:00:00</After>

211


time can be specified. If a relative time is used, then the WithinLast element requires a Unit attribute. The possible values for this attribute are as follows:


<Before>2010-05-27T18:00:00</Before>

</Range>

</LastModifiedTime>

<LastModifiedTime>


</LastModifiedTime>

Last time resolution state was modified

The time that the resolution state of the alert was last modified. A time range or a relative duration from the current time can be specified. If a relative time is used, then the WithinLast element requires a Unit attribute. The possible values for this attribute are as follows:


<ResolutionStateLastModifiedTime>

<Range>

<After>2010-05-16T12:00:00</After>

<Before>2010-05-27T18:00:00</Before>

</Range>

</ResolutionStateLastModifiedTime>

<ResolutionStateLastModifiedTime>


</ResolutionStateLastModifiedTime>

Time alert was resolved

The time that the alert was resolved. A time range or a relative duration from the current time can be specified. If a relative time is used, the WithinLast element requires a Unit attribute. The possible values for this attribute are as follows:

Second

<TimeResolved>

<Range>

<After>2010-05-16T12:00:00</After>

<Before>2010-05-27T18:00:00</Before>

</Range>

</TimeResolved>

<TimeResolved>


</TimeResolved>

212


Minute Hour Day

User who resolved alert

Name of the user who last resolved the alert. Specified text must appear somewhere in the user’s name.

<ResolvedBy>Adams</ResolvedBy>

Time alert was added The time that the alert was added to the database. A time range or a relative duration from the current time can be specified. If a relative time is used, then the WithinLast element requires a Unit attribute. The possible values for this attribute are as follows:


<TimeAdded>

<Range>

<After>2010-05-16T12:00:00</After>

<Before>2010-05-27T18:00:00</Before>

</Range>

</TimeAdded>

<TimeAdded>


</TimeAdded>

Site Site of the alert. Specified text must appear somewhere in the site.

<Site>site</Site>

Custom Fields Text in a custom field of the alert. Specified text must appear somewhere in the custom field. An alert has ten custom fields.

<CustomField1>CustomText</CustomField1>

<CustomField2>CustomText</CustomField2>

213

ColumnsEach column in an Alert view is defined with a ColumnInfo element in the Presentation element of the view. The following XML sample shows a column definition.


IsSortable="true" Visible="true" SortOrder="Ascending">

<Name>Severity</Name>

<Id>Severity</Id>

</ColumnInfo>

The content of each column is determined by its Id value with the title of the column defined by the Name element. The possible contents of a state view are identified in the following table.

Name ID Description

Severity Severity Severity of the Alert

Icon Icon Icon representing alert severity

Path MonitoringObjectPath Path of the monitoring object that the alert is associated with

Source MonitoringObjectDisplayName Display name of the monitoring object that the alert is associated with

Maintenance Mode MonitoringObjectInMaintenanceMode Icon indicating whether the object associated with the alert is currently in maintenance mode

Name Name Name of the alert

Resolution State ResolutionState Current resolution state of the alert

Created TimeRaised Date and time that alert was created

Age Age Duration of time after alert was created

Type Category The category of the rule or monitor that created the alert

Owner Owner Current owner of the alert

214

Name ID Description

Priority Priority Priority of the alert

Latency Latency Duration between the time that the alert was created on the agent and the time that it was written to the database

Description Description Description of the alert

Connector ConnectorId ID of the connector if the alert is forward to a connector

Forwarding Status ConnectorStatus Current forwarding status if the alert is forwarded to a connector

Class Class Display name of the target class for the monitor or rule creating the alert

Time in State TimeInState Duration of time after resolution state of agent was changed

Custom Fields CustomField1

CustomField2

CustomField3

CustomField4

CustomField5

CustomField6

CustomField7

CustomField8

CustomField9

CustomField10

Value of custom fields of the alert

Resolved By ResolvedBy User who resolved the alert

Time Resolved TimeResolved Date and time when the alert was resolved

Last State Change TimeResolutionStateLastModified Date and time when

215

Name ID Description

resolution state was last changed

Last Modified LastModified Date and time when the alert was last modified

Last Modified By LastModifiedBy User who last modified the alert

Management Group ManagementGroup Name of the management group the alert is from

Site SiteName The site name of the alert

Repeat Count RepeatCount Current repeat count for the alert

Ticket ID TicketId The ticket ID of the alert

To specify the order of the columns, modify the settings in the view’s Properties dialog box in the Operations console. This corresponds to the Index attribute in the XML code for the column.

If no columns are specified for the view, by default, the following columns are displayed:

Severity Icon Source Maintenance Mode Name Resolution State Created Age

FormattingTo format an Alert view, modify the attributes of each column definition. Start the external editor from the Authoring console or modify the settings in the view’s Properties dialog box in the Operations console. The following table lists the different characteristics of each column and their corresponding attributes.


Column Order The order of how the columns are positioned can be specified with the Index attribute for the column, or you can use the Display tab in the

216


Properties dialog box for the view in the Operations console.

Column Width Each column has a Width attribute defining the width of the column in pixels. The column width in the dialog box is used the first time that you open the Operations console. If you change the width in the Operations console, the new settings are saved on the local workstation. There is no guarantee that the column width in the management pack is retained on any workstation.

Column Visibility Each column has a Visible attribute that defines whether the column is visible in the Operations console. If you do not want to display a column, still include it in the view with the Visible attribute set to false. If the column is not included in the view, it is not available as an option for the user to add it to the view in the Operations console. For this reason, all columns are typically included in the view with the visibility of the columns that you do not want be displayed set to false.

Sorting The alerts listed in an Alert view can be sorted by any of the included columns. The sorting configuration in the dialog box is used the first time that you open the Operations console. If you change the sort order in the Operations console, the new settings are saved on the local workstation. There is no guarantee that the sort order in the management pack is retained on any workstation.

The dialog box in the Operations console enables the view to be sorted by a single column. You can sort multiple columns by modifying the XML attributes of the view. Change the value of the Sorted attribute of the column entry to true. The SortIndex attribute defines the order that the columns are sorted, and its value must be changed to a value of 0 or greater. The SortOrder attribute must be

217


either Ascending or Descending depending on which sort order for the column you want.

Grouping Alert views can be grouped by any of the included columns. The Operations console dialog box allows for up to three fields to be used for grouping, but any number can be used by modifying the XML attributes. To use a column for grouping, change the value of its Grouped attribute to true. The SortIndex attribute is used to determine the order for the grouping of multiple columns and must be changed to a value greater than 0.

Event ViewsEvent views provide a listing of events that are collected by rules in the Operations Manager database. Columns in the view can include the value of properties of each event.

ContentsThe contents of an event view are determined by the following:

TargetAll event views must specify a target class. An event view will list all the events associated with the target class or any classes hosted by the target class. All instances of the target class in the management group will be included unless criteria or a group is specified to limit the instance displayed. All events associated with these objects will be included unless you specify criteria to limit them.

GroupAn event view does not require a group. If a group is specified, then only events associated with instances of the target class in the group will be included in the view. Even though the group may contain objects of different classes, only events from instances of the target class are displayed.

CriteriaAn event view does not require criteria. If it is provided, criteria allow the included events to be limited according to the values of one or more properties. Criteria is added and configured by

218

starting the external editor from the Authoring console or by using the dialog box in the Operations console. The properties that may be used in criteria are provided in the following table with XML samples.


Rules One more rules that collected the event. The value for Rule indicates the specific rule or monitor. If this is selected in the Operations console, it will be the actual GUID. This should be changed to an $MPElement variable to ensure that it moved between management groups.

<RuleList>

<Rule>$MPElement[Name='MyMP.MyRule']$</Rule>

</RuleList>

Event Number One or more values matching the number of event.

<EventNumberList>

<EventNumber>1234</EventNumber>

</EventNumberList>

Source The name of the publisher of the event.

<PublisherName>MyApp</PublisherName>

Time Generated The time that the event was generated. A time range or a relative duration from the current time can be specified. If a relative time is used, then the WithinLast node requires a Unit

<TimeGenerated>

<Range>

<After>2010-05-16T12:00:00</After>

<Before>2010-05-27T18:00:00</Before>

</Range>

</TimeGenerated>

<TimeGenerated>


</TimeGenerated>

219


attribute. The possible values for this attribute are as follows:


Instance Name <ManagedEntityName>name</ManagedEntityName>

Severity Level One or more value that match the severity level of the event. Valid values are listed in the following table.

<LevelIdList>

<Level>2</Level>

<Level>1</Level>

</LevelIdList>

User The user name that created the event.

<User>NT AUTHORITY\SYSTEM</User>

Computer Name of the computer that logged the event.

<LoggingComputer>svr01.contoso.com</LoggingComputer>

The following table lists the possible values for the severity level criteria:

Value Description

0 Success

1 Error

2 Warning

4 Information

8 Audit Success

16 Audit Failure

ColumnsEach column in an event view is defined by using a ColumnInfo node in the Presentation node of the view. The XML of an example column definition is shown here:

220


IsSortable="true" Visible="true" SortOrder="Ascending">

<Name>Severity</Name>

<Id>Severity</Id>

</ColumnInfo>

The content of each column is determined by its ID value with the title of the column defined by the Name. The possible contents of a state view are identified in the following table:

Column ID Description

Level LevelId Severity level of the event

Date and Time TimeGenerated Date and time that the event was generated

Source PublisherName Publisher name of the event

Name MonitoringObjectDisplayName Name of the monitoring object that the event is associated with

User User User name that generated the event

Event Number Number Number of the event

Log Name Channel Name of the log that the event was collected from

Logging Computer LoggingComputer Name of the computer that logged the event

Rule Name MonitoringRuleDisplayName Name of the rule that collected the event

The order of the columns can be specified by using the dialog box in the Operations console. This corresponds to the Index attribute in the XML for the column.

If no columns are specified for the view, then by default, the following columns are displayed:

Level Date and Time Source Name User Event Number

221

Log Name

FormattingThe formatting of an event view is accomplished by modifying the attributes of each column definition. This is performed by starting the external editor from the Authoring console or with the dialog box in the Operations console. The different characteristics each column and their corresponding attributes are listed in the following table:


Column Order The order of how the columns are positioned can be specified with the Index attribute for the column. This can also be performed by using the Display tab in the Properties dialog box for the view in the Operations console.

Column Width Each column has a width attribute defining the width of the column in pixels. The column width in the dialog box will be used the first time that you open the Operations console. If you change the width in the Operations console, then the new settings will be saved on the local workstation. You cannot guarantee that the column width in the management pack is retained on any workstation.

Column Visibility Each column has a Visible attribute that defines whether the column will be visible in the Operations console. If a column should not be displayed, then it should still be included in the view by using the Visible attribute set to false. If the column is not included in the view, then it is not available as an option for the user to add it to the view in the Operations console. For this reason, all columns are typically included in the view with the visibility of the columns that should not be displayed set to false.

Sorting The events listed in an event view can be sorted by any of the included columns. The sorting configuration in the dialog box will be used the first time that you open the Operations console. If you change the sort order in the Operations console, then the new settings will

222


be saved on the local workstation. There is no way to guarantee that the sort order in the management pack is retained on any workstation.

The dialog box in the Operations console allows for the view to be sorted by a single column. Sorting may be performed on multiple columns by modifying the XML of the view. This is performed by changing the value of the Sorted attribute of the column entry to true. The SortIndex attribute defines the order that the columns will be sorted, and its value must be changed to a value of 0 or more. The SortOrder attribute must be either Ascending or Descending depending on the desired sort order for the column.

Grouping Event views can be grouped by any of the included columns. The Operations console dialog box allows for up to three fields that you can use for grouping, but any number may be used when you edit the XML. To use a column for grouping, change the value of its Grouped attribute to true. The SortIndex attribute is used to determine the order for the grouping of multiple columns and must be changed to a value larger than 0.

Task Status ViewTask status views in System Center Operations Manager 2007 provide a listing of task status events that are generated when you try to run a task.

ContentsThe contents of a task status view are determined by the following.

223

TargetAll task status views must specify a target class. A task status view will list the status events of all tasks targeted at the target class or any classes hosted by the target class. All instances of the target class in the management group will be included unless criteria or a group is specified to limit the instance displayed. All task status events associated with these objects will be included unless you specify criteria to limit them.

GroupIf a group is specified, only task status events associated with instances of the target class in the group are included in the view. Even though the group may contain objects of different classes, only task status events from instances of the target class are displayed.

If Entity is used for the target class, all objects in the group are included in the view. This is because all classes inherit from Entity.

CriteriaA task status view does not require criteria. When provided, criteria limit the included events according to the values of one or more properties. You can add and configure criteria by opening the external editor from the Authoring console or by using the dialog box in the Operations console. The properties that you can use in criteria are provided in the following table with a sample of the XML code in the view definition.


Tasks One or more tasks to include.

<TaskList>

<Task>$MPElement[Name='MyMP.MyTask']$</Task>

</TaskList>

Submitted By User account of the person who submitted the task.

<SubmittedBy>CONTOS\NancyA</SubmittedBy>

Run As account Run as account that was used when the task was run.

<RunningAs>CONTOSO\NancyA</RunningAs>

Status List One or more values matching the status returned by the task. Valid values are as follows:

<StatusList>

<Status>Succeeded</Status>

<Status>Failed</Status>

</StatusList>

Note

224


Scheduled Started Succeeded Failed

Output Text in the output of the task.

<Output>output</Output>

Scheduled to Run The time that the task was scheduled to run. A time range or a relative duration from the current time can be specified. If a relative time is used, the WithinLast node requires a Unit attribute. The possible values for this attribute are as follows:


<TimeScheduled>

<Range>

<After>2010-05-16T12:00:00</After>

<Before>2010-05-27T18:00:00</Before>

</Range>

</TimeScheduled>

<TimeScheduled>


</TimeScheduled>

Started Running The time that the task started running. A time range or a relative duration from the current time can be specified. If a relative time is used, the WithinLast node requires a Unit attribute. The possible values for this attribute are as follows:


<TimeStarted>

<Range>

<After>2010-05-16T12:00:00</After>

<Before>2010-05-27T18:00:00</Before>

</Range>

</TimeStarted>

<TimeStarted>


</TimeStarted>

225


Last Modified The time that the task was last modified. A time range or a relative duration from the current time can be specified. If a relative time is used, the WithinLast node requires a Unit attribute. The possible values for this attribute are as follows:


<LastModified>

<Range>

<After>2010-05-16T12:00:00</After>

<Before>2010-05-27T18:00:00</Before>

</Range>

</LastModified>

<LastModified>


</LastModified>

ColumnsEach column in a task status view is defined by using a ColumnInfo node in the Presentation node of the view. The XML of an example column definition is shown here:


IsSortable="false" Visible="true" SortOrder="Ascending">

<Name>Status</Name>

<Id>Status</Id>

</ColumnInfo>

The content of each column is determined by its ID value with the title of the column defined by the Name. The possible contents of a state view are identified in the following table:


Status Status Status from running the task

Task Name DisplayName Name of the task

Schedule Time TimeScheduled Time that the task was scheduled

Submitted By SubmittedBy Name of the user who submitted the task

226


Run As RunningAs Run as account that is used when the task was run

Run Location LocationName Name of the computer that the task was run on

Task Target Class TargetedType Name of the target class for the task

Category Category Category of the task

Task Description Description Description of the task

The order of the columns can be specified by using the dialog box in the Operations console. This corresponds to the Index attribute in the XML for the column.

If no columns are specified for the view, by default, the following columns are displayed:

Status Task Name Schedule Time Submitted By Run Location

FormattingYou can format a task status view by modifying the attributes of each column definition. You do this by opening the external editor from the Authoring console or with the dialog box in the Operations console. The different characteristics each column and their corresponding attributes are listed in the following table:


Column Order Specify the order of columns by using the Index attribute for the column. This can also be performed by using the Display tab in the Properties dialog box for the view in the Operations console.

Column Width Each column has a width attribute defining the width of the column in pixels. The column width in the dialog box will be used the first time that you open the Operations console. If you change the width in the Operations console, the new settings will be saved on the local

227


workstation. You cannot guarantee that the column width in the management pack is retained on any workstation.

Column Visibility Each column has a Visible attribute that defines whether the column will be visible in the Operations console. When a column should not be displayed, that column should still be included in the view by setting the Visible attribute to false. A column that is not included in the view is not available as an option for the user to add the column to the view in the Operations console. Therefore, all columns are typically included in the view and the visibility of the columns that should not be displayed is set to false.

Sorting The status events listed in a task status view can be sorted by any of the included columns. The sorting configuration in the dialog box is used the first time that you open the Operations console. If you change the sort order in the Operations console, the new settings will be saved on the local workstation. You cannot guarantee that the sort order in the management pack is retained on any workstation.

The dialog box in the Operations console allows for the view to be sorted by a single column. Sorting may be performed on multiple columns by modifying the XML of the view. You can do this by changing the value of the Sorted attribute of the column entry to true. The SortIndex attribute defines the order that the columns will be sorted, and its value must be changed to a value of 0 or more. The SortOrder attribute must be either Ascending or Descending, depending on the preferred sort order for the column.

Grouping Task status views can be grouped by any of the included columns. The Operations console dialog box allows for up to three fields that can

228


be used for grouping, but any number may be used when you edit the XML. To use a column for grouping, change the value of its Grouped attribute to true. The SortIndex attribute is used to determine the order for the grouping of multiple columns and must be changed to a value more than 0.

Performance ViewsPerformance views provide a graphical presentation of values from performance collection rules.

ContentsThe contents of a performance view are determined by the following properties:

TargetA performance view will display one or more performance counters associated with the target class or any classes hosted by the target class. All instances of the target class in the management group will be included unless criteria or a group is specified to limit the instance displayed. All performance values associated with these objects will be included unless you specify criteria to limit them.

GroupIf a group is specified, all instances of the target class in the group will be included. Even though the group may contain objects of different classes, only instances of the target class are displayed.

If Entity is used for the target class, all objects in the group are included in the view. This is because all classes inherit from Entity.

CriteriaA performance view does not require criteria. If it is provided, criteria in a performance view define the performance counters that should be included in the graph. If no criteria are specified than all performance counters from all collection rules targeted at the included objects will be included. If criteria are provided, the performance counters are limited to those matching the specified

Note

229

criteria. The properties that you can use in criteria are provided in the following table with a sample of the XML code in the view definition.


RuleList One or more performance collection rules to include in the view. If the Operations console is used to define this property, the GUID of the rule will be used. This should be replaced with the $MPElement variable for the rule so that the management pack can be copied between management packs.

<RuleList>

<Rule>$MPElement[Name='MyApp.MyCollectionRule']$</Rule>

</RuleList>

Object The object name of the performance counters to include.

<Object>MyObject</Object>

Counter The counter name of the performance counters to include.

<Counter>MyCounter</Counter>

Instance The instance name of the performance counters to include.

<Instance>MyInstance</Instance>

230

FormattingThe formatting of a performance view is controlled by the properties in the following table. Most of this configuration can be performed with the properties dialog box for the view in the Operations console.


Time Range Defines the time range to use for the graph.

If the IsDynamic value is set to true, the time range is set for between the current time and the duration from the current time defined by DynamicTimeTicks. This is the number of seconds multiplied by 10,000,000. This duration is dynamically updated based on the current time.

If the IsDynamic value is set to false, the times set in StartTime and EndTime are used.

<StartTime>2010-06-06T15:10:00.1976772-07:00</

StartTime>

<EndTime>2010-06-013T15:10:00.1976772-07:00</

EndTime>

<DynamicTimeTicks>864000000000</DynamicTimeTicks

<IsDynamic>true</IsDynamic>

ChartType The type of chart. Acceptable values are Line and Spline.

<ChartType>Line</ChartType>

Text The fonts and colors that are used for different titles and labels.

<TitleFont>Microsoft Sans

Serif,12,Regular</TitleFont>

<ChartFont>Microsoft Sans

Serif,8.25,Regular</ChartFont>

<LabelFont>Microsoft Sans

Serif,14,Regular</LabelFont>

<XAxisFont>Microsoft Sans

Serif,8.25,Regular</XAxisFont>

<YAxisFont>Microsoft Sans

231


Serif,14,Regular</YAxisFont>

<LabelColor>-16777216</LabelColor>

Axes Specifies the configuration of the axes. The AxisMin and AxisMax values are only used if AutoAxis is set to false. These values set the configuration of the Y-Axis.

<XLabelAngle>0</XLabelAngle>

<YAxisVisible>True</YAxisVisible>

<YAxisVisible>True</YAxisVisible>

<AutoAxis>true</AutoAxis>

<AxisMax>100</AxisMax>

<AxisMin>0</AxisMin>

Gridlines Specify which gridlines are displayed.

<XShowMajorGridlines>false</XShowMajorGridlines>

<XShowMinorGridlines>false</XShowMinorGridlines>

<ShowInterlaceStrips>false</ShowInterlaceStrips>

<XInterlaceColor>16777215</XInterlaceColor>

<YShowMajorGridlines>true</YShowMajorGridlines>

<YShowMajorGridlines>true</YShowMajorGridlines>

<YShowInterlaceStrips>false</YShowInterlaceStrips>

3D Specifies whether the graph should be displayed in 3D and sets different options for the rotation. The options only take effect if the Is3DMode property is set to true.

<Is3DMode>true</Is3DMode>

<Perspective>10</Perspective>

<GraphXRotation>0</GraphXRotation>

<GraphYRotation>0</GraphYRotation>

<RightAngleAxes>false</RightAngleAxes>

<ClusterSeries>false</ClusterSeries>

<Depth>100</Depth>

<GapDepth>100</GapDepth>

View options Shows the performance baseline for rules using self-tuning.

<BaselineMode>false</BaselineMode>

<ShowAlerts>false</ShowAlerts>

<ShowMaintenanceMode>false</ShowMaintenanceMode>

General Formatting

<XShowSideMargin>true</XShowSideMargin>

<YShowSideMargin>true</YShowSideMargin>

232

Diagram ViewsDiagram views provide a visual representation of the state of a particular object and any objects that the object hosts or contains.

TargetAll diagram views require a target. Although other views can use any class as a target, the contents of a diagram view are determined by a specific object or singleton class. If an object is used, the GUID of the object is required in the management pack. Since this GUID is not known until the object is discovered, a singleton class such as a distributed application or a group is typically used.

If a diagram view is created in the Operations console, that view will have the GUID of a target object in the view configuration in addition to the target class. If the target class is singleton, this GUID may be removed without affecting the functionality of the view. The GUID should be removed so that the management pack can be transferred between management groups.

Diagram views do not have criteria or a group in addition to the target. The view will include all objects that are contained or hosted by the target object.

FormattingThe formatting of a diagram view is determined by XML code in the management pack that is completely configurable in the

Element Description Example

Nodes Per Row Specifies how many nodes are displayed on a single row if box containment style is used.

<NodesPerRow>3</NodesPerRow>

Levels to Show The number of levels to expand when the view is first opened. If no value is provided, the default value of 2 is used.

<LevelsToShow>8</LevelsToShow>

Line Style The style of the line. If no value is provided, the default value of Solid is used. If another style

<LineStyle>DashDotDot</LineStyle>

233


is required, one of the following values can be used:

1. Solid2. Dot3. Dash4. DashDot5. DashDotDot

Line Color Color of the line. <Color Red="6" Green="134" Blue="253" />

Line Width The width of the line. If no value is provided, the default value of 1 is used.

<LineWidth>2</LineWidth>

Arrow Style Specifies whether the end of a line uses an arrow.

NoAnchor ArrowAnchor

<ArrowStyle>NoAnchor</ArrowStyle>

Virtually Group Specified by ShowVirtualGroup attribute of DiagramViewDisplay node. If the attribute is false, virtual grouping is not used. If it is true or not specified, virtual grouping is used.

<DiagramViewDisplay ShowVirtualGroup="false">

Maximum Number of Children

Maximum number of children of a virtual node.

<MaxNumChild>7</MaxNumChild>

VirtualGroupThreshold

Virtual grouping will be applied if a node has more children than the specified value.

<VirtualGroupThreshold>3</

VirtualGroupThreshold>

Minimum Bucket Size Minimum number of <MinBucketSize>2</MinBucketSize>

234


child nodes of a virtual node.

The XML code for the Presentation element of a sample diagram view is shown here:

<Presentation>

<DiagramViewCriteria>

<DiagramViewDisplay>

<NodesPerRow>3</NodesPerRow>

<LevelsToShow>4</LevelsToShow>

<ContainmentLine>

<Color />

<SourceArrow IsFilled="false">


</SourceArrow>

<TargetArrow IsFilled="false">

<ArrowStyle>ArrowAnchor</ArrowStyle>

</TargetArrow>

</ContainmentLine>

<NonContainmentLine>

<Color Red="6" Green="134" Blue="253" />

<SourceArrow IsFilled="false">


</SourceArrow>

<TargetArrow IsFilled="false">

<ArrowStyle>ArrowAnchor</ArrowStyle>

</TargetArrow>

<LineStyle>DashDotDot</LineStyle>

</NonContainmentLine>

<MinBucketSize>3</MinBucketSize>

<VirtualGroupThreshold>3</VirtualGroupThreshold>

</DiagramViewDisplay>

</DiagramViewCriteria>

</Presentation>

235

Dashboard ViewsDashboard views provide a means for displaying multiple views at the same time in the Operations console. A single dashboard view can contain between two and nine other views.

TargetDashboard views have a target like other views, although this target is not used for any purpose. Each view that is contained in the dashboard view has its own target.

ConfigurationDashboard views have a fairly simple configuration that defines the number of rows and columns and a specific report to include in each pane. Unlike the other kinds of views, dashboard views cannot be created in the Authoring console without configuration and then installed into the management group for configuration in the Operations console. At least the number of rows and columns must be specified for being installed. This is because the number of panes in a dashboard view cannot be changed in the Operations console as soon as the view is created.

The definition of a cell in a dashboard view includes the column and row of the cell and the ID of the view for the cell to display. In addition, a cell can span multiple columns by using the ColumnSpan attribute.

The following example shows the configuration a four view diagram view that has each cell the same size.

<PanelConfiguration Columns="2" Rows="2">

<Cell Row="1" Column="1" ViewID="MyMP.MyView1"></Cell>




</PanelConfiguration>

The following example shows the configuration a five view diagram view that has three small views across the top row and two large views in the second and third rows.

<PanelConfiguration Columns="3" Rows="3">




<Cell Row="2" Column="1" ColumnSpan="3" ViewID="MyMP.MyView4"></Cell>

<Cell Row="3" Column="1" ColumnSpan="3" ViewID="MyMP.MyView5"></Cell>

</PanelConfiguration>

236

FoldersFolders are displayed in the Monitoring pane in the Operations Manager 2007 Operations console. They provide a way to organize views just like folders are used to organize files in the file system. A folder will one or more parent folder and may include one or more subfolders. If it has multiple parent folders, the folder and its contents will appear in multiple places in the Monitoring pane. The root of the folder structure is Monitoring, and all folders will be either positioned directly under this folder or be able to trace their parent folders back up to the root.

A view must be included in at least one folder if it is to be displayed in the Operations console. You can use the folder structure to group common views and provide organization to the set of views for a particular application. We recommend as a best practice that each management pack have its own top level folder, and then you can create additional folders as required.

Folders and views follow the same restrictions as other management pack elements for sealed and unsealed management packs. A view or folder may be contained in another folder only if both are in the same management pack or the parent folder is in a sealed management pack.

Linked ReportsReports in System Center Operations Manager 2007 analyze information stored in the data warehouse. In comparison, data included in views comes from the Operations Manager database. The data warehouse includes aggregated data over much longer periods of time.

Linked reports can be created using the Authoring console to provide customized versions of generic reports that are included with Operations Manager 2007. The following sections provide details of linked reports and processes for creating and including them in your management pack.

In This SectionComponents of a Linked Report

Identifies the different components of a linked report that need to be defined for it to be included in a management pack.

Report ParametersDefines report parameters and provides details for using parameters in different kinds of linked reports.

Report ControlsDefines report controls and provides details for using controls in different kinds of linked reports.

237

Generic ReportsDetails on each kind of generic report that can be used as a base for a linked report.

Components of a Linked ReportEach linked report is defined by the properties listed in the following table. The process of designing and creating a linked report primarily involves setting and modifying these properties.

Base Report Each linked report has a report that it is based on. The base report defines the contents and formatting of the report. It has a set of parameters that the linked report must provide values for.

Any report can be a base report for a linked report. The generic reports are specifically designed for this purpose. They are the focus of this documentation.

Target Class A linked report can have a target class although one is not required. If a target class is defined, the linked report is listed in the Actions pane of the Operations console when one or more instances of the target class are selected. If you select the report from the Actions pane, the selected instances are included in the Object XML Picker control of the report. If the report does not have a target class, it can only be run from the Reporting pane.

Parameter Block and Parameters Most reports have parameters that each require a value for the report to run. The linked report is required to provide a value for each of the parameters required by its base report. These values can either be included with the linked report or the user provides them when running or scheduling the linked report.

Values that should be hardcoded by the linked report without requiring the user to provide them are included in parameters. Those values that the user should be able to select are

238

defined by the linked report in parameter blocks. Each report’s parameter block defines one or more controls that the user sees when the report opens. Each control provides the value for one or more parameters based on input from the user.

See AlsoReport Parameters

Report Controls

Generic Reports

Report ParametersMost reports have parameters that require values when the report is run to provide details of what content the report should contain and how it should be configured. Linked reports must provide a value for each parameter required by its base report. These values can be provided either through controls that enable the user to provide the value when the user runs the report or by having the linked report provide a specific value.

Each report has its own set of parameters depending on its specific requirements. In addition to parameters unique to a particular report, multiple generic reports share a common set of parameters. This section provides details of these common parameters. The sections for each type of report in the Generic Reports section provide details about other parameters that are unique to specific reports.

In This SectionCommon Parameters

Parameters used in different kinds of reports.

Alert ParametersParameters used in alert reports that refer to the properties of an alert.

Event ParametersParameters used in event reports that refer to the properties of an event.

239

Performance ParametersParameters used in performance reports to specify the contents and formatting of performance graphs.

Common ParametersThe following parameters are common to different kinds of reports.

Date ParametersMost of the generic reports require a date range that provides the start date and end date for the data to include in the report. Generic reports use a set of common parameters to define these dates. Rather than just enabling a specific start date and end date, parameters can define dates relative to the current date. Therefore, a linked report can specify a predetermined date range without requiring input from the user when the report is run.

For example, you can create a linked report that shows data from the previous week. The starting date could be set to the seven days prior to the date that the report is run, or it could be set to the Sunday of the previous week. Each time you run the report, the dates are set dynamically so that you do not have to provide the start and end date each time.

Relative Data Time ParametersThe following table lists the date and time parameters and their allowed values.

Parameter Description Allowed Values

TimeZone Code for the time zone of the provided dates.

If the Relative Date Time Picker control is not used to let the user select the time zone, the value

A valid time zone code such as E001000000000000C4FFFFFF00000B0000000100020000000000000000000300000002000200000000000000|Pacific Standard Time

240


should be left blank to use the time zone of the current workstation.

TimeZoneName

The name of the time zone.

If the Relative Date Time Picker control is not used to let the user select the time zone, the value should be left blank to use the time zone of the current workstation.

A valid time zone name such as (UTC-08:00) Pacific Time (US & Canada)

StartDate_BaseType

EndDate_BaseType

The type of date for the start date or the end date.

Fixed Today Sunday Monday Tuesday Wednesday Thursday Friday Saturday FirstDayMonth LastDayMonth FirstDayQuarter LastDayQuarter

241


FirstDayYear LastDayYear

StartDate_BaseValue

EndDate_BaseValue

Date and time. Date is only used when StartDate_BaseType is Fixed. For other values of StartDate_BaseType only the time portion of the value is used.

A valid data and time string such as 1/1/2010 12:00:00 AM

StartDate_OffsetType

EndDate_OffsetType

The type of offset to use from the base date and value

A valid integer such as -7.

Date Parameter ExamplesThe following table shows example values required for the relative date parameters to achieve different scenarios.

Scenario BaseType BaseValue OffsetType OffsetValue

Specific date and time

Fixed 5/17/2010 02:00:00 PM

None 0

The current date at a specific time

Today 1/1/2010 12:00:00 AM

None 0

Yesterday at a specific time

Today 1/1/2010 02:00:00 PM

Day -1

This week Sunday 1/1/2010 12:00:00 AM

None 0

242

Scenario BaseType BaseValue OffsetType OffsetValue

Previous week Sunday 1/1/2010 12:00:00 AM

Week -1

This month FirstDayMonth

LastDayMonth

1/1/2010 12:00:00 AM

None 0

Previous month FirstDayMonth

LastDayMonth

1/1/2010 12:00:00 AM

Month -1

This quarter FirstDayQuarter

LastDayQuarter

1/1/2010 12:00:00 AM

Time only

None 0

Previous quarter FirstDayQuarter

LastDayQuarter

1/1/2010 12:00:00 AM

Time only

Quarter -1

This year FirstDayYear

LastDayYear

1/1/2010 12:00:00 AM

Time only

None 0

Previous year FirstDayYear

LastDayYear

1/1/2010 12:00:00 AM

Time only

Year -1

Business Relative Date Time ParametersSome reports use parameters in addition to the relative data time parameters that restrict the analysis period to business hours. These parameters are listed in the following table.


TimeType Specifies if all hours should be used or business hours only.

Regular

Business

TimeWeekMap Specifies the days of the week that business hours are applied. One or more values may be provided.

Only applies if the TimeType is Business.

Sunday

Monday

Tuesday

Wednesday

Thursday

Friday

243


Saturday

If the TimeType parameter is set to Business, the time in the StartDate_BaseValue and EndDate_BaseValue parameter is used to define business hours. The date portion of those values is used to define the start date and end date.

ManagementGroupIdThe ManagementGroupID parameter specifies the GUID of the management group to retrieve data from.

You can use the Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.ManagementPack prompt with the Checked List Box or Combo Box control to populate the control with the list of management packs installed in the management group.

ManagementPackIdThe ManagementPackID parameter specifies the ID for one or more management packs to include in the report.

You can use the Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.ManagementPack prompt with the Checked List Box or Combo Box control to populate the control with the list of management packs installed in the management group.

ObjectListThe ObjectList parameter contains XML code defining the objects used in the report. This includes an element called Object that includes the ID for the object in the data warehouse. This ID is typically not known when the report is created and is provided by the user with the Performance Object Picker control when the report is run. More than one Object element can be used if the series should contain data from more than one target object.

The Object element includes an attribute called Use that defines whether the object itself is used in the report or whether the object and all its contained objects are used. The value of this attribute can be either Self or Containment.The following XML code shows an example of the ObjectList parameter including two objects.

<Data>

<Objects>

<Object Use="Containment">5</Object>

<Object Use="Self">2</Object>

244

</Objects>

</Data>

Performance reports also use the ObjectList parameter, but it includes additional elements in those reports. This is documented in Performance Parameters.

See AlsoCommon Report Controls

Date Report Controls

Alert ParametersThe following parameters are used in alert reports to refer to the properties of an alert.

SeverityThe Severity parameter specifies the severity level of an alert using a value from the following table.

Value Description

0 Information

1 Warning

2 Critical

Use the prompt Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.AlertSeverity to populate a Checked List Box or Combo Box control with the different severity values and their friendly names.

PriorityThe Priority parameter specifies the priority level of an alert using a value from the following table.

Value Description

0 Low

1 Medium

2 High

245

Value Description

Use the prompt Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.AlertPriority to populate a Checked List Box or Combo Box control with the different severity values and their friendly names.

See AlsoReport Controls

Alert Reports

Event ParametersThe following parameters are used in Event reports to refer to the properties of an event.

EventChannelThe EventChannel parameter is a string specifying the channel of an alert. For a Windows event, this is the name of the event log.

Use the prompt Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.EvenChannel to populate a Checked List Box or Combo Box control with the list of event channels currently in the data warehouse.

EventSourceThe EventSource parameter is a string specifying the source of an alert. For a Windows event, this is the publisher name. Use the prompt Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.EventSource to populate a Checked List Box or Combo Box control with the list of event sources currently in the data warehouse.

EventTypeThe EventType parameter is a string with the name of the level of severity of the event. This value can typically be left blank to indicate that all event types should be included in the report. The following strings indicate the severity:

Error

246

Failure Audit Information Success Audit Warning

Use the prompt Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.EventType to populate a Checked List Box or Combo Box control with the list of event types currently in the data warehouse.

Event CategoryThe EventCategory parameter specifies the category of the event.

Use the prompt Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.EventCategory to populate a Checked List Box or Combo Box control with the list of event categories currently in the data warehouse.

See AlsoCommon Report Controls

Event Reports

Performance ParametersThe following parameters are used in Performance reports in Operations Manager 2007 to set the contents and configuration of performance charts.

AggregationTypeThe AggregationType parameter specifies how to aggregate the data on the X-axis of the performance chart. Allowed values for this parameter are provided in the following table.

Value Description

0 None

1 Daily

2 Weekly

3 Monthly

4 Yearly

247

Use the Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.Histogram prompt to populate a ComboBox control with the possible values for the AggregationType parameter.

DataAggregationThe DataAggregation parameter specifies how to aggregate the data included in the performance chart. Allowed values for this parameter are provided in the following table.

Value Description

0 Hourly

1 Daily

Use the prompt Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.DataAggregation to populate a Combo Box control with the list of sources currently in the data warehouse.

Enable3DThe Enable3D parameter specifies whether the chart should be displayed in 3D or not. It can have a value of True or False.

Use the Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.Chart3D prompt to populate a Boolean Picker control with the valid values for the Enable3D parameter.

ObjectListIn performance reports, the ObjectList parameter contains XML code defining the configuration of the charts and series included in the report. The following table describes the elements that may be included in this parameter.

Property Description Allowed Values

Object ID for the object in the data warehouse. This ID is typically not known and is provided by the user who has the Performance Object Picker control.

The ID of an object in the data warehouse.

The Use attribute may have the value Self or Containment.

248


More than one Object element can be used if the series should contain data from more than one target object.

The element includes an attribute called Use that defines whether the object is used or whether the object and all its contained objects are used.

Rule The rule that collects the data to include in the series. This should be an $MPElement variable instead of a GUID to allow for it to be transferred between management packs.

The GUID of the rule. If the parameter is populated from a control when the report is run, it will be the actual GUID of the rule. If a value is provided in the linked report, an $MPElement variable is typically used such as $MPElement[Name="MyMP.MyApp.MyCollectionRule"]$.

Scale Multiplier to use against the value.

An integer value. For example, to use the collected value, you would set this parameter to 1. To multiply the collected value by 100, you would set this parameter to 100. To divide the collected value by 1,000, you would set this parameter to .001.

Type The kind of graph One of the following values

Area Column Line Point

249


Spline SplineArea StepLine

Color Three numeric values that indicate the color of the line.

The allowed values are shown in the following table.

The values for common values for the Color element are listed in the following table.

Color Value

Light Blue 63,63,255

Dark Green 0,159,0

Light Red 255,31,31

Yellow 255,221,0

Black 0,0,0

Dark Blue 31,31,159

Light Green 63,255,63

Orange 255,127,63

Light Gray-Blue 191,191,255

Brown 191,111,47

Each chart is defined by a Values element and each series in the chart is defined by a Value element. The following XML code shows an example of a report that has two charts. The first chart has two series, and the second chart has a single series.

<Data>

<Values>

<Value>

<Object Use="Containment">2</Object>

<Rule>$MPElement[Name="MyMP.MyApp.MyCollectionRule1"]$</Rule>

<Color>63,63,255</Color>

<Type>Line</Type>

<Scale>1</Scale>

250

</Value>

<Value>





<Type>Line</Type>

<Scale>.01</Scale>

</Value>

</Values>

<Values>

<Value>




<Type>Line</Type>

<Scale>100</Scale>

</Value>

</Values>

</Data>

RuleIdThe RuleId parameter specifies the ID of a collection rule for performance reports that display the top objects or instances for a particular rule. If this parameter is collected by a control when you run the report, this is the actual GUID of the rule. If a specific rule is specified in the linked report, an $MPElement variable for the rule should be used.

Use the Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.PerformanceRule prompt to populate a Performance Rule Picker or Performance Rule Instance Picker control with a list of rule IDs currently in the data warehouse.

RuleInstanceThe RuleInstance parameter specifies the name of one or more instances to include in a performance object report.

251

SortOrderThe SortOrder parameter specifies whether to sort from the top or bottom in a top instances or top object performance report. Allowed values for this parameter are provided in the following table.

Value Description

-1 Top

1 Bottom

Use the prompt Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.TopAlgorithmParameter to populate a Combo Box control with the allowed values for the SortOrder parameter.

TopCountThe TopCount parameter specifies how many instances or objects to include in a performance report.

Use the prompt Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.TopAlgorithm to populate a Combo Box control with the allowed values for the TopCount parameter.

See AlsoPerformance Report Controls

Performance Reports

Report ControlsReport controls are displayed in the Operations console when you open a report. They allow you to set the values of parameters for the report before running it. When you want to create a linked report and you are not going to provide specific values for certain parameters, you typically use the same control as the base report for the same parameter. You can also provide configuration for certain controls to modify their behavior.

FormattingControls are displayed in the header of the report when it is opened in the Operations console. The width of the header expands to fit the width of the report window. The parameter block of the report has a columns attribute that defines how many columns the header should be separated

252

into. Each control has a columnSpan attribute that defines the width of the control. If the columnSpan attribute is not provided, it is set to the default value of 1.

The controls are populated into the header from left to right in the order that they are listed in the parameter block. When the column width of the header has been reached, the controls continue to populate from the left side of the header beneath the control in the same horizontal position.

The height of the control is defined by the rowSpan attribute. If the rowSpan attribute is not provided, it is set to the default value of 1. If a control has a rowSpan that is greater than the rowSpan of other controls, the controls stack on top of each other before they are placed in the next column.

For example, the following table lists the controls with their columnSpan and rowSpan attributes for the Alert report. The Relative Date Time Picker and the Monitoring Object XML Picker controls are side-by-side and take up the entire height of the header. Two Checked List Box controls are on the right side of the header and sit on top of each other.

The columns attribute of the parameter block is set to 6. Because the columnSpan attribute for Relative Date Time Picker and Monitoring Object XML Picker are set to 2 and 3 respectively, these controls take up the first five column positions of the header. The Checked List Box controls have a columnSpan of 1 meaning that they should each take up an additional column position. Because the rowSpan for both is 1, and the rowSpan for the first two controls is 2, the controls are able to stack on top of each other and take up just a single column position. If the rowSpan for these controls were the same as the first two controls, the second Checked List Box would wrap to the next position in the first column.

Control columnSpan

rowSpan

Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.RelativeDateTimePicker

2 2

Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.MonitoringObjectXmlPicker

3 2

Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.CheckedListBox

1 1

Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.CheckedListBox

1 1

BindingEach control has one or more report parameters that it collects data for. This parameter is specified in the binding attribute for the control. If a control uses a prompt, it does not require a binding attribute because the prompt maps to a specific parameter.

253

PromptsPrompts can be used to populate a control with possible values. For example, Event reports use a parameter for the event source. The prompt Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.EventSource retrieves a list of all sources in the data warehouse for populating a check box or combo box. Appropriate prompts for different controls and parameters are included in the definition of the generic report. You can copy it to the linked report as part of the parameter block.

Prompts that can be used for different parameters are defined with the parameter in Report Parameters.

PropertiesProperties can be used to control the configuration of certain controls. For example, the Numeric Up Down control allows for two parameters called Minimum and Maximum that define the range of allowed values.

Properties that can be used with different controls are defined with the controls in the following sections. They can be used with multiple types of reports.

In This SectionCommon Report Controls

Describes and provides examples for controls used in multiple kinds of reports for populating different parameters. These include Object XML Picker, Report Column Picker, Boolean Picker, Combo Box, Checked List Box, and Numeric Up Down controls.

Date Report ControlsDescribes and provides examples for controls used in multiple kinds of reports for populating date parameters. These include the Relative Date Time Picker and Business Relative Date Time Picker controls.

Performance ParametersDescribes and provides examples for controls used in performance reports. These include the Performance Chart Object Picker and Linked Performance Chart Object Picker controls.

254

See AlsoReport Parameters

Common Report ControlsThe controls in this section are used in various reports in Operations Manager 2007 to populate different kinds of parameters.

Boolean PickerThe ID of the Boolean Picker control is Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.BooleanPicker. This control provides a drop-down box that prompts for parameters that require a single value of true or false.

ExampleThe following XML code shows an example of the Boolean Picker control to populate the Enable3D parameter in a performance report.

<Control

type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.BooleanPicker">

<ReportParameters>

<ReportParameter name="Enable3D">

<Prompt>Microsoft.SystemCenter.DataWarehouse.Report.Library!

Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.Chart3D</Prompt>

</ReportParameter>

</ReportParameters>

</Control>

Checked List BoxThe ID of the Checked List Box control is Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.CheckedListBox. This control provides a set of check boxes where you can select one or more values. The box includes friendly text that represents the value instead of displaying the value itself.

255

ExampleThe following is an example of the XML code for a Checked List Box control populating the AlertSeverity parameter in an Alert Detail report. This uses a prompt to populate the list with the possible severities.

<Control

type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.CheckedListBox"

rowSpan="1" columnSpan="1">

<ReportParameters>

<ReportParameter name="AlertSeverity">


Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.AlertSeverity</Prompt>

</ReportParameter>

</ReportParameters>

</Control>

Combo BoxThe ID of the Combo Box control is Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.ComboBox. This control provides a drop-down box where you can select one of multiple possible values for a parameter. The box includes friendly text that represents the value instead of displaying the value itself.

ExampleThe following is an example of the XML code for a Combo Box control populating the DataAggregation parameter in an Availability report. This uses a prompt to populate the combo box that has possible aggregation settings.

<Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.ComboBox">

<ReportParameters>

<ReportParameter name="DataAggregation">


Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.DataAggregation</Prompt>

</ReportParameter>

</ReportParameters>

</Control>

256

Object XML PickerThe ID of the Object XML Picker control is Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.MonitoringObjectXmlPicker. This control lets you select the objects that will be included in the report. It will populate the ObjectList parameter which most generic reports use. The data that is created by this control includes an ID for each object. The ID for an object is unique for each data warehouse and is not immediately available to hardcode in a parameter of the linked report. Therefore, this control is typically not removed from a linked report.

For performance reports, the Linked Performance Chart Object Picker control is typically used to populate the ObjectList parameter. This is discussed in the Performance Report Controls section of this guide.

Filtering ObjectsA common source of frustration for users when they run a report is selecting appropriate objects. If they select an instance of the wrong class, the report will typically return no data, and the correct class to use may not be obvious. You can use a filter on the Object XML Picker to ease this frustration. This limits any searches to only instances of a class valid for the report.

The filter is set by the two properties of the Object XML Picker control in the following table.

Property Name Description Allowed Values

TypeFilter ID of the class to limit searches

String with the ID of any class

ContextObjectBinding Specifies whether just the selected object is used as the target of the report or all objects hosted or contained by the target are used

One of the following values:

Self Containment

For example, the Microsoft SQL Server 2008 (Monitoring) management pack includes a report named SQL Server Configuration. This report is only intended to use instances of the SQL Server 2008 DB Engine the XML code shown here is used in the report to set the filter. This ensures that only instances of the class SQL Server 2008 DB Engine are returned.

<Property name="ContextObjectBinding">

<Value>Containment</Value>

</Property>

<Property name="TypeFilter">

<Value>Microsoft.SQLServer.2008.DBEngine</Value>

257

</Property>

ExampleThe XML code that is shown here shows an example of the Object XML Picker control that uses a filter for a custom class.

<Control columnSpan="2" rowSpan="2"

type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.MonitoringObjectXmlPick

er">

<ReportParameters>

<ReportParameter name="ObjectList">


Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.ObjectList</Prompt>

</ReportParameter>

<ReportParameter name="ManagementGroupId" binding="GroupList" />

</ReportParameters>

<Properties>



</Property>


<Value>MyMP.MyComputerRole1</Value>

</Property>

</Properties>

</Control>

Numeric Up DownThe ID of the Numeric Up Down control is Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.NumericUpDown. This control accepts a single numeric value. It provides arrows to increment the value up and down with a mouse click.

The Numeric Up Down control has two properties called minimum and maximum. These properties set the minimum and maximum value that the control will allow. This lets you specify the range of values that will be valid for the property.

258

ExampleThe following is an example of the XML code that uses the minimum and maximum properties to limit the range of the value collected by a numeric up down control to be between 1 and 100. This is from a Performance Top Instances report setting the number of instances to include in the report.

<Control

type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.NumericUpDown">

<ReportParameters>

<ReportParameter name="TopCount">


Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.TopAlgorithmParameter</Prompt>

</ReportParameter>

</ReportParameters>

<Properties>

<Property name="Minimum">

<Value>1</Value>

</Property>

<Property name="Maximum">

<Value>100</Value>

</Property>

</Properties>

</Control>

See AlsoCommon Parameters

Report Parameters

Date Report ControlsThe controls in this section are used in multiple types of reports to select values for date and time parameters.

Relative Date Time PickerThe ID of the Relative Date Time Picker control is Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.RelativeDateTimePicke

259

r. This control enables you to select a start and end date and time for the report by collecting values for the standard date parameters detailed in the Common Parameters section of this guide.

There is typically no configuration required for this control. If it is included in the linked report, then you can select a start and end time when you run the report. If values for the start and end time are provided in the linked report, then this control should be removed.

ExampleThe following is an example of the XML code for a Relative Date Time Picker control. Because this control works with standard date parameters, the following example is typically used without change in different linked reports.

<Control

type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.RelativeDateTimePicker"

columnSpan="2" rowSpan="2">

<ReportParameters>

<ReportParameter name="TimeZone" binding="TimeZone">


Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.TimeZone</Prompt>

</ReportParameter>

<ReportParameter name="TimeZoneName" binding="TimeZoneName" />

<ReportParameter name="StartDate_BaseType" binding="StartDate_BaseType" />

<ReportParameter name="StartDate_BaseValue" binding="StartDate_BaseValue">


Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.StartDateTime</Prompt>

</ReportParameter>

<ReportParameter name="StartDate_OffsetType" binding="StartDate_OffsetType" />

<ReportParameter name="StartDate_OffsetValue" binding="StartDate_OffsetValue" />

<ReportParameter name="EndDate_BaseType" binding="EndDate_BaseType" />

<ReportParameter name="EndDate_BaseValue" binding="EndDate_BaseValue">


Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.EndDateTime</Prompt>

</ReportParameter>

<ReportParameter name="EndDate_OffsetType" binding="EndDate_OffsetType" />

<ReportParameter name="EndDate_OffsetValue" binding="EndDate_OffsetValue" />

</ReportParameters>

</Control>

260

Business Relative Date Time PickerThe ID of the Business Relative Date Time Picker control is Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.BusinessRelativeDateTimePicker. This control is similar to the Relative Date Time Picker control, but adds the Business Relative Date Time Parameters detailed in the Common Parameters section.

ExampleThe following is an example of the XML code for a Business Relative Date Time Picker control. Because this control works with standard date parameters, the following example is used without change in different linked reports.

<Control

type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.BusinessRelativeDateTim

ePicker" columnSpan="2" rowSpan="2">

<ReportParameters>


<Prompt> Microsoft.SystemCenter.DataWarehouse.Report.Library!


</ReportParameter>






</ReportParameter>







</ReportParameter>



<ReportParameter name="TimeType" binding="TimeType" />

<ReportParameter name="TimeWeekMap" binding="TimeWeekMap" />

</ReportParameters>

261

</Control>


Performance Report ControlsThe controls in this section are used to populate parameters for performance reports in Operations Manager 2007.

Performance Chart Object PickerThe ID of the Performance Chart Object Picker is Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl. PerformanceChartObjectPicker. This control lets you select the details of the charts and series that will be include in the report. It will populate the ObjectList parameter as described in the Performance Parameters section of this document and the ManagementGroupId parameter described in Common Parameters.

Using this control, you must select which objects and which collection rules are included in the data when the report is run. Most linked reports will not use this control because linked performance reports will typically define the collection rules being used so that the user does not have to perform this selection. Using this control, the linked report would not vary significantly from the generic report. Linked reports will typically use the Linked Performance Chart Object Picker control instead which gives users just the objects to be selected, while the graph configuration is provided in a property of the control.

ExampleThe following is an example of the XML code for a Performance Chart Object Picker control. If the control is used in a linked report, this code would typically be used without change.

<Control

type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.PerformanceChartObjectP

icker" columnSpan="4" rowSpan="3">

<ReportParameters>




</ReportParameter>


262

</ReportParameters>

</Control>

Linked Performance Chart Object PickerThe ID of the Linked Performance Chart Object Picker is Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.LinkedPerformanceChartObjectPicker. This control allows you to select the Object elements for the ObjectList parameter. The other elements for this parameter are expected to be set by the report and not changed by the user.

This control is used only in linked reports where the performance rules and graph configuration are predefined and the user is required to only select the specific objects to include in the report. The control resembles the Monitoring Object XML Picker control but includes no interface for graph configuration. The control has the following properties to provide the configuration for the graph.

PropertiesThe Linked Performance Chart Object Picker control uses the same properties as the Object XML Picker control to filter available objects in addition to a property to specify the configuration of the graph. The following table lists the properties that can be defined on the Linked Performance Chart Object Picker control.


TypeFilter ID of the class to limit searches

String with the ID of any class

ContextObjectBinding Specifies whether the report will contain data from the selected

Self

Containment

ValueTemplate Defines the configuration of each series included in the chart

XML code described later.

ValueTemplate PropertyThe ValueTemplate property contains XML code defining the configuration of the charts and series included in the report. This XML code resembles the code for the ObjectList parameter that is used by performance reports. The following table describes the elements that may be included in this parameter.

263


Chart Defines a chart in the report. Includes an attribute called ObjectJoin that specifies the behavior of the report if multiple objects are selected.

This element has no data. Each Chart element specifies a separate chart. The allowed values for the ObjectJoin attribute are provided later.

Rule The rule that collects the data to include in the series. This should be an $MPElement variable instead of a GUID to allow for the rule to be transferred between management packs.

The GUID of the rule. If the parameter is populated from a control when the report is run, then it will be the actual GUID of the rule. If a value is provided in the linked report, then an $MPElement variable is typically used such as $MPElement[Name="MyMP.MyApp.MyCollectionRule"]$.

Scale Multiplier to use against the value.

An integer value. For example, to use the collected value, you would set this parameter to 1. To multiply the collected value by 100, you would set this parameter to 100. To divide the collected value by 1,000, you would set this parameter to .001.

Type The type of graph One of the following values

Area Column Line Point Spline SplineArea StepLine

Color Three numeric values that

The allowed values are shown in the table that follows.

264


indicate the color of the line.

The ObjectJoin attribute of the Chart attribute specifies the behavior of the report if multiple objects are selected. The allowed values are listed in the following table.

Value Description

ChartPerObject A separate chart is created for each object.

AverageAll A single chart is displayed with the average of the value from all objects.

The values for common values for the Color element are listed in the following table.

Color Value

Light Blue 63,63,255

Dark Green 0,159,0

Light Red 255,31,31

Yellow 255,221,0

Black 0,0,0

Dark Blue 31,31,159

Light Green 63,255,63

Orange 255,127,63

Light Gray-Blue 191,191,255

Brown 191,111,47

ExampleEach chart is defined by a Charts element while each series in the chart is defined by a Value element. The following XML code shows an example of a report that has two charts. The first chart has two series, and the second chart has a single series.

<Control

type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.LinkedPerformanceChartO

bjectPicker" columnSpan="4" rowSpan="3">

<ReportParameters>

265




</ReportParameter>


</ReportParameters>

<Properties>

<Property name="ValueTemplate">

<Value><![CDATA[

<Data>

<Chart ObjectJoin="ChartPerObject">

<Series>

<Rule>$MPElement[Name="MyApp.MyCollectionRule1"]$</Rule>

<Scale>1</Scale>

<Type>Line</Type>


</Series>

<Series>

<Rule>$MPElement[Name=" MyApp.MyCollectionRule2"]$</Rule>

<Scale>1</Scale>

<Type>Line</Type>


</Series>

</Chart>

</Data>

]]></Value>

</Property>



</Property>


<Value>MyApp.MyComputerRole1</Value>

</Property>

</Properties>

266

</Control>

Performance Rule PickerThe ID of the Performance Rule Picker is Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.PerformanceRulePicker. This control lets you select the rule to include in a top instance performance report. It will populate the RuleID parameter as described in the Performance Parameters section of this document and the ManagementGroupId parameter described in Common Parameters.


<Control

type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.PerformanceRulePicker"

columnSpan="3">

<ReportParameters>

<ReportParameter name="RuleId">


Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.PerformanceRule</Prompt>

</ReportParameter>


</ReportParameters>

</Control>

Performance Rule Instance PickerThe ID of the Performance Rule Picker is Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.PerformanceRuleInstancePicker. This control lets you select the rule and one or more instances to include in a top object performance report. It will populate the RuleID and RuleInstance parameters as described in the Performance Parameters section of this document and the ManagementGroupId parameter described in Common Parameters.


267

<Control

type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.PerformanceRuleInstance

Picker" columnSpan="2" rowSpan="3">

<ReportParameters>




</ReportParameter>


<ReportParameter name="RuleInstance" binding="InstanceList" />

</ReportParameters>

</Control>

See AlsoPerformance Parameters

Performance Reports

Generic ReportsThe following sections provide details for each generic report. These are organized into sections that include reports returning similar data. Provided for each report are the list of the parameters and controls of the report and the XML code of its parameter block. You can copy this XML code into the parameter block of a linked report based on the generic report. As described in Building a Linked Report, copying the parameter block from the base report to the linked report is one step in creating the linked report.

The following table lists the generic reports that can be used as a base for linked reports.

Category Report Description

Alert Reports Alerts Shows for selected objects alerts raised during the selected report duration and for given filter parameters.

Alert Logging Latency Helps to isolate issues in monitoring with System Center Operations Manager by showing the logging latency of an alert for selected objects

268


over time.

Most Common Alerts Shows for selected objects the most common alerts raised during the selected report duration and for given filter parameters.

Event Reports Custom Event Shows event data filtered by all selected parameters.

Event Analysis Shows a table of events and a count by server filtered by all entered parameters.

Most Common Events Shows for selected objects the most common events raised during the selected report duration and for given filter parameters.

Performance Reports Performance Shows selected objects and performance counter values graphically over time.

Performance Details Shows selected objects and performance counter values graphically over time with fixed parameters.

Performance Top Instances Shows for selected objects and a specific performance counter rule the top or bottom "n" instances.

Performance Top Objects Shows for a specific performance counter rule the top or bottom "n" objects.

Availability Reports Availability Shows for selected objects the time in state during the selected report duration. Time in state is summarized by default as per the objects availability Monitors.

Configuration Reports Configuration Changes Shows for selected objects the

269


changes in configuration over time.

Custom Configuration Shows configuration data filtered by all entered parameters.

Alert ReportsAlert reports in Operations Manager 2007 access alerts that have been created from rules or monitors. Following is a description of each Alert generic report that includes a description of its report controls and report parameters. The parameter block of each report that can be copied into the definition of a linked report is also included.

AlertsThe Alerts report shows all raised alerts for a given set of objects during the specified time period. You can add additional filters for alert severity and priority to scope report output.

The ID of the Alerts report is Microsoft.SystemCenter.DataWarehouse.Report.Alert.

Controls and ParametersThe controls that are used in the Alerts report are shown in the following table with the parameters that each populates.

Control Parameters Description

Relative Data Time Picker StartDate_BaseType

StartDate_BaseValue


StartDate_OffsetValue

EndDate_BaseType

EndDate_BaseValue

EndDate_OffsetType

EndDate_OffsetValue

TimeZone

TimeZoneName

All alerts that were raised in the date and time range that are included in the report. These are the standard date parameters described in Common Parameters.

This control can be removed if a defined relative data time range is provided for the parameter.

Monitoring Object XML ObjectList Specifies the groups or

270


Picker

ManagementGroupId

objects that are included in the report. This includes an ID from the data warehouse so that the parameters cannot be populated without the control. This is the standard Object XML Picker control described in Common Report Controls.

This control should not be removed from the report.

Checked List Box Severity Specifies one or more alert severity values to include in the report. The values for this parameter are provided in Alert Parameters.

This control can be removed from the report if one or more specific severity values are provided for the parameter.

Checked List Box Priority Specifies one or more alert priority values to include in the report. The values for this parameter are provided in Alert Parameters.

This control can be removed from the report if one or more specific priority values are provided for the parameter.

Parameter BlockThe following is the parameter block for the Alerts report. You can copy it into a linked report based on the Alerts report to replicate the controls of the base report.

<ParameterBlock columns="6"

xmlns="http://schemas.microsoft.com/mom/reporting/2007/ReportParameterSettings">

<Controls>

271

<Control



<ReportParameters>




</ReportParameter>






</ReportParameter>


<ReportParameter name="StartDate_OffsetValue"

binding="StartDate_OffsetValue" />





</ReportParameter>



</ReportParameters>

</Control>

<Control


er" rowSpan="2" columnSpan="3">

<ReportParameters>




</ReportParameter>


272

</ReportParameters>

</Control>

<Control



<ReportParameters>

<ReportParameter name="Severity">


Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.AlertSeverity</Prompt>

</ReportParameter>

</ReportParameters>

</Control>

<Control



<ReportParameters>

<ReportParameter name="Priority">


Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.AlertPriority</Prompt>

</ReportParameter>

</ReportParameters>

</Control>

</Controls>

</ParameterBlock>

Alert Logging LatencyThe Alert Logging Latency report shows the time an alert takes from being picked up on the agent to the time it is written to the database. Every alert written to the database is time-stamped. The time the alert was raised on the agent is subtracted to give you the latency. This report allows for comparing the reported latencies against a threshold, which can be entered as a parameter.

The ID of the Alert Logging Latency report is Microsoft.SystemCenter.DataWarehouse.Report.AlertLoggingLatency.

Controls and ParametersThe controls that are used in the Alert Logging Latency report are shown in the following table with the parameters that each populates.

273



StartDate_BaseValue



EndDate_BaseType

EndDate_BaseValue

EndDate_OffsetType

EndDate_OffsetValue

TimeZone

TimeZoneName

Specifies all alerts that were raised in the date and time range included in the report. These are the standard date parameters described in Common Parameters.


Monitoring Object XML Picker

ObjectList

ManagementGroupkId

Specifies the groups or objects that are included in the report. This includes an ID from the data warehouse so that the parameters cannot be populated without the control. This is the standard Object XML Picker control described in Common Report Controls.


Combo Box Threshold Specifies a single value, defining the threshold for the alert latency. Alerts are separated in the report between those above the threshold and those below the threshold. This value is a duration measured in seconds. The valid values are listed in the table below.

Combo Box AggregationType Specifies a single value, defining the aggregation type to use for the graph. The allowed values are listed in the table below.

274

Threshold ParameterThe following table lists the valid values for the threshold parameter.

Value Threshold

1 1 second

2 2 seconds

5 5 seconds

10 10 seconds

15 15 seconds

30 30 seconds

60 1 minute

120 2 minutes

300 5 minutes

600 10 minutes

900 15 minutes

1800 30 minutes

AggregationType ParameterThe following table lists the valid values for the AggregationType parameter.

Value Description

0 Hourly

1 Daily

2 Monthly

Parameter BlockThe following is the parameter block for the Alert Logging Latency report. You can copy it into a linked report based on the Alert Logging Latency report to replicate the controls of the base report.

275



<Controls>

<Control



<ReportParameters>




</ReportParameter>






</ReportParameter>








</ReportParameter>



</ReportParameters>

</Control>

<Control


er" rowSpan="4" columnSpan="3">

<ReportParameters>


276



</ReportParameter>


</ReportParameters>

</Control>

<Control

type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.ComboBox" rowSpan="1"

columnSpan="1">

<ReportParameters>

<ReportParameter name="Threshold">


Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.Threshold</Prompt>

</ReportParameter>

</ReportParameters>

</Control>

<Control

type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.ComboBox" rowSpan="1"

columnSpan="1">

<ReportParameters>

<ReportParameter name="AggregationType">


Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.Aggregation</Prompt>

</ReportParameter>

</ReportParameters>

</Control>

</Controls>

</ParameterBlock>

Most Common AlertsThe Most Common Alerts report helps identify high-volume alerts, the management pack they originate from, the volume a distinct alert contributes to the total number of alerts, and the resolution times. This report helps tune alerts.

The ID of the Most Common Alerts report is Microsoft.SystemCenter.DataWarehouse.Report.MostCommonAlerts.

277

Controls and ParametersThe controls that are used in the Most Common Alerts report are shown in the following table with the parameters that each populates.



StartDate_BaseValue



EndDate_BaseType

EndDate_BaseValue

EndDate_OffsetType

EndDate_OffsetValue

TimeZone

TimeZoneName

All alerts that were raised in the date and time range are included in the report. These are the standard date parameters described in Common Parameters.


Checked List Box ManagementPackId Specifies one or more management packs containing the rules and monitors creating the alerts to include in the report.


Numeric Up Down AlertThreshold Specifies the number of alerts to include in the report. This is any numeric value between 1 and 100.

Parameter BlockThe following is the parameter block for the Most Common Alerts report. You can copy it into a linked report based on the Most Common Alerts report to replicate the controls of the base report.



<Controls>

278



>

<ReportParameters>




</ReportParameter>






</ReportParameter>








</ReportParameter>



</ReportParameters>

</Control>


type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.CheckedListBox">

<ReportParameters>

<ReportParameter name="ManagementPackId">


Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.ManagementPack</Prompt>

</ReportParameter>

</ReportParameters>

</Control>

279



<ReportParameters>

<ReportParameter name="AlertThreshold">



</ReportParameter>

</ReportParameters>

<Properties>


<Value>1</Value>

</Property>


<Value>100</Value>

</Property>

</Properties>

</Control>

</Controls>

</ParameterBlock>


Alert Parameters


Common Report Controls

Event ReportsEvent reports in Operations Manager 2007 access events that are collected by rules. Following is a description of each Event generic report that includes a description of its report controls and report parameters. The parameter block of each report that can be copied into the definition of a linked report is also included.

280

Event AnalysisThis report shows a table of events and a count by server filtered by all entered parameters.

The ID of the Event Analysis report is Microsoft.SystemCenter.DataWarehouse.Report.EventAnalysis.

Controls and ParametersThe controls that are used in the Event Analysis report are shown in the following table with the parameters that each populates.

Control Control Description

Relative Date Time Picker StartDate_BaseType

StartDate_BaseValue



EndDate_BaseType

EndDate_BaseValue

EndDate_OffsetType

EndDate_OffsetValue

TimeZone

TimeZoneName

All events that were created in the date and time range are included in the report. These are the standard date parameters described in Common Parameters.



ObjectList

ManagementGroupId



Combo Box Event Source Specifies the event source. The valid values are described in Event Parameters. Leave blank for all.

281

Control Control Description

This control can be removed from the report if one or more specific event source values are provided for the parameter.

Combo Box Event Type Specifies the event type. The valid values are described in Event Parameters. Leave blank for all.

This control can be removed from the report if one or more specific event type values are provided for the parameter.

Combo Box Event Category Specifies the event category. The valid values are described in Event Parameters. Leave blank for all.

This control can be removed from the report if one or more specific event category values are provided for the parameter.

Numeric Up Down Event ID Specifies the event ID. Leave blank for all.

This control can be removed from the report if one or more specific event ID values are provided for the parameter.

Parameter BlockThe following is the parameter block for the Event Analysis report. You can copy it into a linked report based on the Event Analysis report to replicate the controls of the base report.



<Controls>

282

<Control rowSpan="4" columnSpan="2"


>

<ReportParameters>




</ReportParameter>






</ReportParameter>








</ReportParameter>



</ReportParameters>

</Control>



er">

<ReportParameters>




</ReportParameter>


283

</ReportParameters>

</Control>


type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.ComboBox">

<ReportParameters>

<ReportParameter name="EventSource">


Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.EventSource</Prompt>

</ReportParameter>

<ReportParameter name="EventSourceLookup" binding="Lookup" />

</ReportParameters>

</Control>



<ReportParameters>

<ReportParameter name="EventType">


Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.EventType</Prompt>

</ReportParameter>

</ReportParameters>

</Control>



<ReportParameters>

<ReportParameter name="EventCategory">


Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.EventCategory</Prompt>

</ReportParameter>

</ReportParameters>

</Control>



<ReportParameters>

<ReportParameter name="EventID">

284


Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.EventID</Prompt>

</ReportParameter>

</ReportParameters>

</Control>

</Controls>

</ParameterBlock>

Custom EventThe Custom Event report includes collected events containing specific information. The list of event details is defined by the rules collecting the events. By selecting the check box, you can select to print a detail of the event on the report. The controls to the right allow for defining the order of the selected items from left (higher in the parameter list) to right (lower in the parameter list).

The ID of the Custom Event report is Microsoft.SystemCenter.DataWarehouse.Report.EventTemplate.

Controls and ParametersThe controls that are used in the Custom Event report are shown in the following table with the parameters that each populates.



StartDate_BaseValue



EndDate_BaseType

EndDate_BaseValue

EndDate_OffsetType

EndDate_OffsetValue

TimeZone

TimeZoneName



Object Picker ObjectList

ManagementGroupId

Specifies the groups or objects that are included in the report. This includes an ID from the data warehouse so that the parameters cannot be

285


populated without the control. This is the standard Object XML Picker control described in Common Report Controls.


Report Column Picker Columns Specifies the columns to be included in the output of the report and the columns that are used to filter the returned data. This is described in more detail later in this section.

This control can be removed if a set of column definitions is provided for this parameter.

Columns ParameterThe Columns parameter defines the columns to include in the output of the report and the columns that are used to filter the output. The table below lists the values that are required to define each column:

ID Element Element that defines the ID of the property. If the Operations console is used, this will be the GUID of the property. This must be changed to an $MPElement variable so that the management pack can be transferred between management groups.

Visible Attribute Attribute with a value of True or False specifying whether the column should be displayed. If the value is False, it is expected that the column is only used to filter the output.

Filter Element If used, this element identifies the column as being used for filtering the output. The Type attribute can be either Contains or Equals, and the content of the element includes the text to match.

286

If the column should only be displayed and not used for filtering, the filter element is not included.

All properties are included as a single parameter entry using the syntax shown in the following example. This example shows a report that uses the following details:

Displays the columns EventDisplayNumber, DateTime, and EventPublisherName. Only includes events with a level of Error and a Publisher Name of Health Service.

<Data>

<Columns>

<Column Visible="False">

<ID>EventLevelTitle</ID>

<Filter Type="Equals">Error</Filter>

</Column>

<Column Visible="True">

<ID>EventDisplayNumber</ID>

</Column>


<ID>DateTime</ID>

</Column>


<ID>EventPublisherName</ID>

<Filter Type="Contains">Health Service</Filter>

</Column>

</Columns>

</Data>

Parameter BlockThe following is the parameter block for the Custom Event report. You can copy it into a linked report based on the Custom Event report to replicate the controls of the base report.



<Controls>



>

287

<ReportParameters>




</ReportParameter>






</ReportParameter>








</ReportParameter>



</ReportParameters>

</Control>



er">

<ReportParameters>




</ReportParameter>


</ReportParameters>

</Control>

288


type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.ReportColumnPicker">

<ReportParameters>

<ReportParameter name="Columns" />

<ReportParameter name="ColumnList" binding="ColumnList" />

</ReportParameters>

</Control>

</Controls>

</ParameterBlock>

Most Common EventsThe Most Common Events report helps identify high-volume events, the agent they originated from, and the volume that a distinct event contributes to the total number of events. This report helps tune events.

The ID of the Most Common Events report is Microsoft.SystemCenter.DataWarehouse.Report.MostCommonEvents.

Controls and ParametersThe controls that are used in the Most Common Events report are shown in the following table with the parameters that each populates.



StartDate_BaseValue



EndDate_BaseType

EndDate_BaseValue

EndDate_OffsetType

EndDate_OffsetValue

TimeZone

TimeZoneName




ManagementGroupId

Specifies the groups or objects that are included in the report. This includes an ID from the data warehouse

289


so that the parameters cannot be populated without the control. This is the standard Object XML Picker control described in Common Report Controls.


Checked List Box EventChannel Specifies ene or more values indicating the event channel.

Checked List Box EventSource Specifies one or more values for the event source. The valid values are described in Event Parameters.

This control can be removed from the report if one or more specific event source values are provided for the parameter.

Checked List Box EventType Specifies one or more values for the event type. The valid values are described in Event Parameters. Leave blank for all.

This control can be removed from the report if one or more specific event type values are provided for the parameter.

Numeric Up Down EventThreshold Specifies the number of events to include in the report. This is any numeric value between 1 and 100.

Parameter BlockThe following is the parameter block for the Most Common Events report. You can copy it into a linked report based on the Most Common Events report to replicate the controls of the base report.

290



<Controls>



>

<ReportParameters>




</ReportParameter>






</ReportParameter>








</ReportParameter>



</ReportParameters>

</Control>



er">

<ReportParameters>


291



</ReportParameter>


</ReportParameters>

</Control>



<ReportParameters>

<ReportParameter name="EventChannel">


Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.EventChannel</Prompt>

</ReportParameter>

</ReportParameters>

</Control>



<ReportParameters>

<ReportParameter name="EventSource">


Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.EventSource</Prompt>

</ReportParameter>

</ReportParameters>

</Control>



<ReportParameters>

<ReportParameter name="EventType">


Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.EventType</Prompt>

</ReportParameter>

</ReportParameters>

</Control>



292

<ReportParameters>

<ReportParameter name="EventThreshold">



</ReportParameter>

</ReportParameters>

<Properties>


<Value>1</Value>

</Property>


<Value>100</Value>

</Property>

</Properties>

</Control>

</Controls>

</ParameterBlock>


Event Parameters



Performance ReportsPerformance reports in Operations Manager 2007 analyze performance data that collected by rules. Following is a description of each Performance generic report that includes a description of its report controls and report parameters. The parameter block of each report that can be copied into the definition of a linked report is also included.

Performance The Performance report shows one or multiple charts and display data as historical chart or histograms. For the selected time range, the report includes performance data with charts and a data tables.

293

The ID of the Performance report is Microsoft.SystemCenter.DataWarehouse.Report.Performance.

Controls and ParametersThe controls that are used in the Performance report are shown in the following table with the parameters that each populates.


Business Relative Date Time Picker

StartDate_BaseType

StartDate_BaseValue



EndDate_BaseType

EndDate_BaseValue

EndDate_OffsetType

EndDate_OffsetValue

TimeZone

TimeZoneName

TimeType

TimeWeekMap

Only performance data that was collected in the date and time range are included in the report. These are the standard date parameters described in Common Parameters.


Performance Object Picker ObjectList

ManagementGroupId

Specifies objects that are included in the report and the contents and configuration of the graph. This is the standard Performance Object Picker control described in Performance Report Controls.

This control is typically replaced by Linked Performance Object Picker in linked reports that use the contents and configuration of the graph provided in the properties for that control.

Combo Box DataAggregation Specifies how to aggregate the data included in the report. Allowed values for this parameter are provided in

294


Performance Parameters.

This control can be removed from the report if you provide a specific value for the DataAggregation parameter.

Combo Box AggregationType Single value that specifies how to aggregate the data on the X-axis. Allowed values for this parameter are provided in Performance Parameters.

This control can be removed from the report if you provide a specific value for the AggregationType parameter.

Boolean Picker Enable3D A value of true or false indicates whether the graph should be displayed in 3D.

This control can be removed from the report if you provide a specific value for the Enable3D parameter.

Parameter BlockThe following is the parameter block for the Performance report. You can copy this into a linked report that is based on the Performance report to replicate the controls of the base report.



<Controls>

<Control

type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.ComboBox"

columnSpan="2">

<ReportParameters>




</ReportParameter>

295

</ReportParameters>

</Control>

<Control

type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.PerformanceChartObjectP

icker" columnSpan="4" rowSpan="3">

<ReportParameters>




</ReportParameter>


</ReportParameters>

</Control>

<Control


ePicker" columnSpan="2">

<ReportParameters>




</ReportParameter>






</ReportParameter>








</ReportParameter>

296





</ReportParameters>

</Control>

<Control


<ReportParameters>



Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.Histogram</Prompt>

</ReportParameter>

</ReportParameters>

</Control>

<Control

type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.BooleanPicker">

<ReportParameters>



Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.Chart3D</Prompt>

</ReportParameter>

</ReportParameters>

</Control>

</Controls>

</ParameterBlock>

Performance DetailThe Performance Detail report shows a series with these fixed settings:

Average is displayed as a black line. Standard Deviation is displayed as an orange area. The area between the lowest to the highest value is filled with blue color.

If a Histogram is specified, this report displays a link to a table detailing average, min, max and standard deviation for all time periods averaged into one x-axis unit. A second, smaller chart details the number of performance counter samples making up this report.

297

The ID of the Performance Detail report is Microsoft.SystemCenter.DataWarehouse.Report.PerformanceDetail.

Controls and ParametersThe controls that are used in the Performance Detail report are shown in the following table with the parameters that each populates.



StartDate_BaseType

StartDate_BaseValue



EndDate_BaseType

EndDate_BaseValue

EndDate_OffsetType

EndDate_OffsetValue

TimeZone

TimeZoneName

TimeType

TimeWeekMap



Performance Object Picker ObjectList

ManagementGroupId

Specifies objects that are included in the report and the contents and configuration of the graph. This is the standard Performance Object Picker control described in Performance Report Controls.

This control is typically replaced by Linked Performance Object Picker in linked reports that use the contents and configuration of the graph provided in that control’s properties.

Combo Box DataAggregation Specifies how to aggregate the data included in the report. Allowed values for this parameter are provided in

298


Performance Parameters.

This control can be removed from the report if you provide a specific value for the DataAggregation parameter.

Combo Box AggregationType Single value that specifies how to aggregate the data on the X-axis. Allowed values for this parameter are provided in Performance Parameters.

This control can be removed from the report if you provide a specific value for the AggregationType parameter.

Parameter BlockThe following is the parameter block for the Performance Detail report. You can copy this into a linked report based on the Performance Detail report to replicate the controls of the base report.



<Controls>

<Control


<ReportParameters>




</ReportParameter>

</ReportParameters>

</Control>

<Control

type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.PerformanceObjectPicker

" columnSpan="2" rowSpan="3">

<ReportParameters>


299



</ReportParameter>


</ReportParameters>

</Control>

<Control


ePicker">

<ReportParameters>




</ReportParameter>






</ReportParameter>








</ReportParameter>





</ReportParameters>

</Control>

300

<Control


<ReportParameters>



Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.Histogram</Prompt>

</ReportParameter>

</ReportParameters>

</Control>

</Controls>

</ParameterBlock>

Performance Top InstancesThe Performance Top Instances report shows columns for every found object starting at 0 to the max or min value for the selected reporting time range. The chart also indicates with a black error bar the fluctuation in value of this object for the selected reporting time range. If the error bar is very small this object was for the reporting time range always close to value displayed by the column. If it is very wide the object fluctuates and the top or bottom value should be not taken as the value which is to be expected.

The ID of the Performance Top Instances report is Microsoft.SystemCenter.DataWarehouse.Report.PerformanceTopInstance.

Controls and ParametersThe controls that are used in the Performance Top Instances report are shown in the following table with the parameters that each populates.



StartDate_BaseValue



EndDate_BaseType

EndDate_BaseValue

EndDate_OffsetType

EndDate_OffsetValue

TimeZone



301


TimeZoneName

Monitoring Object Picker ObjectList

ManagementGroupId



Combo Box SortOrder Single value that specifies whether to sort the instances from the top or bottom. Allowed values for this parameter are provided in Performance Parameters.

This control can be removed from the report if you provide a specific value for the SortOrder parameter.

Numeric Up Down TopCount Integer specifying the number of instances to include in the report. Allowed values for this parameter are provided in Performance Parameters.

This control can be removed from the report if you provide a specific value for the TopCount parameter.

Performance Rule Picker RuleId

ManagementGroupId

Single GUID or $MPElement variable specifying the rule collecting the performance counter. The RuleId is discussed in Performance Parameters.

302


This control can be removed from the report if you provide a specific value for the RuleId parameter.

Parameter BlockThe following is the parameter block for the Performance Top Instances report. You can copy the code block into a linked report based on the Performance Top Instances report to replicate the controls of the base report.



<Controls>

<Control



<ReportParameters>




</ReportParameter>






</ReportParameter>








</ReportParameter>

303



</ReportParameters>

</Control>

<Control


er" columnSpan="3" rowSpan="2">

<ReportParameters>




</ReportParameter>


</ReportParameters>

</Control>

<Control


<ReportParameters>

<ReportParameter name="SortOrder">


Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.TopAlgorithm</Prompt>

</ReportParameter>

</ReportParameters>

</Control>

<Control


<ReportParameters>




</ReportParameter>

</ReportParameters>

<Properties>


<Value>1</Value>

304

</Property>


<Value>100</Value>

</Property>

</Properties>

</Control>

<Control

type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.PerformanceRulePicker"

columnSpan="3">

<ReportParameters>




</ReportParameter>


</ReportParameters>

</Control>

</Controls>

</ParameterBlock>

Performance Top ObjectsThe Performance Top Objects report shows columns for every found object starting at 0 to the max or min value for the selected reporting time range. The chart also indicates with a black error bar the fluctuation in value of this object for the selected reporting time range. If the error bar is very small this object was for the reporting time range always close to value displayed by the column. If it is very wide the object fluctuates and the top or bottom value should be not taken as the value which is to be expected.

The ID of the Performance Top Objects report is Microsoft.SystemCenter.DataWarehouse.Report.PerformanceTop.

Controls and ParametersThe controls that are used in the Performance Top Objects report are shown in the following table with the parameters that each populates.


Relative Date Time Picker StartDate_BaseType Only performance data that

305


StartDate_BaseValue



EndDate_BaseType

EndDate_BaseValue

EndDate_OffsetType

EndDate_OffsetValue

TimeZone

TimeZoneName

was collected in the date and time range are included in the report. These are the standard date parameters described in Common Parameters.


Performance Rule Instance Picker

RuleId

ManagementGroupId

RuleInstance

Single GUID or $MPElement variable specifying the rule collecting the performance counter. The RuleId is discussed in Performance Parameters.

This control can be removed from the report if you provide a specific value for the RuleId and RuleInstance parameters.

Combo Box ManagementGroupID Single value that specifies the GUID of the management group to retrieve the data from.


Combo Box SortOrder Single value that specifies whether to sort the objects from the top or bottom. Allowed values for this parameter are provided in Performance Parameters.

This control can be removed from the report if you provide a specific value for the SortOrder parameter.

Numeric Up Down TopCount Integer specifying the number

306


of objects to include in the report. Allowed values for this parameter are provided in Performance Parameters.

This control can be removed from the report if you provide a specific value for the TopCount parameter.

Parameter BlockThe following is the parameter block for the Performance Top Objects report. You can copy this into a linked report based on the Performance Top Objects report to replicate the controls of the base report.



<Controls>

<Control



<ReportParameters>




</ReportParameter>






</ReportParameter>






307



</ReportParameter>



</ReportParameters>

</Control>

<Control

type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.ComboBox"

columnSpan="2">

<ReportParameters>

<ReportParameter name="ManagementGroupId">


Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.ManagementGroup</Prompt>

</ReportParameter>

</ReportParameters>

</Control>

<Control

type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.PerformanceRuleInstance

Picker" columnSpan="2" rowSpan="3">

<ReportParameters>




</ReportParameter>


<ReportParameter name="RuleInstance" binding="InstanceList" />

</ReportParameters>

</Control>

<Control


<ReportParameters>

<ReportParameter name="SortOrder">


Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.TopAlgorithm</Prompt>

308

</ReportParameter>

</ReportParameters>

</Control>

<Control


<ReportParameters>




</ReportParameter>

</ReportParameters>

<Properties>


<Value>1</Value>

</Property>


<Value>100</Value>

</Property>

</Properties>

</Control>

</Controls>

</ParameterBlock>




Performance Parameters

Performance Report Controls

Availability ReportsAvailability reports in Operations Manager 2007 provide an analysis of the availability of monitored objects. Following is a description of each Availability generic report that includes a

309

description of its report controls and report parameters. The parameter block of each report that can be copied into the definition of a linked report is also included.

AvailabilityFor every managed object within System Center Operations Manager, monitors configured in each of the disciplines below determine an objects time in state and then roll-up to an objects overall health. The availability Availability report by default shows an objects time in state as per the monitors that roll-up within the availability Availability discipline.

Controls and ParametersThe controls that are used in the Availability report are shown in the following table with the parameters that each populates.



StartDate_BaseType

StartDate_BaseValue



EndDate_BaseType

EndDate_BaseValue

EndDate_OffsetType

EndDate_OffsetValue

TimeZone

TimeZoneName

TimeType

TimeWeekMap

Only availability of the included objects in the date and time range is included in the report. These are the standard date parameters described in Common Parameters.



ManagementGroupId



310


Checked List Box Downtime Specifies one or more values defining what states should be considered as downtime. The valid values for this parameter are provided in the following table.

Combo Box DataAggregation Specifies the type of aggregation that should be performed on the data using a value from the following table.

DowntimeThe Downtime parameter can accept one of the values from the following table:

Value Description

2 Warning

3 Unmonitored

4 Monitor disabled

5 Unplanned Maintenance

6 Planned Maintenance

7 Monitoring Unavailable

The Downtime parameter can use the prompt Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.AvailabilityDownTime in a Combo Box control to list the valid values.

Data AggregationThe DataAggregation parameter can accept one of the values from the following table:

Value Description

0 Hourly

1 Daily

311

The DataAggregation parameter can use the prompt Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.DataAggregation in a Combo Box control to list the valid values.

Parameter BlockThe following is the parameter block for the Availability report. You can copy it into a linked report based on the Availability report to replicate the controls of the base report.



<Controls>

<Control


<ReportParameters>




</ReportParameter>

</ReportParameters>

</Control>

<Control


er" columnSpan="2" rowSpan="2">

<ReportParameters>




</ReportParameter>


</ReportParameters>

</Control>

<Control


rowSpan="2">

<ReportParameters>

<ReportParameter name="DownTime">

312


Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.AvailabilityDownTime</Prompt>

</ReportParameter>

</ReportParameters>

</Control>

<Control


ePicker">

<ReportParameters>




</ReportParameter>






</ReportParameter>








</ReportParameter>





</ReportParameters>

</Control>

</Controls>

</ParameterBlock>

313




Configuration ReportsConfiguration reports in Operations Manager 2007 track changes in the properties of monitored objects. Following is a description of each Configuration generic report that includes a description of its report controls and report parameters. The parameter block of each report that can be copied into the definition of a linked report is also included.

Configuration ChangesManagement Packs contain discoveries that collect object properties that are relevant for the management of the application. The data for the Configuration Changes report is derived from a delta-discovery done in the data warehouse where each discovery value is compared to the last known. If a change is detected, the changed property, the old and the new value and the time the change was discovered are recorded in the data warehouse.

The ID of the Configuration Changes report is Microsoft.SystemCenter.DataWarehouse.Report.ConfigurationChange.

Controls and ParametersThe controls that are used in the Configuration Changes report are shown in the following table with the parameters that each populates.



StartDate_BaseValue



EndDate_BaseType

EndDate_BaseValue

EndDate_OffsetType

EndDate_OffsetValue

TimeZone

TimeZoneName



314



ObjectList

ManagementGroupId



Parameter BlockThe following is the parameter block for the Configuration Changes report. You can copy it into a linked report based on the Configuration report to replicate the controls of the base report.



<Controls>

<Control


>

<ReportParameters>




</ReportParameter>






</ReportParameter>


315







</ReportParameter>



</ReportParameters>

</Control>

<Control


er" columnSpan="2">

<ReportParameters>




</ReportParameter>


</ReportParameters>

</Control>

</Controls>

</ParameterBlock>

Custom ConfigurationA management pack contains discoveries that collect information specific to the management pack. For all selected objects the Custom Configuration report displays the properties discovered by management packs. By checking the box a property can be selected to be printed on the report. The controls to the right allow defining the order of the selected properties from left (higher in the parameter list) to right (lower in the parameter list).

The ID of the Custom Configuration report is Microsoft.SystemCenter.DataWarehouse.Report.CustomConfiguration.

316

Controls and ParametersThe controls that are used in the Custom Configuration report are shown in the following table with the parameters that each populates.



StartDate_BaseValue



EndDate_BaseType

EndDate_BaseValue

EndDate_OffsetType

EndDate_OffsetValue

TimeZone

TimeZoneName




ObjectList

ManagementGroupId



Report Column Picker Columns Specifies the columns to be included in the output of the report and the columns that are used to filter the returned data. This is described below in more detail.

This control can be removed if a set of column definitions is provided for this parameter.

317

Columns ParameterThe Columns parameter defines the columns to include in the output of the report and the columns that are used to filter the output. The following table lists the values that are required to define each column.

ID Node Specifies the node defining the ID of the property. If the Operations console is used, this will be the GUID of the property. This should be changed to an $MPElement variable so that the management pack can be transferred between management groups.

Visible Attribute Specifies the attribute with a value of True or False that determines whether the column is displayed. If the value is False, the column is only used to filter the output.

Filter Node If used, this node identifies the column as being used for filtering the output. The Type attribute can be either Contains or Equals, and the content of the node includes the text to match.

If the column should only be displayed, but not used for filtering, the filter node is not included.

All properties are included as a single parameter entry using the syntax shown in the following example. This example shows a report that uses the following parameters of the Microsoft.Windows.Computer class and is filtered for computers that include ‘srv’ in the name:

PrincipalName IPAddress ActiveDirectorySite

<Data>

<Columns>


<ID>$MPElement[Name="Windows!Microsoft.Windows.Computer"]/PrincipleName$</ID>

<Filter Type="Contains">srv</Filter>

</Column>


<ID>$MPElement[Name="Windows!Microsoft.Windows.Computer"]/IPAddress$</ID>

</Column>

318


<ID>$MPElement[Name="Windows!Microsoft.Windows.Computer"]/ActiveDirectorySite$</

ID>

</Column>

</Columns>

</Data>

Parameter BlockThe following is the parameter block for the Custom Configuration report. You can copy it into a linked report based on the Custom Configuration report to replicate the controls of the base report.



<Controls>

<Control columnSpan="1"


>

<ReportParameters>




</ReportParameter>






</ReportParameter>








319

</ReportParameter>



</ReportParameters>

</Control>



er">

<ReportParameters>




</ReportParameter>


</ReportParameters>

</Control>


type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.ReportColumnPicker">

<ReportParameters>

<ReportParameter name="Properties" />


</ReportParameters>

</Control>

</Controls>

</ParameterBlock>




Presentation Design OverviewDesigning a set of System Center Operations Manager 2007 views and reports for an application consists of determining how information collected by the management pack is best presented to

320

the user. The following sections provide guidance and best practices for using different types of views and reports to let the user analyze the performance and availability of the monitored application.

In This SectionDefining Views

Best practices for creating different types of view.

Defining ReportsBest practices for creating different types of reports.

Defining ViewsThe process of defining a set of views starts by determining a set of each kind of view to provide a complete view of the health and availability of the managed application. After the required views are defined, you can determine a folder structure to organize the views.

Recommended ViewsThe following are recommendations for when each kind of a view should be included in a management pack.

State ViewsState views are the most important views to include in most management packs because they include a listing of the objects that are being managed. You can right-click the object in the Operations console and access all of the other kinds of views. However, these standard views only display information for the selected object. Custom views of each type can display information for multiple objects, and most management packs typically include a variety of other kinds of views in addition to State views.

A State view is typically defined for each class that is defined in the management pack. If multiple classes use the same abstract base class, a State view for the base class lists all instances of classes inheriting from it. This is useful if all these objects have to be viewed together. If not, you can create a separate State view for each class.

321

Alert ViewsAny management pack that creates alerts from rules or monitors should have an Alert view that includes alerts just for the application. The criteria for this view typically are alerts that are not resolved (ResolutionState not equal to 255).

Event ViewsIf the management pack collects events, it should have at least one Event view. The view should have criteria specific to a particular event. Event views with very general criteria can be inefficient and place an excessive load on the root management server. It is more efficient to have multiple views retrieving different, specific sets of events.

Performance ViewsA Performance view can include multiple counters or a single counter. The data typically is available for multiple managed objects of the same class. It is a common practice to provide a single view with all performance counters for each significant class in the management pack. This lets the user analyze a variety of counters. In addition, you should create a separate Performance view for any performance counters that are especially important. A view typically is not created for every performance counter that the management pack collects because some might not be especially useful on a daily basis. You should define a separate view for important performance counters and let the others be available through more general Performance views.

While you can combine multiple performance counters in a single view, it might not be an effective strategy. Different counters that do not have similar values might not display well on the same graph. In this case, combine separate views for each counter into a Dashboard view. This still gives you a single view for related performance counters but uses a separate graph for each.

Diagram ViewsBecause Diagram views are applied to objects instead of classes, they are less important to include in a management pack. A Diagram view is available for any managed object from a State view. There is no concept of a Diagram view for multiple instances of a class like the other kinds of views.

Diagram views are typically created for top-level objects in an application such as a distributed application. This provides a graphical representation of the health of the application itself as it is comprised of the health of its different components.

Task Status ViewsA management pack with tasks typically includes at least one Task Status view to track when tasks are run.

322

Dashboard ViewsDashboard views are useful in combining related views. They usually are views related to a particular application element. For example, multiple performance views might be combined into a single Dashboard view to provide a complete view of the overall performance of an application. Different kinds of views can also be combined such as a State view that displays instances of a particular class that has an Alert view of listing the alerts associated with the same class.

Recommended Folder StructureAll management packs should have a single top-level folder with the name of the application. For a simple application, this might be the only folder that contains all views for the application. Complex management packs can benefit from multiple folders. They still have a single top-level folder together with all other folders created below it.

The following are common reasons why management packs use multiple folders:

If an application has a separate management pack for different versions, a separate folder can be created for each. Each of these folders would contain a similar folder structure and set of views for each version.

For example, the Active Directory Server Common Library management pack includes a top-level folder named Microsoft Windows Active Directory. This contains views and folders that are common to all versions of Active Directory. The views are targeted at abstract classes that the classes for the different versions use as a base class. The management pack for each version has its own folder underneath the Microsoft Windows Active Directory folder. This folder has a name specific to the version of Active Directory, such as Active Directory Server 2008. Each version-specific folder contains the same set of views and folders that use each targeted at classes specific to that version.

An application that has different services might use a separate folder to organize views specific to each service.

For example, the SQL Server management pack has views for different components of SQL Server such as databases, the SQL Agent, and replication. Folders are created for each of these to hold the views targeted at each class. This enables different operators to focus on the information for the application elements that they are interested in.

A management pack with many views might use folders to organize a set of folders of a particular type.

For example, the Microsoft Windows DNS Server 2008 management pack has many Event views for the different application events that it collects. Instead of putting these in the top-level folder together with views that contain more critical information, the management pack has an Events folder to hold the views.

See AlsoTypes of Views

Folders

323

Defining ReportsYou can plan a set of reports in an Operations Manager 2007 management pack by determining a basic reporting strategy. That is, if you at all include any reports in the management pack. If you plan to include linked reports in your management pack, then you should define a set of reports that most effectively provide a valuable set of data to the user.

Determine Report StrategyThere are three options for including reports in a management pack.

No ReportsAll the data that is collected by a management pack can be accessed from the generic reports that are automatically installed with Operations Manager Reporting. The only requirement for the author is to make sure that the management pack includes rules that collect the required data to the data warehouse. Therefore, users of your management pack will have access to reports whether you give them your management pack.

Linked ReportsAlthough users can access generic reports for data collected by any management pack, each user is responsible both for determining what information is important and for selecting values for different report parameters. Providing custom reports or linked reports in the management pack lets you direct the user to important information. In addition, this lets the user run different reports that have a minimal number of options.

Linked reports provide a strategy for you to include generic reports in your management pack customized for your application. This enables the user to provide a minimum of configuration to run the report and means that important parameters have correct values. Linked reports require much less work than creating than a custom report and frequently will be sufficient for the reporting requirements of the application that you are monitoring.

Custom ReportsCustom reports allow for full customization of the report both in the data that is retrieved and in how the report is formatted. Custom reports are written in Report Definition Language (RDL) and can provide any option enabled by Microsoft SQL Server Reporting Services. The complete RDL for the report is included in the management pack.

Creating a custom reports require significantly more effort than creating a linked report and requires detailed knowledge both in writing a query to retrieve data from a SQL Server database and in creating a report for SQL Reporting Services. Because of the additional skills and effort required, the only time that you should create a custom report instead of a linked report is if your reporting requirement cannot be met by one of the generic reports.

324

Custom reports are beyond the scope of this guide. For more information about custom reports, see Overview of Reporting in Operations Manager 2007.

Recommended ReportsThe following are recommendations for when each kind of linked report should be included in a management pack. Other kinds of reports might be included, depending on the requirements of your particular application and the preference of users. However, these are the most common reports for a many management packs for different applications.

Availability ReportsYou should include an availability report for top level application or application role classes. These are classes that use such base classes as Distributed Application, Windows Computer Role, or Windows Local Application and frequently provide a health rollup for other classes. Such a report provides a history of the availability for an application or a significant component of an application.

Availability reports for component of the application, such as classes based on Windows Application Component, are less important because their availability is included in the availability of their hosting class. You can access the availability of these objects by drilling into the availability of the higher level objects when the report is run. State views should still typically be provided for classes to give the user a quick view of their current state. Historical analysis of availability over periods of time, which is the focus of availability reports, is typically more valuable with higher level objects.

Configuration ReportsYou should include configuration reports for classes in your management pack that include custom properties, especially if changes in these properties indicate significant configuration of the application being monitored. Configuration reports show any changes to these properties that occurred in the time duration of the report. Regular review of configuration reports can warn you about unexpected configuration changes. They can also be valuable in identifying when particular changes were made because they may coincide with changes to the availability or performance of the application.

For example, the SQL Server 2008 (Monitoring) management pack includes a report named SQL Server Configuration that includes all properties for the SQL DB Engine class. A separate configuration report named SQL Server Servicepack Report includes only the Version and Service Pack Version properties of the class to quickly identify the service pack history of any SQL Server installations. Both reports have filters to ensure that the user can only select the SQL DB Engine class when they run them.

325

Performance ReportsYou should include performance reports in any management pack that collects performance data. Although you can always use one of the generic performance reports to access interesting performance counters, these require lots of customization, especially if the report contains multiple series.

Linked performance reports let you create individual reports that combine related performance counters for a particular class of object. An effective strategy is to create a separate linked report for each class and potentially for different sets of related counters for each class.

An example of this strategy is provided in the Windows Server 2008 Operating System (Monitoring) management pack. Separate performance linked reports are included for classes such as Windows Server 2008 Logical Disk and Windows Operating System. Multiple linked reports are included for each class combing related sets of counters that can be analyzed together in a single report. Each linked report includes a filter on the Object XML Picker control that ensures that only the correct class can be selected.

See AlsoGeneric Reports

Classes


Building Views and ReportsThe following sections provide walkthroughs of building views and linked reports for Operations Manager 2007 using the Authoring console.

In This SectionCreating and Editing Views

Create different types of views by using the Operations Manager Authoring console and Operations console.

Creating and Editing Linked ReportsCreate different types of linked reports by using the Operations Manager Authoring console.

326

Creating and Editing ViewsViews in an Operations Manager 2007 management pack can be created and edited in the Authoring console, but only minimal user interface is available for this task. All the configurations must be performed with an XML editor which requires you to have detailed knowledge of the XML structure of the view.

The Operations console provides a complete user interface for creating and editing views that requires no knowledge of XML. The sections on each kind of view discuss the features that cannot be configured by using the Operations console. However, the features provided by this console will be sufficient for most any view. The most significant feature that the Operations console will not allow is providing a name for the view.

The basic process that is used for creating views is as follows:

1. Create the view in the Authoring console.

By using the Authoring console to create the view, you can give it a descriptive ID instead of one that contains a GUID that would be generated by the Operations console.

2. Install the management pack into a management group.

By installing the management pack, you can use the Operations console to perform configuration of the view.

3. Configure the view

With the management pack installed, you can use a dialog box for each kind of view in the Operations console to perform most configurations for each kind of view.

4. Load the management pack into the Authoring console.

As soon as the view is configured, you can load the management pack back into the Authoring console to continue to work with it.

Each procedure in this section follows this basic procedure for creating and configuring different kinds of views.

In This SectionHow to Create a Folder

Create a folder for organizing views.

How to Create a State ViewCreate a state view listing all instances of a target class.

How to Create an Alert ViewCreate an alert view that shows all alerts matching specified criteria.

327

Dashboard ViewsCreate a dashboard view displaying multiple views at the same time.

How to Create a FolderThe following procedure shows how to create a folder in the Operations Manager 2007 Authoring console. Before you perform this procedure, you must first complete the prerequisite procedure How to Create a New Management Pack in which you create the management pack.

1. In the Authoring console, select Presentation, and then select Views.2. Right-click Microsoft.SystemCenter.Monitoring.ViewFolder.Root, select New, and

then select Folder.3. In the Choose a unique identifier box, type the name MyMP.Folder.Top, and then click

OK.4. In the Name box, type My Management Pack, and then click OK.

See AlsoFolders

How to Create a State ViewThe following procedure shows how to create a state view in the Operations Manager 2007 Authoring console and then configure the state view by using both the Operations console and the Authoring console.

Before you perform this procedure, you must first complete the prerequisite procedure How to Create a Class in which you create the target class.

The view created in this procedure has the following characteristics:

Includes instances of the My Computer Role 1 class that are in a Critical or Warning health state.

Displays the following columns: State of the object Maintenance Mode Name Path

To create a folder

328

Version State of instances of My Computer Role 2 hosted by the object

Sorted by the following columns: State of the object State of instances of My Computer Role 2 hosted by the object Name

1. In the Authoring console, select Presentation, and then select Views.2. Expand Microsoft.SystemCenter.Monitoring.ViewFolder.Root.3. Right-click MyMP.Folder.Top, select New, and then select State View.4. On the General tab, do the following:

a. In the Element ID box, select MyMP.View.State.MyComputerRole1.b. In the Display Name box, type My Computer Role 1. Click OK.c. In the Target box, select MyMP.MyComputerRole1.d. In the Category box, select StateCollection.

5. Click Finish.6. Right-click MyMP.MyComputerRole1 and select Properties.7. On the Folder tab, do the following:

a. Click to clear Microsoft.SystemCenter.Monitoring.ViewFolder.Root.b. Select MyMP.Folder.Top.

8. Click OK.9. Select File, and then click Save.

2. Select the management group.3. Click Connect.

1. In the Operations console, select Monitoring.2. Expand the My Management Pack folder.3. Right-click My Computer Role 1, and then select Properties.4. On the Criteria tab, do the following:

a. Select with a specific health state.b. In the Criteria description box, click specific.c. Select Critical and Warning, and then click OK.

5. On the Display tab, do the following:a. Select Version.

To create state view

To install the management pack

To modify the view in the Operations console

329

b. Select My Computer Role 2.c. In the Sort columns by box select Name.

6. Click OK.

1. In the Authoring console, select the Tools menu, and then select Import MP from Management Group.

2. Select the management group.3. In the Import from Management Group dialog box, select MyMP and then click Import.4. Select Presentation, and then select Views.5. Expand the Microsoft.SystemCenter.Monitoring.ViewFolder.Root folder.6. Expand the MyMP.Folder.Top folder.7. Right-click MyMP.View.State.ComputerRole1, and then select Properties.8. On the Configuration tab, click Edit to start the external editor.9. Change the Sorted attribute to true for the following columns:

State Name My Computer Role 2

10. Change the SortIndex attribute to the following values: State: 0 Name: 2 My Computer Role 2: 1

11. Close the external editor, and save the configuration in the Authoring console.12. Click OK.13. Select File, and then click Save.

See AlsoState Views

How to Create an Alert ViewThe following procedure shows how to create an alert view in the Operations Manager 2007 Authoring console. You can then configure the view by using both the Operations console and the Authoring console.

Before you perform this procedure, you must first complete the prerequisite procedure How to Create a Group in which you create the target group.


To modify the view in the Authoring console

330

Includes alerts from rules and monitors targeted at any object on a computer in My Computer Group.

Includes only alerts with Critical severity that are not closed. Displays the following columns:

Alert Severity Icon Path Source Name Resolution State Time and date created Age of the alert Repeat count

Grouped by the following columns: Severity

Sorted by the following columns: Path Name

1. In the Authoring console, select Presentation, and then select Views.2. Expand Microsoft.SystemCenter.Monitoring.ViewFolder.Root.3. Right-click MyMP.Folder.Top, select New, and then select Alert View.4. On the General tab, do the following:

a. In the Element ID box, select MyMP.View.Alert.MyComputerGroup.b. In the Display Name box, type My Computer Group Critical Alerts. Click OK.c. In the Target box, select Browse all classes.d. In the Management Pack Class Chooser box, select

Microsoft.Windows.Computer.e. In the Category box, select Alert.

5. Click Finish.6. Right-click MyMP.View.Alert.MyComputerGroup and select Properties.7. On the Folder tab, do the following:



1. In the Authoring console, select the Tools menu, and then select Export MP to

To create alert view


331

Management Group.2. Select the management group.3. Click Connect.

1. In the Operations console, select Monitoring.2. Expand the My Management Pack folder.3. Right-click My Computer Group Critical Alerts, and then select Properties.4. On the Criteria tab, do the following:

a. Click the button to the right side of the Show data contained in a specific group box.

b. Select My Computer Group, and then click OK.c. Select of a specific severity.d. In the Criteria description box, click specific.e. Select Warning and Critical, and then click OK.f. Select with a specific resolution state.g. In the Criteria description box, click specific.h. Select Select only specific Resolution State.i. Select Not Equals.j. Type 255.k. Click OK.

5. On the Display tab, do the following:a. Click to clear Severity.b. Select Path.c. Click to clear Maintenance Mode.d. Select Repeat Count.e. In the Group items by box select Severity.f. In the Sort columns by box select Path.

6. Click OK.


2. Select the management group.3. In the Import from Management Group dialog box, select MyMP and then click Import.4. Select Presentation, and then select Views.5. Expand the Microsoft.SystemCenter.Monitoring.ViewFolder.Root folder.6. Expand the MyMP.Folder.Top folder.



332

7. Right-click MyMP.View.State.MyComputerGroup, and then select Properties.8. On the Configuration tab, click Edit to start the external editor.9. Change the Sorted attribute to true for the following columns:

Path Name

10. Change the SortIndex attribute to the following values: Path: 0 Name: 1

11. Scroll to the bottom and replace the GUID in the Target element with $MPElement[Name='MyMP.MyComputerGroup']$

12. Close the external editor, and save the configuration in the Authoring console.13. Click OK.14. Select File, and then click Save.

See AlsoState Views

How to Create a Performance ViewThe following procedure shows how to create a performance view in the Operations Manager 2007 Authoring console and then configure the view by using both the Authoring console and the Operations console. Before you perform this procedure, you must complete the following prerequisite procedures:

How to Create a Class - Create classes that will serve as the target of the report. How to create a WMI performance collection rule – Create one of the collection rules used by

the performance chart. How to create a script-based performance collection rule - Create one of the collection rules

used by the performance chart.


Includes performance data from instances of the My Computer Role 1 class. Displays counters from the following rules:

My Application Collect Script Performance My Application Collect WMI Performance

1. In the Authoring console, select Presentation, and then select Views.2. Expand Microsoft.SystemCenter.Monitoring.ViewFolder.Root.

To create performance view

333

3. Right-click MyMP.Folder.Top, select New, and then select Performance View.4. On the General tab, do the following:

a. In the Element ID box, select MyMP.View.MyPerformance.b. In the Display Name box, type My Performance. Click OK.c. In the Target box, select MyMP.MyComputerRole1.d. In the Category box, select PerformanceCollection.

5. Click Finish.6. Right-click MyMP.View.MyPerformance and select Properties.7. On the Folder tab, do the following:



1. In the Authoring console, select the Tools menu, and then select Export MP to Management Group.

2. Select the management group.3. Click Connect.

1. In the Operations console, select Monitoring.2. Expand the My Management Pack folder.3. Right-click My Performance, and then select Properties.4. On the Criteria tab, do the following:

a. Select collected by specific rules.b. In the Criteria description box, click specific.c. Select My Application Collect Script Performance and My Application Collect

WMI Performance, and then click OK.5. Click OK.


2. Select the management group.3. In the Import from Management Group dialog box, select MyMP and then click Import.4. Select Presentation, and then select Views.5. Expand the Microsoft.SystemCenter.Monitoring.ViewFolder.Root folder.6. Expand the MyMP.Folder.Top folder.




334

7. Right-click MyMP.View.MyPerformance, and then select Properties.8. On the Configuration tab, do the following:

a. Next to one Rule element, replace the GUID with $MPElement[Name='MyMP.Rule.CollectScriptPerformance']$.

b. Next to the other Rule element, replace the GUID with $MPElement[Name='MyMP.Rule.CollectWMIPerformance']$.


See AlsoPerformance Views

Creating and Editing Linked ReportsThe following is the basic process for building a linked report by using the Authoring console. This is the process that the walkthroughs in the later sections follow to create different kinds of linked reports.

1. Identify the generic report

Linked reports are based on a generic report that retrieves the required information. The first step in creating a linked report is identifying the generic report that retrieves the required information and formats it most closely to your requirements. The list of generic reports is available in Generic Reports.

2. Create the report

Once you know the generic report that the linked report will use, you can create the linked report in the Authoring console and provide additional information such as the name of the report and the target class.

3. Get the report’s parameter block

You can get the parameter block for each type of report in the Generic Reports section of this guide. You can copy and paste this XML code into the linked report which will give the new report the same controls as the base report. When you identify which parameters will have defined values, you can remove the controls from the parameter block that should not be displayed.

4. Determine the parameters that will have defined values

Most linked reports will provide a defined value for one or more parameters for which the report uses a control. Each parameter must be defined for the linked report and be given a value.

5. Remove controls for defined parameters

335

Controls in the parameter block that are needed because they populate parameters that have been given a specific value should be removed from the linked report. This prevents the controls from being displayed when you run the report.

In This SectionHow to Create a Linked Availability Report

Create a linked report based on the generic Availability report.

How to Create a Linked Alert ReportCreate a linked report based on the generic Alert report.

How to Create a Linked Event ReportCreate a linked report based on the generic Custom Event report.

How to Create a Linked Configuration ReportCreate a linked report based on the generic Custom Configuration report.

How to Create a Linked Performance ReportCreate a linked report based on the generic Performance report.

How to Create a Linked Availability ReportThe following procedure shows how to create a linked Availability report in the Operations Manager 2007 Authoring console. Before you perform this procedure, you must first complete the prerequisite procedure How to Create a Class and create the target class.

The report that is created in this procedure has the following characteristics:

Includes data between the current date and seven days before the current date. The date controls are not presented to the user.

Sets aggregation to hourly. The aggregation combo box is not presented to the user. Limits the target objects that may be selected to instances of My Computer Role 1.

1. In the Authoring console, select Reporting, and then select Linked Reports.2. Right-click in the right-side pane, select New, and then select New Linked Report.

To create the linked report

336

3. In the Choose a unique identifier box, type MyMP.MyAvailabilityReport and then click OK.

4. On the General tab, do the following:a. In the Name box, type My Availability Report.b. Click the button to the right side of the Base box.c. Select Microsoft.SystemCenter.DataWarehouse.Report.Availability and then click

OK.d. In the Target box, select MyMP.MyComputerRole1.

1. On the Parameters tab, click Edit in external editor. This starts the external editor.2. Copy and paste the following XML code into the external editor. This is the parameter

block for the Availability generic report.

<ParameterBlock columns="4" xmlns="http://schemas.microsoft.com/mom/reporting/2007/ReportParameterSettings">

<Controls>


<ReportParameters>


<Prompt>Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.DataAggregation</Prompt>

</ReportParameter>

</ReportParameters>

</Control>

<Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.MonitoringObjectXmlPicker" columnSpan="2" rowSpan="2">

<ReportParameters>


<Prompt>Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.O

To add the parameter block

337

bjectList</Prompt>

</ReportParameter>


</ReportParameters>

</Control>

<Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.CheckedListBox" rowSpan="2">

<ReportParameters>


<Prompt>Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.AvailabilityDownTime</Prompt>

</ReportParameter>

</ReportParameters>

</Control>

<Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.BusinessRelativeDateTimePicker">

<ReportParameters>


<Prompt>Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.TimeZone</Prompt>

</ReportParameter>




338

<Prompt>Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.StartDateTime</Prompt>

</ReportParameter>





<Prompt>Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.EndDateTime</Prompt>

</ReportParameter>





</ReportParameters>

</Control>

</Controls>

</ParameterBlock>

3. Completely remove the element for the Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.BusinessRelativeDateTimePicker control.

4. Completely remove the element for the Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.ComboBox control.

5. Add the following XML code to the Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.MonitoringObjectXmlPicker element after the </ReportParameters> line.

339

<Properties>



</Property>



</Property>

</Properties>

6. Verify that the final XML code resembles the following:


<Controls>

<Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.MonitoringObjectXmlPicker" columnSpan="2" rowSpan="2">

<ReportParameters>


<Prompt>Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.ObjectList</Prompt>

</ReportParameter>


</ReportParameters>

<Properties>



</Property>



</Property>

</Properties>

</Control>

340

<Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.CheckedListBox" rowSpan="2">

<ReportParameters>


<Prompt>Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.AvailabilityDownTime</Prompt>

</ReportParameter>

</ReportParameters>

</Control>

</Controls>

</ParameterBlock>

7. Close the external editor and save the XML code back to the Authoring console.

1. Use steps 2-7 to create each parameter for the table that follows:

Parameter Name Parameter Value

StartDate_BaseType Today

StartDate_BaseValue 01/01/2010 12:00:00 AM

StartDate_OffsetType Day

StartDate_OffsetValue -7

EndDate_BaseType Today

EndDate_BaseValue 01/01/2010 12:00:00 AM

EndDate_OffsetType None

EndDate_OffsetValue 0

TimeType Regular

TimeWeekMap Monday

Tuesday

Wednesday

Thursday

Friday

To add the hardcoded parameters

341


DataAggregation 0

2. In the Parameters section of the Parameters tab, click Create, and then click Edit.3. In the Name box, type the Parameter Name.4. Click Create, and then click Edit.5. Clear the existing text and type the Parameter Value, and then click OK.6. If the parameter has multiple values, repeat the previous two steps for each value.7. Click OK.

1. On the Options tab, change the Visible option to True.2. Click OK.3. Select File, and then click Save.

See AlsoAvailability Reports

Common Parameters


How to Create a Linked Alert ReportThe following procedure shows how to create an Alert linked report in the Operations Manager 2007 Authoring console. Before you perform this procedure, you must first complete the prerequisite procedure How to Create a Class in which you create the target class.


Includes data between the current date and the first date of the current month. The date controls are not presented to the user.

Only includes alerts with a severity of Warning or Error. The severity combo box is not presented to the user.

Only includes alerts with a priority of Medium or High. The priority combo box is not presented to the user.

Limits the target objects that may be selected to instances of My Computer Role 1.

1. In the Authoring console, select Reporting, and then select Linked Reports.2. Right-click in the right-side pane, select New, and then select New Linked Report.

To complete and save the linked report


342

3. In the Choose a unique identifier box, type MyMP.MyAlertReport and then click OK.4. On the General tab, do the following:

a. In the Name box, type My Alert Report.b. Click the button to the right side of the Base box.c. Select Microsoft.SystemCenter.DataWarehouse.Report.Alert and then click OK.d. In the Target box, select MyMP.MyComputerRole1.


block for the Alert generic report.


<Controls>

<Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.RelativeDateTimePicker" rowSpan="2" columnSpan="2">

<ReportParameters>



</ReportParameter>





</ReportParameter>


343






</ReportParameter>



</ReportParameters>

</Control>

<Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.MonitoringObjectXmlPicker" rowSpan="2" columnSpan="3">

<ReportParameters>



</ReportParameter>


</ReportParameters>

</Control>

<Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.CheckedListBox" rowSpan="1" columnSpan="1">

344

<ReportParameters>

<ReportParameter name="Severity">

<Prompt>Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.AlertSeverity</Prompt>

</ReportParameter>

</ReportParameters>

</Control>

<Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.CheckedListBox" rowSpan="1" columnSpan="1">

<ReportParameters>

<ReportParameter name="Priority">

<Prompt>Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.AlertPriority</Prompt>

</ReportParameter>

</ReportParameters>

</Control>

</Controls>

</ParameterBlock>

3. Completely remove the element for the Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.RelativeDateTimePicker control.

4. Completely remove the element for both of the Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.CheckedListBox controls.


<Properties>



</Property>


345


</Property>

</Properties>


<ParameterBlock xmlns="http://schemas.microsoft.com/mom/reporting/2007/ReportParameterSettings" columns="6">

<Controls>

<Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.MonitoringObjectXmlPicker" rowSpan="2" columnSpan="3">

<ReportParameters>



</ReportParameter>


</ReportParameters>

<Properties>



</Property>



</Property>

</Properties>

</Control>

</Controls>

</ParameterBlock>


1. Use steps 2-7 to create each parameter for the table that follows:To add the hardcoded parameters

346


StartDate_BaseType FirstDayMonth


StartDate_OffsetType None

StartDate_OffsetValue 0





Severity 1

2

Priority 1

2



See AlsoAlert Reports

Common Parameters



347

How to Create a Linked Event ReportThe following procedure shows how to create an Event linked report in the Operations Manager 2007 Authoring console. Before you perform this procedure, you must first complete the prerequisite procedure How to Create a Class in which you create the target class.


Includes data between the current date and the first day of the current week. The date controls are not presented to the user.

Only includes events with a Level equal to Error and a Publisher that contains Health Service. The Report Fields checklist box is not presented to the user.

Includes the following fields in the report: Event ID Channel Publisher Object Logging Computer

Limits the target objects that may be selected to instances of My Computer Role 1.

1. In the Authoring console, select Reporting, and then select Linked Reports.2. Right-click in the right-side pane, select New, and then select New Linked Report.3. In the Choose a unique identifier box, type MyMP.MyEventReport and then click OK.4. On the General tab, do the following:

a. In the Name box, type My Event Report.b. Click the button to the right side of the Base box.c. Select Microsoft.SystemCenter.DataWarehouse.Report.EventTemplate and then

click OK.d. In the Target box, select MyMP.MyComputerRole1.


block for the Custom Event generic report.


<Controls>

<Control rowSpan="4" columnSpan="2" type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterCo



348

ntrol.RelativeDateTimePicker">

<ReportParameters>



</ReportParameter>





</ReportParameter>






</ReportParameter>



349

</ReportParameters>

</Control>

<Control rowSpan="4" columnSpan="3" type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.MonitoringObjectXmlPicker">

<ReportParameters>



</ReportParameter>


</ReportParameters>

</Control>

<Control columnSpan="2" rowSpan="4" type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.ReportColumnPicker">

<ReportParameters>

<ReportParameter name="Columns" />


</ReportParameters>

</Control>

</Controls>

</ParameterBlock>

3. Completely remove the element for the Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.RelativeDateTimePicker control.

4. Completely remove the element for the Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.ReportColumnPicker control.


<Properties>

350



</Property>



</Property>

</Properties>





StartDate_BaseType Sunday


StartDate_OffsetType None

StartDate_OffsetValue 0





Columns <Data>

<Columns>


<ID>EventDisplayNumber</ID>

</Column>

<Column Visible="False">

<ID>EventLevelTitle</ID>

<Filter Type="Equals">Error</Filter>


351


</Column>


<ID>EventChannelTitle</ID>

</Column>


<ID>EventPublisherName</ID>

<Filter Type="Contains">Health Service</Filter>

</Column>


<ID>ManagedEntityDefaultName</ID>

</Column>


<ID>ComputerName</ID>

</Column>


<ID>Parameter1</ID>

</Column>

</Columns>

</Data>


1. On the Options tab, change the Visible option to True.2. Click OK.


352


See AlsoEvent Reports

Event Parameters

Common Parameters


How to Create a Linked Configuration ReportThe following procedure shows how to create a Configuration linked report in the Operations Manager 2007 Authoring console. Before you perform this procedure, you must first complete the prerequisite procedure How to Create a Class in which you create the target class.


Includes data from the current quarter. The date controls are not presented to the user. Includes the following fields in the report:

Display Name Logical Processors IP Address Version

Filters the output for objects where the Version includes 1.. Limits the target objects that may be selected to instances of My Computer Role 1.

1. In the Authoring console, select Reporting, and then select Linked Reports.2. Right-click in the right-side pane, select New, and then select New Linked Report.3. In the Choose a unique identifier box, type MyMP.Report.MyConfigurationReport and


a. In the Name box, type My Configuration Report.b. Click the button to the right side of the Base box.c. Select Microsoft.SystemCenter.DataWarehouse.Report.CustomConfiguration

and then click OK.d. In the Target box, select MyMP.MyComputerRole1.

1. On the Parameters tab, click Edit in external editor. This starts the external editor.



353

2. Copy and paste the following XML code into the external editor. This is the parameter block for the Custom Configuration generic report.


<Controls>

<Control columnSpan="1" type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.RelativeDateTimePicker">

<ReportParameters>



</ReportParameter>





</ReportParameter>





354


</ReportParameter>



</ReportParameters>

</Control>

<Control columnSpan="3" type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.MonitoringObjectXmlPicker">

<ReportParameters>



</ReportParameter>


</ReportParameters>

</Control>

<Control columnSpan="2" type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.ReportColumnPicker">

<ReportParameters>

<ReportParameter name="Properties" />


</ReportParameters>

</Control>

</Controls>

</ParameterBlock>

3. Completely remove the element for the

355

Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl. RelativeDateTimePicker control.

4. Completely remove the element for the Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.ReportColumnPicker control.


<Properties>



</Property>



</Property>

</Properties>



<Controls>

<Control columnSpan="3" type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.MonitoringObjectXmlPicker">

<ReportParameters>



</ReportParameter>


</ReportParameters>

<Properties>



356

</Property>



</Property>

</Properties>

</Control>

</Controls>

</ParameterBlock>



Parameter Name

Parameter Value

StartDate_BaseType

FirstDayQuarter

StartDate_BaseValue

01/01/2010 12:00:00 AM


None


0

EndDate_BaseType

LastDayQuarter

EndDate_BaseValue

01/01/2010 12:00:00 AM

EndDate_OffsetType

None

EndDate_OffsetValue

0

Properties<Data>

<Columns>



357

Parameter Name

Parameter Value

<ID>$MPElement[Name='System!System.Entity']/DisplayName$</ID>

</Column>


<ID>$MPElement[Name='Windows!Microsoft.Windows.Computer']/LogicalProcessors$</ID>

</Column>


<ID>$MPElement[Name='Windows!Microsoft.Windows.Computer']/IPAddress$</ID>

</Column>


<ID>$MPElement[Name='MyMP.MyComputerRoleBase']/Version$</ID>

<Filter Type="Contains">1.</Filter>

</Column>

</Columns>

</Data>




358

See AlsoAvailability Reports

Common Parameters


How to Create a Linked Performance ReportThe following procedure shows how to create an Availability linked report in the Operations Manager 2007 Authoring console. Before you perform this procedure, you must complete the following prerequisite procedures:

How to Create a Class - Create classes that will serve as the target of the report. How to create a WMI performance collection rule – Create one of the collection rules used by

the performance chart. How to create a script-based performance collection rule - Create one of the collection rules

used by the performance chart.


Sets aggregation of the data to Hourly. The data aggregation combo box is not presented to the user.

Sets aggregation of the x-axis to Daily by hours. The histogram combo box is not presented to the user.

Limits the target objects that may be selected to instances of My Computer Role 1. Creates a single chart with the following series:

Rule Color Type Scale

Collect Script Performance

Light Blue Line 1

Collect WMI Performance

Light Red Line .001

1. In the Authoring console, select Reporting, and then select Linked Reports.2. Right-click in the right-side pane, select New, and then select New Linked Report.3. In the Choose a unique identifier box, type MyMP.Report.MyPerformanceReport and


a. In the Name box, type My Performance Report.b. Click the button to the right side of the Base box.


359

c. Select Microsoft.SystemCenter.DataWarehouse.Report.Performance and then click OK.

d. In the Target box, select MyMP.MyComputerRole1.


block for the Performance generic report.


<Controls>

<Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.ComboBox" columnSpan="2">

<ReportParameters>


<Prompt>Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.DataAggregation</Prompt>

</ReportParameter>

</ReportParameters>

</Control>

<Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.PerformanceChartObjectPicker" columnSpan="4" rowSpan="3">

<ReportParameters>



</ReportParameter>



360

</ReportParameters>

</Control>

<Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.BusinessRelativeDateTimePicker" columnSpan="2">

<ReportParameters>



</ReportParameter>





</ReportParameter>






</ReportParameter>

361





</ReportParameters>

</Control>


<ReportParameters>


<Prompt>Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.Histogram</Prompt>

</ReportParameter>

</ReportParameters>

</Control>

<Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.BooleanPicker">

<ReportParameters>


<Prompt>Microsoft.SystemCenter.DataWarehouse.Report.Library!Microsoft.SystemCenter.DataWarehouse.Report.ParameterPrompt.Chart3D</Prompt>

</ReportParameter>

</ReportParameters>

</Control>

</Controls>

</ParameterBlock>

362

3. Completely remove the element for both of the Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.ComboBox controls.

4. Completely remove the element for the Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.BooleanPicker control.

5. Completely remove the element for the Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.PerformanceChartObjectPicker control and replace it with the following XML code which is for a Linked Performance Object Picker control configured for the desired performance charts:

<Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.LinkedPerformanceChartObjectPicker" columnSpan="4" rowSpan="3">

<ReportParameters>



</ReportParameter>


</ReportParameters>

<Properties>


<Value><![CDATA[

<Data>


<Series>

<Rule>$MPElement[Name='MyMP.Rule.CollectScriptPerformance']$</Rule>


<Type>Line</Type>

<Scale>1</Scale>

</Series>

363

<Series>

<Rule>$MPElement[Name='MyMP.Rule.CollectWMIPerformance']$</Rule>


<Type>Line</Type>

<Scale>.001</Scale>

</Series>

</Chart>

</Data>

]]></Value>

</Property>



</Property>



</Property>

</Properties>

</Control>



<Controls>

<Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.LinkedPerformanceChartObjectPicker" columnSpan="4" rowSpan="3">

<ReportParameters>



</ReportParameter>

364


</ReportParameters>

<Properties>


<Value><![CDATA[

<Data>


<Series>

<Rule>$MPElement[Name='MyMP.Rule.CollectScriptPerformance']$</Rule>


<Type>Line</Type>

<Scale>1</Scale>

</Series>

<Series>

<Rule>$MPElement[Name='MyMP.Rule.CollectWMIPerformance']$</Rule>


<Type>Line</Type>

<Scale>.001</Scale>

</Series>

</Chart>

</Data>

]]></Value>

</Property>



</Property>



</Property>

365

</Properties>

</Control>

<Control type="Microsoft.SystemCenter.DataWarehouse.Report.ParameterControl.BusinessRelativeDateTimePicker" columnSpan="2">

<ReportParameters>



</ReportParameter>





</ReportParameter>






</ReportParameter>

366





</ReportParameters>

</Control>

</Controls>

</ParameterBlock>




DataAggregation 0

AggregationType 1

Enable3D False



See AlsoPerformance Parameters



367

Common Parameters

Performance Report Controls


CompositionThe Operations Manager 2007 authoring console allows a variety of different monitoring scenarios to be implemented by using wizards that do not require extensive knowledge of how these scenarios are actually implemented in the management pack.


Introduces the concepts of modules and workflows and identifies the different types of each.

Designing Custom Modules and WorkflowsExplains the criteria that you must consider for designing different types of custom modules and workflows.

Creating Custom Modules and WorkflowsDemonstrates how to create custom modules and workflows for implementing different scenarios.

Key ConceptsThis section provides high-level background information on the operation of modules and workflows in Operations Manager 2007.

In This SectionModule and Workflow Basics

Describes the basic operation of modules and workflows.

368

Modules TypesProvides the details of the different types of modules.

Module ImplementationsDefines the different module implementations with particular detail for composite modules.

Kinds of WorkflowsProvides details of the different kinds of workflows.

CookdownDescribes the concept of cookdown and how custom modules and workflows can be designed to take advantage of it for more efficient operation.

Module and Workflow BasicsA workflow in Operations Manager 2007 refers to a running process that is defined in a management pack and run by the Operations Manager agent. Examples of different kinds of workflows are monitors, rules, and discoveries. The primary job of the Operations Manager agent is to load and run workflows defined by the management packs relevant to the applications installed on the agent.

Workflows are composed of one or more modules. A module in Operations Manager performs a discrete function based on information that is provided to the module through parameters. For example, a module may detect an event, collects a particular performance counter, runs a script, or generates an alert. A workflow can achieve complex functionality by piecing together different modules that perform different required actions.

Wizards in the Authoring console let workflows such as monitors and rules be created without direct knowledge of the modules that they will use. These wizards address a limited set of specific scenarios, but with knowledge of the underlying structures, custom workflows can be made up from any valid combination of available modules to achieve specific functionality.

ModulesManagement pack libraries contain many modules that are individually documented in the Module Types Reference section of the Operations Manager 2007 Management Pack

369

Development Kit (MPDK). These modules may be used to compose custom workflows or to create custom modules required for specific functionality in a management pack.

A sample module is illustrated in the following diagram. The module is included in the Microsoft Windows Library management pack and has the name Microsoft.Windows.TimedScript.PropertyBagProvider. The function of this module is to run a script according to a specified schedule and return the output in the form of a property bag.

Module

The module can be inspected by opening the Windows Core Library management pack in the Authoring console. Detailed documentation for the module is provided in the MPDK under Microsoft.Windows.ScriptProbeAction. The reason that the module does not have its own topic is that it and other modules make use of the Microsoft.Windows.ScriptProbeAction module. Instead of providing separate documentation for each module, the MPDK groups similar modules under a common topic.

To perform its required function, the module requires a set of parameters that specify such information as the script itself and how frequently the script should be run. Any output from the script is formatted as a particular data type and sent into the data stream, where the output is retrieved by the next module in the workflow. These concepts are detailed in the following sections.

Module ParametersMost modules will require one or more parameters. These parameters are values that the module requires in order to perform its required functionality. Explicit values may be provided for these parameters, or they may be $Target or $Data variables that are determined at run time. A parameter can be defined to be required or optional. Any workflow or composite module that uses a module must provide values for each of its required parameters.

The following table lists the parameters for the previous sample module:

370

Parameter Name Description Required? Possible Values

IntervalSeconds How frequently the script should run.

Yes Typically explicit value, such as 900 seconds.

SyncTime Synchronization time for scheduling of the script.

No Typically explicit value, such as 00:15, or blank if synchronization is not required.

ScriptName Name of the script. Yes Explicit value, such as MyScript.vbs.

ScriptBody Body of the script. This is the full text of the script itself.

Yes Explicit value with the complete body of the script.

Arguments Values for arguments that the script requires.

No Combination of explicit values and $Target variables providing the command-line arguments sent to the script.

TimeoutSeconds Number of seconds that the script can run before it is automatically stopped.

Yes Explicit value, such as 300 seconds.

The list of parameters for a particular module is available by viewing its management pack in the Operations console or an XML editor. When a module is used in the Authoring console, its list of required parameters will be automatically populated. If optional parameters are used, they must be added manually.

Data StreamModules in a workflow exchange data through a data stream. Data sent from one module is accepted by the next module in the workflow. The receiving module is expected to perform some function by using the received data and then potentially sending its own data as output where it may be accepted by another module.

Each workflow has its own data stream that is created when the workflow runs. If there are multiple copies of a particular workflow running on an agent, each will have its own data stream.

371

Data TypesData output from a module will match a particular data type, and modules that accept data will require a particular type of data for input. When composing a workflow, you must make sure that the output data type of one module matches the required input data type of the next module. If they do not match, another module can be used to translate from one type to another.

The previous example module above sends output data in a property bag. Any module receiving this data in a workflow would be required to accept property bag data as input. If a module requiring another data type were used, for example, performance data, another module would be required in the workflow to map the property bag to the required data type.

WorkflowsThe following diagram shows a sample workflow. This particular sample represents a rule that runs a script and collects performance data in the Operations Manager database. It uses three modules to perform this function. The following diagram shows the parameters that are required for each module and the data type for the output and input of each.

Workflow

The first module is Microsoft.Windows.TimedScript.PropertyBagProvider that was introduced in the previous module example. This module requires values for the listed parameters, which include how frequently the script should run, the name and body of the script, and a set of arguments that will be sent to the script. The values for these parameters would be provided by the configuration of the workflow itself.

The final module Microsoft.SystemCenter.CollectPerformanceData accepts performance data from the data stream and stores it in the Operations Manager database. Because the output from the first module is a property bag, a separate module is required to map data from a property bag to performance data.

The second module in the workflow System.Performance.DataGenericMapper provides the required mapping between data types. This module can accept any input data type and output performance data. In order to perform this function, it requires the parameters that are shown in the diagram. The object name and counter name would presumably be static values, although the instance, if provided, would probably come from a value in the property bag or from a $Target variable using the value of a property on the target object to uniquely identify the instance. The

372

value for the data would most likely come from a value from the property bag that was calculated during execution of the script.

The final module Microsoft.SystemCenter.CollectPerformanceData requires no parameters. As long as the data is provided to the module from the data stream, the module has all the information that it requires to save that data to the Operations Manager database.

Workflow TargetsEvery workflow requires a target class which defines the agents the workflow will run on and how many copies of the workflow will be run.

A separate copy of a workflow is loaded by an agent for each instance of the target class managed by the agent. If an agent has no instances of the target class, the workflow is not loaded. If the agent has multiple instances of the target class, multiple copies of the workflow are loaded. Each copy of the workflow runs independently of the others and will have its own data stream and its own set of property values.

Explicit values that are provided for parameters that are passed to modules in the workflow are common for all copies of the workflows. $Target variables will resolve to different values depending on the values of the properties for the individual target instances.

Modules TypesEach module in an Operations Manager 2007 management pack will be one of four specific types as detailed in the following sections. Understanding the definition of each type and their role in different workflows is critical to designing and creating custom monitoring scenarios.

In This SectionData Source Modules

Collect information at the start of a workflow and send that information into the data stream.

Probe Action ModulesCollect information in response to a trigger and send that information into the data stream.

Condition Detection ModulesFilter data, map data to an alternate type, or consolidate multiple data streams.

373

Write Action ModulesAccept a single input from the data stream and make a change to system state.

Data Source ModulesData source modules in Operations Manager 2007 accept no input from the data stream because they are used at the start of a workflow. They produce a single output data stream. Data source modules are used in rules, discoveries, and regular detection in monitor types. They are always the first module in these kinds of workflows, since they define the schedule for the operation of the workflow and the initial data that is retrieved.

Data source modules collect information from an external source and pass that information into the data stream. They start workflows by using a timed-trigger mechanism that does not require user intervention. Data source modules perform activities such as collecting events from a specified log, sampling performance data at set intervals, or running a script according to a defined schedule.

Data source module

Data source modules are not expected to make any changes to the environment but instead collect information that is sent into the data stream for other modules to potentially work with. This restriction cannot be enforced with custom modules performing actions such as running a script. The management pack author is expected to make sure that any such scripts or other actions used in a data source do not change the managed system.

Common Data Source ModulesThe following table lists typically used data source modules. This is not a complete list of all data source modules that are available, but they are the most common modules that management pack authors will directly use in building custom workflows. The Module Types Reference can be accessed for a complete list of data source modules that are available to use for composing custom modules and workflows.

Module Name Management Pack Function Output Data Type

Microsoft.Windows.Discovery.WMISinglePropertyProvider

Microsoft.Windows.Library

Runs a WMI query

System.Discovery.Data

374


and returns discovery data. Includes an expression to determine whether discovery data should be created.

Microsoft.Windows.EventProvider Microsoft.Windows.Library

Retrieves events with specified criteria from the Windows event log.

Microsoft.Windows.EventData

Microsoft.Windows.FilteredRegistryDiscoveryProvider


Collects keys and values from the registry and returns discovery data. Includes an expression to determin


375


e whether discovery data should be created.

Microsoft.Windows. RegistryDiscoveryProvider


Collects keys and values from the registry and returns discovery data.


Microsoft.Windows.TimedPowerShell.DiscoveryProvider


Runs a Windows PowerShell script at regular intervals and returns output as discovery data.


Microsoft.Windows.TimedScript.DiscoveryProvider


Runs a script at set intervals and returns output as discover


376


y data.

Microsoft.Windows.TimedScript.EventProvider


Runs a script at set intervals and maps property bag output to event.

System.Event.Data

Microsoft.Windows.TimedScript.PerformanceProvider


Runs a script at set intervals and maps property bag output to performance data.

System.Performance.Data

Microsoft.Windows.TimedScript.PropertyBagProvider


Runs a script at set intervals and returns output as property bag.

System.PropertyBagData

Microsoft.Windows.WmiEventProvider Microsoft.Windows.Library

Monitors for occurrence of specified WMI


377


event.

System.Discovery.Scheduler System.Library Output a trigger on a schedule. Used only for discoveries.

SystemTriggerData

System.Performance.DataProvider System.Performance.Library

Collects a performance counter at set intervals.


System.Performance.OptimizedDataProvider

System.Performance.Library

Collects a performance counter at set intervals only if delta between samples matches specified criteria.


System.Scheduler System.Library Output a trigger on a schedule.

System.TriggerData

System.SimpleScheduler System.Library Output a trigger on a

System.TriggerData

378


schedule using frequency and sync time only.

Probe Action ModulesProbe action modules resemble data source modules because they collect information and pass it into the data stream. A probe action module is also not intended to change the agent in any way. The difference is that a probe action requires some trigger to start it.

Probe action module

Probe action modules accept a single input from the data stream and produce a single output data stream. The input could be data from another module, or it could be a simple trigger for probe action modules that do not require input data.

Probe action modules are directly used in monitor types for On Demand Detection and can be used in Diagnostics and Recoveries. All those workflow types provide a trigger that is required to initiate the probe action. Probe action modules are most frequently used within composite data source modules. Many of the data source modules that are included in the management pack libraries actually contain probe action modules to perform their core functionality.

Common Probe Action ModulesThe following table lists common probe action modules. This is not a complete list of all probe action modules that are available. However, they are the most common probe action modules that management pack authors will directly use in building custom workflows and modules.

Module Name Management Pack

Function

Input Data Type

Output Data Type

Microsoft.Windows.PowerShellDiscoveryProbe


Runs a Windows

System.BaseData

System.DiscoveryData

379


Function

Input Data Type

Output Data Type

PowerShell discovery script.

Microsoft.Windows.PowerShellPropertyBagProbe


Runs a Windows PowerShell monitoring script. Requires input data.

System.BaseData


Microsoft.Windows.PowerShellPropertyBagTriggerOnlyProbe


Runs a Windows PowerShell monitoring script. Does not require input data.

None System.PropertyBagData

Microsoft.Windows.ScriptPropertyBagProbe


Runs a monitoring script.

System.BaseData


Microsoft.Windows.WmiProbe System.Library Runs WMI query to

System.BaseData


380


Function

Input Data Type

Output Data Type

retrieve data. Requires input data.

Microsoft.Windows.WmiTriggerProbe Microsoft.Windows.Library

Runs WMI query to retrieve data. Does not require input data.

None System.PropertyBagData

System.CommandExecuterProbe System.Library Run a command line program.

System.BaseData

System.CommandOutput

System.PassThroughProbe System.Library Use to provide input to non-trigger probe action modules for on demand monitor type workflows.

None System.BaseData

381

Condition Detection ModulesCondition detection modules in an Operations Manager 2007 management pack take one or more inputs from the data stream and produce a single output. They are used regularly in rules and monitor types. Although they are not directly used in other workflow types, they are included in composite modules whenever their functionality is required.

Condition detection modules perform one of the following three functions:

Filter the input data according to a specified condition.

For example, a condition detection module might be used to determine whether a particular sampled performance counter exceeded a specified threshold or whether an event matched certain criteria.

Map data from one data type to another.

For example, condition detection might be used to map data from a property bag generated by a script run from a data source module to performance data required for insertion into the Operations Manager database.

Consolidate the data from multiple data streams.

For example, a particular workflow might only generate a message when multiple events of the same type are generated in a specified time window. A condition detection module can be used to compile the events and determine when the specified number of events have been collected.

Condition detection module

Common Condition Detection ModulesThe following table lists frequently used condition detection modules. This is not a complete list of all condition detection modules that are available, but they are the most common ones that management pack authors will directly use in building custom workflows.

Module Name Library Function

Input Data Type Output Data Type

System.Event.GenericDataMapper

System.Library Maps data to an event

System.BaseData

System.Event.Data

382


Input Data Type Output Data Type

System.ExpressionFilter System.Library Evaluates data according to specified criteria to determine whether the data should be allowed through to the next module in the workflow

System.BaseData

System.BaseData

System.OptimizedCollectionFilter


Optimizes performance data



System.Performance.DataGenericMapper


Maps data to performance data.

System.BaseData


Write Action ModulesWrite action modules accept a single input from the data stream and make a change to system state. They have no output into the data stream and represent the end of a workflow. The change

383

made by a write action module could be to the monitored system or in Operations Manager itself. Examples include generating an alert, writing information to the Operations Manager database, or running a script to try to fix a detected problem in an application.

Write action module

Common Write Action ModulesThe following table lists common write action modules. This is not a complete list of all write action modules that are available. However, they are the most common ones that management pack authors will directly use in building custom workflows.


Input Data Type

Microsoft.SystemCenter.CollectEvent Microsoft.SystemCenter.Library

Write events into the Operations Manager database.

System.Event.Data

Microsoft.SystemCenter.CollectPerformanceData

Microsoft.SystemCenter.Library

Write performance data into the Operations Manager database.


Microsoft.SystemCenter.DataWarehouse.PublishEventData

Microsoft.SystemCenter.DataWarehouse.Library

Write event data into the data

System.Event.Data

384


Input Data Type

warehouse.

Microsoft.SystemCenter.DataWarehouse.PublishPerformanceData

Microsoft.SystemCenter.DataWarehouse.Library

Write performance data into the data warehouse.


Microsoft.Windows.PowerShellWriteAction

Microsoft.Windows.Library Run a Windows PowerShell script.

System.BaseData

Microsoft.Windows.ScriptWriteAction Microsoft.Windows.Library Run a script.

System.BaseData

System.CommandExecuter System.Library Run a command line program

System.BaseData

System.Health.GenerateAlert System.Health.Library Generate an alert.

System.BaseData

Module ImplementationsAll modules are implemented in one of the following three ways:

Native code Managed code Composite

As their names imply, managed code modules and native code modules represent managed code and native code installed on the agent computer. These modules are defined in

385

management packs but must be installed separately on the agent computer. Modules that are defined in library management packs are installed automatically with the Operations Manager agent. The definition of a native module in the management pack just includes its Class ID. Managed modules include the details of their assembly. Creation or modification of native modules and managed modules is not supported, but those included in library management packs are available that can be used by modules and workflows in other management packs.

Composite modules are composed of one or more other modules. Composite modules are included in library management packs, and custom composite modules may be defined by management pack authors for performing custom logic. Composite modules require no installation on the agent computer and are completely defined in a particular management pack. They may include native code modules, managed code modules, other composite modules, or any combination of such modules.

There is no difference between using modules with different implementations in a workflow or composite module. In fact, any workflow using a particular module is unaware how it is implemented or the details of how its functionality is performed. The workflow just has to know what function the module performs, its input data type requirement (if any), its output data type (if any), and its required parameters.

If you inspect the modules in a composite module and then continue to inspect any one of those modules that are composite, you will eventually drill down to a native or managed code module. These are the modules that perform core functionality on the agent whereas composite modules provide different variations on this functionality.

Composite Module ExampleTo explain the concept of composite modules, the following diagram shows an example of a module included in the Microsoft Windows Library management pack. This is a common data source module named Microsoft.Windows.TimedScript.PropertyBagProvider. The function of this module is to run a script on a regular timed basis and return the results as a property bag. If you create a rule or monitor based on a script that uses a wizard in the Authoring console, this is the data source module that will be used in the resulting workflow.

Windows Timed Script Property Bag module

386

This module is a composite module that is actually composed of two other modules as follows:

The System.SimpleScheduler module is a data source module that sends a trigger at set intervals. It requires parameters specifying the schedule that will be followed.

Microsoft.Windows.ScriptPropertyBagProbe is a probe action module that runs a specified script returning the output as a property bag. Because it is a probe action, it requires a trigger to start. That trigger is provided by the System.SimpleScheduler data source module. This module needs parameters for such information as the name of the script, the script body, and its arguments.

Both of the modules included in this composite module are composite modules themselves. However, this knowledge is not required in order to use them. The composite module that contains them just has to know what function the module will perform, what parameters it requires to perform that function, what input data type it requires, and what output data type it will generate. The internal details of how it performs this functionality are not relevant.

Another module in the same management pack library Microsoft.Windows.TimedScript.PerformanceProvider uses Microsoft.Windows.TimedScript.PropertyBagProvider but then maps its output from a property bag to performance data. This is performed by adding a condition detection module System.Performance.DataGenericMapper.

Windows Timed Script Performance module

387

The advantage of this strategy is that the management pack author can select the module with the type of data output that is required. Instead of duplicate functionality in the management pack libraries, one module can just build on another. This same strategy can be leveraged in creating custom modules and workflows.

Sample Workflow with Composite ModulesTo additionally explain this concept of composite modules and how they can all be traced back to native or managed code modules, the following diagram shows a sample workflow from the SQL Server 2008 management pack. This is a rule named Microsoft.SQLServer.2008.Database.DBSpaceFree.Collection that runs a script to collect the free space for databases on a SQL Server 2008 instance.

The workflow has a single data source module named Microsoft.SQLServer.2008.DBSizeOptimizedPerfProvider that runs the required script, formats it into performance data, and optimizes it for efficient collection. Then it stores the collected data into the Operations Manager database and the data warehouse using two write action modules.

SQL DB Size Optimized Performance rule

388

Each of the write action modules are native modules. Neither requires any input parameters but can just work with performance data output from the previous module. The data source module is a custom composite module in the same management pack. That module is shown in the following diagram. It uses another data source module named Microsoft.SQLServer.2008.DBSizeRawPerfProvider that collects the free space data and outputs it as performance data. This data is sent to a native condition detection module System.Performance.OptimizedCollectionFilter that optimizes the collected performance data. Its function is to determine whether the collected value has deviated sufficiently from the previously collected value in order to pass it along for collection.

SQL Server Database Size Optimized module

Microsoft.SQLServer.2008.DBSizeRawPerfProvider is another composite module made up of three modules. The first is a data source module that runs the script on a regular schedule and sends output as a property bag. This is followed by a condition detection module that maps the property bag data to performance data. A second condition detection module filters the property bag according to the database name. This is required because the script returns multiple property bags, one for each database on the SQL instance. This strategy is used to support Cookdown, which is discussed in a separate section. The two condition detection modules are native modules, and the data source module is the same composite module discussed previously.

Kinds of WorkflowsEach kind of workflow in an Operations Manager 2007 management pack must follow specific criteria according to the modules types they can contain. The following sections provide details on each kind of workflow.

389

DiscoveriesDiscoveries are a special type of rule that are used for the sole purpose of collecting discovery data to be inserted into the Operations Manager database.

A discovery has only a single data source module that must output discovery data. If more complex logic is required that uses other modules, such as a condition detection, a composite data source module must be created and used by the discovery.

Discovery workflow

RulesRules are typically used for one of the following purposes:

Collect and store data in either the Operations Manager database, the data warehouse, or both.

Generate an alert based on collected data. Run a script or command according to a regular schedule.

A rule is defined by the following:

One or more data source modules. Zero or one condition detection modules.

A condition detection module is required if more than one data source module is used. In this case, the condition detection module would collect data from the different data source modules in order to produce a single output.

One or more write action modules.

Each write action module accepts the same data output from the data source module or the condition detection module if present.

Rule workflow

TasksTasks are workflows that are not loaded by the agent until they are run by an operator.

390

A task is defined by using a single module. If the task is only collecting information, a probe action module should be used. If the task is modifying the system, a write action module should be used.

Task workflow

MonitorsMonitors are workflows used to determine the state of monitored objects. Each monitor has either two or three potential states and is in a single state at any particular time. Aggregate monitors and dependency monitors derive their states from one or more unit monitors. They are workflows, but their details are not exposed to the management pack author. Unit monitors are the only type of monitor that the management pack author will compose.

Monitor TypesMonitors are based on monitor types. Monitor types define the modules and logic that are used in the workflow. They have parameters like modules so that a single monitor type can be shared by multiple modules with each monitor providing values specific to the particular scenario. Each monitor represents the actual workflow that targets a particular class and provides values to the monitor type parameters.

Monitor and monitor type

391

A single monitor type can detect state using both regular detection and the optional on-demand detection. Regular detection is the normal operation of the monitor as it continuously polls for information to determine the state of the monitored object. On-demand detection occurs when the monitor is first initialized on an agent, when the monitored object returns from maintenance mode, and when the operator selects Reset Health for the monitor in the Operations console. If on-demand detection is not defined for a monitor type, the state is not immediately set from these events but is defined the next time that regular detection occurs.

Each health state of the monitor has its own workflow. For example, if a particular monitor type has three states and defines both regular detection and on-demand detection, that monitor type will have six different workflows. While the end result of each workflow is to set the state of the same monitor, each workflow operates completely independently of the others. Each one is working to determine whether it should set the state of the monitor to the workflow’s specific state. Because of this, the management pack author must ensure that workflows for different states can never resolve to true at the same time. If this situation does occur, the results on the health state of the monitor are unpredictable.

The workflow for each health state for regular detection for a monitor type is defined by the following:

Must begin with one or more data source modules. May include probe action modules and condition detection modules in any order. Only a single data stream can be output. A condition detection module is required if more

than one data source module or probe action module is used. In this case, the condition detection module would collect data from the different modules in order to produce a single output.

May not include a write action module. The only result of a workflow in a monitor type is to set the health state of the monitored object, so there is no purpose for a write action module.

392

Monitor type regular detection

The workflow for each health state for regular detection for a monitor type is defined by the following:

Must begin with a probe action module that requires no input data. May include probe action modules and condition detection modules in any order. Only a single data stream can be output. A condition detection module is required if more

than one data source module or probe action module is used. In this case, the condition detection module would collect data from the different modules in order to produce a single output.

May not include a data source module. Data source modules are not able to operate on demand.

May not include a write action module. The only result of a workflow in a monitor type is to set the health state of the monitored object, so there is no purpose for a write action module.

Monitor type on demand detection

DiagnosticsDiagnostics are special kinds of tasks that collect information about a particular monitor. Diagnostics can be run automatically when the monitor changes state, or manually by an operator when the monitor is in a given state. It is not intended to make any changes to the system.

393

A diagnostic is defined by the following:

Zero or one condition detection module. One probe action module.

Diagnostic workflow

RecoveriesRecoveries, just as diagnostics, are special tasks that are triggered by a state change in a monitor. Recoveries can be run automatically when the monitor changes state, or manually by an operator when the monitor is in a given state. Whereas a diagnostic is intended to collect information, the function of a recovery is to try to resolve the problem detected by the particular monitor. Or, a recovery may run only after a particular diagnostic runs and returns data matching specific criteria.

A recovery is defined by the following:

Zero or one condition detection module. One write action module.

Recovery workflow

CookdownCookdown refers to a feature of Operations Manager 2007 where a single copy of a data source module is shared among multiple workflows to reduce overhead. Understanding how cookdown works and how to design workflows to take advantage of cookdown can be important to making sure that a particular workflow operates in the most efficient manner and does not place too much overhead on the managed agent.

394

Overview of Cookdown

Multiple WorkflowsThe Operations Manager agent will load a separate copy of a workflow for each instance of the target class. Most agents manage a considerable number of objects each with several workflows targeted at them. This means that several workflows are typically running on any given agent. The Operations Manager agent can run multiple workflows efficiently, so that this is typically not a concern. However, Data Source modules often run processes outside of the Operations Manager agent that have the potential for considerable overhead. The most obvious example of this is a script that can potentially generate significant overhead, depending on what actions it is performing. If a workflow running that script is targeted at a class that has multiple instances on an agent, that agent will be running multiple instances of the script at the same time. As the number of instances of the class increases, the number of instances of the script increases. These could generate significant overhead on the agent.

Multiple instances of workflow on a single agent

For example, the Windows Server 2008 management pack has a monitor called Microsoft.Windows.Server.2008.LogicalDisk.FreeSpace (display name Logical Disk Free Space) that runs a script to measure the free space on each logical disk on a managed agent. This monitor is targeted at the Windows Server 2008 Logical Disk class, and will have multiple

395

instances on any agent that has more than one logical disk defined. The monitor has three states, meaning that the agent will load a copy of three workflows for each instance of the target class. This means that an agent with four logical disks would have 12 different workflows. Without cookdown, every time the monitor was scheduled to run, 12 copies of the script would run at the same time.

Multiple Workflows with CookdownWith cookdown, the agent still runs a separate workflow for each instance of the target class. However, it loads only a single instance of the data source sharing the output with the different workflows. This is a significant reduction in potential overhead.

Multiple instances of workflow sharing a single data source

Only data source modules are cooked down. However, composite data source modules may contain modules of other types such as probe action modules and condition detection modules. If such a composite data source module supports cookdown, it will be cooked down. Because only a single instance of the data source module is loaded, only a single instance of the modules within it is also loaded.

The previously mentioned monitor Microsoft.Windows.Server.2008.LogicalDisk.FreeSpace supports cookdown, and only a single instance of its data source is loaded regardless of the number of logical disks on the agent. A separate set of workflows are still loaded for each agent, yet they all share the single copy of the data source module. Because the data source module

396

runs the script, the result is a significant reduction in the overhead generated by the different instances of the monitor.

In addition to multiple copies of the same workflow, cookdown applies to different workflows sharing the data source module. For example, one data source module running a script might be used by a monitor for measuring health state and also used by a rule for collecting performance data. Cookdown could be performed in such a way that a single copy of the data source module would be shared between the different workflows.

Multiple instances of workflow sharing single data source module

Criteria for CookdownA workflow does not have to specify whether cookdown should be performed. Cookdown is performed automatically on any workflow that meets the cookdown criteria: the only criterion is that all copies of the data source module are called by using identical values for each parameter. If this is the case, all instances of the workflow on each agent will cookdown to a single data source module.

The only way that values for a parameter will vary for different instances of the same module is if a $Target variable is used. This kind of variable uses the value of a property on the target object. Because this value may vary between different instances, the value that is provided to the module

397

parameter could vary. In this case, cookdown would not be performed, and a separate copy of the data source would be used for each workflow.

Values that are provided to the parameters for a data source module shared between different kinds of workflows have more potential to vary. For example, a rule and a monitor might share a data source module running a script. The interval that the script should run is provided to the data source module as a parameter. If the monitor and rule are configured to run at different intervals, the value that is provided to that parameter will vary between the workflows. In this case, cookdown would not be performed, and a separate copy of the data source module would be required for the different workflows.

When to Configure for CookdownChanging a script and a workflow to support cookdown can take significant effort, and that effort is not valuable in all circumstances. You should be concerned about cookdown only when multiple instances of the target class are expected on a single agent. When there is only a single instance of the target class expected on the agent, cookdown will not be performed anyway because there will only be a single copy of the workflow.

Scripts Supporting CookdownFrequently, a script in a data source module will require the value of a property from the target object. The most straightforward method of providing this value would be to use a $Target variable in a parameter to the module, but then cookdown cannot be performed. The method for supporting this type of scenario is to have the script collect information for all instances of the target class and return a property bag for each. Because the script itself becomes responsible for identifying the values of the individual properties, you do not have to provide them through parameters to the module. Because there are no $Target variables in the parameters, cookdown is preserved.

Multiple Property BagsFor the script to perform cookdown, it will frequently re-create some basic logic used in a discovery script for the target class. The discovery script is typically responsible for identifying the different instances and collecting values for the different properties. Whereas adding this logic makes the script itself more complex and requires more overhead than a script written for only a single instance, the script has the advantage of supporting cookdown. One copy of the script running for all instances of the target class typically generates significantly less overhead than multiple copies of a script running for each single instance.

A script can return multiple property bags by using the ReturnItems method on the MOM.ScriptAPI object instead of Return. This returns a single property bag. When a script returns multiple property bags, each one is collected and processed by the next module in the workflow. If a method of filtering is not used, each workflow will incorrectly complete for each

398

instance. This can result in unwanted situations such as all monitors going to an error state when an error condition is detected on a single instance or collecting multiple duplicate performance values for each instance.

To have a workflow filter for the property bag matching its target instance, a condition detection module is used after the data source module or probe action module running the script. This condition detection module uses a $Target variable for the key property of the target instance. The property bag itself must include the same value in one of its properties. The condition detection is then able to match the value from the property bag to the value of the $Target property to let each copy of the workflow to select the property bag specific to its particular instance. This concept is illustrated in the following diagram.

Workflow supporting cookdown

399

The module Microsoft.SQLServer.2008.DBSizeRawPerfProvider described in Module Implementations provides an example of a script creating multiple property bags to support cookdown. The DatabaseName of the target instance is sent to the module; the name is not passed to the Microsoft.Windows.TimedScript.PerformanceProvider module which runs the actual script. This module can cookdown to a single instance, although the modulecreates a separate property bag for each database. Each property bag includes a value for the name of the database. The value of the DatabaseName parameter is sent to the System.Expression module that compares it to the value in the property bag. Using this method, all instances of a workflow on a particular agent that uses this module will be able to share a single copy of the data source module yet will be able to select only the property bag specific to the particular instance.

The following is a simplified view of the Microsoft.SQLServer.2008.DBSizeRawPerfProvider module showing this concept.

SQL Database Raw Performance module using cookdown

Designing Custom Modules and WorkflowsMany workflows, such as rules, monitors, and discoveries, can be created using wizards in the Authoring console. When these wizards are used, minimal knowledge of the underlying modules and data stream is required. The Authoring console wizard helps you construct a workflow addressing a specific scenario with minimal input from the user. The wizard does this by selecting from a specific set of modules and by using user-specified information for parameters. Once the workflow is created though, the individual modules can be viewed and changed as if it was created manually.

The Authoring console does provide functionality for manually creating workflows, although some modules may require direct editing of the XML by using an editor. When a custom workflow is created, you have to select the individual modules that will be used and provide values or variables for their parameters. Depending on the kind of workflow you are creating, there may be other considerations also, as identified in the following sections.

400

When to Create a Custom Workflow

Functionality Not Provided with WizardThe wizards in the Authoring console create workflows based on a specific set of scenarios. If you must have logic outside these scenarios, you must create a custom workflow. The workflow may use custom modules or the workflow may be composed completely of modules from management pack libraries.

For example, the Authoring console provides a number of complex scenarios for wizards that use events. These include correlating multiple events, detecting missing events, and waiting for multiple occurrences of the same event. These options are not provided for rules however, and those wizards are limited to more basic scenarios. A custom rule would have to be created to use any of this logic. The rule could be created from the identical set of modules used by the monitor types that the wizards are based on.

Custom ModulesWizards in the Authoring console use specific modules that are defined in management pack libraries. If a workflow requires a custom module, you have to create a custom workflow. Those reasons why you might create a custom module are detailed in Custom Module Types.

A common scenario for a custom workflow is to share a script between a monitor and a rule with the monitor measuring health state and the rule collecting data for reporting and analysis. This scenario is achieved by creating a custom data source module or probe module to contain the script and then creating a custom rule, custom monitor type, and custom monitor to use the new module.

Windows PowerShellOperations Manager 2007 R2 includes modules for running Windows PowerShell scripts. There are no wizards in the Authoring console that will take advantage of these modules, so they may only be accessed by creating a custom workflow.

When to Create Custom ModulesIf an existing module will achieve the requirements for a particular workflow, it can typically be used without creating a custom module. A custom composite module may be useful to address the conditions described here.

Share Common Logic between Different WorkflowsA single module can be used by multiple workflows. If a script or some other complex logic has to be shared by multiple workflows, a custom module can be created to encapsulate the logic.

401

Instead of implementing the logic separately in each workflow, the custom module can be shared by each.

For example, consider a script that is used to collect performance data for a particular application. A monitor could be used to set the health state of a monitored object according to the collected data’s comparison with a particular threshold. In addition, a rule could be used to collect the performance data for analysis and reporting. Without a custom module, the script would have to be individually provided as a parameter to an existing module in both the rule and the monitor. If that script were included in a custom module however, it might be shared by both the monitor and the rule. The script would only have to be created and maintained in one location in the management pack.

Implement Complex Logic Not Possible with Existing Modules Custom workflows can be created to implement complex logic with existing modules. However, different kinds of workflows have specific requirements as to the types and number of modules that they contain. If the logic cannot be created within these restrictions, custom modules can be created to encapsulate this logic and make it valid for the particular workflow.

For example, a particular discovery might require a data source module in addition to a condition detection module. However, a discovery is allowed only a single data source module. A custom module could be created that contains the required data source and condition detection modules. The discovery would use the custom data source module without exposure to the modules that it contained.

Improve Override ExperienceCustom modules can define parameters that accept values from the workflow. These are exposed to the end-user of the management pack through overrides where they can be changed. If a particular module has a complex parameter that may not be intuitive to the user, the module may be wrapped in a composite module that provides more intuitive parameters. The values are then passed on to the required parameters through $Config variables.

For example, the modules to run a script will typically have a parameter called Arguments that contains a space- delimited list of arguments to be provided to the script. If the user needed to override one or more of these values, they would have to be exposed to the complete Arguments parameter and determine which particular part of it needed to be modified. For a script that uses multiple arguments, the required formatting will most likely not be intuitive to the end-user. An alternative strategy would be to create a custom module with parameters by using descriptive names. This module would contain the module running the script that would build the Argument parameter through the appropriate combination of $Config variables.

402

Custom Module TypesCustom module types are not as restrictive as custom workflows. Each type has requirements as to the kinds of modules they can contain, and whether they require input or output data. Within those guidelines though, the custom module can contain multiple modules arranged in any specified order.

Data Source ModulesData source modules are the most common type of custom module, because they are used for rules, regular detection on monitors, and discoveries. They frequently contain custom scripts and other logic to retrieve data from a particular application or device.

Data source modules can contain modules of the following types:

Data source modules Probe action modules Condition detection modules

Data source modules have the following requirements:

Must start with at least one data source module. Must deliver output in a single data stream. If the module contains multiple data source

modules or multiple probe action modules, one or more condition detection modules must be used to consolidate or filter the data streams.

The type of the output data will match the type output by the last included module.

Probe Action ModulesProbe action modules are used in tasks and in monitors for on-demand detection. Like data source modules, they can use to custom scripts and other logic to retrieve data from a particular application or device. The difference is that a probe action cannot be used without being embedded in a data source module in rules and in monitor regular detection. A common strategy is to use a probe action module to hold the script and then encapsulate that module in a data source module that adds a scheduler. This strategy allows the same logic to be used for rules, both on demand and regular detection monitors, and tasks.

Probe action modules can contain modules of the following types:

Probe action modules Condition detection modules

Probe action modules have the following requirements:

Must declare an input data type that matches the required input of the first module. Must deliver output in a single data stream. If the module contains multiple probe action

modules, one or more condition detection modules must be used to consolidate or filter the data streams.

403

The type of the data will match the type output by the last included module.

Probe Action Module Input Data and TriggersProbe action modules will either require input data from a previous module or require only a trigger without data provided. Only those that are configured as Trigger Only may be used in on-demand detection for a monitor type. If a composite probe action module contains another probe action module that requires input data, however, that module must also require input data.

This may present an issue if a probe action module is required for a monitor type that uses on-demand detection but a Trigger Only probe action module is not available. The most obvious example of this is the probe action module for running a script Microsoft.Windows.ScriptPropertyBagProbe that does require input.

The solution to this issue is a special probe action module named System.PassThroughProbe. This module requires no input, performs no function, and outputs blank data. It may be used at the start of any composite probe action module that has to be Trigger Only but must also include another module requiring input.

Pass through probe

Condition Detection ModulesCustom condition detection modules are not common, although they can be created for specific scenarios.

Condition detection modules can contain modules of the following types:

Condition detection modules

Condition detection modules have the following requirements:

Must declare one or more input types that match the type of the expected data. Must deliver output in a single data stream. The type of the data will match the type output by the last included module.

Write Action ModulesWrite action modules are used in rules to perform some final action of a workflow or in tasks that perform some action at the request of the user. The data from a write action module is never sent into the data stream. If data is output from a write action module, it is stored in the Operations Manager database or data warehouse. Custom write action modules are frequently created to contain scripts that perform some action against a particular application.

404

Write action modules can contain modules of the following types:

Write action modules

Write action modules have the following requirements:

Must declare one or more input types that match the type of the expected data. Must include at least one write action module.

Passing data with parametersMost modules and monitor types will have parameters in order to accept information from the defined workflow and from other modules in the data stream. Workflows and composite modules must provide values for the required parameters of the modules that they contain and may provide values for optional parameters.

Values and VariablesValues that are provided to parameters will be a combination of explicit values, $Config variables, $Target variables, and $Data variables. Each of these is discussed in the following sections with recommendations on when each should be used.

Explicit ValuesExplicit values for parameters are just values that do not change regardless of the target object or incoming data. Examples include the threshold value for a monitor, an event number that indicate a particular error, or the interval that a script should run.

Explicit values are typically provided by workflows to monitor types and modules. For example, a module running a timed script will require a parameter defining how frequently it should run. A rule that uses this module would have to provide an explicit value such as 900 seconds. This means that the module would run every 15 minutes. In this context, a variable wouldn’t make any sense, and all copies of the workflow would be run on the same 15-minute schedule.

The definition of modules and monitor types will also use explicit values for parameters where a particular value will not change. For example, a composite module might be created in order to share a particular script between rules and monitors. One of the modules that is contained by this composite module would be responsible for running the script. Values for parameters that are required by this module, such as the name of the script and the body of the script, would not vary between different target objects and would be explicitly defined in the definition of the module.

$Target Variables$Target variables refer to the value of a property on the target object or one of the target object’s hosting parents. These values are collected by the discovery process for the target class and will not be known when the workflow is defined. The workflow will also run against all instances of the target object, and each may have a different value for the particular property.

405

$Target variables are most frequently used by workflows sending values to monitor types and modules that accept the value that uses a $Config variable. For example, a rule collecting a performance counter might be targeted at a class where multiple instances are expected on each agent. To distinguish each collected value, the instance name of the performance data could be populated with the name or some other key property of each object. This value would be provided through a $Target variable that would provide a unique value for each target object.

$Data Variables$Data variables refer to some value from the data incoming from the previous module. The format of the variable will depend on the type of data being used. Example uses of $Data variables are in expressions that inspect the incoming data to determine whether some action should be taken, in the mapping of data from one type to another, and in write action modules generating alerts where incoming data values are used in the alert description.

For example, a common scenario is a monitor that runs a script and uses the resulting data to determine the health state of the target object. The workflow for each state (of the possible health states) would use a condition detection module with an expression comparing the resulting data to different specified values. These expressions would use a $Data variable to access the required value.

$Config Variables$Config variables are used to reference the value that is provided to the module or monitor type that contains the particular module. Values for parameters of a module inside a composite module will typically be either explicit values or $Config variables. This is a means of having the workflow provide the value for a parameter that is then passed to a module inside the composite module.

Although parameters that are passed through to contained modules typically map directly between parameters, this is not a requirement. $Config parameters can actually be used to hide the complexity of underlying parameters from the workflow. This can be valuable in providing users with more straightforward parameters exposed to overrides. For example, consider a composite module that contains the data source module Microsoft.TimedScriptPropertyBagProvider. That module has a parameter called Arguments that requires the arguments line that is provided to the script when it is run. The script may require several parameters, not all of which should be overridden by the end-user. Instead of defining a parameter called Arguments on the composite module, a separate parameter could be provided for individual arguments. The Arguments parameter on the module would be composed of multiple $Config variables.

Overrideable ParametersUsers of a management pack can change the values being passed to modules in the workflow by using overrides. Only parameters that are specified as overrideable are available to be overridden. The user may not change the value of any other variables. The definition of

406

parameters that can be overridden is not made on the workflow itself but is made on the module or monitor type that the workflow is based on. In the Authoring console, parameters that can be overridden are specified on the Overrideable Parameters tab of the module properties.

Some parameters are always available to be overridden and do not have to be specified. These are available to the user as parameters that can be overridden but are not specified as parameters on the module or monitor type.

The following table shows workflows that have the following parameters that can be overridden.

Enabled Enable or disable the workflow.

Any monitor or rule that creates an alert has several parameters specific to the alert that can be overridden. The following parameters on rules that generate alerts can be overridden:

Priority Priority of the alert.

Severity Severity of the alert.

As shown in the following table, monitors that generate alerts will have these parameters:

Alert On State Monitor state that generates the alert.

Alert Priority Priority of the alert.

Alert severity Severity of the alert.

Auto-Resolve State Monitor state that automatically resolves the alert.

Generates Alert Specifies whether an alert should be generated in response to a state change for the monitor.

Sample WorkflowThe following sample workflow shows the different values and variables provided to the parameters of different modules. This represents a rule based on a script collecting performance data. The script requires two arguments for the name of the computer and the name of the component that the module is running against. The script itself is included in a probe action module. This module is used in a data source module that adds a scheduler in order to run the script on a timed basis. This data source module is then included in another data source module that maps the property bag from the script to performance data.

Although this may seem to be a complex strategy that uses three different modules for functionality that might be completed by using a wizard in the Authoring console, it is actually a common strategy to support multiple scenarios sharing the same script. The probe action module

407

could be used in a task or in on-demand detection for a monitor. The two data source modules could be used in a rule or regular detection for a monitor. Each provides a different kind of output that depends on the requirements for the particular workflow.

The custom probe action module uses Microsoft.Windows.ScriptPropertyBagProbe (alias Script) to run the actual script, as is shown here.

Custom probe action module

The following table lists the values that are provided for the parameters to the module:

Module Parameter Name Value Used Details

Script ScriptName MyScript.vbs Explicit value, because the name of the script will not vary for different copies of the workflow.

Arguments $Config/ComputerName$ "$Config/ComponentName$"

These are the arguments that are provided on the command line of the script. These are variables because they will vary, depending on the agent and target object the workflow is running against. $Config variables are used so that different workflows can provide

408


the required values. Quotation marks are used around the ComponentName variable in case its value contains spaces.

ScriptBody <Body of the script> Explicit value, because the body of the script will not vary for different copies of the workflow.

TimeoutSeconds 300 Explicit value, because the timeout for the script will not vary for different copies of the workflow.

The first data source module uses System.Scheduler (alias Schedule) followed by the custom probe module (alias Probe). This is shown here:

Custom data source module outputting property bag

The values that are provided for the parameters to the modules are shown on the following table:

409


Schedule IntervalSeconds $Config/IntervalSeconds$ $Config variable used so that the workflow can provide its own schedule.

SyncTime $Config/SyncTime$ $Config variable used so that the workflow can provide its own schedule.

Probe ComputerName $Config/ComputerName$ $Config variable used so that the workflow can provide the computer name.

ComponentName $Config/ComponentName$ $Config variable used so that the workflow can provide the component name.

The second data source module uses the first data source module (alias Script) followed by the condition detection module System.Performance.DataGenericMapper (alias MapToPerf), as illustrated here.

Custom data source module outputting property bag

410

The following table shows the values that are provided for the parameters to the modules:


Script IntervalSeconds $Config/IntervalSeconds$ $Config variable used so that the workflow can provide its own schedule.

SyncTime $Config/SyncTime$ $Config variable used so that the workflow can provide its own schedule.

MapToPerf ObjectName MyApp Explicit value, because the name of the object for the performance data will not vary for different copies of the workflow.

CounterName MyCounter Explicit value, because the name of the counter for the performance data will not vary for different copies of the workflow.

InstanceName $Data/Property[@Name='ComponentName']$ $Data variable that refers to a value from the property bag generated by the previous module. The script would be required to create the property bag with

411


a value with the name ComponentName.

InstanceName $Data/Property[@Name='Value']$ $Data variable that refers to a value from the property bag generated by the previous module. The script would be required to create the property bag with a value with the name Value.

The rule uses the second data source module (alias DS) followed by two write action modules to store the data in the Operations Manager database and the data warehouse. There is no requirement for a condition detection module in the rule because the required modules for filtering and mapping to a different data type were included with composite modules. The write action modules do not require any parameters. This is shown here:

Custom rule

The values that are provided for the parameters to the module are shown in the following table:

412

Module

Parameter Name

Value Used Details

DS IntervalSeconds

900 Run the script every 15 minutes.

SyncTime Left blank, because no synchronization time is required.

ComputerName

$Target/Host/Host/Property[Type= "Windows!Microsoft.Windows.Computer"]/PrincipalName$

$Target variable to use the computer name of the agent hosting the target object. This variable assumes that the target class is hosted by a class that is hosted by Windows Computer.

ComponentName

$Target/Property[Type="MyMP.MyApplicationComponent"]/ComponentName$

$Target variable to use the component name of the target object. This variable assumes that the target class has a property named ComponentName.

413

Creating Custom Modules and WorkflowsThe following procedures provide guidance on how to create custom modules and workflows in the Operations Manager 2007 Authoring console.

In This SectionHow to create a monitor based on a custom module

Create a monitor and monitor type based on a custom data source module and a custom probe action module that contains a script.

How to create a monitor based on a Windows PowerShell scriptCreate a monitor and monitor type based on a custom data source module and a custom probe action module that contains a Windows PowerShell script.

How to create a monitor and rule that share a script supporting cookdownCreate a monitor and monitor type based on custom data source module that contains a script supporting cookdown.

How to create a monitor based on a custom moduleThe following procedure shows how to create a monitor based on a custom data source module running a script using Operations Manager 2007 Authoring console. Before you perform this procedure, you must first complete the prerequisite procedure How to Create a Class in which you create the class to act as the target.

The monitor has the following characteristics:

Targeted at a class with only a single instance on an agent. Because there is a single instance, there is no requirement to support cookdown.

Sets its state based on the comparison of the script value to specified threshold values. The monitor supports On Demand Discovery. This requires a probe action module to run the

script. The script accepts only a single argument for the computer name of the target object’s agent.

414

The script itself is only for testing and performs no real function. It simulates a script running a synthetic transaction and returning a status message of success or failure.

1. Select Type Library and then Probe Actions.2. Right-click in the Probe Actions pane and select New and then Composite Probe

Action.3. In the Choose a unique identifier box, type

MyMP.ProbeActionModule.MyTransactionScript. Click OK.4. On the General tab, in the Name box, type Transaction Script Probe Action.5. On the Member Modules tab, do the following:

a. Click Add to add a module.b. In the Choose Module Type box, select

Microsoft.Windows.ScriptPropertyBagProbe.c. In the Module ID box, type Script. Click OK.d. In the ScriptName box, type MyTransactionScript.vbs.e. In the Arguments box, type $Config/ComputerName$.f. In the TimeoutSeconds box, type 300.g. Click the Edit… button. This starts the custom editor.h. Paste the complete contents of the following script between the ScriptBody tags in


<![CDATA[




oAPI.LogScriptEvent "MyTransactionScript.vbs",10,4, "Running script on " & sComputerName




Call oBag.AddValue("Result","Good")

Else

Call oBag.AddValue("Result","Bad")

End If

oAPI.Return(oBag)

]]>

To create probe action module to run a script

415

i. Close the editor to save the script back to the module.j. Click OK to save the module configuration.k. In the NextModule column for the Script module, select Module Output.

6. On the Configuration Schema tab, do the following:a. In the Simple Configuration Schema section, click Add to add a parameter.b. In the Please enter the requested value box, type ComputerName. Click OK.

7. On the Data Types tab, do the following:a. In the Input Data section, select This module required input data.b. In the Output Data section, in the Data Type: box select System.PropertyBagData.

8. Click OK to save the module.9. Select File, and then click Save.

1. Select Type Library and then Data Sources.2. Right-click the Data Sources pane, select New, and then Composite Data Source.3. In the Choose a unique identifier box, type

MyMP.DataSourceModule.MyTransactionScriptTimed. Click OK.4. On the General tab, in the Name box, type Timed Transaction Script Data Source5. On the Member Modules tab, do the following:

a. Click Add to add a module.b. In the Choose Module Type box, select System.SimpleScheduler.c. In the Module ID box, type Schedule. Click OK.d. Click the button to the right side of the IntervalSeconds box and select Promote.

This enters the text $Config/IntervalSeconds$e. Click the button to the right side of the SyncTime box and select Promote. This

enters the text $Config/SyncTime$f. Click OK to save the module configuration.g. Click Add to add a new module.h. In the Choose Module Type box, select

MyMP.ProbeActionModule.MyTransactionScript.i. In the Module ID box, type Probe. Click OK.j. Select the button to the right side of the ComputerName box and select Promote.

This enters the text $Config/ComputerName$.k. Click OK to save the module configuration.l. In the NextModule column for the Schedule module, select Probe.m. In the NextModule column for the Probe module, select Module Output.

6. On the Configuration Schema tab, do the following:a. Change the Type for the IntervalSeconds parameter to Integer.b. Clear the Required box next to the SyncTime parameter. The SyncTime parameter

To create data source module to run probe action on schedule

416

is optional for this module.7. On the Overrideable Parameters tab, do the following:

a. Click Add and then IntervalSeconds.b. In the Choose a unique identifier box, type IntervalSeconds. Click OK.c. Change Configuration Element to Integer.d. Click Add and then SyncTime.e. In the Choose a unique identifier box, type SyncTime. Click OK.

8. On the Data Types tab ensure the value in the Data Types box is System.PropertyBagData.


1. Select Type Library and then Monitor Types.2. Right-click in the Monitor Types pane and select New and then Composite Monitor

Type.3. In the Choose a unique identifier box, type MyMP.MyTransactionMonitorType. Click

OK.4. On the General tab, in the Name box, type My Transaction Script Monitor Type.5. On the States tab, do the following:

a. Select 2 State Monitor Type.b. In the ID of state 1 box type Success.c. In the ID of state 2 box, type Failure.

6. On the Member Modules tab, do the following:a. Click Add to add a module.b. In the Choose Module Type box, select System.PassThroughProbe.c. In the Module ID box, type PassThru. Click OK.d. Click OK to save the module configuration.e. Click Add to add a module.f. In the Choose Module Type box, select

MyMP.ProbeActionModule.MyTransactionScript.g. In the Module ID box, type Probe. Click OK.h. Click the button to the right of the ComputerName box and select Promote. This will

enter the text $Config/ComputerName$i. Click OK to save the module configuration.j. Click Add to add a new module.k. In the Choose Module Type box, select

MyMP.DataSourceModule.MyTransactionScriptTimed.l. In the Module ID box, type DataSource. Click OK.

To create monitor type using custom data source

417

m. Click the button to the right side of the IntervalSeconds box and select Promote . This enters the text $Config/IntervalSeconds$

n. Click the button to the right side of the ComputerName box and select Promote. This enters the text $Config/ComputerName$

o.

Click Edit. This starts the custom editor.

p. After the line

<IntervalSeconds>$Config/IntervalSeconds$</IntervalSeconds>

Add the following line

<SyncTime>$Config/SyncTime$</SyncTime>

q. Close the editor to add the XML back the Authoring console.

NoteIf you receive an error saying that the IntervalSeconds parameter is invalid according to its data type, click Ignore. This error message occurs because the IntervalSeconds parameter is configured as an integer, and the Authoring Console is reading $Config/IntervalSeconds$ as a string. This variable will be replaced with an integer value when the workflow is run so the error can be ignored.

r. Click OK to save the module configuration.s. Click Add to add a new module.t. In the Choose Module Type box, select System.ExpressionFilter.u. In the Module ID box, type FilterSuccess. Click OK.v. Click Configure to open the Expression dialog box.w. Click Insert.x. In the Parameter Name box type Property[@Name='Result'].y. In the Operator box select Equals.z. In the Value box type Good.aa. Click OK to save the expression.bb. Click OK to save the module configuration.cc. Click Add to add a new module.dd. In the Choose Module Type box, select System.ExpressionFilter.ee. In the Module ID box, type FilterFailure. Click OK.ff. Click Configure to open the Expression dialog box.gg. Click Insert.hh. In the Parameter Name box type Property[@Name='Result'].ii. In the Operator box select Equals.jj. In the Value box type Bad.kk. Click OK to save the expression.

418

ll. Click OK to save the module configuration.7. On the Regular tab, do the following:

a. Select Success.b. Check the Include box next to DataSource.c. Check the Include box next to FilterSuccess.d. In the Next Module box next to DataSource select FilterSuccess.e. In the Next Module box next to FilterSuccess select Monitor State Output.f. Select Failure.g. Check the Include box next to DataSource.h. Check the Include box next to FilterFailure.i. In the Next Module box next to DataSource select FilterFailure.j. In the Next Module box next to FilterFailure select Monitor State Output.

8. On the On Demand tab, do the following:a. Check the box next to Use On Demand Detection.b. Select Success.c. Check the Include box next to PassThru.d. Check the Include box next to Probe.e. Check the Include box next to FilterSuccess.f. In the Next Module box next to PassThru select Probe.g. In the Next Module box next to Probe select FilterSuccess.h. In the Next Module box next to FilterSuccess select Monitor State Output.i. Select Failure.j. Check the Include box next to PassThru.k. Check the Include box next to Probe.l. Check the Include box next to FilterFailure.m. In the Next Module box next to PassThru select Probe.n. In the Next Module box next to Probe select FilterFailure.o. In the Next Module box next to FilterFailure select Monitor State Output.

9. On the Configuration Schema tab, do the following:a. In the Type box next to IntervalSeconds select Integer.b. Click Add to add a parameter.c. In the Please enter the requested value box type SyncTime. Click OK.d. Clear the Required box next to SyncTime.

10. On the Overrideable Parameters tab, do the following:a. Click Add, then IntervalSeconds.b. In the Choose a unique identifier box type IntervalSeconds. Click OK.c. In the Configuration Element box for IntervalSeconds, select Integer.d. Click Add, then SyncTime.

419

e. In the Choose a unique identifier box, type SyncTime. Click OK.11. Click OK to save the module type.12. Select File, then click Save.

1. Select Health Model, then Monitors.2. In the Monitors pane, expand MyMP.MyComputerRole1 and

System.Health.EntityState.3. Right-click System.Health.AvailabilityState, select New, and then Custom Unit

Monitor.4. In the Choose a unique identifier box, type MyMP.MyTransactionMonitor. Click OK.5. On the General tab, in the Name box, type My Transaction Monitor.6. On the Configuration tab, do the following:

a. Click Browse for a type.b. In the Choose unit monitor type box, select MyMP.MyTransactionMonitorType.

Click OK.c. In the IntervalSeconds box type 900.d. Clear the text in the ComputerName box. Click the button to the right side of the box,

select (Host=Windows Computer), and then Principal Name (Windows Computer).

7. On the Health tab, do the following:a. In the Health State box for Success select Healthy.b. In the Health State box for Failure select Critical.

8. On the Alerting tab, do the following:a. Check the box next to Generate alerts for this monitor.b. In the Generate an alert when, select The monitor is in a critical or warning

health state.c. In the Alert name: box, type Test transaction failed.

9. Click OK to save the monitor.10. Select File, then click Save.

To create monitor based on custom monitor type

420

How to create a monitor based on a Windows PowerShell scriptThe following procedure shows how to create a monitor based on a custom data source module running a Windows PowerShell script by using Operations Manager 2007 Authoring console. This is the same procedure in How to create a monitor based on a custom module with the script that is written in Windows PowerShell instead of VBScript.

Before you perform this procedure, you must first complete the prerequisite procedure How to Create a Class in which you create the class to act as the target.

The monitor has the following characteristics:

Targeted at a class that has only a single instance on an agent. Because there is a single instance, there is no requirement to support cookdown.

Sets its state based on the comparison of the script value to specified threshold values. The monitor supports On Demand Discovery. This requires a probe action module to run the

script. The script accepts only a single argument for the computer name of the target object’s agent. The script itself is only for testing and performs no real function. It simulates a script running a

synthetic transaction and returning a status message of success or failure.

1. Select Type Library and then Probe Actions.2. Right-click in the Probe Actions pane and select New and then Composite Probe

Action.3. In the Choose a unique identifier box, type

MyMP.ProbeActionModule.MyTransactionPSScript. Click OK.4. On the General tab, in the Name box, type Transaction PowerShell Script Probe

Action.5. On the Member Modules tab, do the following:


Microsoft.Windows.PowerShellPropertyBagProbe.c. In the Module ID box, type PSScript. Click OK.d. In the ScriptName box, type MyTransactionScript.ps1.e. In the TimeoutSeconds box, type 300.f. Click the Edit button. This starts the external editor.g. Paste the contents of the following script between the ScriptBody tags in the XML.

Replace any text that might already exist.

<![CDATA[

param($computerName)

Create probe action module to run Windows PowerShell script

421

$testSuccessful = $true


$api.LogScriptEvent('MyScript.ps1',20,4,$computerName)

$bag = $api.CreatePropertyBag()

$bag.AddValue('ComputerName',$computerName)

if ($testSuccessful -eq $true)

{$bag.AddValue('Result','Good')}

else

{$bag.AddValue('Result','Bad')}

$bag

]]>

h. Paste the following XML after the </ScriptBody> tag.

<Parameters>

<Parameter>

<Name>ComputerName</Name>

<Value>$Config/ComputerName$</Value>

</Parameter>

</Parameters>

i. Close the external editor to save the script back to the module.j. Click OK to save the module configuration.k. In the NextModule column for the PSScript module, select Module Output.

6. On the Configuration Schema tab, do the following:a. In the Simple Configuration Schema section, click Add to add a parameter.b. In the Please enter the requested value box, type ComputerName. Click OK.

7. On the Data Types tab, do the following:a. In the Input Data section, select This module required input data.b. In the Output Data section, in the Data Type: box select System.PropertyBagData.


Create data source module to run probe action on schedule422

1. Select Type Library and then Data Sources.2. Right-click in the Data Sources pane and select New and Composite Data Source.3. In the Choose a unique identifier box, type

MyMP.DataSourceModule.MyTransactionPSScriptTimed. Click OK.4. On the General tab, in the Name box, type Timed Transaction PowerShell Script Data

Source5. On the Member Modules tab, do the following:

a. Click Add to add a module.b. In the Choose Module Type box, select System.SimpleScheduler.c. In the Module ID box, type Schedule. Click OK.d. Click the button to the right side of the IntervalSeconds box and select Promote.

This enters the text $Config/IntervalSeconds$e. Click the button to the right side of the SyncTime box and select Promote. This

enters the text $Config/SyncTime$f. Click OK to save the module configuration.g. Click Add to add a new module.h. In the Choose Module Type box, select

MyMP.ProbeActionModule.MyTransactionPSScript.i. In the Module ID box, type Probe. Click OK.j. Select the button to the right side of the ComputerName box and select Promote.

This enters the text $Config/ComputerName$.k. Click OK to save the module configuration.l. In the NextModule column for the Schedule module, select Probe.m. In the NextModule column for the Probe module, select Module Output.


is optional for this module.7. On the Overrideable Parameters tab, do the following:

a. Click Add, and then click IntervalSeconds.b. In the Choose a unique identifier box, type IntervalSeconds. Click OK.c. Change Configuration Element to Integer.d. Click Add, and then click SyncTime.e. In the Choose a unique identifier box, type SyncTime. Click OK.

8. On the Data Types tab, make sure that the value in the Data Types box is System.PropertyBagData.


423

1. Select Type Library and then Monitor Types.2. Rightclick in the Monitor Types pane and select New, and then click Composite

Monitor Type.3. In the Choose a unique identifier box, type MyMP.MyPSTransactionMonitorType.

Click OK.4. On the General tab, in the Name box, type My Transaction PowerShell Script Monitor

Type.5. On the States tab, do the following:

a. Select 2 State Monitor Type.b. In the ID of state 1 box, type Success.c. In the ID of state 2 box, type Failure.

6. On the Member Modules tab, do the following:a. Click Add to add a module.b. In the Choose Module Type box, select System.PassThroughProbe.c. In the Module ID box, type PassThru. Click OK.d. Click OK to save the module configuration.e. Click Add to add a module.f. In the Choose Module Type box, select

MyMP.ProbeActionModule.MyTransactionPSScript.g. In the Module ID box, type Probe. Click OK.h. Click the button to the right side of the ComputerName box and select Promote.

This enters the text $Config/ComputerName$i. Click OK to save the module configuration.j. Click Add to add a new module.k. In the Choose Module Type box, select

MyMP.DataSourceModule.MyTransactionPSScriptTimed.l. In the Module ID box, type DataSource. Click OK.m. Click the button to the right side of the IntervalSeconds box and select Promote .

This enters the text $Config/IntervalSeconds$n. Click the button to the right side of the ComputerName box and select Promote.

This enters the text $Config/ComputerName$o. Click Edit to start the custom editor. The SyncTime parameter must be added

manually with an XML editor. This is because the Authoring Console only populates the Configuration dialog box by using required parameters for the selected module. The SyncTime parameter was configured not to be required.

p. After the line



Create monitor type using custom data source

424


q. Close the editor to add the XML back the Authoring Console.

NoteIf you receive an error that says that the IntervalSeconds parameter is invalid according to its data type, click Ignore. This error message occurs because the IntervalSeconds parameter is configured as an integer, and the Authoring Console is reading $Config/IntervalSeconds$ as a string. This variable will be replaced with an integer value when the workflow is run so the error can be ignored.

r. Click OK to save the module configuration.s. Click Add to add a new module.t. In the Choose Module Type box, select System.ExpressionFilter.u. In the Module ID box, type FilterSuccess. Click OK.v. Click Configure to open the Expression dialog box.w. Click Insert.x. In the Parameter Name box type Property[@Name='Result'].y. In the Operator box select Equals.z. In the Value box type Good.aa. Click OK to save the expression.bb. Click OK to save the module configuration.cc. Click Add to add a new module.dd. In the Choose Module Type box, select System.ExpressionFilter.ee. In the Module ID box, type FilterFailure. Click OK.ff. Click Configure to open the Expression dialog box.gg. Click Insert.hh. In the Parameter Name box type Property[@Name='Result'].ii. In the Operator box select Equals.jj. In the Value box type Bad.kk. Click OK to save the expression.ll. Click OK to save the module configuration.

7. On the Regular tab, do the following:a. Select Success.b. Check the Include box next to DataSource.c. Check the Include box next to FilterSuccess.d. In the Next Module box next to DataSource select FilterSuccess.e. In the Next Module box next to FilterSuccess select Monitor State Output.f. Select Failure.g. Check the Include box next to DataSource.

425

h. Check the Include box next to FilterFailure.i. In the Next Module box next to DataSource select FilterFailure.j. In the Next Module box next to FilterFailure select Monitor State Output.

8. On the On Demand tab, do the following:a. Check the box next to Use On Demand Detection.b. Select Success.c. Check the Include box next to PassThru.d. Check the Include box next to Probe.e. Check the Include box next to FilterSuccess.f. In the Next Module box next to PassThru select Probe.g. In the Next Module box next to Probe select FilterSuccess.h. In the Next Module box next to FilterSuccess select Monitor State Output.i. Select Failure.j. Check the Include box next to PassThru.k. Check the Include box next to Probe.l. Check the Include box next to FilterFailure.m. In the Next Module box next to PassThru select Probe.n. In the Next Module box next to Probe select FilterFailure.o. In the Next Module box next to FilterFailure select Monitor State Output.

9. On the Configuration Schema tab, do the following:a. In the Type box next to IntervalSeconds select Integer.b. Click Add to add a parameter.c. In the Please enter the requested value box type SyncTime. Click OK.d. Clear the Required box next to SyncTime.

10. On the Overrideable Parameters tab, do the following:a. Click Add and then IntervalSeconds.b. In the Choose a unique identifier box type IntervalSeconds. Click OK.c. In the Configuration Element box for IntervalSeconds select Integer.d. Click Add and then SyncTime.e. In the Choose a unique identifier box type SyncTime. Click OK.

11. Click OK to save the module type.12. Select File, and then click Save.

1. Select Health Model and then Monitors.2. In the Monitors pane, expand MyMP.MyComputerRole1 and then

System.Health.EntityState.3. Right-click System.Health.AvailabilityState and select New. and then select Custom

Create monitor based on custom monitor type

426

Unit Monitor.4. In the Choose a unique identifier box, type MyMP.MyPSTransactionMonitor. Click

OK.5. On the General tab, in the Name box, type My PowerShell Transaction Monitor.6. On the Configuration tab, do the following:

a. Click Browse for a type.b. In the Choose unit monitor type box select MyMP.MyPSTransactionMonitorType.

Click OK.c. In the IntervalSeconds box type 900.d. Clear the text in the ComputerName box. Click the button to the right side of the box

and select (Host=Windows Computer) and then Principal Name (Windows Computer).

7. On the Health tab, do the following:a. In the Health State box for Success select Healthy.b. In the Health State box for Failure select Critical.

8. On the Alerting tab, do the following:a. Check the box next to Generate alerts for this monitor.b. In the Generate an alert when select The monitor is in a critical health state.c. In the Alert name: box type Test PowerShell transaction failed.

9. Click OK to save the monitor.10. Select File, and then click Save.

How to create a monitor and rule that share a script supporting cookdownThe following procedure shows how to create a monitor and rule based on a common data source module running a script using Operations Manager 2007 Authoring console. Before you perform this procedure, you must first complete the prerequisite procedure How to Create a Class in which you create the class to act as the target.

The workflows have the following characteristics:

Rule and monitor targeted at a class that has multiple instances on an agent. Because there are multiple instances, cookdown support is required.

The rule collects a performance value from the script while the monitor sets its state based on the comparison of the script value to specified threshold values.

The monitor does not support On Demand Discovery so that it does not require that you use a probe action module to run the script.

427

The script accepts arguments for the computer name of the target object’s agent and the version of the application.

The script itself is only a test that generates a constant value.

1. Select Type Library, then Data Sources.2. Right-click the Data Sources pane and select New and Composite Data Source.3. In the Choose a unique identifier box, type

MyMP.DataSourceModule.MyPerformanceScriptTimed. Click OK.4. On the General tab, in the Name box, type Timed Performance Script Data Source5. On the Member Modules tab, do the following:


Microsoft.Windows.TimedScript.PropertyBagProvider.c. Click the button to the right side of the IntervalSeconds box and select Promote.

This will enter the text $Config/IntervalSeconds$d. In the Module ID box, type Script. Click OK.e. Click the button to the right side of the SyncTime box and select Promote. This will

enter the text $Config/SyncTime$f. In the ScriptName box, type MyCookdownScript.vbs.g. In the Arguments box, type $Config/ComputerName$ $Config/Version$.h. In the TimeoutSeconds box, type 300.i. Click the button. This starts the custom editor. Editj. Paste the complete contents of the following script between the ScriptBody tags in


<![CDATA[




oAPI.LogScriptEvent "MyCookdownScript.vbs",10,4, "Running script on " & sComputerName & ". Version is " & sVersion

For i = 1 to 3



Call oBag.AddValue("ComponentName","Component" & i)

Call oBag.AddValue("Value",30)

oAPI.AddItem(oBag)

To create data source module to run script on schedule

428

Next

oAPI.ReturnItems

]]>

k. Close the editor to save the script back to the module.l. If you receive an error that says that the IntervalSeconds parameter is invalid

according to its data type, click Ignore. This error message occurs because the IntervalSeconds parameter is configured as an integer, and the Authoring Console is reading $Config/IntervalSeconds$ as a string. This variable will be replaced with an integer value when the workflow is run so the error can be ignored.

m. Click OK to save the module configuration.n. Click Add to add a new module.o. In the Choose Module Type box, select

System.Performance.DataGenericMapper.p. In the Module ID box, type MapToPerf. Click OK.q. In the ObjectName box, type MyApp.r. In the CounterName box, type TestCounter.s. In the InstanceName box, type $Data/Property[@Name='ComponentName']$t. In the Value box, type $Data/Property[@Name='Value']$.u. Click OK.v. In the NextModule column for the Script module, select MapToPerf.w. In the NextModule column for the MapToPerf module, select Module Output.


is optional for this module.c. In the Simple Configuration Schema section, click Add to add a parameter.d. In the Please enter the requested value box, type ComputerName. Click OK.e. In the Simple Configuration Schema section, click Add to add a parameter.f. In the Please enter the requested value box, type Version. Click OK.

7. On the Overrideable Parameters tab, do the following:a. Click Add, then IntervalSeconds.b. In the Choose a unique identifier box, type IntervalSeconds. Click OK.c. Change Configuration Element to Integer.d. Click Add, then SyncTime.e. In the Choose a unique identifier box, type SyncTime. Click OK.

8. On the Data Types tab ensure the value in the Data Types box is System.Performance.Data.

9. Click OK to save the module.

429

10. Select File, then click Save.

1. Select Type Library, then Data Sources.2. Right-click the Data Sources pane and select New and Composite Data Source.3. In the Choose a unique identifier box, type

MyMP.DataSourceModule.MyPerformanceScriptFiltered. Click OK.4. On the General tab, in the Name box, type Filtered Performance Script Data Source5. On the Member Modules tab, do the following:


MyMP.DataSourceModule.MyPerformanceScriptTimed.c. In the Module ID box, type Script. Click OK.d. Click the button to the right side of the IntervalSeconds box and select Promote.

This will enter the text $Config/IntervalSeconds$e. Click the button to the right side of the ComputerName box and select Promote.

This will enter the text $Config/ComputerName $f. Click the button to the right side of the Version box and select Promote. This will

enter the text $Config/Version$g. Click Edit to start the custom editor. The SyncTime parameter must be added

manually with an XML editor. This is because the Authoring Console only populates the Configuration dialog box by using parameters required for the selected module. The SyncTime parameter was configured to not be required.

h. After the line




i. Close the editor to save the script back to the module.


j. Click OK to save the module configuration.k. Click Add to add a module.l. In the Choose Module Type box, select System.ExpressionFilter.

To create data source module to filter on instance

430

m. In the Module ID box, type FilterComponent. Click OK.n. Click Configure to open the Expression dialog box.o. Click Insert.p. In the Parameter Name box type InstanceName.q. In the Operator box select Equals.r. In the Value box type $Config/ComponentName$.s. Click OK to save the expression.t. Click OK to save the module configuration.u. In the NextModule column for the Script module, select FilterComponent.v. In the NextModule column for the FilterComponent module, select Module Output.

6. On the Configuration Schema tab, do the following:a. Change the Type for the IntervalSeconds parameter to Integer.b. In the Simple Configuration Schema section, click Add to add a parameter.c. In the Please enter the requested value box, type SyncTime. Click OK.d. Clear the Required box next to the SyncTime parameter. The SyncTime parameter

is optional for this module.e. In the Simple Configuration Schema section, click Add to add a parameter.f. In the Please enter the requested value box, type ComponentName. Click OK.

7. On the Overrideable Parameters tab, do the following:a. Click Add, then IntervalSeconds.b. In the Choose a unique identifier box, type IntervalSeconds. Click OK.c. Change Configuration Element to Integer.d. Click Add, then SyncTime.e. In the Choose a unique identifier box, type SyncTime. Click OK.

8. On the Data Types tab ensure the value in the Data Types box is System.Performance.Data.

9. Click OK to save the module.10. Select File, then click Save.

1. Select Health Model, then Rules.2. Right-click the Rules pane and select New, then Custom Rule.3. In the Choose a unique identifier box, type MyMP.

MyAppComponent.PerformanceCollectionRule. Click OK.4. On the General tab, do the following:

a. In the Name box type Collect MyApp Component performance data.b. In the Target box, select MyMP.MyApplicationComponent.

5. On the Modules tab, do the following:

To create rule to collect performance data

431

a. In the Data Sources section click Create.b. In the Choose Module Type box, select

MyMP.DataSourceModule.MyPerformanceScriptFiltered.c. In the Module ID box, type DS. Click OK.d. Click Edit to modify the module parameters.e. In the IntervalSeconds box, type 900.f. Clear the text in the ComputerName box. Click the button to the right of the box,

select (Host=My Computer Role 1). Now select (Host=Windows Computer) and then Principal Name (Windows Computer). This enters the text $Target/Host/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/PrincipalName$.

g. Clear the text in the Version box. Click the button to the right side of the box and select (Host=My Computer Role 1) and then Version (My Computer Role Base). This will enter the text $Target/Host/Property[Type="MyMP.MyComputerRoleBase"]/Version$.

h. Clear the text in the ComponentName box. Click the button to the right of the box and select ComponentName.

i. Click OK to save the module configuration.j. In the Actions section click Create.k. In the Choose Module Type box, select

Microsoft.SystemCenter.CollectPerformanceData.l. In the Module ID box, type WriteToDB. Click OK.m. In the Actions section click Create.n. In the Choose Module Type box, select

Microsoft.SystemCenter.DataWarehouse.PublishPerformanceData.o. In the Module ID box, type WriteToDW. Click OK.

6. Click OK.7. Select File, then click Save.

1. Select first Type Library and then select Monitor Types.2. Right-click in the Monitor Types pane, select New, and then Composite Monitor Type.3. In the Choose a unique identifier box, type MyMP.MyAppComponentMonitorType.

Click OK.4. On the General tab, do the following:

a. In the Name box, type MyApplicationComponent Monitor Type.5. On the States tab, do the following:

a. Select 3 State Monitor Type.b. In the ID of state 1 box type UnderThreshold.c. In the ID of state 2 box type OverWarningThreshold.

To create monitor type using custom data source

432

d. In the ID of state 3 box type OverErrorThreshold.6. On the Modules tab, do the following:


MyMP.DataSourceModule.MyScriptFiltered.c. In the Module ID box, type DataSource. Click OK.d. Click the button to the right of the IntervalSeconds box and select Promote. This

enters the text $Config/IntervalSeconds$e. Click the button to the right side of the ComputerName box and select Promote.

This enters the text $Config/ComputerName$f. Click the button to the right side of the Version box and select Promote. This enters

the text $Config/Version$g. Click the button to the right side of the ComponentName box and select Promote.

This enters the text $Config/ComponentName $h. Click Edit to start the custom editor. The SyncTime parameter must be added

manually with an XML editor. This is because the Authoring console only populates the Configuration dialog box with required parameters for the selected module. The SyncTime parameter was configured to not be required.

i. After the line




j. Close the editor to add the XML back the Authoring Console.


k. Click OK to save the module configuration.l. Click Add to add a module.m. In the Choose Module Type box, select System.ExpressionFilter.n. In the Module ID box, type FilterUnderThreshold. Click OK.o. Click Configure to open the Expression dialog box.p. Click Insert.q. In the Parameter Name box type Value.r. In the Operator box select Less than.s. In the Value box type $Config/WarningThreshold$.

433

t. Click OK.u. In each >>>@Type box, change the value String to Integer.v. Click OK to save the module configuration.w. Click Add to add a module.x. In the Choose Module Type box, select System.ExpressionFilter.y. In the Module ID box, type FilterOverWarningThreshold. Click OK.z. Click Configure open the Expression dialog box.aa. Click Insert.bb. In the Parameter Name box type Value.cc. In the Operator box select Greater than or equal to.dd. In the Value box type $Config/WarningThreshold$. Click OK.ee. Click Insert.ff. In the Parameter Name box type Value.gg. In the Operator box select Less than.hh. In the Value box type $Config/ErrorThreshold$. Click OK.ii. In each >>>@Type box, change the value String to Integer.jj. Click OK to save the module configuration.kk. Click Add to add a module.ll. In the Choose Module Type box, select System.ExpressionFilter.mm. In the Module ID box, type FilterOverErrorThreshold. Click OK.nn. Click Configure.oo. Click Insert.pp. In the Parameter Name box type Value.qq. In the Operator box select Greater than or equal to.rr. In the Value box type $Config/ErrorThreshold$.ss. Click OK.tt. In each >>>@Type box, change the value String to Integer.uu. Click OK to save the module configuration.

7. On the Regular tab, do the following:a. Select UnderThreshold.b. Check the Include box next to DataSource.c. Check the Include box next to FilterUnderThreshold.d. In the Next Module box next to DataSource select FilterUnderThreshold.e. In the Next Module box next to FilterUnderThreshold select Monitor State Output.f. Select OverWarningThreshold.g. Check the Include box next to DataSource.h. Check the Include box next to FilterOverWarningThreshold.i. In the Next Module box next to DataSource select FilterOverWarningThreshold.

434

j. In the Next Module box next to FilterOverWarningThreshold select Monitor State Output.

k. Select OverErrorThreshold.l. Check the Include box next to DataSource.m. Check the Include box next to FilterOverErrorThreshold.n. In the Next Module box next to DataSource select FilterOverErrorThreshold.o. In the Next Module box next to FilterOverErrorThreshold select Monitor State

Output.8. On the Configuration Schema tab, do the following:

a. In the Type box next to IntervalSeconds select Integer.b. Click Add to add a parameter.c. In the Please enter the requested value box type SyncTime. Click OK.d. Clear the Required box next to SyncTime.e. Click Add to add a parameter.f. In the Please enter the requested value box type WarningThreshold. Click OK.g. In the Type box next to WarningThreshold select Integer.h. Click Add to add a parameter.i. In the Please enter the requested value box type ErrorThreshold. Click OK.j. In the Type box next to ErrorThreshold select Integer.

9. On the Overrideable Parameters tab, do the following:a. Click Add and then IntervalSeconds.b. In the Choose a unique identifier box type IntervalSeconds.c. In the Configuration Element box for IntervalSeconds select Integer.d. Click Add and then SyncTime.e. In the Choose a unique identifier box type SyncTime.f. Click Add, then WarningThreshold.g. In the Choose a unique identifier box type WarningThreshold.h. In the Configuration Element box for WarningThreshold select Integer.i. Click Add, then ErrorThreshold.j. In the Choose a unique identifier box type ErrorThreshold.k. In the Configuration Element box for ErrorThreshold select Integer.

10. Click OK to save the monitor type.11. Select File, then click Save.

1. Select Health Model, then Monitors.2. Expand MyMP.MyApplicationComponent and then System.Health.EntityState.3. Right-click System.Health.PerformanceState, select New, and then Custom Unit

To create monitor based on custom monitor type

435

Monitor.4. In the Choose a unique identifier box, type

MyMP.MyAppComponent.PerformanceMonitor. Click OK.5. On the General tab, in the Name box, type My Application Component Performance.6. On the Configuration tab, do the following:

a. Click Browse for a type….b. In the Choose unit monitor type box select

MyMP.MyAppComponentMonitorType.c. In the IntervalSeconds box type 900.d. Clear the text in the ComputerName box. Click the button to the right side of the box

and select (Host=My Computer Role 1) and then(Host=Windows Computer) and then Principal Name (Windows Computer).

e. Clear the text in the Version box. Click the button to the right side of the box and select (Host=My Computer Role 1) and then Version (My Computer Role Base).

f. Clear the text in the ComponentName box. Click the button to the right side of the box and select ComponentName.

g. In the WarningThreshold box type 10.h. In the ErrorThreshold box type 20.

7. On the Health tab, do the following:a. In the Health State box for UnderThreshold select Healthy.b. In the Health State box for OverWarningThreshold select Warning.c. In the Health State box for OverErrorThreshold select Critical.

8. On the Alerting tab, do the following:a. Check the box next to Generate alerts for this monitor.b. In the Generate an alert when… select The monitor is in a critical or warning

health state.c. In the Alert name: box type Performance problem detected.

9. Click OK to save the monitor.10. Select File, then click Save.

436

management pack authoring guidedownload.microsoft.com/download/b/f/d/bfdd0f66-1637-4ea3... · web...

Documents