WMI script entry: second part

xiaoxiao2021-03-06 58

Release Date: 09/06/2004 | Update Date: 09/06/2004

Greg Stemp, Dean Tsaltas, Bob Wells, Microsoft Corporation, My.Settings, My.user and My.Webservices

Ethan Wilansky Network Design Group

Summary: Scripting guys Continued their discussion to write WMI scripts, which focuses on the CIM repository and CIM classes to help you use all powerful features of WMI scripts.

If you want to build a house, you need to know how to read and explain the architectural chart. If you want to make an electronic appliance, you need to know how to read and explain the diagram. So if you want to write a WMI script, you guessed it, you need to know how to explain WMI's blueprint-CIM repository for management. The CIM repository, also known as the WMI repository in the WMI SDK, is a WMI architecture that stores a class definition of the modeling WMI hosted resource.

In order to emphasize the importance of CIM and CIM classes, carefully consider entry in WMI scripts: 4 scripts displayed in the first part, and list 1 and Listing 2 below. Listing 1 is a slightly enhanced version from the first part of the service script, and Listing 2 is another variant of the same script using the Win32_OperatingSystem class.

Note If you have doubts about Listing 1 and 2, we recommend that you read (or re-read) the first part of this series.

Listing 1: Search service information using WMI and VBScript

Strcomputer = "." 'Dot (.) Equals Local Computer In WMI

Set objwmiservice = getObject ("WinMgmts: //" & struser)

Set colservices = objwmiservice.instancesof ("Win32_Service")

For Each ObjService in colservices

Wscript.echo "name:" & objService.name & vbcrlf & _

Display Name: "& objService.DisplayName & VBCRLF & _

"Description:" & objService.Description & Vbcrlf & _

"Path Name:" & objService.pathname & Vbcrlf & _

"START MODE:" & objService.Startmode & Vbcrlf & _

"State:" & objService.State & Vbcrlf

Listing 2: Retrieve operating system information using WMI and VBScript

StrComputer = "."

Set objwmiservice = getObject ("WinMgmts: //" & struser)

Set coloperatingsystems = objWMiservice.instancesof ("Win32_OperatingSystem")

For Each ObjoperatingSystem in coloperatingsystemswscript.echo "name:" & objoodativesystem.name & vbcrlf & _

"CAPTION:" & objoteingsystem.caption & vbcrlf & _

"CurrentTimezone:" & objoodativesystem.currenttimezone & vbcrlf & _

"Lastbootuptime:" & objoodativesystem.lastbootuptime & vbcrf & _

"LocalDatetime:" & objoteingsystem.localdatetime & vbcrlf & _

"Locale:" & objoodativesystem.locale & vbcrlf & _

"Manufacturer:" & ObjoperatingSystem.Manufacturer & Vbcrlf & _

"Ostype:" & ObjoperatingSystem. Ostype & Vbcrlf &_

"Version:" & objoteingsystem.version & vbcrlf & _

Service Pack: "& ObjoperatingSystem.ServicePackmajorversion & _

"." & objoodativesystem.servicePackminorversion & VBCRLF & _

"Windows Directory:" & objoteingsystem.windowsDirectory

Each script in the first part of this series and in Listing 1 and 2, in Listing 1 and 2, the only feature is identifying the class name of the WMI hosting resource and the subset of each class attribute. The same script template can be used to retrieve all physical memory, service, event logging, processes, and operating system information, which proves important roles played in the CIM class in the WMI script. Once you know how to write a script to manage a class of WMI managed resources, you can use the same basic techniques for other managed resources.

Of course, knowing the class name of a hosted resource and the corresponding attributes of this class are only part of this article. Before you can use the WMI script, you need to know more about the structure of the CIM repository and the CIM class. why? We will give two important reasons.

1. Learn how to browse CIM will help you determine computer and software resources exposed via WMI. 2. Learn how to explain the blueprint (class definition) of the hosted resource (class definition) will help you understand the tasks that can be performed on the managed resource.

No matter what WMI tool is used, these two points are established, whether using the WMI script library, WMI command line tool (WMIC.exe), or enterprise management applications, you need to know how to browse CIM and explain the CIM class.

The reason why CIM is not so obvious but equally important is that CIM is an excellent document resource for WMI managed resources. That's right, if you need more information about the WMI class, you can use WMI SDK. However, if you don't need detailed information about the WMI class? Suppose you just want to know if you are running, whether you support a specified class, method, or attribute. So, look at the CIM of the target computer. For example, we are often asked "Why can't the 'join the computer in the TECHNET's script to domain' scripts in Windows 2000?" Answer Yes, because Win32_computerstem class in Windows 2000 (it is WMI used in the script Class) does not support JoIndomainorWorkGroup methods. In the WMI version of Windows XP and Windows Server 2003, the JoIndomainorWorkGroup method is added to the Win32_computersystem class.

So how do you understand or learn it? One way is to use the WMI tool collection listed in the first part. Another more powerful, flexible approach is to use the WMI script library. One of the things that WMI, true cool, you can use the WMI script library to learn WMI. That's right, use the WMI script to retrieve the same method of WMI hosting resources, you can also write WMI scripts to learn about the various interesting details of WMI itself. You can write WMI scripts to list all namespaces and classes in the CIM repository. You can write a script to list all the providers installed on a computer that enables WMI. You can even write the WMI script to search the hosted resource class definition.

Whether you choose an existing tool or create your own tool, you need a basic understanding of the structure of the CIM repository. So, let us start from the place where the first part is stopped, and take a closer understanding of the WMI's management blueprint - CIM repository. In the entire discussion, we will use the WMI script library to explain how to retrieve WMI configuration information and manage resource class definitions.

Manage blueprint

In the first part, we said that the basic idea of WMI is - configuration and management information from different sources can be uniformly represented by an architecture, and the CIM repository is a schema for WMI. The architecture can be imagined as a blueprint or a model that represents a thing existing in the real world. It is like building a model to build a physical structure (for example, a house), and WMI CIM builds a model that constitutes hardware, operating system, and software of the computer. CIM is the data model of WMI.

Note Although the CIM repository can store some data (and it does store), its main purpose is to build a model of the management environment. CIM is not designed for a large number of management information it defined. Instead, most of the data is dynamically retrieved from the WMI provider as needed. One exception is WMI operation data. WMI operation data (for example, named spatial information, provider registration information, managed resource class definition, and permanent event subscription) are stored in the CIM repository.

Figure 1 provides a conceptualized view of the internal structure and organization of a CIM repository. As shown in Figure 1, the CIM uses classes to create a data model. It is undeniable that CIMs are far exceeding 11 of the relationship maps - last time we count about 5,000 on Windows Server 2003. It is important to understand that the CIM repository is a custom WMI hosted environment and a class store for each manageable resource exposed through WMI.

