The Visual Basic Scripting-Environment
In this topic I would like to explain briefly the framework in which we develop our scripts for manipulating directories.
Due to the fact that Visual Basic Script is an easy to learn variant of scripting which offers almost all imaginable possibilities for accessing a directory service, we will concentrate on this scripting language in the SelfADSI project.
The following contents are available here:
The Windows Scripting Host
If you want to run ADSI scripts under Windows, you need the runtime environment of the Windows Scripting Host (WSH). This module builds the basic framework for handling scripts - either as standalone scripts or as part of a HTML document loaded from a web browser.
In this context the Windows Scripting Host isn't able to run only Visual Basic Scripts, but can also handle other types of scripting languages such as JavaScript, Perl, REXX or Phyton. For this purpose, different script engines can be actively directed by the WSH. Modern Windows systems already include script engines for VBScript und JavaScript (JScript). You can download the latest version of the Windows Scripting Host including VBScript and JScript from the MSDN website:
Download site for the Windows script environment (WSH / VBScript Engine / JScript Engine) version 5.6
Download site for the documentation according the Windows Script version 5.6
Writing Scripts - Script Editors
It is possible to write VB scripts with any text editor, for example with the standard Notepad editor. Simply save the script you write there as an *.vbs file.
But there are much more comfortable ways of developing scripts (for example in a way that shows you the key words of the script in another font color): With one of the various third party script editors. A few examples will be given here examplarily.
The ASE
Editor (Admin Script Editor) e.g comes with syntax highlighting
in the source code:
VBSEdit offers the intellisense technique (known from the Microsoft Visual Studio IDEs), which can auto-complete syntactical elements like commands or keywords while entering them in the editor. An object browser shows all the members (methods and properties) of script objects. Thus, it is very recommendable and not expensive:
A classic among the script editors: PrimalScript offers something beyond the abilities of VBSEdit, it can fold and unfold syntactical structures like "If Then .... Else....End If". So you can easily manage to get an overview even in very complex scripts:
When you choose your script editor, please keep always in mind that it's no mistake to be used to the editor you will find on all windows systems: Notepad. However, a real advantage in the use of script editors is the possibility to call the microsoft script debugger directly within the editor environment.
Running scripts
Scripts can be run by swapping them in a HTML page and this website being opened by a web browser. However, for administrative tasks standalone scripts are more practical that are used in the command shell. This works with following command:
C:>cscript [//WSH parameter] <path of script file> [Script parameter]
Thus, e.g.:
C:>cscript //nologo n:\admin\create-user.vbs /u:phil /d:"cn=Philipp,dc=company,dc=kashmir,dc=net"
Scripts can also be run by the use of the 'sibling tool' wscript - the difference between the two is the way how outputs are handled that were produced e.g. with the function WScript.Echo.
- cscript shows outputs in the terminal window (cmd-command shell) in which the script was started.
- wscript shows outputs in a Windows message box.
Lets have a look at the following simple script, which is stored in the file hello.vbs:
Call by cscript hello.vbs:
Call by wscript hello.vbs:
By the way, the call parameter of the two utilities cscript and wscript are identical:
MSDN
info about the commandline parameter for cscript and wscript
In most cases cscript is used. Thus, each output is simply shown in a new line of the terminal window, whereas wscript opens a new message popup window for every line of output! Furthermore, with cscript you can send the script output to a text file by using pipelining.
Running Scripts directly just like programs
After all you can configure your windows shell to run VBS files in a command window directly, so that this call
C:>cscript [//WSH parameters] <path to the script file > [script parameters]
is NOT neccesary any more. Instead, it would be great if we could just start the script like a normal program by entering the script name on the command line and hitting enter. This can be done by changing the appropriate registry key:
HKEY_CLASSES_ROOT\
VBSFile\
Shell\
Open\
Command\
(Standard) REG_EXPAND_SZ: cScript.exe //nologo "%1" %*
After that registry change you can start the 'Hello World' script as follows:
You can find a registry import file for automating the the neccessary changes here:
 |
Download vbsfile.reg |
Debugging Scripts
You can debug Visual Basic Scripts step by step with the Microsoft Script Debugger.
Download Website for the Microsoft Script Debugger
Originally the debugger was made to debug scripts which are embedded in HTML. To run a Visual Basic Script directlry in the Debugger you have to insert the command "stop" into you code. When you call the script with the parameter //x, then the debugger pops up just on that line where you inserted the stop command:
C:>cscript //x test.vbs
But the Microsoft script debugger does not have very comfortable debugger functions like the evaluation of variable values. And you cannot edit the script source code directly in the debugger window. Therefore I would recommend a specialized script editor for this task, for example VBSEdit:
Encrypting Scripts
Maybe you want to give your script to other people but you dont want to let them know the source code of this script? There is a very simple (but quite low-level and weak) encryption possibilty with the Microsoft Script Encoder. You can encrypt complete scripts on the command line - the encrypted script can be still run on all computers where the original script could have be run also.
Download website for the Mcrosoft Script Encoder
ADSI Versions
Currently the ADSI interface is availble in version 2.5. This version offers the access not only to native LDAP directories like Active Directory. You can also access other (old-fashioned) directory services with the so-called providers. There are ADSI-Providers for NT 4.0, Novell NetWare 3.x, Netware Directory Service and also for the Metabase of the Microsoft Internet Information Service.
If you want to find out what ADSI version is installed on your computer, you have to look in the registry. There the version is stored in the following key:
HKEY_LOCAL_MACHINE\
SOFTWARE\
Microsoft\
Active Setup \
Installed Components\
{E92B03AB-B707-11d2-9CBD-0000F87A369E}
Version REG_SZ
Oddly enough - the version listed in this key is in modern Windows operating systems "5,0,00,0". Nevertheless in this case the version is 2.5. There is a detailed description how to find out the ADSI-Version by means of evaluating the file versions of the according DLL files on the Microsoft website: Knowledge Base Article Q216290.
Using ADSI under Windows 2000/XP/Vista/7 and Windows 2003/2008
For these operating systems the libraries of the ADSI interface are included by default. So you dont have to prepare anything if you want to run a script which creates and uses ADSI objects and which access a directory service in this way. To detect the version of ADSI your computer runs with you can follow the instructions outlined above in the last paragraph.
Using ADSI under Windows 9x und Windows NT
For these operating systems the ADSI interface is not included by default. A Script using ADSI obejcts and functions would raise a runtime error similar to this:
If you want to use ADSI under Windows 9x or Windows NT, you need the so called Active Directory Extensions for Windows NT 4.0. This is a free driver which is used to adds DFS and printers search capabilities to NT and W9x clients. And one of the advantages of these additional features is the implementation of the ADSI interface. This driver is also known as "DSClient". The setup requires a rebott on the computers.
Download website: The Active Directory extensions for W9x und NT