| Downloads |
|---|
| 20137.zip |
Do you have a scripting-related question or problem? You can send your question or problem to [email protected].
When I use the command shell's Set command in a command shell window, I find that the command doesn't work with System environment variables. How can I make System environment variables available throughout my Windows 2000 system?
Win2K has four types of environment variables: Process, System, User, and Volatile. You can use the Set command to modify only Process environment variables, so the behavior of your Win2K system is appropriate. To add, modify, or delete System environment variables, you can use several tools, including Windows Script (WS), Windows Management Instrumentation (WMI), a registry editor (i.e., regedit or regedt32), or the Control Panel System applet.
The script in Listing 1 shows how you can use WS to add an environment variable called MyNewEnvVar to the pool of System environment variables. To add an environment variable, you need to use the WshEnvironment::Item property. However, WSH doesn't directly expose the WshEnvironment object. You need to indirectly access this object through the Shell object. First, you use VBScript's CreateObject function to create an instance of the Shell object, as callout A in Listing 1 shows. Then, you use the Shell::Environment property to access the WshEnvironment object and call the WshEnvironment::Item property, as callout B in Listing 1 shows. In this case, you're adding MyNewEnvVar to the collection of System environment variables and setting MyNewEnvVar's value to "The quick brown fox jumps over the lazy dog's back."
The code between callout A and callout B in Listing 1 displays all the System environment variables before you add MyNewEnvVar. To show that you've indeed added MyNewEnvVar to this collection, the script again displays the System environment variables, as the code at callout C in Listing 1 shows. Finally, the script displays the Process, User, and Volatile environment variables.
By default, VBScript files run with WScript. How can I make VBScript files automatically run with CScript?
Listing 2 contains code that changes the scripting host from WScript (Windows-based host) to CScript (console-based host) on the fly. Changing the default host on the fly might seem simple—just use VBScript's CreateObject function to create an instance of the Shell object and use the Shell::Run method with cscript.exe to run CScript instead of WScript. Unfortunately, the solution isn't quite that easy because you also need to deal with
- The appearance of a new command prompt window
- Any arguments passed to the original script
Using Shell::Run to run CScript opens a new command prompt window by default. The appearance of this new command prompt window is an easy problem to solve. You can hide the new window by specifying a value of 0 for intWindowStyle—the Run method's second parameter. I create a constant named vbHide for this purpose in Listing 2. Using a constant instead of the value 0 produces code that's easier to read. You need to make sure that your script doesn't write to STDOUT because, with the window hidden, you won't be able to see the output.
The more challenging problem is dealing with the arguments. You must repackage the arguments so that you can pass them to the second invocation of the script. In Listing 2, I solve this problem with the PoundBangCScript subroutine. This subroutine repackages the arguments, including those that contain white space (i.e. one or more spaces).
You can use this code with any scripts you write in VBScript. To use the code, add the PoundBangCScript subroutine to the bottom of the script and call the subroutine at the beginning of the script, as Listing 2 demonstrates. The code at callout A in Listing 2 verifies that the arguments were correctly repackaged by writing them to a file called arguments.txt.
How can I use Active Directory Service Interfaces (ADSI) to set Windows NT Server 4.0, Terminal Server Edition (WTS) settings, such as the Terminal Server Profile Path? I know that I can use third-party utilities such as Wilson WindowWare's WinBatch to change this setting, but as a contractor, I don't always have these tools available at clients' sites.
Unfortunately, you can't use ADSI to modify a user's Terminal Services Profile Path or any other WTS settings. If a third-party solution is unavailable, you can use Microsoft Visual Basic (VB) in conjunction with WTSAPI32 to write a custom component. For more information about writing such a component, see Thomas Eck, "Practical Usage of ADSI: Using COM Objects to Manage WTS Profile Paths, Part 1," page 14.
