ADSI Architecture

Microsoft® Windows® 2000 Scripting Guide

« Previous | Next »   

Understanding architectural aspects of Active Directory is a critical part of writing ADSI scripts that perform a wide variety of tasks efficiently. In fact, the schema of the underlying directory service ultimately defines the rules for using ADSI to programmatically administer the directory. For example, an ADSI script that creates an object in Active Directory must also write mandatory attributes defined for the object that are not automatically set by the directory.

Another critical part of writing ADSI scripts is having an understanding of the ADSI object model, the ADSI file and logical components, the various ADSI providers available for directory access, and the interfaces that make performing tasks possible.

ADSI Object Model

ADSI is a collection of dynamic-link libraries (DLLs) that are used by client applications such as Windows Script Host (WSH) and Active Directory Users and Computers to administer directory services such as Active Directory.

When you perform a binding operation in an ADSI script, the script uses the moniker in the ADsPath to load the proper ADSI provider DLL. For example, specifying the LDAP moniker loads the LDAP provider, (Adsidp.dll). The ADSI provider DLL creates or instantiates a Component Object Model (COM) object. The COM object is given the name you provide as a reference in the Set statement, for example, objUser, objGroup, or objDomain.

Each instantiated object contains interfaces. An interface is a grouping of related methods. As all of the preceding listings demonstrated, methods allow you to perform administrative tasks upon a directory. For example, you used the Create, Put, Get, and Delete methods to perform create, write, read, and delete tasks in Active Directory. All of these methods are contained in a single interface named IADs. Figure 5.7 shows the relationship between a binding operation, a provider, a COM object, its interfaces, and a directory.

Figure 5.7   Creating a COM Object Representation of a Directory Object

Creating a COM Object Representation of a Directory Object

In Figure 5.7, the LDAP provider instantiates a COM object. The provider determines that MyerKen in the HR OU of the na.fabrikam.com domain is a user account object, so it creates a COM object with the appropriate interfaces for interacting with a user account object. Only three interfaces, IADs, IADsUser, and IUnknown appear in the figure. IADs and IADsUser are the two interfaces that you are most likely to use from an ADSI script to interact with an Active Directory user account object. The IUnknown interface is attached to every COM object and is the base interface for all other interfaces.

The Set statement in Figure 5.7 provides a reference to the object and names the object objUser.

ADSI Installation Components

ADSI resides in the systemroot\System32 folder of Microsoft® Windows NT® based client computers. The file names are ActiveDS.dll, ActiveDS.tlb, and DLLs starting with the ads prefix, such as Adsldp.dll. An installation of ADSI also updates some DLLs, such as Wldap32.dll.

ADSI is a system component on computers running Windows 2000 and Microsoft® Windows® XP operating systems. Therefore, you do not have to install it separately from the operating system. In contrast, ADSI is not a system component on computers running Microsoft® Windows® 95, Windows® 98, Windows® Millennium Edition (Me), or Windows NT 4.0. This means you must install it to use it on these computers. For information about how you can install ADSI on client computers, see the Active Directory Service Interfaces link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

---

 Send us your feedback

« Previous | Next »