Figure 1 shows three important CIM concepts, you need to understand them to successfully browse and explain the WMI architecture.

1. The CIM repository is divided into multiple namespaces. 2. Each namespace contains a group of one or more classes below: System class, core, and public class and / or extension classes. 3. There are three main types: abstraction, static and dynamic. The abstract class is a template for derived (defined) and non-abstract classes that cannot be used to retrieve an example of managed resources. Static class definitions of physical stored in a CIM repository - the most common is WMI configuration and operational data. Dynamic class is a class that models WMI managed resource modeling from the provider. The fourth type of associated class is also supported. Associated classes are an abstract, static or dynamic class, describe the relationship between two or hosted resources. Don't worry too much about the type of CIM class, we will soon discuss the CIM class type in a more practical environment. Let us see every CIM concept in more detail.

Figure 1: Structured view of the CIM repository - WMI architecture

Note CIM Physics resides in Windows XP and Windows Server 2003 named% systemroot% / system32 / wbem / repository / fs / objects.data file. Windows 2000 and Windows NT 4.0 Service Pack 4 stores CIM in% SystemRoot% / System32 / WBEM / Repository / Cim.rep. In Windows Millennium Edition (ME), Windows 98, and Windows 95 OSR 2.5 operating systems, CIM is stored in% Windir% / System / WBEM / Repository / Cim.rep.

Namespace definition

The CIM class is organized into the namespace. Namespace is the partition mechanism used by CIM, controlling the scope and visibility of managed resource class definitions. Each namespace in CIM contains a logical group that represents a specific technique or a management area. All classes in the namespace must have a unique class name, the class in a namespace cannot be derived from the class in another namespace, which is why you will find the same system, core defined in multiple namespaces. And public categories.

Most of the types of Windows managed resource modeling resident in the root / cimv2 namespace. However, according to the recommendations in Figure 1, root / cimv2 is not the only namespace you need to pay attention to. For example, event logs, performance counters, Windows installer, and Win32 providers store their managed resource class definitions in root / cimv2 namespace. On the other hand, the registry provider stores its class definition in the root / default namespace. In addition, the new Windows Server 2003 DNS provider stores its hosted resource class definition in the root / microsoftDNS namespace.

Name space

So how do name space affect your WMI script? Each WMI script is connected to a named space as part of the initial connection step (last month we briefly discussed), as shown below:

StrComputer = "."

Set WbemServices = getObject ("WinMgmts: //" & strComputer)

As above, if the target namespace is not specified, the script is connected to the namespace identified by the following registry:

HKEY_LOCAL_MACHINE / SOFTWARE / Microsoft / WBEM / Scripting / Default Namespace

The default namespace setting is the WMI script, and the default setting for% PATH% environment variable is the operating system. When you submit a command, the operating system uses% PATH% environment variable to locate the executable file of the command using the% Path% environment variable when you submit a command prompt. If the operating system cannot find this file, an error will occur. Similarly, when you retrieve a hosted resource in the WMI script, if you do not specify a namespace, the CIMOM (WMI service) looks for the blueprint (class definition) of the managed resource in the default namespace. If CIMOM can't find a managed resource class definition in the default namespace, a WBEM_E_INVALID_CLASS (0x80041010) error is generated.

Note Do not confuse the default namespace settings with root / default namespace. They are unrelated unless you set the root / default settings for your default namespace.

Namespace root / CIMv2 is initially configured as script default namespace; however, the default script namespace can be easily changed. Therefore, you should always identify a namespace of a managed resource in your WMI script, not the default setting. If we follow our own suggestions last month, all 4 lists (and the links 1 and 2 of this article) should be written as follows:

StrComputer = "."

SET WBEMSERVICES = GetObject ("WinMgmts: //" & strComputer & "/ root / cimv2")

Add the target namespace to the connection string to tell CIMOM where to find the managed resource class definition in the CIM, very much like the fully qualified path tells the operating system to find a file. When you specify the target namespace, the default namespace is not used.

Manage scripts default namespace

You can use the WMI script library with the Win32_WMisetting class to read and change the default namespace of the script in conjunction with the WMI script library to read and change the script. Win32_wmisetting is a dynamic class modeling for operating parameters for WMI services. The writable attribute indicates that the default namespace of the script is AspscriptDefaultNamespace.

Listing 3 Use the same three WMI scripts to write steps - connection, retrieval, and display - we have been using the steps, but there is a significant change. As mentioned earlier, we specify a fully qualified namespace of the Win32_WMisetting class in the WMI connection string that passes the getObject function of Microsoft Visual Basic Scripting Edition (VBScript). Then, here you will think Microsoft does not follow their own suggestions. Not only do we follow our namespace in Listing 3, but we will define namespaces since then. Yes, if you want to avoid invalidated class errors in your WMI script, it is so important.

Listing 3: In order to use WMI and VBScript, retrieve the default namespace of the script

StrComputer = "."

Set objwmiservice = getObject ("WinMgmts: //" & strComputer & "/ root / cimv2")

Set colwmisettings = objwmiservice.instancesof ("win32_wmisetting")

For Each Objwmisetting in ColWMisettings

WScript.echo "Default Namespace for Scripting:" & _objwmisetting.aspscriptdefaultnamespace

To run the sample script in Listing 3, copy this script and paste into your favorite text editor, save the script (extension .vbs), then run the script as shown in Figure 2. You should see the default namespace of the local computer back to the console.

Figure 2: GetDefaultNameSpace.vbs output

To set the default namespace of the script, perform the same script in Listing 3, but to do an important change - well, if you count the number of questions, you count two. You should use SwbemObject to set the properties of the PUT_ method called SwbemObject to submit the changes to WMI managed resources without reading attributes from the WMI Script Library of SwbemObject from the WMI managed resource. Setting and submitting operations execute within the for Each cycle in Listing 4, because the SwbemServicesInstancesOf method always returns a SwbemObjectset collection, even if there is only one target WMI hosting resource instance, such as Win32_WMisetting.

Listing 4: Set the default namespace for the script with WMI and VBScript settings

StrComputer = "."

Set objwmiservice = getObject ("WinMgmts: //" & strComputer & "/ root / cimv2")

Set colwmisettings = objwmiservice.instancesof ("win32_wmisetting")

For Each Objwmisetting in ColWMisettings

Objwmisetting.aspscriptdefaultnamespace = "root / cimv2"

Objwmisetting.put_

Don't focus too focus on the structure of the WMI script, because we will detail the WMI script library in the third part of this series. Now let's turn your attention back to CIM.

List the namespace

