Windows Management Instrumentation
As noted in Chapter 3, "Application Center Architecture," WMI is at the core of the Application Center architecture. The monitoring feature, in particular, uses WMI extensively. This set of extensions to the Windows Driver Model (WDM) provides the interface through which components can provide information and notification. WMI consolidates data from the hardware platform, drivers, and applications, and passes it to a management information store. This data store uses the Common Information Model (CIM) to expose and interact with the data it holds. Working in combination, WMI and CIM provide a mechanism that enables management applications, platforms, and consoles to perform a variety of tasks, including monitoring and logging events.
Architecturally, WMI consists of four main elements:
- Managed applications
- Managed objects
- WMI providers
- Management infrastructure
Managed Applications
Management applications are applications based on services provided by the Windows or Microsoft Windows NT/ Windows 2000 operating system that process or display data from managed objects. A management application can perform a variety of tasks, such as:
- Respond to events.
- Start or stop services.
- Measure performance.
- Report outages.
- Correlate data.
Several strategies are used to implement management applications. Applications can access WMI directly through the COM or scripting APIs, or indirectly with one of the following access methods.
- Web browsers can use a set of Microsoft ActiveX controls to control the appearance, relationships, and behavior of data relating to managed objects. The controls are customizable and can be included in a standard schema definition.
- Web browsers also can use HTML, which is supported through an ISAPI layer that interacts with WMI.
- Database applications can use the WMI ODBC adapter to merge ODBC's database capabilities with WMI's management capabilities. With the ODBC adapter, an application can use a wide range of ODBC-based reporting packages and tools, such as Microsoft Excel and Microsoft Access.
- Directory services applications can use the WMI Active Directory Service Interface (ADSI) extension to integrate directory service and management data.
Management applications can be written in any programming language that can communicate with the WMI Service by using a WMI-supported API. Among the supported APIs are the COM-based API for C/C++, and the scripting API for the Microsoft Visual Basic development system, DHTML, Active Server Pages (ASP), and Windows Scripting Host (WSH).
Managed Objects
Managed objects are logical or physical enterprise components. They are modeled by using the CIM and accessed by management applications through WMI. A managed object can be any system component—from a small piece of hardware, such as a cable or disk drive, to a large software application, such as a database system.
Example
The Win32_LogicalDisk WMI class, derived from CIM_LogicalDisk—an industry standard definition for disk drives with Windows extensions that enables the platform to manage drives—represents a data source that resolves to an actual local storage device on a system that is running the Microsoft Win32 API. Table 7.2, taken from the Platform SDK in the MSDN Library, provides some representative properties for this particular object, properties whose values can be altered or queried through WMI.
Table 7.2 Property Examples for the Win32_LogicalDisk Object
| Property | Description |
|---|---|
| Access | Type of media access available. |
| BlockSize | Size, in bytes, of the blocks that form this storage extent. If the size is unknown or if a block concept is not valid (for example, for aggregate extents, memory, or logical disks), enter a 1. |
| Caption | Short description (one-line string) of the object. |
| Compressed | Indicates whether the logical volume exists as a single compressed entity, such as a DoubleSpace volume. If file-based compression is supported (such as on NTFS), this property will be FALSE. |
| DriveType | Numeric value corresponding to the type of disk drive that this logical disk represents. |
| DeviceID | Uniquely identifies the logical disk from other devices on the system. |
| FreeSpace | Space available on the logical disk. |
| VolumeName | The volume name of the logical disk. |
| Size | The size of the disk drive. |
| PNPDeviceID | Win32 Plug and Play device identifier of the logical device. |
WMI Providers
Providers are used to supply WMI with data from managed objects, to handle requests on behalf of management applications, and to generate notifications of events.
Windows Management Instrumentation defines two types of providers:
- Built-in providers
- Application-specific providers (also called custom providers)
Built-in providers are providers that are included with WMI. These providers supply WMI with information from various logical and physical sources such as the operating system registry, the Win32 subsystem, and Simple Network Management Protocol (SNMP) devices.
WMI's built-in providers are summarized in Table 7.3.
Table 7.3 WMI Built-In Providers
| Provider | Description |
|---|---|
| Directory Services | Makes the classes and objects in Microsoft Active Directory available to WMI management applications. |
| Event Log | Provides access to data and notifications of events from the Windows NT or Windows 2000 Event Log. |
| Microsoft Windows Installer | Provides access to information about applications that are installed with the Windows Installer. |
| Performance Counters | Provides access to raw performance counter data. |
| Performance Monitor | Provides access to data from the Windows NT or Windows 2000 Performance Monitor. |
| Power Management Event | Represents power management events resulting from power state changes. |
| Registry Event | Sends an event whenever a change occurs to a key, a value, or an entire tree in the registry. |
| Registry | Provides access to data from the registry. |
| Security | Provides access to security settings that control ownership, auditing, and access rights to NTFS. |
| SNMP | Provides access to data and events from SNMP devices. |
| View | Creates new classes made of properties from different source classes, namespaces, or computers. |
| WDM | Provides access to data and events from device drivers that conform to the WMI interface. |
| Win32 | Provides access to data from the Win32 subsystem. |
Developers create application-specific providers to communicate information from objects in their domain to WMI.
Providers communicate with the WMI service by using the COM/DCOM API and are typically written in C or C++.
Figure 7.3, which is based on the WMI architecture diagram (Figure 3.2 in Chapter 3), illustrates the use of providers to provide a link between managed objects, the CIM Object Manager (CIMOM), and the CIM Repository.
Figure 7.3 Providers and managed objects in the WMI architecture
Providers serve one of two purposes: they either provide data or provide events. The distinction between these two purposes is categorized further in Table 7.4.
Table 7.4 Provider Types
| Type | Description |
|---|---|
| Class | Retrieves, modifies, deletes, and/or enumerates provider-specific classes. It can also support query processing. |
| Instance | Retrieves, modifies, deletes, and/or enumerates the instances of provider-specific classes. It can also support query processing. |
| Property | Retrieves and/or modifies individual property values. |
| Method | Invokes methods for a provider-specific class. |
| Event | Generates notifications of events. |
| Event consumer | Supports event notification by mapping a physical consumer with a logical consumer. |
Management Infrastructure
The management infrastructure consists of the WMI Service and the CIM repository. WMI enables users to handle communications between management applications and providers. Applications and providers communicate through WMI by using a common programming interface (COM API). The COM API, which supplies event notification and query processing services, is available in the C and C++ programming languages. The CIM repository holds static management data that changes infrequently.
WMI Service
The file WinMgmt.exe implements the WMI Service.
WinMgmt.exe starts when the first management application makes a call to connect, and is activated when the first client application successfully connects and runs continuously when management applications actively seek its services.
WMI supports the following programming interfaces:
- The COM API for WMI—Components, written in C or C++, use this API for communicating between management applications, providers, and schema extensions and the WMI service.
- Scripting API for WMI—WMI client applications based on this API are created by using various scripting languages and Visual Basic.
When an application makes a request by calling a method in either the COM or Scripting API, the WMI Service determines whether the request involves static data stored in the CIM repository or dynamic data supplied by a provider.
NOTE
Static data can be handled by WMI, whereas dynamic data always involves a provider. Providers register their location and support for particular operations, such as data retrieval, modification, deletion, enumeration, or query processing. WMI uses this registration information to match application requests with the appropriate providers—and to locate and load the providers when necessary. When a provider finishes processing a request, it returns the results back to WMI, which, in turn, forwards the result to the application.
In addition to implementing the operations associated with application requests, WMI also supplies support for the following:
- Event notification
- Query language
- Security
Event Notification
Events are occurrences of interest in the managed world; for the Application Center administrator, events related to a cluster member, or cluster operations as a whole, can be used to manage, maintain, and troubleshoot cluster operations.
WMI supports the detection of events and their delivery to interested subscribers, or event consumers. Events are represented by instances of classes derived from the system class _Event. Although WMI can detect some events by itself, such as changes to the CIM repository, WMI event providers are used to detect most events. Event providers are WMI providers that monitor a source of events and notify WMI when events occur. An example is the Registry Event Provider, which notifies WMI when a registry entry changes.
WMI supports the registration for, and distribution of, event notifications to event consumers. Event consumers register to receive particular types of notifications. Event providers register to supply particular types of notifications. WMI acts as an intermediary between event consumers and providers, which enables them to operate independently.
WMI supports both temporary and permanent event consumers. Temporary event consumers receive notifications only as long as they are active, and their registration is removed when they terminate. Permanent consumers, on the other hand, will receive a notification whenever one occurs. WMI must be available at all times to deliver these event notifications.
In addition to the events generated by event providers, referred to as extrinsic events, WMI also produces two of its own events: timer events and intrinsic events. Timer events occur either periodically, according to a specified time interval, or once at a specified time. Intrinsic events are driven by changes to the data that is stored in the CIM repository.
WMI forwards the notifications of all types of events to applications that have registered to receive them.
Query Language Support
WMI supports the Windows Management Instrumentation Query Language (WQL), a subset of the ANSI standard Structured Query Language (SQL), with WMI-specific extensions.
WQL supports the following types of queries:
- Data queries are used to retrieve class instances and data associations.
- Event queries enable consumers to register for event notification and enable providers to register to support events.
- Schema queries are used to retrieve class definitions and schema associations. Class providers use these queries to specify the classes they support when they register. The following example illustrates how you can use SQL's query extensions to discover/transverse a schema:
IWbemServices::ExecQuery ("Associators of {Win32_Service = 'DHCP'}) You can query any CIM object, such as the logical disk that was provided as an example of a managed object. An example of such a query is:
IWbemServices::ExecQuery ("select * from Win32LogicalDisk where Win32LogicalDisk.FreeSpace < 2000000") By using WMI's rich query language support, you can execute sophisticated event filtering (thresholds, aggregation, and inheritance). The following code sample demonstrates this:
//* within nnn - for specifying the tolerance for event delay //* isa - registration applies to all events from class (including derived classes) //* within nnn (within group by clause) - specifies aggregation interval select * from _InstanceModificationEvent within 5 where TargetInstance is a Win32_LogicalDisk group by Driveletter within 10 having count > 25
NOTE
WQL does not support cross-namespace queries or associations. You cannot query for all instances of a specified class residing in all the namespaces on the target computer, and you can't associate two objects across a namespace boundary and retrieve or query for the associations.
Security Support
WMI provides some security support, in that it will validate user credentials before a user is allowed to connect to WMI. WMI does not support protection of individual classes or instances of dynamic data. However, it does support protecting individual classes and instances of dynamic data through the use of impersonation. WMI also supports security for individual namespaces.
Because WMI is implemented by using DCOM, it is important to understand how to use the DCOM security settings. The following extracts from the WMI SDK documentation summarize these settings.
Using DCOM security from WMI
DCOM security settings fall into two categories: authentication and impersonation. Authentication is the means by which one process identifies itself to another. Impersonation indicates how much authority a client grants a server to call other processes on its behalf.Impersonation
DCOM impersonation levels range from no identification to full-blown delegation of authority. DCOM provides default security levels, which it reads from the system registry. Unfortunately, unless specifically modified, these registry settings set the impersonation level too low for WMI to function. The default impersonation level is typically RPC_C_IMP_LEVEL_IDENTIFY, while WMI needs at least RPC_C_IMP_LEVEL_IMPERSONATE to function with most providers. This impersonation level, or higher, must be explicitly set before calling into WMI.
Authentication
DCOM authentication levels range from no authentication to per-packet encrypted authentication.
User identification involves verifying the user name and password, the responsibility of system security packages such as NTLM. Security packages have no information about access rights; their only responsibility is to positively identify valid users.
Depending on the operating system, WMI supports varying levels of authentication. For the Windows 95 and Windows 98 operating systems, all local users are assumed to be authentic, regardless of the user and password. There is no local authentication, and true authentication only occurs over remote connections. For the Windows NT and Windows 2000 operating systems, all users are authenticated. After authentication, the user is still subject to permissions settings, which are strictly enforced.
Permission assignment involves granting access to valid users and is the responsibility of WMI. Because Windows 95 and Windows 98 are not secure operating systems, granting and denying permissions have less effect on these systems than on other systems. For example, for the Windows NT and Windows 2000 operating systems, file operations may be denied to a user even if WMI considers the user as having full access.
For Windows NT version 4.0, the only authentication service is NTLM. Under Windows 2000, two additional authentication services are available: Kerberos V5 authentication and the Negotiate authentication service. Negotiate is recommended for use with code that needs to work in domains that are not using the Kerberos V5 protocol. If the client and server are on two computers running Windows 2000, the default authentication service will be Negotiate. In all other cases, the default authentication service is NTLM. For more information on DCOM impersonation and authentication levels, see the COM reference documentation in the Platform SDK.
Application Center and WMI Security
In Application Center, the Application Center and Health Monitor namespaces can be read by any authenticated user, but can be written (that is to say, an instance of existing classes or new classes can be created) only by an administrator and by the cluster user group account, which is identified by ACA_computername.
On the Windows 2000 platform WMI, a remote connection to a given WMI namespace is a separate user right that may or may not be granted by the system administrator.
WARNING
With a remote connection, a user can specify a user name and password as a substitute for his or her current user name and password. If authenticated, the user can access the target namespace. (With a local connection, you cannot override the current name and password.) If you want to control access to a namespace, you have to do it via user rights.
The CIM Repository
The CIM repository is a central storage area managed by the CIM Object Manager. The repository uses a simple schema, consisting of namespaces, classes, and class instances, for storing and accessing data.
Namespace
The namespace is the top-level node, or root, of the CIM schema. A namespace is a logical unit for grouping classes and class instances, and for controlling their scope and visibility. Typically, a namespace contains a set of classes and instances that represent managed objects in a particular environment.
A namespace is represented in its parent namespace by an instance of the _Namespace system class or a class that derives from the __Namespace class. The __Namespace class has a single property: Name. It is the name of the namespace that distinguishes it from all other namespaces.
All WMI installations have these predefined namespaces:
- root
- root\default
- root\cimv2
The root namespace is primarily designed to contain other namespaces. The WMI installation places the other predefined namespaces under the root namespace. The root\default namespace holds most of the system classes. The root\cimv2 namespace contains the classes and instances that represent a Win32 environment, such as Win32_LogicalDisk and Win32_OperatingSystem. Namespaces can be nested, which is the case with the Application Center environment. The Application Center namespace structure in the CIM repository is as follows:
root\
\MicrosoftApplicationCenter
root\cimv2
\MicrosoftHealthMonitor
Classes and Instances
A WMI class defines a template for describing a type of managed object. An instance of a WMI class represents a specific managed object of the type described by the class. Where the class generally models the real-world device or component in the general sense, each instance represents a specific occurrence of the device or component. For example, a general class called FloppyDisk might exist, with the instances on a particular host computer representing drives A and B.
Class definitions can be either static or dynamic. A static class has a definition that is persistent and is stored in the CIM repository until it is explicitly deleted. WMI can provide definitions of static classes without the help of a provider.
A class provider supplies a dynamic class definition at run time when the class definition is required. Dynamic class definitions are not persisted. Whenever the definition of a dynamic class is requested, WMI makes a call to the appropriate class provider to get the definition of the dynamic class.
All instances of a class exist within the namespace to which the class belongs. Within a namespace, instances can be either static or dynamic.
The following limits apply to storing data in the repository:
- Static classes with static instances store the class definitions and the instances in the CIM repository.
- Static classes with dynamic instances store only the definitions.
- Dynamic classes store neither the class definitions nor the instances. This information has to be handled by a provider.
Figure 7.4 shows how the example counter, Physical Disk Queue Length, is stored in the CIM repository. In this example, the object's namespace is root\MicrosoftHealthMonitor\PerfMon.
NOTE
There are several tools available that you can use to access WMI and the CIM repository. First, there's wbemtest, which is a Win32 application; then there's the tool collection that ships with the WMI SDK. The SDK includes online documentation, WMI CIM Studio (an HTTP-based browser used to provide the view shown in Figure 7.4), the WMI Event Registration and the WMI Object Browser (HTTP-based), and the WMI Event Viewer, which is Win32-based.
Figure 7.4 The Physical Disk Queue Length counter, as it is stored in the CIM repository
WMI or network administrators can either place data directly into the repository or add it programmatically. Developers can use the Managed Object Format Language (MOF) or the COM API to write information, such as a new performance counter, to the repository. In Chapter 10, "Working with Performance Counters," you'll see how to create and add performance counters by using .mof files and the MOF compiler.
The following example shows the .mof source that is used to create the Physical Disk Queue Length counter. This source was created by using the CIM Studio MOF Generator Wizard, one of several tools included in the WMI SDK. The wizard automates the process of generating .mof source for class definitions and/or instances. The WMI SDK is available from Microsoft at http://wmig.
//************************************************************************* //* File: SampleMOF.mof //************************************************************************* //************************************************************************* //* This MOF was generated from the "\\.\ROOT\CIMV2\MicrosoftHealthMonitor\PerfMon" //* namespace on machine "ACDW822AS". //* To compile this MOF on another machine you should edit this pragma. //************************************************************************* #pragma namespace("\\\\.\\ROOT\\CIMV2\\MicrosoftHealthMonitor\\PerfMon") //************************************************************************* //* Class: PhysicalDisk //* Derived from: Win32_PerfFormattedData //************************************************************************* [dynamic: ToInstance, provider("PerfProv"), DisplayName("PhysicalDisk"), Description("The Physical Disk performance object consists of counters that monitor hard or fixed disk drive on a computer. Disks are used to store file, program, and paging data and are read to retrieve these items, and written to record changes to them. The values of physical disk counters are sums of the values of the logical disks (or partitions) into which they are divided."), ClassContext("local|PhysicalDisk")] class PhysicalDisk : Win32_PerfFormattedData { [read, key] string Name; [read, CounterType(65536), PropertyContext("Current Disk Queue Length"), DisplayName("Current Disk Queue Length"), Description("Current Disk Queue Length is the number of requests outstanding on the disk at the time the performance data is collected. It includes requests in service at the time of the snapshot. This is an instantaneous length, not an average over the time interval. Multi-spindle disk devices can have multiple requests active at one time, but other concurrent requests are awaiting service. This counter might reflect a transitory high or low queue length, but if there is a sustained load on the disk drive, it is likely that this will be consistently high. Requests are experiencing delays proportional to the length of this queue minus the number of spindles on the disks. This difference should average less than 2 for good performance.")] real32 CurrentDiskQueueLength; [read, CounterType(542573824), PropertyContext("% Disk Time"), DisplayName("% Disk Time"), Description("% Disk Time is the percentage of elapsed time that the selected disk drive is busy servicing read or write requests.")] real32 PercentDiskTime; [read, CounterType(5571840), PropertyContext("Avg. Disk Queue Length"), DisplayName("Avg. Disk Queue Length"), Description("Avg. Disk Queue Length is the average number of both read and write requests that were queued for the selected disk during the sample interval.")] real32 AvgDiskQueueLength; [read, CounterType(542573824), PropertyContext("% Disk Read Time"), DisplayName("% Disk Read Time"), Description("% Disk Read Time is the percentage of elapsed time that the selected disk drive is busy servicing read requests.")] real32 PercentDiskReadTime; [read, CounterType(5571840), PropertyContext("Avg. Disk Read Queue Length"), DisplayName("Avg. Disk Read Queue Length"), Description("Avg. Disk Read Queue Length is the average number of read requests that were queued for the selected disk during the sample interval.")] real32 AvgDiskReadQueueLength; [read, CounterType(542573824), PropertyContext("% Disk Write Time"), DisplayName("% Disk Write Time"), Description("% Disk Write Time is the percentage of elapsed time that the selected disk drive is busy servicing write requests.")] real32 PercentDiskWriteTime; [read, CounterType(5571840), PropertyContext("Avg. Disk Write Queue Length"), DisplayName("Avg. Disk Write Queue Length"), Description("Avg. Disk Write Queue Length is the average number of write requests that were queued for the selected disk during the sample interval.")] real32 AvgDiskWriteQueueLength; [read, CounterType(805438464), PropertyContext("Avg. Disk sec/ Transfer"), DisplayName("Avg. Disk sec/Transfer"), Description("Avg. Disk sec/Transfer is the time in seconds of the average disk transfer.")] real32 AvgDiskSecPerTransfer; [read, CounterType(805438464), PropertyContext("Avg. Disk sec/Read"), DisplayName("Avg. Disk sec/Read"), Description("Avg. Disk sec/Read is the average time in seconds of a read of data from the disk.")] real32 AvgDiskSecPerRead; [read, CounterType(805438464), PropertyContext("Avg. Disk sec/Write"), DisplayName("Avg. Disk sec/Write"), Description("Avg. Disk sec/Write is the average time in seconds of a write of data to the disk.")] real32 AvgDiskSecPerWrite; [read, CounterType(272696320), PropertyContext("Disk Transfers/sec"), DisplayName("Disk Transfers/sec"), Description("Disk Transfers/sec is the rate of read and write operations on the disk.")] real32 DiskTransfersPerSec; [read, CounterType(272696320), PropertyContext("Disk Reads/sec"), DisplayName("Disk Reads/sec"), Description("Disk Reads/sec is the rate of read operations on the disk.")] real32 DiskReadsPerSec; [read, CounterType(272696320), PropertyContext("Disk Writes/sec"), DisplayName("Disk Writes/sec"), Description("Disk Writes/sec is the rate of write operations on the disk.")] real32 DiskWritesPerSec; [read, CounterType(272696576), PropertyContext("Disk Bytes/sec"), DisplayName("Disk Bytes/sec"), Description("Disk Bytes/sec is the rate bytes are transferred to or from the disk during write or read operations.")] real32 DiskBytesPerSec; [read, CounterType(272696576), PropertyContext("Disk Read Bytes/sec"), DisplayName("Disk Read Bytes/sec"), Description("Disk Read Bytes/sec is the rate bytes are transferred from the disk during read operations.")] real32 DiskReadBytesPerSec; [read, CounterType(272696576), PropertyContext("Disk Write Bytes/sec"), DisplayName("Disk Write Bytes/sec"), Description("Disk Write Bytes is rate bytes are transferred to the disk during write operations.")] real32 DiskWriteBytesPerSec; [read, CounterType(542573824), PropertyContext("% Idle Time"), DisplayName("% Idle Time"), Description("% Idle Time reports the percentage of time during the sample interval that the disk was idle.")] real32 PercentIdleTime; [read, CounterType(272696320), PropertyContext("Split IO/Sec"), DisplayName("Split IO/Sec"), Description("Split IO/Sec reports the rate that I/Os to the disk were split into multiple I/Os. A split I/O may result from requesting data in a size that is too large to fit into a single I/O or that the disk is fragmented.")] real32 SplitIOPerSec; }; //************************************************************************* //* Instances of: PhysicalDisk //************************************************************************* instance of PhysicalDisk { AvgDiskQueueLength = 0.1049272; AvgDiskReadQueueLength = 0; AvgDiskSecPerRead = 0; AvgDiskSecPerTransfer = 5.24653E-03; AvgDiskSecPerWrite = 5.24653E-03; AvgDiskWriteQueueLength = 0.1049272; CurrentDiskQueueLength = 0; DiskBytesPerSec = 10350.89; DiskReadBytesPerSec = 0; DiskReadsPerSec = 0; DiskTransfersPerSec = 20.21658; DiskWriteBytesPerSec = 10350.89; DiskWritesPerSec = 20.21658; Name = "_Total"; PercentDiskReadTime = 0; PercentDiskTime = 10.49272; PercentDiskWriteTime = 10.49272; PercentIdleTime = 88.41473; SplitIOPerSec = 0; }; //* EOF SampleMOF.mof Performance Counters
Because you may want to access other performance counters in addition to those exposed by the Application Center user interface, this is a good point to examine performance counters.
NOTE
Performance counters are accessed and manipulated via direct communications between Application Center and the Performance Data Helper (PDH) interface in order to achieve performance gains.
The Performance Data Helper
In order for a program to utilize the Windows performance feature set and library, it has to use the functions that the registry interface provides. These functions retrieve blobs of data from the key HKEY_PERFORMANCE_DATA, which contains performance information. In order to use this data—which is to say, convert it to human usable form—it's necessary to traverse the existing data structure, and then apply calculations against the raw data to produce usable counter information.
The Performance Data Helper (PDH) library is built on top of the standard performance monitoring features provided by Windows. Through its APIs the PDH Library supplies an interface that is essentially a higher-level abstraction of the registry interface's functionality. However, the PDH functions can use either the registry interface or WMI. In the latter case the PDH functions obtain data through providers that use performance extension DLLs or the high-performance data provider object.
NOTE
The PDH is oriented more towards operations on single counters rather than groups of counters.
The PDH packages the data in a form that doesn't require any traversal of the data structure. Additionally, it applies the appropriate statistical calculations to each counter.
Windows Performance Data Collection
The performance data that Windows 2000 collects is described in terms of objects, counters, and instances. A performance object is any resource, application, or service that can be measured.
Each performance object has performance counters that are used to measure various aspects of performance, such as transfer rates for disks or the amount of processor time consumed for processors. The object may also have an instance, which is a unique copy of a particular object type (not all object types support multiple instances).
An instance called _Total instance, which is available on most objects, represents the sum of the values for all instances of the object for a specific counter.
Counter Types
Every counter is assigned a counter type, which determines how counter data is calculated, averaged, and displayed.
NOTE
The Windows performance console supports more than 30 counter types, but many of the available counter types are not implemented in the counters installed with Windows 2000.
Counter types are described in the following manner:
- Counter type name—the name of the counter type.
- Description—a brief description of the counter type, including a description of the formula used to calculate and display counters of the specified type.
- Generic type—the general category that represents the display format counter. Generic types include:
- Average. These counters measure a value over time and display the average of the last two measurements.
- Difference. These counters subtract the last measurement from the previous one and, if the measurement is positive, they display the difference; if negative, they display a zero.
- Instantaneous. These counters display the most recent measurement.
- Percentage. These counters display calculated values as a percentage.
- Rate. Similar to an average counter, these counters sample an increasing count of events over time and divide the cache in count values by the change in time to display a rate of activity.
- Formula—describes how the raw data and other components, such as performance frequency, are converted to arrive at the formatted counter value for display in the console.
- Average—the mathematical formula used to calculate averages of the formatted counter data.
Operating System Counters
The Windows 2000 operating system provides a collection of more than 70 performance objects, each with its own set of counters. The Memory object, which is described in Table 7.5, provides one of the counters that you can access through the Application Center user interface.
The Memory performance object consists of 29 counters that describe the behavior of physical and virtual memory on the computer. Physical memory is the amount of RAM on the computer, whereas virtual memory consists of space in physical memory and on disk. Table 7.5, extracted from the Windows 2000 SDK documentation, provides a summary of the Available Bytes counter for the Memory object.
Table 7.5 Example of a Windows 2000 Performance Counter
| Counter name | Description | Counter type |
|---|---|---|
| Available Bytes | Shows the amount of physical memory, in bytes, available to processes running on the computer. It is calculated by adding the amount of space on the zeroed, free, and standby memory lists. Free memory is ready for use. Zeroed memory consists of pages of memory filled with zeros to prevent later pro- cesses from seeing data used by a pre- vious process. Standby memory is memory that has been removed from a process's working set (its physical memory) en route to disk, but is still available to be recalled. | PERF_COUNTER_RAWCOUNT |
The counter type for the Available Bytes counter is PERF_COUNTER_RAWCOUNT, which is described in Table 7.6.
Table 7.6 Performance Counter Type Description
| Element | Comment |
|---|---|
| Description | Shows the last observed value only. It does not display an average. |
| Generic type | Instantaneous |
| Formula | None; shows raw data as collected. |
| Average | SUM (n) / x |
| Example | Memory\available bytes |
Feature Counters
Some Windows 2000 features or services install one or more performance objects to measure the activity of the feature or service. Table 7.7 summarizes the list of features or services and their corresponding performance objects.
Table 7.7 Windows 2000 Feature/Service Performance Objects
| Feature or service | Performance object |
|---|---|
| Internet Information Service 5.0 (IIS) | ASP pages, FTP Service, Web Service, Internet Information Services Global |
| Indexing Service | Indexing Service, Indexing Service Filter, HTTP Indexing Service |
| Message Queuing | MSMQ Session, MSMQ IS, MSMQ Queue, MSMQ Service |
| Quality of Service (QoS) Admission Control | ACS/RSVP Service, ACS/RSVP Interfaces, ACS/RSVP Policy |
| Routing and Remote Access (RRAS) | RAS Port, RAS Total |
| File Replication Service | File ReplicaConn, FileReplicaSet |
| Terminal Service | Terminal Services Session |
| Active Directory | NTDS |
EAN: N/A
Pages: 183