If your WMI scripts connect only to computers with WMI 1.5, you don't need to explicitly set impersonationLevel=Impersonate. However, if you omit it, scripts accessing computers with an earlier release of WMI fail. For backward and potentially future compatibility, you should always explicitly set impersonationLevel.
The authenticationLevel setting lets you request the level of DCOM authentication and privacy that a WMI connection should use. The seven permissible moniker settings are Default, None, Connect, Call, Pkt, PktIntegrity, and PktPrivacy. DCOM won't necessarily honor your requested setting. For example, local connections always use authenticationLevel=PktPrivacy.
The authority setting lets you specify the security package that WMI uses to authenticate your WMI connection. You can specify standard NT LAN Manager (NTLM) or Kerberos authentication. To use NTLM, specify authority=ntlmdomain:DomainName, where DomainName identifies a valid NTLM domain name. To use Kerberos, specify authority=kerberos:DomainName\ServerName. You can't include the authority setting in WMI monikers that access the local computer.
The final security setting lets you grant or revoke privileges as part of a WMI moniker string. For example, you might grant yourself the Security privilege so that you can successfully query the Win2K or Windows NT Security log. The privileges you can override are CreateToken, PrimaryToken, LockMemory, IncreaseQuota, MachineAccount, Tcb, Security, TakeOwnership, LoadDriver, SystemProfile, SystemTime, ProfileSingleProcess, IncreaseBasePriority, CreatePagefile, CreatePermanent, Backup, Restore, Shutdown, Debug, Audit, SystemEnvironment, ChangeNotify, RemoteShutdown, Udock, SyncAgent, and EnableDelegation. To grant a privilege, list the privilege name. To revoke a privilege, preface the privilege name with an exclamation point (!).
Listing 4 shows the general format you use when including security settings in WMI monikers. The security-settings component immediately follows the colon (:) in "winmgmts:" and is enclosed in braces. You must comma-delimit multiple settings, and you must further separate override privileges inside parentheses and comma-delimit them.
WMI Object-Path Component
The third component of WMI monikers is a WMI object path, and 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, so chances are good that you'll use WMI object paths. You use a WMI object path to uniquely identify one or more of the following target resources:
- remote computer
- WMI namespace
- Common Information Model (CIM) class within a namespace
- specific instances of a CIM class within a namespace
The format of the object-path component varies slightly depending on whether you also include some portion of the security-settings component. If you include security settings, the object path follows the security settings' closing brace and is separated from the security component by an exclamation point, as the statement in Listing 5 shows. If you omit security settings altogether, the object path follows the colon in "winmgmts:" without the exclamation point, as the statement in Listing 6 shows.
Notice that you format the object path hierarchically, beginning with the target computer name, followed by a WMI namespace, followed by a CIM class name, and ending with a key value. Although I included all the object-path subcomponents in the listings, you can specify only what you need to while observing the following constraints and guidelines:
- WMI connects to the local computer if you don't supply a target computer name or if you provide a dot (.) as the computer name (e.g., "winmgmts://./ root/cimv2"). If you omit the target namespace, WMI accesses the default namespace that the HKEY_LOCAL_ MACHINE\SOFTWARE\Microsoft\ WBEM\Scripting\Default Namespace subkey defines. The default namespace for scripting is root\cimv2. You can use the Microsoft Management Console (MMC) WMI Control snap-in's Advanced tab to change this value.
- You can't omit the target namespace in WMI monikers that specify a target computer name and CIM class name.
- Values that you use to identify a specific instance of a class must correspond to a CIM class key. For example, the key for the Win32_LogicalDisk class is DeviceID. Thus, you must specify an appropriate value for the DeviceID property when identifying a specific instance of the Win32_LogicalDisk class. To determine CIM class keys, use wbemtest.exe or WMI CIM Studio, or view the Managed Object Format (MOF) file that contains the corresponding class definition.
WMI Moniker Best Practices
Here are a few key take-aways regarding the WMI moniker and its components:
- Always explicitly set impersonationLevel. Don't rely on the Default Impersonation Level registry subkey.
- Likewise, always explicitly identify the target namespace rather than relying on the Default Namespace registry subkey. If the default value changes and you don't realize it, the result isn't fun.
- If your script mines data from multiple CIM classes, create one reference to an SWbemServices object and reuse the reference.
- If you must supply a username and password, you can't use the WMI moniker. You must use the WMI Scripting Library's SWbemLocator object instead.
To learn more about the WMI moniker, visit the Microsoft Developer Network (MSDN) Online Library at http://msdn.microsoft.com/library/psdk/wmisdk/scintro_6tpv.htm and http://msdn.microsoft.com/library/psdk/wmisdk/hmmapp_2z8z.htm. You'll find useful information and numerous moniker examples to use in your scripts.