So far, we have used the same WMI script technique to retrieve an instance of dynamic WMI managed resources. For example, in the first part, we use the same script template to retrieve physical memory, services, event logging, and processes. In the second part, we retrieve service, operating system information, and script default namespaces. This shows that you can use the same WMI script technology to retrieve naming space information from the CIM. Like the situation in the hosted resource script, you need the only change to the script to be the target class name.

Name Space Information is stored in a CIM as a static instance of the __namespace class. __Namespace class is an example of a static class type of our previously defined defined. Unlike dynamic WMI managed resources from the provider on-demand, static class instances are stored in the CIM and do not need to be retrieved from the CIM using the WMI provider. Listing 5 Use the __namespace class to retrieve and return to all namespaces directly under the root namespace.

Listing 5: Retrieving CIM namespace using WMI and VBScript

StrComputer = "."

Set objServices = getObject ("WinMgmts: //" & strComputer & "/ root")

Set colnamespaces = objServices.instancesof ("__ namespace") for Each ObjNamespace in colnamespaces

Wscript.echo objnamespace.name

Figure 3 shows the results of running Listing 5 on a Windows Server 2003 computer. The namespace list will vary depending on the different versions of Windows and WMI installed on the target computer.

Figure 3: GetNameSpaces.vbs output

If you may have noticed, Listing 5 does not provide a complete description of all available namespaces on the target computer. It only retrieves and is displayed in a single, specifies the namespace under the namespace. In order to return all namespaces on the local or remote enable WMI, you need to modify the list 5 to recursively connect to and enumerate each namespace. Fortunately, this doesn't want you to imagine it. Especially like the list of lists, we do this for you.

Change Listing 5 to the recursive namespace script shown in Listing 6, mainly including the original scripting body in the subroutine, and providing a mechanism to call the subroutines of each namespace instance retrieved from the CIM. Listing 6 This task is completed by performing the following steps:

1. Listing 6 initializes StrComputer from the name of the target computer. Single point (".") In WMI represents a local computer. You can change the values assigned to the StrComputer to any WMI-enabled computer in the domain where you have managed control. 2. Script calls the recursive subroutine, then passed to the subroutine a string that initializes the namespace to "root". 3. The body of the enumnamespaces subroutine is the same as the list 5, except for an important change. Let us gradually study the subroutines.

1. EnumnameSpaces starts from the value of a single parameter strnamespace from the echo generic routine. The STRNAMESPACE identifies the namespace used in the connection string when the subroutine is called. 2. Use the getObject function in VBScript, and the subroutine is connected to the namespace identified by the Strnamespace parameter identifier of the subroutine. 3. After establishing the WMI service and namespace of the target computer, the subroutine immediately retrieves all namespace instances under the namespace referenced by the StrNameSpace reference. Use the for Each loop, the subroutine immediately enumerates the current connection Namespace instance under namespace. However, it is not simply emitting the name of the namespace, and the name of each sub-name space is connected to the current namespace in the new call to the EnumNameSpaces subroutine. Repeat these subroutine steps until all namespace instances are enumerated.

Listing 6: Retrieve all CIM namespaces using WMI and VBScript

StrComputer = "."

Call Enumnamespaces ("root")

Sub EnumNamespaces (StrnameSpace)

WScript.echo Strnamespace

