Do you have a scripting-related question or problem? You can send your question or problem to [email protected].
I've used VBScript for some time now. However, I'm frustrated that Windows 2000 (Win2K) and Windows NT system calls remain largely undocumented. I need to manipulate permissions (NTFS, share, Registry, and printer), the User Rights Policy, the SAM database, and NT Event Viewer logging and properties. The Microsoft Windows NT Server 4.0 Resource Kit typically doesn't offer command-line utilities that perform the tasks I need to accomplish. How can I use VBScript to perform these administrative tasks?
The Platform Software Development Kit (SDK) documents Win2K and NT system calls, otherwise known as the Win32 API and ancillary libraries. The documentation for the Platform SDK is available online or through paid subscription. You can access the free online library at http://msdn.microsoft.com/ library/default.htm.
I agree with your assessment of command-line utilities for the reason you state. Fortunately, the need for command-line utilities is steadily decreasing as Microsoft continues to expose core system and application functionality through a diverse set of automation interfaces that includes ActiveX Data Objects (ADO), Active Directory Service Interfaces (ADSI), Collaboration Data Objects (CDO), and Windows Management Instrumentation (WMI). I'm convinced that the days of not being able to automate a particular task on the Windows platform are numbered.
Let's take your list, for example. You can automate most of these tasks today if you use VBScript with the appropriate automation technology:
- You can manage NTFS and Registry permissions with ADSI 2.5 and the ADsSecurity.dll that the Microsoft Active Directory Service Interfaces Resource Kit includes. The ADSI Resource Kit is part of the ADSI 2.5 SDK. Go to http://www.microsoft.com/windows/server/technical/directory/ adsilinks.asp to download and learn more about ADSI 2.5 and its SDK.
- You can create, enumerate, and delete shares with ADSI 2.5's IADsFileShare interface or with WMI's Win32_Share class. You can set share permissions with WMI's Win32_Share, Win32_SecurityDescriptor, Win32_ACE, and Win32_Trustee classes. Visit http://www.microsoft.com/ntserver/management/techdetails/default.asp to learn more about WMI.
- The NT resource kit utility ntrights.exe remains the best way to automate the management of the User Rights Policy.
- You can manage the SAM database with ADSI 2.5's WinNT: provider.
- You can manage the event log with WMI's Win32_NTEventLogFile and Win32_NTLogEvent classes.
As this list shows, you can use VBScript with the appropriate automation interface to automate all but one of your tasks: managing printer permissions. For that task, you can use the Win32 API and the Platform SDK to develop a custom utility.
I downloaded Windows Scripting Host (WSH) 2.0 from the Microsoft Windows Script Technologies Web site. However, when I try to run a .ws file, I receive the error message There is no script engine for file extension .ws. Did I install WSH 2.0 incorrectly, or do I need to register the new engine for .ws files?
Microsoft changed the Windows Script File extension from .ws to .wsf in the final release of Windows Script (WS) 5.1, which WSH 2.0 uses. If you rename your .ws scripts to .wsf, WSH 2.0 will recognize those scripts as Windows Script Files.
I'm trying to use WSH 2.0's new IntelliSense and Syntax Coloring features on a Win2K system. How do you enable these features in Microsoft Visual InterDev 6.0?
You need to make several changes to enable WSH 2.0's IntelliSense and Syntax Coloring features in Visual InterDev 6.0. Perform the following steps to enable Tools Support for Windows Script:
- Create a text file that contains the lines
<job> <script language="VBScript"> </script> </job>Save the file, naming it New Windows Script File.wsf.
- Copy or move New Windows Script File.wsf to the default path C:\program files\microsoft visual studio\common\ide\ide98\newfileitems.
- Use Notepad to create a file that contains the code in Listing 1. The Registry key that callout A in Listing 1 highlights must be on one line and not wrapped as Listing 1 shows. Save the file, naming it wsedit.reg.
- Run wsedit.reg. A Registry Editor dialog box will appear that asks you to confirm the Registry changes. Click Yes. A second Registry Editor dialog box will appear that asks you to acknowledge the changes. Click OK.
- Start Visual InterDev. Select Tools, Options on the Visual InterDev menu bar.
- Select HTML in the treeview on the left side of the Options dialog box. Then select Start HTML pages in: Source in the Initial View section on the right side of the Options dialog box. Click OK to apply the change.
To verify that IntelliSense and Syntax Coloring now function when you edit Windows Script Files in Visual InterDev 6.0, perform these steps:
- Select File, New File on the Visual InterDev menu bar.
- Select the New Windows Script File icon in the New File dialog box. Click Open. A New Windows Script File# edit window will open in the Source view, where you can see whether Syntax Coloring is working.
- Type the following lines between the opening and closing <script> elements:
Set oNet = CreateObject ("WScript.Network") oNet.
When you type the opening parenthesis after CreateObject, IntelliSense will offer Parameter Info. In addition, when you type the dot operator (i.e., the period) after oNet, IntelliSense will display the List Members pop-up menu. This pop-up menu lists the methods and properties that WSH's Network object exposes.
You must use the .wsf format for IntelliSense and Syntax Coloring to work. Raw VBScript or JScript source files don't support these features. If you prefer not to run your scripts as Windows Script Files, you can remove the opening and closing <job> and <script> elements and rename your script with the appropriate extension (i.e., .vbs or .js).
My employer mandates Perl as the company's scripting language. VBScript isn't an option. Can you use Perl to create WSH scripts?
Providing you have an ActiveX scripting engine that plugs into the WS architecture, you can use Perl (or any other ActiveX-compliant scripting language) to create WSH scripts. For example, ActiveState offers an ActiveX-compliant Perl-based scripting engine called PerlScript. You can use PerlScript to develop WSH-compliant scripts. ActiveState includes the PerlScript engine with its ActivePerl distribution. When you run ActivePerl Setup, PerlScript installs by default. PerlScript relies on the core Perl runtime to function. You can download ActivePerl for free from ActiveState at http://www.activestate.com.
After you install ActivePerl, you can test the PerlScript installation with the script in Listing 2. Here's how the script interacts with WSH's Network object. The script begins by creating a reference to the Network object. After the script initializes the $objNet reference, the script uses WSH's Echo method to display, or echo, the values of the three properties that the Network object exposes (i.e., ComputerName, UserDomain, and UserName). Next, the script calls the EnumNetworkDrives method that the Network object exposes and echoes the result. The $objNetDrives variable holds the result that the EnumNetworkDrives method returns. If the script finds a mapping to "Z:" in the result, the script uses the Network object's RemoveNetworkDrive method to disconnect the network drive. This action prepares the script for the next statement, in which the script maps "z:" to the local C$ administrative share. The script ends by enumerating and echoing the mapped network drives a second time.
As you can see, you can use Perl to create WSH scripts. However, you can achieve the same result in a more elegant and efficient manner by using Perl's Win32-based modules and extensions. In this case, you can use the Win32::OLE module instead of WSH.