Rem - 27 Nov 2000

Do you have a scripting-related question or problem? You can send your question or problem to [email protected].

My environment consists of a mix of Windows Management Instrumentation (WMI) clients: Some run WMI 1.1 (installed by Microsoft Systems Management Server—SMS 2.0), and others run WMI 1.5. When I run a WMI script that queries a remote client, the script fails on the WMI 1.1 clients unless I include the following impersonationLevel setting in the moniker string:

impersonationLevel=Impersonate

Why do I need to include an impersonationLevel setting in the moniker string for the WMI 1.1 clients, but not for the WMI 1.5 clients?

This problem occurs because the various versions of WMI handle impersonationLevel settings differently. Table 1 details the three WMI versions (i.e., WMI 1.01, WMI 1.1, and WMI 1.5) and their build numbers, release vehicles, and default impersonationLevel settings.

By default, the WMI service (winmgmt.exe) runs under the Local System account. Although Local System is sufficient when you use the WMI scripting API to access a local machine's WMI service, Local System is typically insufficient when you use the WMI scripting API to access a remote machine's WMI service.

Unfortunately, in WMI 1.01, winmgmt.exe runs under Local System regardless of the identity of the user (i.e., caller) running the WMI client application, which includes WMI scripts. In other words, the WMI service runs under Local System no matter whether the caller is trying to access WMI on a local machine or a remote machine.

To address this problem, Microsoft introduced the concept of impersonation in WMI 1.1. This concept isn't specific to WMI but rather to Distributed COM (DCOM). WMI uses DCOM to access the WMI service on remote systems.

Impersonation is a process in which calls made on behalf of a client must impersonate the client's security context to succeed. The client specifies this security context by setting the DCOM impersonation level that a WMI script will use. DCOM supports four levels of impersonation:

Because Microsoft added impersonation to WMI 1.1, you must set impersonationLevel to Impersonate (i.e., impersonationLevel=Impersonate) in scripts performing remote operations on WMI 1.1 clients. If the script doesn't include an impersonationLevel setting, WMI defaults to the impersonationLevel setting of Identify (i.e., impersonationLevel=Identify) and the remote operation will likely fail.

Given that impersonationLevel=Impersonate is a required setting to perform remote operations, Microsoft changed the default impersonationLevel setting from Identify in WMI 1.1 to Impersonate in WMI 1.5. Microsoft implemented the default impersonation level as a registry setting in the registry subkey HKEY_LOCAL_MACHINESOFTWAREMicrosoftWBEMScriptingDefaultImpersonationLevel. For more information about impersonation levels in WMI scripts, see the Microsoft article "Setting the DCOM Impersonation Level for the Scripting API" in the Microsoft Developer Network (MSDN) Online Library (http://msdn.microsoft.com/library/psdk/wmisdk/scintro_56jt.htm).

Because Microsoft changed the default impersonationLevel setting to Impersonate in WMI 1.5, you don't need to include

impersonationLevel=Impersonate

in your moniker string for the WMI 1.5 clients. However, you still need to include that setting in your moniker string for the WMI 1.1 clients.

So, you have two options. You can include the impersonationLevel=Impersonate setting for your WMI 1.1 clients but not your WMI 1.5 clients. Or, if you don't want to use two different moniker strings, you can upgrade your WMI 1.1 clients to WMI 1.5.

If you want to learn more about WMI, check out the repository of scripting resources on the Windows Scripting Solutions Web site (http://www.winscriptingsolutions.com). This Web-exclusive repository contains references and links to many sources of information on the various scripting technologies, including WMI.

In the scripting articles I've viewed online on the Windows Scripting Solutions and Windows 2000 Magazine Web sites, I've noticed the lines

BEGIN CALLOUT A

and

END CALLOUT A

in the listings. I can't find anything about these lines in VBScript or Windows Script Host (WSH) books, and they don't run at the command line. What are they?

BEGIN CALLOUT A and END CALLOUT A are not part of the listing's source code; nor are they valid VBScript or WSH statements. Callouts are markers unique to Windows Scripting Solutions and Windows 2000 Magazine. Callouts are used to direct readers' attention to a specific portion of a listing that is being discussed in the article.

To prevent the callouts from causing problems when you run the code in listings, you need to delete or comment out the callouts. To comment out these lines in VBScript code, you place a single apostrophe (') immediately before each callout. (Some listings might already have the callouts commented out.)

Do any WSH editors highlight the native commands in one color and the variables in another?

The feature you're describing is called syntax coloring or syntax highlighting. Several programmable editors support this feature for Windows Script (WS) language engines (i.e., VBScript and JScript). A few of the more popular editors are

PrimalSCRIPT is popular because of its PrimalSENSE feature. PrimalSENSE is similar to the IntelliSense feature found in Microsoft Visual Studio (VS), except that it works for VBScript and JScript rather than Visual Basic (VB).

All these editors offer a host of features, so create a list of what you need in an editor, then visit each product's Web site. Compare each product's feature list with your list. In most cases, you can download a free, limited-time trial of the full product to aid in your selection process.