Chapter 16: Active Directory Service Interfaces (ADSI)

The last two chapters of this book are intended for those administrators who want to learn how to use scripting methods for managing various directories, primarily Windows NT 4.0 and Active Directory-based domains (Windows 2000 and Windows .NET). Two of Microsoft's program products — Active Directory Service Interfaces (ADSI) and Windows Script Host (WSH) — allow administrators to implement a uniform approach to managing various platforms and program products. We will consider only a small part of this challenging problem area, and try to describe how to use ADSI for managing Windows NT 4.0- and AD-based directories (i.e., NT Directory Service, or NTDS, and Active Directory). The Visual Basic and VBScript are the programming languages selected for the examples provided, since Basic is a popular, simple, and compact language for illustrating ADSI programming. I do not want to overload the book with reference information nor overburden you with documentation that you can find elsewhere. (You can find and print out the necessary help files yourself.) Rather, I would like to consider some ADSI essentials and pitfalls that can be dangerous for beginners, and illustrate basic programming methods with simple but practical scripts and programs. (Most of them illustrate several methods at the same time.) I would strongly recommend that you download the ADSI SDK (also known as Active Directory SDK) from the Microsoft website, or use the online MSDN library (see links in Appendix A). You will need to have on hand many reference tables, definitions of interfaces and their methods and properties, constants, error codes, etc. You can print out the necessary documents as required.

ADSI as an Administrative Tool

ADSI is a very valuable facility for administrators, since ADSI is quite easy to learn and use, and can significantly help in performing bulk or routine operations. For example, you can write an export/import tool specific to your domain configuration, or a specialized migration utility. Although Windows .NET systems provide administrators with a new option of multiple selection of directory objects, scripting is a much more flexible way to manipulate various objects.

For an administrator, ADSI has two distinct advantages:

• ADSI can communicate with a number of platforms and products, including the following:

  • LDAP-compliant servers, such as Active Directory servers based on Windows 2000/.NET, and Exchange 5.x

  • Windows NT 4.0 Primary and Backup Domain Controllers

  • Internet Information Services (IIS)

  • Novell Directory Services (NDS) servers (4.x and higher)

  • Novell NetWare Servers (3.x)

• ADSI supports many languages like Visual Basic, VBScript or JScript, and Perl that are automation-aware (certainly, "full-fledged" languages, such as C/C++ are also supported), and uses the same component object model (COM). Scripting languages do not require a lot of preliminary study. You can combine or modify a few existing scripts, and quickly construct a working, individual tool.

To work with ADSI, it is very helpful to have some administrative tools on hand, such as the Ldp.exe and AdsVw.exe utilities, and the ADSI Edit and Active Directory Schema Manager snap-ins. These tools will allow you to control the results obtained from the developed scripts or applications, monitor Active Directory's state and values of object attributes, and do a lot of work, without which your programming efforts would be ineffective.

Remote Administration Scripts

The Windows 2000 Server Resource Kit contains a collection of scripts called Remote Administration Scripts. (Windows .NET Server Resource Kit will most likely include them, too. "Professional" versions of the Resource Kits also contain many useful scripts.) You can use these scripts not only for performing various administrative tasks, but as a "cookbook", too, while learning ADSI basics and creating your own scripts. All scripts are located in the Ras.cab file on the Windows 2000 Resource Kit CD and installed into the same folder as all other Resource Kit tools.