Do you have a scripting-related question or problem? You can send your question or problem to firstname.lastname@example.org.
I've installed a Windows 2000 network with Microsoft Exchange 2000 Server. The domain is running in native mode. I want to create a logon script that performs certain tasks (e.g., connect to a printer or drive) based on whether the user logging on is a member of a group. How can I create this script?
In the user's logon script, you can use Active Directory Service Interfaces (ADSI) to check the user's group membership. You can use one of two approaches:
- You can bind to the target User object in the directory, then retrieve and enumerate the User object's memberOf attribute.
- You can bind to the Group object and call the Group object's IsMember method.
Let's look at the second approach because it's more efficient.
The script Logon.vbs in Listing 1 shows how to use the IsMember method to test whether the user logging on is a member of the Engineers group in the americas.acme.com domain. Here's how I created this script. I began by initializing a variable named strGroupDN with the distinguished name (DN) of the target group (i.e., the group against which the user logging on is tested for membership). I used strGroupDN to connect to the target group, then initialized objGroup with the reference that the bind operation returned.
Next, I created a reference to ADSI's ADSystemInfo object. This object has several important properties and methods that let you determine the DN for the current domain, site, computer, and user. These DNs reflect the state of the current process as it relates to the domain, site, computer, and user. In this case, I used the ADSystemInfo object's UserName property to retrieve the DN of the user running the current process, which is the logon process.
With this DN in hand, I called the Group object's IsMember method and passed the method the ADsPath of the object to test. The ADsPath is the provider name (in Active Directory—AD—the provider name is LDAP:) followed by two slashes, then the target object's DN. IsMember returns True if the user is a group member and False if the user isn't a group member. I used an If...Then...Else statement to echo an appropriate message based on the IsMember method's outcome. Callout A in Listing 1 shows the point at which you can add code to perform certain tasks (e.g., connecting to printers or drives) if the user is a group member.
If you use Logon.vbs, you need to keep two considerations in mind. First, if your domain is running in native mode (i.e., only Win2K-based domain controllers—DCs—can participate in the domain), AD supports nested groups. Logon.vbs doesn't account for nested groups. Thus, if you're using nested groups, you need to modify Logon.vbs.
The second consideration is that a user's Primary Group ID (Domain Users, by default) isn't part of the User object's memberOf attribute or the Group object's Members collection. As such, you can't use IsMember to check Primary Group membership. AD handles Primary Groups differently because they're considered a special case.
Can a DLL that includes ADSI code work in a transactional environment?
Unfortunately, AD and ADSI don't support transactional environments at this time.
I'm trying to write a script that loops through a list of remote servers and uses Windows Management Instrumentation (WMI) to obtain each server's WINS server configuration. However, the script retrieves my workstation's IP addresses instead of the remote servers' IP addresses. Listing 2 contains the problematic VBScript code. What am I doing wrong?
The problem is that you're trying to use two different WMI objects to perform one task. The WMI scripting library provides two distinct mechanisms through which you can connect to WMI and perform WMI-related tasks. The two mechanisms are
- The WMI moniker (i.e., Winmgmts:)
- The WMI scripting library's SWbemLocator object
The WMI moniker lets you use one line of code to express a complete object path to a specific instance of an object or collection of objects. Although the WMI moniker is extremely powerful and concise, it doesn't let you specify alternative credentials to connect to a remote WMI service.
Unlike the moniker, SWbemLocator provides a more traditional method-based approach to connecting to a local or remote WMI service. SWbemLocator's ConnectServer method provides parameters that let you specify an alternative username and password to connect to a remote WMI service.
For all practical purposes, Winmgmts: and SWbemLocator are mutually exclusive, so you need to decide which approach to use. You can easily use either approach to check WINS server configurations on remote machines. Listing 3, page 5, demonstrates the moniker approach; Listing 4, page 5, shows the SWbemLocator approach.
To learn about the WMI moniker syntax, go to http://msdn.microsoft.com/library/psdk/wmisdk/scintro_6tpv.htm. To learn about the SWbemLocator syntax, go to http://msdn.microsoft.com/library/psdk/wmisdk/scref_2oqa.htm.