Chapter 1. Overview of the Active Directory Service Interfaces (ADSI)
| The job description of a system administrator rarely includes reference to the tedious tasks that are inherently part of the responsibilities of most support professionals. To have time for the more interesting aspects of their jobs, many administrators turn to scripting languages to automate monotonous tasks. While Microsoft included several command-line utilities in the original release of Windows NT, these tools were somewhat limited in terms of functionality and offered the administrator no option but to run these scripts from a command prompt. Although this may be adequate for scripts intended for limited internal use, shelling to a command prompt is a far from acceptable solution for inclusion in a Graphical User Interface (GUI) application. Thus, to access additional functionality not included in the command-line tools, or to avoid the need to shell to a command prompt, developers were forced to directly access the appropriate Application Programming Interface (API) to perform the desired action. Whereas most C++ programmers are intimately familiar with manipulating APIs, most system administrators familiar with shell scripting or even Visual Basic found themselves in some rather uncharted territory. Administrators wishing to automate tasks beyond the functionality provided by the command-line tools had no choice but to turn to third-party tools, to use direct API calls, or to wait for someone else to develop an easier method to automate the administrative tasks at hand. Soon, a number of products appeared to rescue the administrator from this seemingly impossible situation. For administrators familiar with Perl scripting, the AdminMisc extensions allowed user and domain management using a relatively simple scripting language. However, while these extensions work well for managing the Windows NT environment, they do not fit into Microsoft's current strategic direction for administering Windows environments. And although shell scripting is extremely effective, it does not fit in well with today's GUI application development standards, nor can it easily scale to fit the needs of larger enterprises. Countless other products, including WinBatch and Kixtart, were developed to help perform some of the more difficult tasks such as Registry manipulation, but still lack the robustness required for today's enterprises . For many years , competing operating system vendors maintained a significant advantage over Microsoft by implementing robust directory services supporting LDAP, X.500, and even proprietary directory services such as Novell's Netware Directory Service (NDS). Critics of the Windows NT environment often pointed to the "flat" architecture of the Security Account Manager (SAM) database as leading a long list of flaws preventing Windows NT 4.0 from sharing the spotlight with UNIX in the enterprise-level operating system market. Responding to the need for a true directory services solution, Microsoft began supporting the industry-standard Lightweight Directory Access Protocol (LDAP), first in Microsoft Exchange 5.0 and later in Site Server and Windows 2000. In keeping with Microsoft's recent marketing and product naming standards, the directory services architecture found in Windows 2000 was named the Active Directory . Due to the central role the Active Directory plays in administration and support of the Windows 2000 operating system, a robust development environment supporting the Active Directory is essential to help automate workflow processes and administrative tasks in Windows 2000. Although Microsoft could have restricted customization of the Active Directory to experienced C++ developers, the company instead decided to make manipulation of the Active Directory as easy to automate as any Visual Basic for Applications (VBA)-enabled application. Using the Active Directory Service Interfaces (ADSI) libraries, managing a Windows NT or Windows 2000 namespace has now been brought down to the level of even the most novice developer. By trading in the significantly complex API calls needed previously for a simple set of procedures that can manipulate the environment, programmatic administration of a namespace is now well within the reach of a systems administrator. However, despite the release of ADSI in February 1997, few people paid much attention to the product (nor its predecessor, OLE-DS). Microsoft's work with directory services would not be well publicized until the Windows 2000 development effort matured and Microsoft's commitment to developing an enterprise namespace was embraced by the public. While the name "Active Directory Service Interfaces" might imply that the product solely supports the Active Directory, ADSI fully supports programmatic control of administrative tasks in Windows NT 4.0. Additionally, ADSI supports the following:
Although extremely powerful, ADSI is accessible to developers and administrators familiar with either Visual Basic or C++, as well as those who are familiar with the "lighter" versions of these languages, such as VBScript and JavaScript. In addition, ADSI is supported on other automation controllers, including Perl and Rexx, and allows administrators to use any language supporting Object Linking and Embedding (OLE) automation with the ADSI Component Object Model (COM) objects. Whether you are developing a natively compiled executable, COM object, Web application, or even as part of a login script using Windows Scripting Host (WSH), ADSI provides a relatively simple interface to automate most every enterprise administration task. Should an enterprise decide to upgrade to Windows 2000 today or in the distant future, adoption of ADSI will prove an invaluable investment by supporting the automation of workflow processes and reducing tedious administrative tasks. ADSI's simple cross-language nature enables rapid development of customized applications and allows more robust login scripts to be created, thus providing better support for any organization's infrastructure. |
| Top |
EAN: 2147483647
Pages: 194