This chapter is from the book
This chapter is from the book
This chapter is from the book
A WMI Primer
If the SQL Server database is the heart of ConfigMgr, consider WMI its lifeblood. WMI has been the core management infrastructure for all Windows desktop and server operating systems beginning with Windows 2000. WMI is the Windows implementation of Web-Based Enterprise Management (WBEM). WBEM is a set of standards intended to provide the basis for cross-platform interoperability of technologies to exchange management data and access management interfaces across distributed computing environments.
The Distributed Management Task Force (DMTF) supports WBEM. This group is an industry consortium created to promote standardization and integration of enterprise and Internet management technology. For more information about WBEM in general and the DMTF, see http://www.dmtf.org/standards/wbem. Although much of the architectural material in this chapter is common to all implementations of WBEM, the next sections exclusively focus on WMI and its role in ConfigMgr:
- WMI architecture: This includes describing the WMI feature set, reviewing the major components of WMI, and discussing how they interact.
- WMI object model: The WMI object model and its implementation are discussed, with several tools you can use to manage WMI and look into its inner workings.
- ConfigMgr use of WMI: Configuration Manager’s use of WMI is discussed, with examples of how you can look inside ConfigMgr through its WMI interfaces.
WMI Feature Set and Architecture
WMI makes it much easier to write programs and scripts that interact with local resources on Windows systems. WMI serves as an abstraction layer between management applications and scripts and the physical and logical resources they manage. WMI exposes managed resources through a COM (Component Object Model) API (application programming interface). Programs written in C/C++ can call these resources directly, or you can access them through intermediate layers by applications such as scripts, Windows forms, or web forms. WMI presents a consistent and extensible object model to represent a wide variety of system, network, and other resources. Here are some examples of what you can do with WMI:
- Rename the built in administrator account.
- Compile a list of printers that support color printing.
- Receive an alert each time a new device connects to a USB port.
Using an object model removes much of the complexity that would otherwise be required to access and manipulate these resources. Some examples of resources you can manage through WMI include hardware devices, running processes, the Windows file system and registry, and applications and databases.
Here are several ways you can invoke WMI services:
- Locally on a machine
- Remotely through a DCOM (Distributed COM) connection
- Remotely using a WS-Management (Web Services for Management) connection
WS-Management is a SOAP (Simple Object Access Protocol)–based specification published by the DMTF. SOAP is a standard for invoking objects remotely over an HTTP (Hypertext Transfer Protocol) or HTTPS (Hypertext Transfer Protocol over Secure Socket Layer) connection. The main advantage of SOAP is that it works across many existing network firewalls without requiring additional configuration. You can find a complete description of WS-Management and related specifications at http://www.dmtf.org/standards/wsman.
WMI supports requests from management applications to
- Retrieve or modify individual data items (properties) of managed objects.
- Invoke actions (methods) supported by managed objects.
- Execute queries against the data set of managed objects.
- Register to receive events from managed objects.
Here is how WMI handles requests from management applications:
- Management applications submit a request to the WMI infrastructure, which passes the request to the appropriate provider. The next section describes WMI providers.
- The provider then handles the interaction with the actual system resources and returns the resulting response to WMI.
- WMI passes the response back to the calling application. The response may be actual data about the resource or the result of a requested operation.
Figure 3.8 shows the basic data flow in WMI.
)
Figure 3.8. How WMI accepts a request from a management application and returns a response from a managed resource.
WMI Providers
WMI providers are analogous to device drivers in that they know how to interact with a particular resource or set of resources. In fact, many device drivers also act as WMI providers. Microsoft supplies several built-in providers as part of Windows, such as the Event Log provider and File System provider. You will see providers implemented in the following ways:
- As DLLs (Dynamic Link Libraries)
- As Windows processes and services
Just as the WMI infrastructure serves management applications through a COM interface, providers act as COM servers to handle requests from the WMI infrastructure. When a provider loads, it registers its location and the classes, objects, properties, methods, and events it provides with WMI. WMI uses this information to route requests to the proper provider.
The WMI Infrastructure
Figure 3.9 displays the main logical components of the WMI infrastructure. The core of the WMI infrastructure is the Common Information Model Object Manager (CIMOM), described in the “Inside the WMI Object Model” section. CIMOM brokers requests between management applications and WMI providers, and communicates with management applications through the COM API, as described earlier in the “WMI Feature Set and Architecture” section. CIMOM also manages the WMI repository, an on-disk database used by WMI to store certain types of data. Beginning with Windows XP, WMI also includes an XML (eXtensible Markup Language) encoder component, which management applications and scripts can invoke to generate an XML representation of managed objects.
)
Figure 3.9. The major WMI infrastructure components.
Most files used by WMI are stored on the file system by default under the %windir%\System32\Wbem folder. The WMI repository is a set of files located by default under %windir%\System32\Wbem\Repository. The exact file structure varies slightly depending on the Windows version. WMI uses a customized version of the Jet database engine to access the repository files.
The executable containing the WMI service components is Winmgmt.exe. The physical implementation of the WMI infrastructure varies, depending on the version of Windows. In Windows 2000, Winmgmt runs as a separate Windows service. In this implementation, WMI providers are loaded into the Winmgmt process space, which means that a fault in one provider can crash the entire WMI process. This can cause repository corruption, which is a common cause of WMI problems in earlier Windows implementations. Using a single process space also means that providers share the security context of the Winmgmt process, which is generally the highly privileged Local System account. Newer versions of Windows achieve greater process isolation by loading providers into one or more instances of WMIPrvse.exe. All WMI service components beginning with Windows XP run inside shared service host (SVCHOST) processes. Beginning with Windows Vista, Microsoft introduced several significant enhancements in WMI security and stability, including the ability to specify process isolation levels, security contexts, and resource limits for provider instances. These enhancements are also available as an update for Windows XP and Windows Server 2003 systems at http://support.microsoft.com/kb/933062.
Configuration parameters for the WMI service are stored in the system registry subtree HKEY_LOCAL_MACHINE\Software\Microsoft\WBEM. The keys and values in this section of the registry specify WMI file locations, logging behavior, the list of installed provider, the default namespace for script, and other WMI options. You will rarely need to edit these options directly. As with any modification of the registry, you should use extreme caution as changes to the registry can destabilize your system.
WMI also provides detailed logging of its activities. Prior to Windows Vista, log entries were written in plain text to files in the %windir%\System32\Wbem\logs folder. In Windows Vista, Windows 7, and Windows Server 2008 and 2008 R2, most of these logs no longer exist, and Windows Event Tracing makes log data available to event data consumers, including the Event Log Service. By default, event tracing for WMI is not enabled. The “Managing WMI” section discusses logging and event tracing options for WMI and describes how to configure tracing for WMI.
Some WMI providers, such as the ConfigMgr provider, also log their activity. The “Viewing Detailed Process Activity” section discusses logging by the ConfigMgr WMI provider.
Inside the WMI Object Model
Understanding the WMI object model is essential if you will write programs or scripts that interact with WMI. It is also helpful for ConfigMgr administrators who want a better understanding of ConfigMgr objects such as collections and client settings. The DMTF’s Common Information Model (CIM) is the basis for the WMI object model. CIM defines a core model that provides the basic semantics for representing managed objects and describes several common models representing specific areas of management, such as systems, networks, and applications. Third parties develop extended models, which are platform platform-specific implementations of common classes. You can categorize the class definitions used to represent managed objects as follows:
- Core classes represent general constructs that are applicable to all areas of management. The Managed Element class is the most basic and general class and is at the root of the CIM class hierarchy. Other examples of core classes include
- Component
- Collection
- CIM_StatisticalInformation
Core classes are part of the core model and are the basic building blocks from which other classes are developed.
- Common classes represent specific types of managed objects. Common classes are generalized representations of a category of objects, such as a computer system or an application. These classes are not tied to a particular implementation or technology.
- Extended classes are technology-specific extensions of common classes, such as a Win32 computer system or ConfigMgr.
WMI classes support inheritance, meaning you can derive a new class from an existing class. The derived class is often referred to as a child or subclass of the original class. The child class has a set of attributes available to it from its parent class. Inheritance saves developers the effort of needing to create definitions for all class attributes from scratch. Developers of a child class can optionally override the definition of an inherited attribute with a different definition better suited to that class. A child class can also have additional attributes not inherited from the parent.
Typically, core and common classes are not used directly to represent managed objects. Rather, they are used as base classes from which other classes are derived. The “Looking Inside the CIMV2 Namespace” section of this chapter presents an example of how a class inherits attributes from its parent class.
A special type of WMI class is the System class. WMI uses system classes internally to support its operations. They represent things such as providers, WMI events, inheritance metadata about WMI classes, and more.
WMI classes support three types of attributes:
- Properties are the characteristics of the managed objects, such as the name of a computer system or the current value of a performance counter.
- Methods are actions that a managed object can perform on your behalf. As an example, an object representing a Windows service may provide methods to start, stop, or restart the service.
- Associations are actually links to a special type of WMI class, an association class, which that represents a relationship between other objects. The “Looking Inside the CIMV2 Namespace” section examines the associations that link a file share security descriptor to the share and to the security principals specified in its access control lists.
You can also modify WMI classes, properties, and methods by the use of qualifiers. A qualifier on a class may designate it as abstract, meaning the class is used only to derive other classes and no objects of that class will be created. Two important qualifiers designate data as static or dynamic:
- Static data: Supplied in the class or object definition and stored in the WMI repository
- Dynamic data: Accessed directly through the provider and represents live data on the system
The CIM specification also includes a language for exchanging management information. The Managed Object Format (MOF) provides a way to describe classes, instances, and other CIM constructs in textual form. In WMI, MOF files are included with providers to register the classes, properties, objects, and events they support with WMI. The information in the MOF files is compiled and stored to the WMI repository. Examples of information in MOF format are included in the next section.
Namespaces organize WMI classes and other elements. A namespace is a container, much like a folder in a file system. Developers can add objects to existing namespaces or create new namespaces. The Root namespace defines a hierarchy organizing the namespaces on a system. The “Managing WMI” section describes the WMI Control tool, which allows you to specify the default namespace for connections to WMI. Generally, the default namespace will be Root\CIMV2. This namespace defines most of the major classes for Windows management. The next section looks at several classes in that namespace. Because ConfigMgr is all about Windows management, it is not surprising that it uses this namespace extensively. ConfigMgr also defines its own namespaces, discussed in the “Looking Inside Configuration Manager with WMI” section.
If you are familiar with relational databases such as SQL Server, you may find it useful to consider an analogy between WMI and a database system. Table 3.2 presents some corresponding WMI and database concepts.
Table 3.2. Analogous WMI and Database Concepts
|
WMI Concept |
Database Concept |
|
WMI Infrastructure |
Database Engine |
|
Namespace |
Database |
|
Class |
Table |
|
Instance |
Row |
|
Attribute |
Column |
This section presented the major concepts of WMI and the CIM model, which are essential to understanding ConfigMgr WMI activity. If you are interested in learning about other aspects of CIM, a good place to start is the tutorial at http://www.wbemsolutions.com/tutorials/CIM/index.html. The full CIM specification can be found at http://www.dmtf.org/standards/cim. Documentation for WMI is available at http://msdn.microsoft.com/en-us/library/aa394582.aspx.
Managing WMI
This section is intended to illustrate the options available for configuring WMI rather than being a “how-to” guide to administering WMI. You will rarely need to modify the WMI settings directly during day-to-day ConfigMgr administration. However, understanding the available options can help you understand the inner workings and functionality of WMI.
The Windows WMI Control is a graphical tool for managing the most important properties of the WMI infrastructure. Only members of the local Administrators group can use the WMI Control. To run this tool, perform the following steps:
- Launch the Computer Management MMC snap-in. The exact procedure will vary depending on the version of Windows you are running. Generally you can right-click Computer or My Computer, and choose Manage.
- Expand the Services and Applications node in the tree pane. For server operating systems, expand the Configuration node.
- Right-click WMI Control and choose Properties.
The WMI Control opens to the General tab. As shown in Figure 3.10, the General properties confirm you have successfully connected to WMI on the local machine, display some basic properties of your system, and specify the installed version of WMI.
)
Figure 3.10. The General tab of the WMI Control showing a successful connection to WMI on the local machine.
You can manage WMI security from the Security tab of the WMI Control tool. WMI uses standard Windows access control lists (ACLs) to secure each of the WMI namespaces that exist on your machine. A namespace, as described more precisely in the “Inside the WMI Object Model” section of this chapter, is a container that holds other WMI elements. The tree structure in the Security tab shows the WMI namespaces, as displayed in Figure 3.11.
)
Figure 3.11. The Security tab of the WMI Control tool, displaying the top-level WMI namespaces.
The namespace is the most granular level in which to apply ACLs in WMI. The process of setting security on WMI namespaces, and the technology behind it, is very similar to the process of setting NTFS (NT File System) security. If you click a namespace to select it and click Security, you see a dialog box similar to the one displayed in Figure 3.12.
)
Figure 3.12. The WMI Security dialog box for the CCM namespace (the root namespace of the ConfigMgr client).
The dialog box in Figure 3.12 allows you to add security principals to the discretionary ACL (DACL) of the WMI namespace. The DACL specifies who can access the namespace and the type of access they have. With Windows XP and earlier operating systems, this was the only namespace access control implemented in WMI. Beginning with Windows Vista, enhancements to WMI, mentioned previously in the “WMI Feature Set and Architecture” section, added a system access control list (SACL) for WMI namespaces. The SACL specifies the actions audited for each security principal.
)
Figure 3.13. Specifying a user, computer, or group for WMI control security.
To specify auditing on a WMI namespace, follow these steps:
- From the Security dialog box, as shown in Figure 3.12, click the Advanced button.
- In the Advanced Security Settings dialog box, click the Auditing tab.
- Click the Add button and then enter the name of the user, group, or built-in security principal (see Figure 3.13). Click OK.
- Complete the selections in the Auditing Entry dialog box, and click OK.
Figure 3.14 shows the entries to enable auditing for all access failures by members of the CM12 Servers group.
)
Figure 3.14. The WMI Auditing Entry dialog box displaying auditing enabled for all access failures by members of the ConfigMgr Site Servers group.
The remaining tabs of the WMI Control tool allow you to change the default namespace for WMI connections, and provide one of several methods of backing up the WMI repository. Windows system state backups also back up the repository. Prior to Windows Vista, the WMI Control tool also contained a Logging tab that allowed you to specify verbose, normal, or no logging, as well as choose the WMI log location and maximum log size. In Windows Server 2008, Windows Server 2008 R2, Windows Vista, and Windows 7, you can enable logging and configure log options in the Windows Event Viewer. To enable WMI Trace Logging in these versions of Windows, perform the following steps:
- Open Event Viewer.
- On the View menu, select Show Analytic and Debug Logs.
- In the tree control, expand Applications and Service Logs -> Microsoft -> Windows -> WMI Activity.
- Right-click Trace and then select Enable Log from the context menu. Choosing Properties from the same menu allows you to configure logging properties for WMI. You can now view, filter, and manage the WMI log from this node in the Event Viewer tree.
You can read more about WMI logging at http://msdn.microsoft.com/en-us/library/aa394564.aspx.
You should be aware that User Account Control, first introduced in Windows Vista, applies to privileged WMI operations. This can affect some scripts and command-line utilities. For a discussion of User Account Control and WMI, see http://msdn.microsoft.com/en-us/library/aa826699.aspx.
Additional command-line tools are available for managing WMI, which you can download from http://msdn.microsoft.com/en-us/library/aa827351.aspx. These tools include a MOF compiler, a command-line tool for performing WMI operations, and more. Another great resource for working with WMI is the WMI Diagnosis Utility (WMIDiag). WMIDiag is a Visual Basic script that tests the WMI functionality on the system and repairs many WMI problems. You can obtain the WMIDiag from the Microsoft download site (http://www.microsoft.com/en-us/download/details.aspx?id=7684), or go to www.microsoft.com/downloads and search for WMIDiag. The WMI Diagnosis Utility documentation provides a wealth of information about WMI.
Looking Inside the CIMV2 Namespace
Windows provides a basic tool called WBEMTest that allows you to connect to a WMI namespace and execute WMI operations. However, there are a number of tools from Microsoft and third parties with more intuitive graphical interfaces for displaying and navigating WMI namespaces. This section uses the Microsoft WMI Administrative Tools to look into the Root\CIMV2 namespace. These tools include the WMI CIM Studio and the WMI Object Browser. To download the latest WMI Administrative Tools, search for WMITools at www.microsoft.com/downloads. After downloading, run the WMITools.exe executable file to install the tools.
You can use CIM Studio to explore the classes in a namespace and view the properties, methods, and associations of each class. Perform the following steps to launch CIM Studio and connect to the CIMV2 namespace:
- Select Start -> All Programs -> WMI Tools -> WMI CIM Studio.
- CIM Studio opens a web browser and attempts to run an ActiveX control.
- If your browser blocks the control, select the option Allow Blocked Content.
- Verify that root\CIMV2 displays in the Connect to namespace dialog box and then click OK. Notice that you can also browse to other namespaces on the local computer or a remote computer.
- Click OK to accept the default logon settings.
When you open CIM Studio and connect to a namespace, the Class Explorer in the left pane contains a tree structure that displays the base classes in the selected namespace. Figure 3.15 displays the left pane with some of the root classes of the CIMV2 namespace.
)
Figure 3.15. The root classes of the CIMV2 namespace displayed in CIM Studio.
Notice that most of the class names in Figure 3.15 begin with CIM or Win32. Class names starting with CIM indicate that the class is one of the core or common classes defined in the DMTF CIM schema. Classes with names beginning with Win32 are those extended classes that are part of the Win32 schema defined by Microsoft for managing the Win32 environment.
The Win32_LogicalShareSecuritySetting Class
This section uses the Win32_LogicalShareSecuritySetting class to illustrate how you can use CIM Studio to understand a class of managed objects. Figure 3.16 shows the Win32_LogicalShareSecuritySetting class displayed in CIM Studio. This class represents the security settings on a Windows file share. The expand tree shows the root class, CIM_Setting, and the classes derived from each successive subclass.
)
Figure 3.16. The Win32_LogicalShareSecuritySetting class displayed in CIM Studio.
Looking at the tree structure, you can see that Win32_LogicalShareSecuritySetting is derived from Win32_SecuritySetting, which in turn is derived from CIM_Setting. The Class View in the right pane displays the properties of the Win32_LogicalShareSecuritySetting class. To the left of each property name, you will see one of the following icons:
- A yellow downward-pointing arrow indicates the property is inherited from the parent class.
- A property page indicates the property is defined within the class.
- A computer system indicates that the property is a system class. You can also recognize system classes by their names, which always start with a double underscore (__).
For example, each WMI class has certain System properties, such as __PATH, __DYNASTY, __SUPERCLASS, and __DERIVATION. Here are some points to keep in mind:
- The __PATH property shows the location of the class in the namespace hierarchy. Management applications and scripts use the __PATH property to connect to the class.
- __DYNASTY, __SUPERCLASS, and __DERIVATION are all related to class inheritance and represent the root class from which the class is derived its immediate parent, and the entire family tree of the class, respectively.
Clicking the Array button next to __DERIVATION displays the array of parent classes from which the class is derived. The array is essentially the inheritance information already observed by traversing the tree, as shown in Figure 3.17.
)
Figure 3.17. The array of classes from which the Win32_LogicalShareSecuritySetting class is derived, as displayed in CIM Studio.
The remaining properties of Win32_LogicalShareSecuritySetting are the ones that actually represent characteristics describing instances of Windows file share security settings. You can see that except for the name, all these properties are inherited. An object that has nothing unique about it except its name would not be very interesting, but there is more to the Win32_LogicalShareSecuritySetting class than the class properties. The most interesting attributes of Win32_LogicalShareSecuritySetting are on the remaining tabs of the CIM Studio Class View pane.
Clicking the Methods tab displays the two methods (GetSecurityDescriptor and SetSecurityDescriptor) of the Win32_LogicalShareSecuritySetting class, as shown in Figure 3.18.
)
Figure 3.18. The Win32_LogicalShareSecuritySetting class methods, displayed in CIM Studio, allow management applications to retrieve or modify security on file shares.
Getting Additional Information
These methods let you work with the permissions on the actual file share. Clicking the Help button on the toolbar in the upper-right corner of Class View in Figure 3.18 provides additional information about the class.
Putting It All Together
The Win32_LogicalShareSecuritySetting example in the “A Sample Help Entry” sidebar shows that the GetSecurityDescriptor method returns the current security descriptor of the file share as an object of type Win32_SecurityDescriptor. The SetSecurityDescriptor method accepts a Win32_SecurityDescriptor object as input and replaces the security descriptor on the share with information supplied in the security descriptor object. The example also lists the status codes returned by these methods.
The information on the Class View Associations tab, shown in Figure 3.19, provides the key to understanding the implementation of Win32_LogicalShareSecuritySetting.
)
Figure 3.19. The Win32_LogicalShareSecuritySetting class associations, displayed here in CIM Studio, link the share security setting’s objects to objects representing the share and the share’s ACL entries.
The Win32_LogicalShareSecuritySetting Associations tab (refer to Figure 3.19) displays an association with the Win32_Share class as well as associations with the two instances of the Win32_SID class. Class icons marked with a diagonal arrow represent the association classes linking other classes together. If you hover your mouse cursor over the Class icons for each of the association classes linking Win32_LogicalShareSecuritySetting to Win32_SID class instances, you can see that one is a Win32_LogicalShareAccess class instance and the other is a Win32_LogicalShareAuditing class instance.
- Instances of the Win32_LogicalShareAccess association represent access control entries (ACEs) in the DACL (that is, share permissions).
The Win32_LogicalShareAuditing instances represent ACEs in the SACL (audit settings) on the share. You can double-click any of the classes shown on this tab to navigate to it in Class View.
Because objects of the Win32_LogicalShareSecuritySetting class allow you to work with live data on the system, you would expect this to be a dynamic class. You can verify this by returning to the Properties or Methods tab, right-clicking any attribute, and selecting Object Qualifiers. The Win32_LogicalShareSecuritySetting object qualifiers are shown in Figure 3.20, including the dynamic qualifier, which is of type boolean with a value of true.
Figure 3.20. The Win32_LogicalShareSecuritySetting class qualifiers displayed in CIM Studio.
)
From the Class View, you can also use the Instances button to display all instances of the class, and you can open the properties of an instance by double-clicking it. The “Hardware Inventory Through WMI” section discusses how to use another of the WMI Administrative Tools, the WMI Object Browser, to view class instances. Just above the toolbar are icons that launch the MOF generator and MOF compiler wizards, as shown earlier in Figure 3.16. To launch the MOF compiler, you must check the Class icon next to the class and double-click the Wizard icon. The MOF language defining the Win32_LogicalShareSecuritySetting class is as follows:
#pragma namespace("\\\\.\\ROOT\\CIMV2")
//**************************************************************************
//* Class: Win32_LogicalShareSecuritySetting
//* Derived from: Win32_SecuritySetting
//**************************************************************************
[dynamic: ToInstance, provider("SECRCW32"): ToInstance, Locale(1033): ToInstance,
UUID("{8502C591-5FBB-11D2-AAC1-006008C78BC7}"): ToInstance]
class Win32_LogicalShareSecuritySetting : Win32_SecuritySetting
{
[key, read: ToSubClass] string Name;
[Privileges{"SeSecurityPrivilege", "SeRestorePrivilege"}: ToSubClass,
implemented, ValueMap{"0", "2", "8", "9", "21", ".."}]
uint32 GetSecurityDescriptor([OUT] Win32_SecurityDescriptor Descriptor);
[Privileges{"SeSecurityPrivilege", "SeRestorePrivilege"}: ToSubClass,
implemented, ValueMap{"0", "2", "8", "9", "21", ".."}]
uint32 SetSecurityDescriptor([IN] Win32_SecurityDescriptor Descriptor);
};
The first line of the MOF entry, #pragma namespace ("\\\\.\\ROOT\\CIMV2"), is a preprocessor command instructing the MOF compiler to load the MOF definitions into the Root\CIMV2 namespace. A comment block follows, which indicates the class name Class: Win32_LogicalShareSecuritySetting and the class derivation Derived from: Win32_SecuritySetting. Next is a bracketed list of object qualifiers:
- The dynamic qualifier indicates that the class is dynamic and will be instantiated at runtime.
- The provider qualifier specifies that the instance provider is SECRCW32.
- The locale qualifier indicates the locale of the class, 1033 (U.S. English).
- The UUID qualifier is a Universally Unique Identifier for the class.
Each of these qualifiers propagates to class instances, as indicated by the toinstance keyword. Refer to Figure 3.20 to see a GUI representation of the object qualifiers.
The next section contains the class declaration Win32_LogicalShareSecuritySetting : Win32_SecuritySetting. This declaration derives the Win32_LogicalShareSecuritySetting class from the Win32_SecuritySetting base class. The body of the class declaration declares locally defined class properties and methods. The Name property (the name of the share) is declared to be of type String and designated as a key value, indicating that it uniquely identifies an instance of the class. The GetSecurityDescriptor and SetSecurityDescriptor methods are both of type uint32, indicating that each method return an unsigned 32-bit integer. GetSecurityDescriptor has an output parameter of type Win32_SecurityDescriptor, whereas SetSecurityDescriptor has a corresponding input parameter of the same type. Immediately preceding each of these method definitions, you will see the following method qualifiers specified:
- Privileges requests the access privileges required to manipulate Win32 security descriptors.
- Implemented is a Boolean value indicating the method is implemented in the class.
- Valuemap specifies the method’s return values. The “A Sample Help Entry” sidebar lists the meaning of each of these values.
In addition to the locally implemented properties and qualifiers, the Win32_LogicalShareSecuritySetting class inherits properties and qualifiers defined as part of its parent class, Win32_SecuritySetting.
Before continuing, you may want to explore several other classes in the Root\CIMV2 namespace:
- Work your way up the inheritance tree from the Win32_LogicalShareSecuritySetting class and see where each of the inherited properties of the class originates. In addition, notice that if you bring up the object qualifiers on the parent classes, you can see these are qualified as abstract classes.
- The immediate sibling of the Win32_LogicalShareSecuritySetting class is the Win32_LogicalFileSecuritySetting class. Notice the differences in the properties and associations for this class. Share security and file security have many characteristics in common but a few important differences. Seeing how they are both derived from the Win32_SecuritySetting class demonstrates the power and flexibility of class inheritance.
- Expand the CIM_StatisticalInformation root class and then the Win32_Perf class. The two branches of Win32_Perf show how a variety of performance counters are implemented as managed objects.
This section looked at several of the default classes in the Root\CIMV2 namespace and discussed how to use CIM Studio to explore a WMI namespace. The “WMI in ConfigMgr” section describes how ConfigMgr uses the classes in Root\CIMV2 and as well as its own namespaces and classes.