Do you have a scripting-related question or problem? You can send your question or problem to [email protected].
I've read that Windows Scripting Host (WSH) requires Internet Explorer (IE) 3.0 or later. I'm using IE 4.0, and I've tried to run some of the WSH scripts published in the Win32 Scripting Journal. When I double-click one of the .vbs files from Windows Explorer, the Open With window asks me which program I want to use. I've searched my hard disk, but there is no wscript.exe or cscript.exe program on my system. What am I missing?
Although WSH requires that you install IE 3.0 or later on your system to run WSH scripts, WSH isn't part of the IE installation. In a way, this situation is rather ironic considering the number of other options that IE does include. Nevertheless, you can download WSH for Windows 95 or Windows NT from Microsoft's WSH Web site at http://msdn.microsoft.com/scripting/windowshost. After you've displayed the WSH Web page, click Downloads to download the self-extracting executable (.exe) file that you can use to install WSH. After you've installed WSH, you can download a reference guide that documents the WSH objects. You can find the WSH object reference guide by selecting Documentation, followed by the Technical Paper link.
In Win98, WSH is an installation option. Microsoft also plans to include WSH with Windows 2000 (Win2K).
Where can I find information about Active Directory Service Interfaces (ADSI)?
Information about ADSI is slowly becoming available online and in print. You can find ADSI information online at these Web sites:
You can also visit the Web sites at http://wsh.glazier.co.nz and http://msdn.microsoft.com/scripting. These Web sites include example WSH scripts that use ADSI.
As for print media, you can check out Alistair G. Lowe-Norris' 12-part series "An ADSI Primer" in the Win32 Scripting Journal. (Part 3 of this series, which began in the January 1999 issue, starts on page 7.) The series is based on Alistair's forthcoming book about Win2K's Active Directory (AD), which O'Reilly and Associates will publish. You can also check out Steven Hahn's ADSI ASP Programmer's Reference (Wrox Press, 1999).
I'm experiencing password synchronization problems in a large network that consists of an NT domain with Win95 clients. By default, users' machines prompt them to create a local password list (PWL) password on the first network logon and to change that password every 60 days in accordance with the domain's account policy. Users can create a PWL password initially, but they can't change the password later.
If I delete the local *.pwl files and have the user reboot, log back on to the network, and create a blank PWL password, future domain password changes don't result in problems. This solution, however, strains the Help desk and confuses users. How can I script a logon routine that accomplishes the same result?
To solve your Win95 password synchronization problems, you can use ScriptIt to automate the password change process. But before you can script this solution, you have to know how to change passwords manually with the Passwords applet:
- Select Start, Settings, Control Panel, Passwords.
- In the Password Properties dialog box that appears, select Change Windows Password.
- In the dialog box that appears, click OK. (Don't check the Microsoft Networking password box, because it changes the domain password, not the PWL password.)
- In the new Change Windows Password box, have the users type their old password in the Old password text box. Leave the New password and Confirm new password text boxes blank. Click OK.
- If the users enter their old password correctly, a message appears stating that the PWL password change was successful.
Now that you know how to use the Passwords applet, you need to install ScriptIt on each client machine. You can download ScriptIt from Microsoft's Web site (http://www.microsoft.com/ntserver/nts/deployment/custguide/scriptit3.asp).
After you've installed ScriptIt, you can use the script in Listing 1. This script changes the current user's Win95 password (e.g., abc) to a blank password. However, you must obtain the user's current password to plug into the old password field in the script. (You face this requirement in any script-based solution, unless you want to decipher the contents of the PWL file.) One approach is to wrap the ScriptIt snippet in a wrapper that you write in WSH with Visual Basic Script (VBScript) and use VBScript's InputBox box function to prompt users for their current password.
This ScriptIt solution solves the problem with prompted PWL password changes. However, the script doesn't work at logon, because Control Panel's Password Properties aren't accessible at the time the logon script runs.
How can I translate the Visual Basic (VB) code in Listing 2 into VBScript code?
Listing 3 shows the VBScript code you're aiming for. As you see in Listing 3, you first need to remove your typed declarations (i.e., as IADsGroup and as IADs), because VBScript doesn't understand typed declarations. You then need to change your Debug.Print statement to the WSH equivalent, WScript.Echo. Finally, you need to drop the variable name (i.e., Member) in the Next line of the For Each...Next statement.
How can I automate the process in which you give users dial-up access?
You can use a Perl-based or a Component Object Model (COM)-based solution. The Perl solution uses the Win32::RasAdmin module with the script Listing 4 shows. You can obtain the module at ftp://ftp.roth.net/pub/ntperl/rasadmin/971008/bin. Download the RasAdmin_Build_311.zip file, following the installation instructions in the accompanying README file. (The RasAdmin_Build_311.zip file is for ActiveState's Perl for Win32 Version 5.004 Build 311 or later.) After you install the Win32::RasAdmin module, you can alter the code in Listing 4 to meet your needs.
The COM-based solution uses the NTAccess.RAS automation server available at http://www.zaks.demon.co.uk/code. You can use this automation server with many scripting environments and languages, including Perl, VB, Visual Basic for Applications (VBA), Active Server Pages (ASP), and WSH with VBScript or JScript.
Do I need to compile .pl files to run a Perl script?
Perl is an interpreted language. You typically don't compile interpreted languages, because an interpreter automatically compiles the files when you run the script. You need to install the Perl interpreter on the machine that you want to run the Perl script on. You then pass the script to the interpreter with a command such as
C:\> perl myscript.pl
If myscript.pl contains valid Perl code, the Perl interpreter parses and runs the script. Like Java, the interpreter performs a compilation pass, during which it produces byte code to speed up the script's execution. However, the compilation pass doesn't produce an .exe file.
I want to use Perl with the Win32::OLE module to access network functions and databases. Where can I obtain information about the automation server's exposed objects, methods, properties, and optional events?
Developers typically supply this information with the automation server in the form of a Help file or documentation. If developers don't supply this information, the best place to start looking for information is the Microsoft Developer Network (MSDN) at http://msdn.microsoft.com/developer. For example, you can find detailed information about the ActiveX Data Object (ADO), Collaboration Data Objects (CDO), and ADSI object models on the MSDN Web site.
Another source is the OLE/COM Object Viewer utility (OLEView.exe), which you can find in Visual Studio (VS) or the Microsoft Windows NT Server 4.0 Resource Kit. This utility displays and provides access to all the objects, methods, properties, and optional events related to the automation components that you have installed and registered on your system.
If automation is new to you, you might want to start with the article "Your Unofficial Guide to Using OLE Automation with Microsoft Office and Microsoft BackOffice," which you can obtain at http://www.microsoft.com/officedev/ articles/omg.htm. Keep in mind that most of Microsoft's examples are in VB or VBA, so you need to adjust the code as necessary.
Information is also available from Microsoft's Office Developer's Forum Web site (http://www.microsoft.com/officedev). If you perform a Site Search on object model, you can find references to the object models that Microsoft Office applications expose.
How can I access NT's Performance Monitor with Perl scripts?
You have several options. First, you can use a traditional Perl approach: Amine Moulay Ramdane's Perl Win32 IPerfmon module. This module provides access to NT's perflib (i.e., performance counters) from Perl scripts. To use IPerfmon, you must first install Aldo Calpini's Perl Win32 API module. You can download both modules from http://www.generation.net/~cybersky/Perl/perlmod.htm.
Another option is the NTAccess.Performance COM component available from http://www.zaks.demon.co.uk/code. You can use this component with any language that supports COM automation.
In the long term, you're better off becoming familiar with Microsoft's Windows Management Instrumentation. WMI is a Web-Based Enterprise Management (WBEM) implementation that Microsoft introduced as part of NT 4.0 Service Pack 4 (SP4). WMI includes a COM-based performance counter provider. For more information about WMI, see http://msdn.microsoft.com/developer/sdk/wbemsdk/default.htm.
Note that the second two options are COM-based. As a result, you need to use Perl's support for OLE automation via Win32::OLE with them.