Using WMI Object Paths

Microsoft® Windows® 2000 Scripting Guide

The third component of WMI monikers is the WMI object path. Like the security settings component, the object path component is optional. However, the object path provides a great deal of flexibility, including the ability to identify remote computers. Because of this, chances are good you will use WMI object paths whether or not you realize it. You use the WMI object path to uniquely identify one or more of the following target resources:

  • Remote computer. If the computer is not specified in the object path, the script will connect to the WMI service on the local computer. For example, this moniker does not include a computer name, so it runs on the local computer:

    Set objSWbemServices = GetObject("winmgmts:")

    This moniker connects to the WMI service on a remote computer named atl-dc-01:

    Set objSWbemServices = GetObject("winmgmts:\\atl-dc-01")

    Computer names are typically specified using the NetBIOS name of the computer. However, computer names can also be specified using a DNS name (for example, or an IP address (for example,

  • WMI namespace. If not specified, the default namespace is used. This moniker connects to the default namespace on a remote computer named atl-dc-01:

    Set objSWbemServices = GetObject("winmgmts:\\atl-dc-01")

    This moniker connects to the root\default namespace on atl-dc-01:

    Set objSWbemServices = GetObject("winmgmts:\\atl-dc-01\root\default")
  • WMI class within a namespace. If a class is specified within a moniker, it must be separated from the computer name and the namespace by a colon. For example, this moniker binds directly to the Win32_OperatingSystem class:

    Set objSWbemObject = GetObject _
  • Specific instance or instances of a WMI class within a namespace. This moniker connects directly to the WMI instance representing drive C. To bind directly to an instance, you must include the key property (defined in the "Key properties" section of this chapter) in the object path:

    Set objSWbemObject = GetObject _

Formatting Object Paths

In an object path, the computer name and the WMI namespace are separated using either forward slashes or back slashes. Both of these are valid object paths:



  • In fact, you can even mix forward and back slashes within the same object path. This is not recommended because the code will likely confuse anyone reading or editing it. However, this is a valid object path: \\Webserver/root/cimv2.

If a WMI class is to be included in the object path, the class name must be separated from the namespace by a colon (:). For example, this object path connects to the Win32_Printer class:



  • You will rarely use an object path like the preceding one within a system administration script. This is because the path binds you to the class itself and not instances of the class. In the preceding example, you cannot return information about any printers installed on the computer; you can only return information about the Win32_Printer class. However, this type of binding is occasionally used to create new objects for example, to create a new shared folder, you connect directly to the Win32_Share class and then call the Create method.

To bind directly to an instance of a class (for example, to bind to a particular service), you must include the class name, a dot (.), the key property of the class, and the value of that property. This object path returns only one object, representing the Alerter service:


Key properties

A key property is a property that can be used to uniquely identify an instance. Name is a key property of Win32_Service because all services must have unique names. StartMode is not a unique property of a service because all services could, at least in theory, have the same start mode.

In other words, a connection string such as the following will fail because StartMode is not a key property of the Win32_Service class:

Set colServices = GetObject _

If you attempt to run the preceding script, you will receive an "Invalid syntax" error.


Classes typically have only one key property, although there are some exceptions. The Win32_NTLogEvent class has two key properties: Logfile and RecordNumber. This is because RecordNumber alone does not uniquely identify an event recorded in the event logs: Both the Application event log and the Security event log can have a record with a RecordNumber of 555. To uniquely identify an event log record, you need to specify both key properties in the object path: