Design Goals of the ADSI Object Library

The ADSI library is the strategic library for accessing directory objects and information from Microsoft, and it doesn't matter whether this information is in Exchange Server or the forthcoming Active Directory. When designing ADSI, Microsoft had three primary goals in mind. First, ADSI had to be based on COM and on providers to access directory information. In a provider-based model, the client interacts with the COM interfaces exposed by the ADSI library, and the installed providers convert the calls in the interfaces into function calls that access the targeted directory provider. The provider model allows the same calls to be used in an ADSI client application to access any type of directory with an ADSI provider. ADSI ships with four primary directory providers—a Microsoft Windows NT directory provider for Windows NT 4.0, a Novell NDS provider, a Novell Netware Bindery provider for Netware versions before 4.x, and an LDAP provider—but you can write your own because the ADSI provider architecture is extensible. We will focus on the built-in LDAP provider in this chapter because it supports accessing and updating the Exchange Server directory.

What Is the Active Directory?

The Active Directory is the directory technology integrated into Microsoft Windows 2000 Server products. It is the next generation of directory services offered by Microsoft. Because the Active Directory is built on Exchange Server technology, you will already be familiar with some of its capabilities and APIs. By placing information in the Exchange Server directory, you can easily migrate to the Active Directory by using the replication capabilities of the Exchange Active Directory Connector, which is included with Windows 2000 Server.

Microsoft's second goal for ADSI was to allow developers to use any COM-based development tool with the object library, including Visual Basic, Visual C++, Java, VBScript, and JavaScript. You can decide which tool is the best for creating your ADSI Exchange Server applications. In this chapter, I use VBScript and Microsoft Active Server Pages to create a web-based administrator program for Exchange Server. However, this application easily could have been written in Visual Basic or Java.

The third goal of ADSI was to provide you with a single directory API as a replacement for multiple directory APIs. With Exchange Server, you can use CDO or Directory API (DAPI) to access information stored in the Exchange Server directory. With the Windows NT directory, you can use the Win32 directory functions to access information stored in the Windows NT directory. However, depending on your application, you can more easily write to a single set of interfaces and use different providers for these directory services rather than learn two or three different APIs. With ADSI, you need to learn only one API to use a multitude of directory services.