Set objwmiservice = getObject ("WinMgmts: //" & strcomputer & "& strnamespace)

Set colnamespaces = objwmiservice.instancesof ("__ namespace")

For Each Objnamespace in colnamespaces

Call enumnamespaces (Strnamespace & "/" & objNamespace.name)

End Sub

Figure 4 shows the results of running Listing 6 on the same Windows Server 2003 computer. Figure 4: GetAllNameSpaces.vbs output

Define class classification

As shown in Figure 1 above, there are three universal classes for constructing CIM: systems, cores, and public, and expansions.

System class

The system class is a class that supports internal WMI configuration and operations (for example, namespace configuration, namespace security, provider registration, and event subscriptions and notifications). When browsing the CIM, you can easily identify system classes through two underscores before each system class. For example, the __systemclass, __, and __win32provider classes shown in Figure 1 are system classes. In the previous section, our __namespace classes we study are examples of another system class.

The system class can be abstract or static. Abstract systems are templates for derived other abstract or static system classes. Static system class definitions Physics store WMI configuration and operational data in the CIM repository. For example, the __ Win32Provider system class defines the provider registration information stored in the CIM. CIMOM (WMI Service) uses the provider registration information stored in the CIM to map the request of the dynamic managed resource to the corresponding provider.

As we have previously used the __namespace system class, you can use the same WMI script technology to retrieve the static instance of the system class stored in the CIM. For example, Listing 7 retrieves and displays all the __win32provider instances registered in root / cimv2 namespace.

Listing 7: Retrieve Win32 Provider registered in root / CIMV2 namespace using WMI and VBScript

StrComputer = "."

Set objwmiservice = getObject ("WinMgmts: //" & strComputer & "/ root / cimv2")

Set colwin32providers = objwmiservice.instancesof ("__ win32provider")

For Each Objwin32Provider in ColWin32Providers

Wscript.echo objWIN32Provider.name

Unless you are writing a book about WMI, you are unlikely to use the system class in the WMI script. There is an exception to the WMI monitor script. The WMI monitor script is a script for subscribing to the WMI event. (The event is a real-time notice of WMI hosting resources.) We will discuss WMI event subscriptions and notices in future columns.

Note For those who are inappropriate, three of the most common WMI __event system classes are: __ instancecreationEvent, __ instancemodificationeverent, and __instancedeeletionevent. Although we still discuss them here, you can find sample monitoring scripts that use these system classes in the monitor section of the TechNet Script Center.

Core and public categories

The core and public classes play two roles. First of all, it is also the most important, they show abstract classes - systems and application software developers (such as Microsoft Developers) derive and create specific technologies from these abstract classes. Second, they define all of the special management areas, but they are not limited to special technologies or resources. Distributed Management Task Force (DMTF) Defines and maintains the core and public categories that can be identified by the CIM_ prefix. The four classes starting in CIM_ are core and public classes in Figure 1.

In approximately 275 cores and public cages defined in root / cimv2 namespace, all of them are abstract classes in addition to several exceptions. What does this mean for you? This means you will rarely use the core and public categories (class CIM_-prefixed classes) in the WMI script. why? Because you can't retrieve an instance of an abstract class, the abstract class can only be used as the foundation of the new class. Because 271 in the core and public categories are abstract, they are mainly used by software developers to create specific technical extensions. So, what is the exception? 4 of 275 cores and public categories are not an abstract class. They use the Win32 Provider (CIMWIN32.DLL) to search the dynamic class of the hosted resource instance. Record, these 4 dynamic classes are CIM_DataFile, CIM_DirectoryContainsfile, CIM_ProcessExecutable, and CIM_VideoControllerResolution.

Extension class

Extended class is a specific technical class created by the system and application software developers. The win32_baseservice, win32_systemservices, win32_systemservices, and win32_computersystem classes shown in Figure 1 are Microsoft Extensions. The Microsoft extension class in the root / cimv2 namespace can be identified by the Win32_ prefix. Although so, you should not infer that all Microsoft extensions start with Win32_, because not this. For example, the stdregProv class defined in the root / default namespace is not prefixed in Win32_, although the StdRegProv class is a Microsoft extension class for registry management tasks. Before you ask, we must first say: No, we don't know why the stdregProv class is defined in root / default namespace instead of root / CIMv2.

When we write this article, approximately 463 Win32 expansion classes are defined in the root / cimv2 namespace. In 463 Win32 classes, 68 are abstract classes and the remaining 395 are dynamic classes. What does this mean for you? This means that the extension class is the primary category you will want to use in the WMI script.

Note The class statistics we provide is based on the beta version of Windows Server 2003, and only wants to explain the general CIM concept. Based on individual factors, such as: Windows versions, WMI versions, and installed software, your number will vary.

List of classes

At this point, we will tell you something should not be a big accident. You can write a script to retrieve all classes defined in a namespace. For example, inventory 8 lists all classes defined in the root / cimv2 namespace. However, unlike all the scripts that use the SwbemServicesInstanceSOF method, inventory 8 uses a different method, which is SubClassesof, which is also provided by the SwbemServices object of the WMI script library.

As the name of the method, SubClassesOf returns all subclasses that specify the parent class or namespace (when there is no parent class). Such as instancesof, subclasseSOF returns all subclasses in the SwbemObjectSet collection, where each project in the collection is a SwbemObject representing a single class.

Another important difference in Listing 8 is an objclass.path_.path attribute in the for Each loop body. Let's take a look at the for Each loop to understand what this is. The For Each loop is enumerating each SwbemObject (Objclass) in the SwbemObjectUBClasS set of SwbemServicesUBClassesof methods. Each SwbemObject represents a discrete class in the root / cimv2 namespace. This is some of the possibility of confusing. Unlike us, all the scripts displayed by the property defined by the hosted resource blueprint (class definition), Path_ is the attribute provided by the SwbemObject of the WMI script library. To understand this, you have to consider using SwbemObject's context. Do you use SwbemObject to access instances of managed resources? Or are you defined by using SwbemObject to access the category of the hosted resource?

When you use SwbemObject to access instances of managed resources, you are more likely to use SwbemObject to access properties and methods defined by managed resource blueprints (class definitions). When you use SwbemObject to get detailed class information - such as supported properties, methods, and qualifiers - you use the properties and methods provided by SwbemObject themselves. Path_ is a such attribute.

Path_ actually references another WMI script library object that provides the Path property named SwbemObjectPath. The SWBemObjectPathPath property contains a fully qualified path to the class referenced by the SwbemObject (ObjClass in Listing 8). A reminding you again, don't focus too much on the script object, because we will discuss in detail in the third part.

Listing 8: Retrieve all classes defined in root / cimv2 namespace using WMI and VBScript

StrComputer = "."

Set objwmiservice = getObject ("WinMgmts: //" & strComputer & "/ root / cimv2")

Set colclasses = objwmiservice.subclassesof ()

For Each Objclass in colclasses

WScript.echo Objclass.Path_.path

Running on our Windows Server 2003 Computer Run list 8 shows a long list of 914 classes, Figure 5 shows part of it.

Figure 5: GetClasses.vbs output

Of course, you can easily modify the list 8 to list the classes in other namespaces by changing only the target namespace of the script. You can also use the list 8 with the FINDSTR.EXE command to search for classes. For users who are unfamiliar with the FindStr.exe command: FindStr.exe is a command line tool for searching for strings in a file.

For example, suppose you need to know if you are running Windows version supports new Windows XP and Windows Server 2003 Win32_TSSessionSetting classes. You can use the following command line to determine if the WIN32_TSSESSETTING class exists in the root / cimv2 namespace.

C: / scripts> CScript getClasses.vbs | FindSTR / I "Win32_tssetting"

Here to try a few additional solutions.

• List all system classes in root / cimv2 namespace: C: / scripts> CScript getClasses.vbs | FindSTR / I "__" • List all core and public categories in root / cimv2 namespace: C: / scripts > cscript getClasses.vbs | FindSTR / I "CIM_"

• List all Win32 extensions in root / cimv2 namespace: C: / scripts> cscript getClasses.vbs | FindSTR / I "Win32_"

• List all the c: / scripts> cscript getClasses.vbs | Findstr / I "Process" in the root / cimv2 namespace: c: / scripts> cscript getClasses.vbs |

CIM class type definition

It should be apparent that the class is the basic construction block of the CIM repository. WMI configuration information and WMI managed resources are defined by one or more classes. Similar to the Active Directory architecture, the CIM class is organized by level, in which subclasses in this organizational structure are inherited from the parent class, methods, and qualifiers (now do not have to consider attributes, methods, and qualifiers, we will be next Festival discussion). For example, Win32_Service Dynamic class is inherited from Win32_baseservice abstraction; the latter is inherited from the CIM_Service abstraction; CIM_Service abstraction is inherited from the CIM_LogicalElement abstraction class; CIM_LogicAleMent abstraction is inherited from the CIM_MANAGEDSystemElement abstraction (As shown in Figure 1). It is the sum of the category in the class level of the hosted resource definition to define managed resources.

As mentioned earlier, there are 3 main types: abstraction, static and dynamic.

Abstract class

The abstract class is a template for defining a new class. For example, the abstract class in the Active Directory architecture, the CIM abstraction class is based on other abstractions, static and dynamic classes. Each, um, almost the definition of each WMI hosted resource class is from one or more abstract classes (or derived).

You can identify abstract classes by checking the Abstract qualifiers of the class. The abstract class must define the Abstract Limit and set the value of the Abstract qualifier to True. Supplemental List A of this article shows how to use the WMI script library to list all abstraction classes defined in root / cimv2 namespace.

Abstract class types are most commonly used for core and public class definitions. Abstracts are very small in the WMI script because you cannot retrieve an instance of an abstract class.

Static class

Static class defines the data stored in the CIM repository. The static class has the same example as the dynamic class, but the instance of the static class is stored in the CIM repository. Similarly, static class instances are retrieved from the CIM. They don't use the provider.

You can identify static classes by checking the qualifiers of the class. However, it is different from the abstraction and dynamic class type identified by the specified default, and the static class is identified by not containing the Abstract and Dynamic qualifiers.

Static class types are most commonly used for system class definitions. The static class is extremely useful in the WMI script.

Dynamic class

Dynamic class is a class that models WMI managed resource from providing programs.

You can identify dynamic classes by checking the Dynamic qualifiers of the class. Dynamic classes must define a Dynamic qualifier and set the value of the Dynamic qualifier to True. Supplemental List B in this article demonstrates how to use the WMI script library to list all the dynamic classes defined in root / cimv2 namespaces.

Dynamic class types are most commonly used for definitions of expansion classes. Dynamic classes are the most common class types used in WMI scripts.

Associated class

The fourth type is called associated classes and is also supported. Association class is an abstraction, static or dynamic class that describes the relationship between two or hosted resources. The Win32_SystemServices class shown in Figure 1 is an example of a dynamic associated class that describes the relationship between the computer and the service running. You can identify associated classes by checking the class of Association qualifiers. Abstract, static or dynamic association classes must define the ASSociation qualifier and set the value of the Association qualifue to True.

Analyze

It sounds like breaking a record, each of which is defined by a class through the WMI managed hardware and software resources. A class is a blueprint (or template) of a discrete WMI hosted resource, and all instances of resources use this blueprint. Class represents what your computer has. Because computers have things such as disks, event logs, files, folders, memory, printers, processes, processors, services, etc., WMIs have on disks, event logs, files, folders, memory, printers, processes, processors, Class of services such as services. Although there are exceptions (such as __event abstract system classes), most classes used in scripts can be directly contacted to actual, active substances.

These so-called blueprints are composed of attributes, methods, and restrictions. Before studying attributes, methods, and restrictions, let us briefly discuss the origins of the managed resource definition.

Suppose Microsoft decides to create a new, system administrator can be used to manage and monitor WMI providers for Microsoft DNS servers. The DNS Provider Development Team requires at least two files: a provider and a managed object format (MOF) file.

The provider is a dynamic link library that acts as the WMI infrastructure and the basic managed resource (in this example, the Microsoft DNS server). The provider responds to WMI requests by calling the local API of the hosted resource.

The MOF file contains a class definition that describes the functions provided by the DNS provider. The MOF file utilizes a function of describing the DNS provider for class that typically modeling resource modeling with the DNS server. Each class defined in the DNS MOF file defines data (attributes) - the data and properties are associated with the specified DNS-related resources, and the operations you can perform on this resource (Method).

After installing the DNS provider, the DNS Provider Dynamic Link Library registers the operating system and WMI, and the DNS MOF file has undergone a compilation process, which loads the DNS provider class definition to the CIM repository. At this point, the DNS provider can be used for any user-enabled users (including scripts).

Although our story is real - Microsoft has developed a new DNS provider for Windows Server 2003, the important thing that can be obtained is that the hosted resource class defines from the MOF file. The MOF file is for WMI and like the MIB file to SNMP.

The MOF file is based on a text file for a MOF language created and maintained by Distributed Management Task Force (DMTF). As shown in Figure 6, each managed resource class definitions comply with a well-defined structure and syntax.

Figure 6: Structure defined by hosted resource class

As shown in Figure 6, each managed resource class definition is composed of attributes, methods, and qualifiers.

Attributes

Attributes are the nouns describing the hosted resource. Class use properties describe, such as identification, configuration, and managed resource status, etc. For example, the service has a name, display name, description, startup type, and status. The Win32_Service class also has the same thing.

Each attribute has named, type, and optional attribute qualifiers. As with the method shown in the previous Listing 1, the property name is used with the SwbemObject of the WMI script to access the properties of the managed resource.

method

The method is to perform a verb of an operation on the hosted resource. What can you do with the service? Ok, you can start them, stop them, suspend them or continue them. The result is how to allow you to start, stop, suspend, and continue the service. Nothing is incredible. Each method is named, return type, optional parameter, and optional method qualifiers. Like attributes, the name of the name is used to use the SwbemObject of the WMI script library to call the method.

Not all classes define methods.

Default

The qualifier is an adjective that provides additional information about classes, attributes, or methods to what they apply. For example, the problem "WIN32_SERVICE class is?" Is an answer from the Dynamic qualifier of the class. When you start writing a WMI script that is not just simply retrieving information (for example, modifying attributes, or calling methods), the qualifier becomes more important because they define the operating features of the properties you are updating or being called. So which information provides for the qualifier?

Class qualifier

The class qualifier provides information about the class. E.g:

• If you know before, Abstract, Dynamic and Association qualifiers will tell you type. • The Provider qualifier tells you the provider of this class. For example, the Provider qualifier of the Win32_Service class tells you this class using the CIMWIN32 provider (CIMWIN32.DLL). On the other hand, as the Win32_NTLOGEVENT class is indicated by the Win32_NTLOGEVENT class, the Win32_NTLOGEVENT class uses the MS_NT_EVENTLOG_PROVIDER provider (NTEVT.DLL). • The Privileges qualifier tells you the special privileges you want to use. For example, the Privileges qualifier of the Win32_NTLOGEVENT class tells you that the SSESECURITYPRIVILEGE must be enabled before the Win32_NTLOGEVENT class can manage the security log.

Attribute qualifier

The attribute qualifier provides information about each attribute. E.g:

• The CIMTYPE qualifier tells you the data type of the property. • The READ qualifier indicates that this property is readable. • The WRITE qualifier indicates whether you can modify the value of the properties. For example, the AspscriptDefaultNamespace property of the Win32_WMisetting class modified in Listing 4 is marked as writable. On the other hand, all Win32_service properties elected in Listing 1 are defined as read-only - means that they do not define the WRITE qualifier. • The key qualifier indicates that this property is a key to the class and is used to identify the unique example of managed resources in the same resource collection.

Method definition

The method qualifier provides information about each method. E.g:

• The Implement Limit is indicated that this method has a implementation provided by the provider. • ValueMap qualifiers define a set of allowed values for method parameters or return types. • The Privileges qualifier tells you the dedicated privileges you need to call this method.

There is more qualifiers than those mentioned herein. For a complete list, see the WMI Qualifiers theme in WMI SDK.

As shown in Figure 7, you can use the WMI Tester (WBEMTEST.exe tool to check the properties, methods, and qualifiers of the class. Of course, you can also use the WMI script library to retrieve the same information, soon you will see it.

Figure 7: Use the WMI Tester (WBEMTEST.EXE) View Win32_Service Class

Comparison class and hosting resources

Most WMI properties and methods are reasonably named. For example, as shown in Figure 8, if you will be compared to the properties and methods defined by the Win32_Service class, it is not difficult to infer Win32_service.name, win32_service.displayname or win32_service.displaithpion, may contain anything. Figure 8: Service Properties dialog and Win32_Service class properties and methods

So why should we care about all these content? Because the class determines what you can (or can't) do with WMI. If there is a class of services, you can manage the service; if not, you can't do this. Properties and methods are important because the WMI version is different between operating systems. Win32_computersystem classes in Windows XP have many new properties and methods, and they are not in the Win32_Computersystem class in Windows 2000. You must know the details of WMI, because of ADSI, in order to make the work, WMI properties and methods must be available for target computers.

How do I determine if a remote Windows computer supports an attribute or method? Check the class definition.

Search class definition

Like everything in WMI, there are countless ways to retrieve the class definition of managed resources. Ok, maybe we have a bit exaggerated, but it is also enough to say that there are many ways to provide solutions for each user interface preferences. If you want to retrieve text files, just split the MOF file. If you prefer the command line, use the WMI command line tool wmic.exe (Windows XP only). If you are willing to spend the time on the graphical tool, use the WMI tester (WBEMTEST.EXE) or CIM Studio. Or if you like us, use the WMI script library.

With the WMI script library, you can retrieve managed resource classes in three different ways.

1. You can search class information using SwbemObjectQualifiers_, Properties_, and Methods_ attributes. 2. You can use the SwbemObjectGTGETObjectText_ method to retrieve class definitions formatted in MOF syntax. 3. You can use the SWBemObjectExgetText_ method to retrieve class definitions formatted in XML (Windows XP and Windows Server 2003).

Let us briefly look at each script scheme, which ends today.

Use SwbemObject Properties_, Methods_ and Qualifiers_

Listing 9, 10 and 11 demonstrate how to use the extenties_, methods_, and Qualifiers_ attributes of the WMI script library to retrieve information about the Win32_Service class. We will study inventory 9, then point out the differences in Listing 10 and Listing 11, because three scripts use the same basic method.

Listing 9 begins with initialization three variables, they are: strComputer, Strnamespace and StrClass assignments to StrComputer are enabled WMI target computers. The value assigned to the StrnameSpace is the namespace to connect to. Values assigned to STRCLASS are the name of the class in the target namespace, and the properties of this namespace will be retrieved and displayed. Separate these three values to multiple variables to make other computers, namespaces, and classes of the script simpler. In fact, you can easily convert the list 9 to the command line script with the Windows Script Host (WSH) parameter set.

Next, this script uses VBScript's getObject function to connect to WMI services on the target computer. CAUTION What is the difference between the connection string passing to getObject? In addition to specifying the target namespace, the class name is also specified, which has a profound impact on the content returned by GetObject and WMI script libraries. For all the scripts we have, getObject returns a reference to the SwbemObject that represents the target class, rather than returns a reference to the SwbemServices object. why? The answer is the object path. Although we will discuss the object path in detail in the third part, we still give you an outline interpretation to help you understand what is done in Listing 9 to Listing 11 (and supplemental list c). Each WMI class and each WMI managed resource instance have an object path. Understand the object path as a WMI version of a fully qualified path. Each file has a fully qualified path, which is composed of the device name, followed by 0 or more directory names, plus the file name. Similarly, each class and hosted resources have an object path, which is enabled by the WMI computer name, followed by the CIM namespace, followed by the hosted resource class name, the key attribute of the KEY property, and the value of the key attribute, as shown below . (Note that square brackets only intend to distinguish the four license parts of an object path, they are not part of the object path.)

[//Computername][/namespace][ :classname][.keyproperty='Value ']

When you use all or part of the object path in the connection string passing to getObject (By the way, this is what we have been doing), the object path you use is determined by the reference type returned by the getObject and WMI script library. . For example, if you only contain a computer name part of an object path, you will get a SWBEMServices object reference to the default namespace. If you contain a computer name and / or namespace, you will also get a reference to the SwbemServices object. If you contain a computer name, namespace, and class name, you will get a reference to SwbemObject that represents this class. If all four parts are included, you will get SWBemObject that represents a managed resource instance identified by the class, key, and values. Remind again that we will discuss the object path in more detail in the third part of this series. Now, understand the OBJClass in Listing 9 is a reference to the SwbemObject that represents the Win32_Service class.

The remainder of the script is quite simple and easy. After returning a simple, identifying its property After the title of the class name of the display, the script uses the SwbemObject reference reference (OBJClass) returned from getObject to access the SwbemObjectProperties_ attribute (Objclass.properties_). The SwbemObjectProperties_ attribute references a SwbemPropertySet, which is a collection of properties of this class. Each attribute in the SwbemPropertySet collection is an SwbemProperty (ObjClassProperty) object, we use it to read and echo the name of each property.

In summary, the For Each loops enumerate the class's SwbemPropertySet collection (via the SwbemObjectProperties_ attribute) and returns the Name property of each SwbemProperty in the SwbemPropertySet collection.

Listing 9: Retrieving Win32_Service property using SwbemObject Properties_

StrComputer = "." strnamespace = "root / cimv2"

STRCLASS = "Win32_Service"

Set objclass = getObject ("WinMgmts: //" & strComputer &_

"/" & strnamespace & ":" & strs)

WScript.echo Strclass & "Class Properties"

WScript.echo "------------------------------"

For Each ObjclassProperty In objclass.properties_

WScript.echo Objclassproperty.Name

Figure 9 shows the names of 25 attributes defined by the Win32_Service class (or inheritance).

Figure 9: GetProperties.vbs Output

In addition to a significant exception, the list 10 is the same as the list 9. For Each loop enumeration class SwbemMethodSet collection (via the SwbemObjectMethods_ attribute) and returns the Name property of each SwbemMethod (ObjClassMethode) in the SwbemMethodSet collection.

Listing 10: Use SwbemObject Methods_ to retrieve Win32_Service method

StrComputer = "."

Strnamespace = "root / cimv2"

STRCLASS = "Win32_Service"

Set objclass = getObject ("WinMgmts: //" & strComputer &_

"/" & strnamespace & ":" & strs)

WScript.echo Strclass & "Class Methods"

WScript.echo "---------------------------"

For Each ObjclassMethod in objclass.methods_

WScript.echo ObjclassMethod.Name

Figure 10 shows the names of 10 methods defined by the Win32_Service class (or inherited).

Figure 10: GetMethods.vbs Output

In addition to three-point exception, Listing 11 is the same as the list 9 and the list 10.

1. For Each loop enumeration class SwbemQualifierSet collection (via the SwbemObjectQualifiers_ attribute) and returns the Name property of each Swbemqualifier (ObjclassQualifier) in the Swbemqualifier (ObjClassqualifier). 2. Because the class qualifier is part of the class definition and the qualifier has a value, the Listing 11 also retrieves and elects the Value property of each Swbemqualifier (ObjClassquaalifier) in the SWBemquaNErges collection. 3. Because a qualifier can have a number of values stored in an array, the list 11 must illustrate this point before the value of the qualifier is read. If you don't do this, if the script is trying to read an array-based qualifier as a scalar variable, it will cause an error in runtime. The Privileges qualifier of the Win32_NTLOGEVENT class is an array-based qualifier instance. Listing 11: Use SwbemObject Qualifiers_ to retrieve Win32_Service class qualifiers

StrComputer = "."

Strnamespace = "root / cimv2"

STRCLASS = "Win32_Service"

Set objclass = getObject ("WinMgmts: //" & strComputer &_

"/" & strnamespace & ":" & strs)

WScript.echo Strclass & "Class Qualifier"

WScript.echo "------------------------------"

For each objclassqualifier in objclass.qualifiers_

If Vartype (Objclassqualifier.Value) = (VBVARIANT VBARRAY) THEN

Strqualifier = Objclassqualifier.name & "=" & _

Join (Objclassqualifier.Value, ",")

Else

Strqualifier = Objclassqualifier.name & "=" & _

Objclassqualifier.value

END IF

WScript.echo Strqualifier

Strqualifier = ""

Figure 11 shows the names and values of the five classes defined by the Win32_Service class definition (or inherit).

Figure 11: GetClassqualifiers.vbs output

If you may have noticed, Listing 9 and Listing 10 cannot display attributes and method qualifiers. To be honest, this is deliberate to keep the script in a size that is easy to understand. The good news is that the end of this column we have joined the full class qualifier, attribute, attribute qualifier, method, method definition script (see Supplemental List C). Welcome.

In case, this is not clear, you can combine the properties of each class defined in the CIM in a list 6 (getAllNameSpaces.vbs script) and the list 8 (getClasses.vbs script) to retrieve the properties of each class defined in the CIM. Methods and qualifiers. With the generated script with the findstr.exe command, you get a solution to search for any class, properties, methods, or qualifiers defined in the CIM. Use SwbemObject getObjectText_

In the previous we said, you can retrieve the management resource class definition directly from the MOF file (including the definition of the class). For example, if you want to find the Win32_Service class, you can view the% systemroot% / system32 / wbem / custom32.mof file. However, it is cost to use the MOF file directly. You must check each class in the class hierarchy of the hosted resource to get a full managed resource blueprint.

For example, you want to find Win32_Service. You have to check all 5 classes in the Win32_Service class hierarchy to get a complete blueprint, as shown in Figure 1. If you use the WMI tester (WBEMTEST.EXE) SHOW MOF button (see Figure 7), it is also the same. The more simple method of obtaining the form of the MOF representation is to use the SwbemObjectGTObjectText_ method of the WMI script, as shown in Listing 12.

Unlike Listing 9 to 11, inventory 12 uses the SwbemServicesget method to retrieve classes without using getObject. You must use the SWBEMSERVICESGET method to enable the WbemflagUseamentededquailifiers flag. Enable the WBEMFLAGUSEAMENDEDQUAILIFIERS flag telling WMI to return the entire hosting resource blueprint (class definition), not just local definitions.

There is also a second benefit using the wbemflaguseadeededqualifiers tag. You also retrieve class descriptions, as well as descriptions of the properties, methods, and qualifiers of each class. Class, attributes, methods, and qualifiers are typically defined in a localized purpose, separate MOF files. For example, the neutral language part of the Win32_Service class is defined in CIMWIN32.MOF. The specific language part of the Win32_Service class, includes description information, is defined in CIMWIN32.mfl. Specific language (or localized) MOF files typically have a .mfl (rather than .mof) extension.

The SWBEMServicesget method returns a reference to the SwbemObject (ObjClass) that represents the target class, which is used to call the SwbemObjectGTgetObjectText_ method. The getObjectText_ method returns the MOF representation of the class. If we use getObjectText_ without enabling WBEMFLAGUSEAMENDEDQUAILIFIERS tags, this method will only return only those defined by Win32_Service, and inherited attributes and methods are omitted.

Figure 12: Use SwbemObject GetObjectText_ to retrieve the MOF expression form of the Win32_Service class

StrComputer = "."

Strnamespace = "root / cimv2"

STRCLASS = "Win32_Service"

Const wbemflaguseagendededqualifiers = & h20000Set objWMiservice = getObject ("WinMgmts: //" & strcomputer & "/" & strnamespace)

Set objclass = objwmiservice.get (strclass, wbemflaguseageready)

Strmof = Objclass.getObjectText_

WScript.echo Strmof

However, there is a qualification for using getObjectText_: there is no information about inheritance definition in the MOF syntax included in this method. When the Key qualifier is defined in the properties of a parent class, if you want to use getObjectText_ to determine a class's Key property, this may bring problems.

Use SwbemObjectEx GetText_

Windows XP and Windows Server 2003 include a new way called GetText_, which can be used to retrieve the XML performance form defined by the managed resource class.

In addition to an obvious exception, use GetText_ similar to using getObjectText_ similar: 3 parameters passing to the getText_ method.

The first parameter is required, it identifies the generated XML format. It is currently possible as one of two values defined by WMI WbemObjectTextFormatenum: WbemObjectTextFormatcimdtd20 (value: 1) or WBemObjectTextFormatWMIDTD20 (value: 2). Value 2 (WBemObjectTextFormatWMIDTD20) tells GetText_ The XML generated by the extended WMI version formatted according to the Distributed Management Task Force CIM Document Type Definition (DTD) version 2.0.

The second parameter is optional and is currently reserved for the operation mark. It must be set to 0 (zero).

The third parameter colnamedValueSet is also a SWBemNameDValueSet collection for providing a special instructions for getText_. Here, we let GetText_ perform:

• Retrieve and encode all properties and methods, more than just local defined properties and methods. • Contains class qualifiers, attribute qualifiers, and method qualifiers in the generated XML. • Contains system properties in the generated XML. • Contains a class origin for all properties and methods.

Listing 13: Use SwbemObjectEx getText_ to retrieve the XML performance form of the Win32_Service class (Windows XP and Windows .NET)

StrComputer = "."

Strnamespace = "root / cimv2"

STRCLASS = "Win32_Service"

Const wbemflaguseagendededqualifiers = & h20000

Const wbemObjectTextFormatWMIDTD20 = 2

Set objwmiservice = getObject ("WinMgmts: //" & strcomputer & "& strnamespace)

Set objclass = objwmiservice.get (strclass, wbemflaguseage) set colnamedvalueset = createObject ("wbemscripting.swbemnamedvalueset")

ColnamedValueSet.Add "Localonly", False

ColnamedValueSet.Add "includequalifiers", True

ColnamedValueSet.Add "Excludesystemproperties", False

ColnamedValueSet.Add "IncludeClassorigin", True

Strxml = objclass.gettext_ (WbemObjectTextFormatWmidtd20, 0, ColnamedValueSet)

Wscript.echo strXml

To successfully run list 13, copy the script and paste into your most common text editor, save the script (extension .vbs, for example: getXml.vbs), then run the script using the command line listed below.

C: / scripts> cscript // nologo getXml.vbs> Win32_service.xml

Figure 12 shows the generated XML file, Win32_Service.xml, using Microsoft Internet Explorer.

Figure 12: GetXml.vbs output

Just here.

If there is any doubt, difficult or unknown for WMI, it may be a lot of data issued by WMI. We are willing to think that we have been equipped with knowledge and tools necessary to effectively find and explain the WMI managed resource class definition. Of course, you are the best referee for this point, so please try our best to know if we are in short. The boring content is over, ready to be happy in the third part when we invest in the WMI script library. Oh, no matter what, please send the rest of the time.

Wait! Before you pack, there is the last place to pay attention to: The WMI development team let us tell you that the WMI tool used before WMI SDK can now be updated. Updated tools (including WMI CIM Studio, WMI event registration, WMI event viewer and WMI object browser), are now compatible with Windows XP and Windows Server 2003 and Windows 2000. In addition, the updated tool does not contain WMI SDK, which means that you can now install these tools without having to install the entire WMI SDK. Isn't this very cool?

Supplemental script

Listing A: List the abstract class type defined in root / cimv2 namespace

StrComputer = "."

Set objwmiservice = getObject ("WinMgmts: //" & strComputer & "/ root / cimv2")

Set colclasses = objwmiservice.subclassesof ()

For Each Objclass in colclasses

For each objclassqualifier in objclass.qualifiers_

If Lcase (Objclassqualifier.name) = "Abstract" thenswscript.echo objclass.path_.class & ":" & _

Objclassqualifier.name & "=" & _

Objclassqualifier.value

END IF

Listing B: List the dynamic class type defined in the root / cimv2 namespace

StrComputer = "."

Set objwmiservice = getObject ("WinMgmts: //" & strComputer & "/ root / cimv2")

Set colclasses = objwmiservice.subclassesof ()

For Each Objclass in colclasses

For each objclassqualifier in objclass.qualifiers_

If lcase (objclassqualifier.name) = "Dynamic" THEN

WScript.echo Objclass.Path_.class & ":" & _

Objclassqualifier.name & "=" & _

Objclassqualifier.value

END IF

List C: Use SwbemObject Qualifiers_, Properties_, and Methods_ to search class qualifiers, attributes, attribute qualifiers, methods, and method qualifiers

StrComputer = "."

Strnamespace = "root / cimv2"

STRCLASS = "Win32_Service"

Set objclass = getObject ("WinMgmts: //" & strComputer &_

"/" & strnamespace & ":" & strs)

WScript.echo Strclass & "Class Qualifier"

WScript.echo "------------------------------"

i = 1

For each objclassqualifier in objclass.qualifiers_

If Vartype (Objclassqualifier.Value) = (VBVARIANT VBARRAY) THEN

STRQUALIFIER = I & "." & objclassqualifier.name & "=" & _

Join (Objclassqualifier.Value, ",")

Else

STRQUALIFIER = I & "." & objclassqualifier.name & "=" & _

Objclassqualifier.value

END IF

WScript.echo Strqualifier

Strqualifier = ""

i = i 1

WScript.echo

Wscript.echo strclass & "class property" "wscript.echo" ------------------------------------------------------------------------------------------------------------------------------------------------------------ -------------------- "

i = 1: j = 1

For Each ObjclassProperty In objclass.properties_

WScript.echo I & "." & Objclassproperty.name

For Each ObjPropertyqualifier In objclassproperty.qualifiers_

IF Vartype (ObjPropertyqualifier.Value) = (vbvariant vbarray) THEN

Strqualifier = I & "." & j & "."

ObjPropertyqualifier.name & "=" & _

Join (ObjPropertyqualifier.Value, ",")

Else

Strqualifier = I & "." & j & "."

ObjPropertyqualifier.name & "=" & _

ObjPropertyqualifier.Value

END IF

WScript.echo Strqualifier

Strqualifier = ""

J = J 1

WScript.echo

i = i 1: j = 1

WScript.echo

WScript.echo Strclass & "Class methods and method qualifier"

WScript.echo "---------------------------------------------- --- "

i = 1: j = 1

For Each ObjclassMethod in objclass.methods_

WScript.echo I & "." & Objclassmethod.name

For each objmethodqualifier in objclassmethod.qualifiers_

IF Vartype (ObjMethodqualifier.Value) = (vbvariant vbarray) THEN

Strqualifier = I & "." & j & "."

Objmethodqualifier.name & "=" & _

Join (Objmethodqualifier.Value, ",")

Else

Strqualifier = I & "." & j & "."

Objmethodqualifier.name & "=" & _

Objmethodqualifier.Value

END IF

WScript.echo Strqualifier

Strqualifier = "" j = j 1

WScript.echo

i = i 1: j = 1

Scripting clinic

Greg Stemp has long been recognized as one of the authorities in the US domestic scripting, and is widely known as world-class ... Haha! Well, how do you have a football coach in their resume? really? He was fired? Oh, OK. Greg STEMP is working in ... Oh, ok, I can't even say this? Ok! Greg Stemp raised from Microsoft, where he had the title of the SYSTEM Administration Scripting Guide.

Dean Tsaltas is a Nova Scotian living in redmond. He has begun to say a fluent American, and even laugh at his pronunciation of friends and families in the Marina. His computer career begins at his very small, then his grandmother and parents gave him, bought him with his beloved C-64, and subscribed to Compte! Journal. Now, he has worked for several years in Microsoft. He has a sentence to tell friends and family in hometown and Vancouver: "No, I haven't seen Bill yet!"

Bob Wells swayed around, and prepared to each of the people listening to him. There are rumors that Bob's two Daxie Rethers have more written to scripts than most human beings. BOB submitted to the System Administration Scripting Guide in a spare time.

Ethan Wilansky spends many of his working hours in writing and consulting. He is enthusiastic on script writing, yoga, gardening and his family (not necessarily in this order). He is currently working on a method of creating scripts that can put down the garbage and washing disc.

转载请注明原文地址:https://www.9cbs.com/read-118870.html

9cbs

New Post(0)