ADSI Abstracts Namespace Manipulation | Windows NT/2000 ADSI Scripting for System Administration

ADSI Abstracts Namespace Manipulation

Despite common misconception among many system administrators, ADSI is not a programming language. It is rather a collection of COM objects that allows programmatic manipulation of any supported namespace. ADSI thus provides a layer of abstraction between a programming language and the processes required to manipulate a namespace. This abstraction is taken a step further when using OLE automation controllers, such as Visual Basic, which are able to automate the creation of the underlying OLE code. Visual Basic can make all necessary IDispatch interface calls, leaving the developer free to concentrate on the business logic of the application rather than the inner workings of COM.

To provide a non-technical example of this abstraction technique, assume you have hired a translator who speaks fluent English, Spanish, German, French, and Italian. Although you are fluent only in English, with this translator at your side, you now have the ability to communicate with almost anyone you might encounter in your travels about Western Europe. Because ADSI knows how to speak to Windows NT, LDAP, and NDS/Bindery namespaces, ADSI can be viewed in a similar fashion to this translator. ADSI can also manipulate the IIS Metabase, third-party products, and even custom namespaces by implementing custom-developed service providers and extensions to directory service schema.

Note

The database schema is responsible for defining the available fields for storing data. "Extending" the schema refers to the definition of additional fields in which to store custom information, such as a field to hold the serial number of a Security Dynamics access token given to an employee, or other enterprise-specific data.

For a non-technical example, consider the U.S. Postal system. The post office defines the following address schema to assure proper delivery of a letter:

Name

Address

City, State ZIP

Postage Amount

Sometimes, however, we must extend the schema to include an apartment number, floor location, or mail stop to further derive the recipient's location .

Abstraction Technology

The concept of generating code that can span multiple products or even multiple vendors is not new to developers familiar with the Windows platform development process. Just as the Telephony Application Programming Interface (TAPI) masks the low-level language required to access a telephony device, ADSI provides an interface to mask the required API calls to perform the requested actions in multiple namespaces. In TAPI, a modem vendor is responsible for supplying a device driver that complies with the TAPI standard. Thus, an application developer working on a telephony application can forget about the hundreds of modem types available on the market today and instead write code that will work with any TAPI-compliant hardware.

Microsoft has not limited this concept of abstraction only to hardware devices. The same abstraction technology can be found when writing mail applications using the Messaging Application Program Interface (MAPI) interface, and even database connectivity when using the Open Database Connectivity (ODBC) interfaces. Using ADSI, this abstraction permits a developer to learn only the syntax specific to each ADSI provider instead of learning the API calls necessary to manipulate each individual namespace.

By the very nature of this abstraction, ADSI allows corporate developers to establish management applications with little concern over future infrastructure decisions that might otherwise force the application into a major redevelopment effort or extinction . To give a brief example of this concept, consider the following Visual Basic code that creates a user in the Windows NT namespace:

 Dim Container as IADsContainer 'Establish Container variable of type IADsContainer Dim User as IADsUser 'Establish NewUser variable of type IADsUser 'Bind to the WinNT namespace and instantiate the ADSNT.DLL object if it is not active: Set Container = GetObject("WinNT://UserDomain") 'Create a new user in the namespace: Set User = Container.Create("User","TEck") 'Write the information to the namespace User.SetInfo

Although the WinNT provider still functions properly in Windows 2000, to perform a user creation directly in the proper container within the Active Directory, examine the following Visual Basic code:

 Dim Container as IADsContainer 'Establish Container variable of type IADsContainer Dim User as IADsUser 'Establish NewUser variable of type IADsUser 'Bind to the LDAP namespace and instantiate the ADSLDP.DLL object if it is not active: Set Container = GetObject("LDAP://ldap_server/OU=Engineering,DC=PerotSystems, DC=COM") 'Create a new user in the namespace: Set User = Container.Create("User","cn=Teck") User.Put("sAMAccountName", "Teck") 'Write the information to the namespace User.SetInfo

Even if you are not familiar with Visual Basic, you can see that the code segments for the WinNT and LDAP namespaces are strikingly similar. Notice that while the arguments passed for binding the namespace and defining the user may differ between the WinNT and LDAP providers (because of the requirement to specify the location of the object within the directory), the syntax used to manipulate the ADSI interfaces is nearly identical. The parameters differ per ADSI service provider to accommodate the requirements of each underlying directory service. Unlike the flat architecture found in the WinNT namespace, the LDAP service provider allows the administrator to explicitly define the location within the namespace in which to create the user object.

Without ADSI, you would need to learn how to manipulate each namespace vendor's API to create a new user, resulting in longer development times and reduced adaptability to changes in the enterprise infrastructure. In today's heterogeneous environment, such a task would inevitably result in a huge learning curve for an administrator simply wishing to automate a few manual tasks , and probably would negate any benefits derived from such an automation exercise. ADSI clearly lowers the bar to enable almost any administrator (even those new to programmatic administration methods ) to develop custom administration applications for his or her organization.

If careful planning and good programming practices are exercised when developing applications utilizing ADSI, a single code base can be established that can span any of the ADSI provider namespaces without future code modification.

ADSI Versus Native Vendor Namespace API Performance

Whether discussing technical architecture or the non-technical aspects of daily life, logic dictates that the introduction of each layer of abstraction should significantly decrease the overall performance (or efficiency) of a system. Microsoft claims that despite the layer of abstraction ADSI provides between the application and the native API, the performance delta between using native API calls and using ADSI is negligible. Although this may seem questionable, the negligible performance degradation experienced when using ADSI is due to the efficiency of the routing layer that handles calls between the application and the raw processes to manipulate each respective namespace. For most administrators, the relative ease of ADSI far outweighs any slight performance advantages the native API calls might maintain.

Top