How to use ADSI to configure NT's Account Policy
A common question that people new to scripting ask me is, "How do you know which scripting technology to use?" Unfortunately, no one answer exists. Many factors affect the selection of a scripting solution. Furthermore, you often must use multiple scripting technologies to achieve a comprehensive automation environment. However, you need to make certain your scripting toolkit includes a language that supports Object Linking and Embedding/component object model (OLE/COM) automation. For situations in which you once used batch files to call standalone executables, you can now use OLE-savvy scripting languages to bind automation-enabled applications and components. Take Windows NT's NET commands, for example. In the past, you needed to use NET commands to automate many of NT's computer, user, and environment settings. Now, you can use automation objects in Windows Scripting Host (WSH) or directory service (DS) objects in Active Directory Service Interfaces (ADSI). Although NET commands are still useful, automation and DS objects are more robust and flexible than NET commands.
In this column, I'll explain the basic concepts behind OLE/COM automation and their effect on scripting. I'll also demonstrate how to write scripts that use OLE/COM objects to automate tasks. Specifically, I'll show you how to use Perl and ADSI objects to automate the configuration of NT 4.0's Account Policy.
OLE/COM Automation 101
Automation is Microsoft's answer to open, reusable software components. In general, automation is the process through which one application uses the functionality that another application provides. From a scripting perspective, automation is the process through which Perl, Visual Basic Script (VBScript), and other interpreted languages that support automation can access and control the functionality that an automation application or component exposes.
Applications and components that expose automation interfaces are automation servers. Applications and languages that host or control objects are automation controllers. In the example script I will show you how to write, ADSI is the server and Perl is the controller.
Dispatch interfaces (e.g., IDispatch) make automation possible. IDispatch is one of the many COM interfaces available to application and component developers. What's unique about IDispatch is that it lets interpreted languages dynamically bind to and use the objects, methods, properties, and events IDispatch-enabled applications or components expose. Objects represent a class (i.e., a logical grouping of methods and properties that defines something meaningful). Examples of objects include ADSI Domain Objects and ADSI User Objects. Methods represent the behavior of an object. Methods are functions you invoke to make an object perform a task. For example, the ADSI User Object includes a SetPassword method that you can invoke to change a user's password. Properties represent an object's state. The ADSI Domain Object you'll be working with in your script includes properties that describe the state of an NT 4.0 domain's Account Policy. Events represent asynchronous messages that an object responds to. For example, an object might respond when a user selects a certain menu item.
OLE/COM Automation Servers
The two main types of OLE/COM automation servers are application- and component-based automation servers. Application- and component- based automation servers expose objects, methods, properties, and events. (Vendors typically identify which objects, methods, properties, and events a component or application provides in the documentation.)
Application-based automation servers are applications (.exe files) that expose their functionality via automation interfaces in addition to performing their primary role that a GUI accesses. Examples of such applications include Internet Explorer (IE), Office 97, Notes, and Visio. You can create instances of and use these applications without displaying the applications' user interface. Application-based automation servers run out-of-process, meaning they run in a separate process from that of the automation controller.
Component-based automation servers are usually .dll files. Unlike applications, components typically don't provide a user interface. Instead, the components' primary role is to abstract and provide access to various systems and application services, letting other applications use the underlying technology without regard to location, programming language, platform, and other factors. Examples of components include ADSI, ActiveX Data Objects (ADO), and Collaboration Data Objects (CDO). Components run in-process, meaning they share the same process with that of the controller.
Prev. page
[1]
2
3
next page 
