Integrating Applications with Windows 2000 and Active Directory

The Microsoft® Windows® 2000 Server operating system and the Active Directory™ service provide the ideal foundation for achieving synergy between information about users, network infrastructure elements, and applications. This paper describes a variety of architectural models for integrating Active Directory with applications to deliver enhanced functionality and lower total cost of ownership.

On This Page

Overview
Opportunities for Active Directory Integration
Application Scenarios
Conclusion
More Information

Overview

Customer Situation

Without Active Directory Integration

With Active Directory Integration

Most companies recognize that installing, using, and maintaining distributed applications represents a cost to their bottom line. Most ongoing costs, such as those associated with daily data backups and installing new users, are fairly easy to understand and predict. But other costs are less obvious:

• Client Configuration. As the rate of business change increases, making sure that client machines continue to have the right software installed and are configured properly represents a significant and growing expense. For example, when a person moves from one department to another, an administrator needs to delete some applications and add others – and make sure that each is configured correctly. Improper configurations cause problems ranging from service interruptions to applications that damage corporate data unintentionally by applying out-of-date business rules.

• Server Configuration. Most applications require administrators to assign clients to specific server-side elements, such as databases and application components, at the time of client deployment. Because clients are bound to specific machines, this kind of static configuration can hurt service levels. Users must wait for failed machines to be restarted before they can continue working. And when server load increases, users can experience slower response times even if other servers have excess capacity.

• Information Proliferation. The growing popularity of distributed applications has led to a proliferation of directories that contain similar information about users, machines and other network resources. E-mail systems have address books, for example, that contain much of the same information about users as kept by enterprise resource planning (ERP) systems. As users are added or updated, all directories must be kept up-to-date and synchronized with each other. In addition to problems that occur when information gets out of synchronization, identifying sources of synchronization problems – and restoring consistency to directories – can be very costly.

• Lack of Inter-Application Awareness. Perhaps most harmful, most corporate infrastructures deliver very little synergy between applications, information kept about users, and infrastructure elements such as networks. For example, an employee's applications cannot detect his or her movement between departments. And doctors in the emergency room may receive the same quality of network service as clerks in the billing department; participants in an Internet video conference see jerky motions and hear distorted audio because someone else is downloading games. Unfortunately, the costs represented by lack of synergy can be the hardest to identify and address.

Whether the cost is tangible or simply an opportunity cost, each of the areas above contributes in some way to total cost of ownership (TCO).

Solution Requirements

To lower TCO, companies need applications that are more aware of the environment in which they are deployed, sense and adapt to changes, and share information about themselves with other applications to enable synergy. Companies require the following characteristics:

• Clients should be able to configure themselves based on the role of their user or environment in which they are deployed. When required, administrators should be able to manage relevant elements of client configuration centrally.

• Clients must be able to find resources dynamically such as an accounting database, wherever they happen to be located at the time. It should also be possible to have multiple providers of a service running at the same time to improve service levels.

• Applications should be engineered to take advantage of standards-based directory services to store, use, and share information about users, machines, application components, and infrastructure services.

• Applications need ways to interact synergistically with other components in their environment. For example, it should be possible to provide doctors a higher quality of network service automatically when they are part of an emergency-room security group. Internet video applications should be able to request more bandwidth dynamically from the network. And it should be possible to grant or deny bandwidth requests based on policies defined by administrators.

Solution: Active Directory-Enabled Applications

Windows 2000 Server, including the Active Directory service, is designed to provide applications with the features they need to deliver lower TCO:

• Group Policy Integration. Group Policy features enable administrators to define sets of applications, including specific configurations, that users should have available based on their role in the company, the domain of which they are a member, and the Windows security groups to which they belong. When a user is moved into an organization, or added to a security group, his or her applications can be installed and configured automatically – helping to lower installation and configuration costs dramatically.

• Service Publication. Active Directory enables applications to publish the names and locations of services they provide so that clients can locate and use services dynamically. This enables administrators to reconfigure servers for optimal response times and higher availability without having to update clients.

• Directory Object Extension. Active Directory provides the ability for administrators to add new types of objects and to extend existing objects with new attributes. This enables Active Directory to be a consolidation point for reducing the number of directories that companies have. Benefits include improved information sharing, roaming support and common management of users, computers, applications, and directory-enabled devices.

• The ADSI Extension Model. The Active Directory Services Interface (ADSI) provides a feature called the ADSI Extension Model that enables application developers to associate COM-based business rules with objects stored in Active Directory. This provides a consistent and simple way for developers and administrators to interact with an application and its objects. The Extension Model also makes it easy to invoke methods across groups of objects, such as 'all users in the Accounting department' to simplify administration.

• The Active Directory Class Store. Active Directory provides a section of the directory tree called the Class Store that is used to store the names (for instance, Class ID or Program ID) and locations of COM objects installed on the network. COM uses the Class Store to locate and install the COM objects that users are allowed to use on their machines automatically. This can lower the TCO of COM-based applications by simplifying client configuration and administration.

Windows 2000 Server and Active Directory provide the ideal foundation for achieving synergy between information about users, network infrastructure elements, and applications. In addition, tight integration of the Active Directory with the Windows 2000 Server operating system offers greater management simplicity, system integrity and powerful new functionality. Ultimately, Windows 2000 and Active Directory provide a standards-based platform for building the next generation of distributed applications and policy-driven, centralized management of the entire network infrastructure.

Opportunities for Active Directory Integration

Group Policy Integration

Specifying Policy by Hierarchy

Refining Policy by Security Group

It is extremely common for companies to be organized in a hierarchical structure of some sort. For example, a company might have product development, marketing, sales, human resources, and accounting departments that all report to the chief executive officer. Within the sales group, there might be a headquarters staff and four regional managers who report to the vice president of sales. And so on.

Most companies also have the concept of groups that span across the different divisions and departments of the organization. For example, the Human Resources department may keep track of managers even though managers as a grouping concept spans across the organizational hierarchy. In other cases, people from different departments and different roles (for instance, managers and non-managers) will have to work together on a project. They also can be thought of as a group.

It is very common for companies to want to allocate and control resources, such as systems management functions, applications, file access and storage limits, based on where users reside in the organization and the groups of which they are members. For example, companies may decide to allow only managers to run certain human resources applications, or to configure backup applications to do full (as opposed to incremental) backups of machines used by employees in the accounting department.

Despite how intuitive this seems, most companies today must work very hard to implement these types of policies. For example, administrators typically have to know which applications to install on an employee's machine when he or she joins a department or is added to a group. If an individual moves to a different department or changes groups (for instance, he or she is promoted) someone has to make sure that they have the set of applications and privileges appropriate for the new role. It is also common for administrators to have to configure applications on a person-by-person basis to implement policies such as backup intervals and storage limits. And even the best configuration management procedures can be thwarted when users decide to customize or change their application settings in ways that make standardized support more difficult.

To address these issues, Windows 2000 Server provides features that allow administrators to implement a policy-based installation, configuration, and management environment based on the organizational hierarchy, group definition, and physical configuration information stored in Active Directory. Active Directory permits companies to organize information about users, computers, networks, and other resources in a hierarchical fashion to mirror the way that they are structured and configured. Policy management features enable administrators to associate operational policy attributes, such as the names of applications that should be installed (or made available) or settings that should be applied, with sites, domains or organizational units defined within Active Directory. In addition, administrators can further refine policies to include or exclude the members of Windows security groups. For example, administrators could deny access to a timecard reporting application by default and then define a domain-level policy — that grants access to the timecard application — which only gets applied if the user is a member of the manager group.

Windows 2000 Server also provides a way for developers to integrate their applications with policy management features. In particular, when users log on to machines that support Group Policy features (such as Windows 2000 Server and Windows 2000 Professional) policies that are applied automatically to the user's configuration can include settings for Windows-based Registry keys. Applications that read important configuration information from Registry keys enable administrators to tailor functionality based on a combination of policy entries and the user's membership within a specific Active Directory organizational unit. For example, the name of a database server could be stored in a Registry key and all users contained in the accounting department organizational unit could be assigned to that database by means of a policy entry. When users join (or are moved into) the accounting department organization unit, their applications are automatically reconfigured to access the correct database.

Applications can also use Group Policy features to tailor functionality by Windows security group membership. For example, corporate officers might be granted update access to certain fields whereas non-officers get read-only access. And, because many applications already store configuration information in Registry keys, they can take basic advantage of policy features without modification.

The policy features of Windows 2000 Server and Active Directory help lower TCO by making it easy to implement and manage application-oriented policies centrally and by permitting applications to automatically configure themselves based on security group memberships and the site, domain, and organizational unit in which users are located.

Service Publication

Service Publication and Lookup

In a network computing environment there will be many different applications running on many different machines. User desktops will run client-side applications ranging from payroll and accounting systems that the user works with every day, to automated backup systems that run by themselves after business hours. Other machines will contain server-side elements including databases, shared application components, and network services such as file and print servers. Historically, client-side applications have used static configuration files to hold location information about servers that they access. Because of the increasingly dynamic nature of most network environments, however, maintaining associations between client and servers is becoming more difficult and adds significantly to ongoing administrative costs. Moving a resource from one server machine to another, for example, can be time-consuming and costly process as each client machine may require an update to its configuration files.

Windows 2000 Server addresses this issue by enabling applications and servers to store the names and locations of services that they provide in the Active Directory service. This process is called service publication because providers of services publish their locations in Active Directory. When a client application needs access to a particular application or server, it:

• Looks up the resource in Active Directory by name using a programming interface such as ADSI or LDAP request

• Retrieves the binding information associated with the resource (for instance, database name, connection point or TCP/IP port address)

• Connects to the resource and begins using it

To facilitate higher availability and performance, applications can be programmed to support multiple providers of the same service within the same network. Each provider then registers itself with Active Directory using the same name. When all providers are running and reachable, users see better performance because the load is shared across more than one machine. When a machine or network connection fails, users see higher availability because their client applications can locate alternative machines that provide the same service. Service publication also makes it easier for administrators to move services between machines (for instance, to take advantage of available CPU resources) – even on a daily basis – because the need to reconfigure clients is removed.

The process is analogous to making a telephone call to a business such as a hardware store to see if a product is in stock. As long as the consumer knows the store's name, he or she can look up the telephone number (in the phone book) of the store closest to home. If the hardware store is currently sold out of the product or the telephone line is busy, the person can look up the telephone numbers for other locations of stores with the same name – which may have the product in stock.

In a business environment, applications that support service publication deliver lower TCO advantages by providing reduced application downtime, faster responses to user requests, and greater flexibility to match machine resources to application requirements.

Directory Object Extension

Many applications use some form of directory or database to store information about users. For example, e-mail systems have address books that contain lists of users along with their e-mail addresses and other information such as telephone numbers. This promotes valuable functionality within applications, such as the ability to search for people by first or last name, or to move to a different machine and still see personalized settings. Within most companies, however, information about people and configurations now exists (and must be maintained) within many different application-specific directories. Higher TCO results from the expense associated with maintaining many directories containing information in various structures and formats. And there can be a significant opportunity cost of not having a single repository of information, ranging from organizational structure to purchase-order signing limits, that can be accessed and mined using consistent programming interfaces and data formats.

Historically, application developers have developed their own repositories for three reasons:

• No reliable directory was available in the user's environment.

• There was no widely accepted way to access directory-based objects.

• Most existing directories require developers to make tradeoffs between extending directory objects with new attributes and scalability.

Active Directory is positioned to address both of these issues. First, Active Directory is a core feature of Windows 2000 Server and will be installed and available wherever Windows 2000 Server is running. Second, Active Directory is designed to remain scalable to millions of users spanning many different sites – even when applications add their own extensions to core Active Directory objects such as users, security groups, and machines. Adding additional application-specific data to existing objects offers several benefits:

• Having information about users, machines, and other objects consolidated in Active Directory allows administrators to view, change, and manage information in one place as opposed to multiple repositories.

• Configuration information about users can be stored in Active Directory instead of on the machine where a given user typically works. When users roam to different machines, applications can retrieve their configuration from the Active Directory. This permits users to have a consistent, personalized experience that is unbounded by the machine on which they happen to access their applications. In environments where users move from machine to machine, such as technical support departments, this capability is very important for productivity. In other environments such as those in which users access services by using Web pages, and Web server connections may change constantly, the ability to store personalized information centrally is a requirement.

• Applications can take advantage of information stored in the directory by other applications. For example, a human resources application could store the name of each employee's manager as an extra attribute on his or her user object in Active Directory. The accounts payable system could store approval limits for expense reports on each manager's user object. A new online expense-report approval system could be developed that would automatically send an employee's expense report to the person in his management chain with sufficient authority to approve a given report.

Applications that use Active Directory to store information about users and network elements help lower TCO by minimizing the number of application-specific repositories that must be maintained, facilitating centralized administration and fostering new functionality that can extract greater business value from existing applications.

The ADSI Extension Model

Although one of the important goals of Active Directory is to enable information-sharing and consolidation, in some cases, it is not advisable to simply store data in a directory and assume that all applications will use the data correctly. For example, a user's spending_limit attribute might not be a single, static value in Active Directory. The actual value that should be returned in response to a particular request might need to be based on the type of spending request and whether a higher-level manager has delegated some authority.

In other cases, the information that an application needs will be the result of business rules performed on a combination of data kept in Active Directory and other data. For example, an application might create a workflow_queue object in Active Directory that contains information about a particular queue. But it will probably be inappropriate to also store the contents of the queue in Active Directory, because entries may change frequently as documents are processed. Also, every application that wants to examine the queues would have to be programmed to understand the various data structures and access methods required by the application that owns the queue.

To address these needs, the Active Directory Services Interface (ADSI) provides a feature called the ADSI Extension Model. This feature allows application developers to extend the list of standard ADSI Interfaces (for example, those designed to facilitate access to users, machines, devices, and other directory-based objects) with application-specific functionality. Developers of new applications can use tools that support COM objects such as the Visual Basic® development system; Visual Basic, Scripting Edition, or the Visual J++® development system for Java to call ADSI Extensions.

Based on the spending_limit example above, the accounting application could provide an ADSI Extension that dynamically associates a method called get_spending_limit with standard Active Directory user objects. By means of a request such as:

   set limit = this_user.get_spending_limit(Hardware_Purchase)

the implementation of this method can read required information from Active Directory, apply business rules, and return an appropriate dollar value (assuming that this method takes purchase_type as a parameter, and that the user object is selected using standard ADSI functionality). The ADSI Extension model also provides a number of other features that add value in an Active Directory environment. First, the Extension Model makes it easy for any number of vendors or developers to extend the same directory objects. Issues such as COM class aggregation and interface conflict resolution are handled automatically. Second, the Extension Model provides support services for applying operations to groups of similar objects within an Active Directory container. For example, it is easy to create a list of all user objects in an organizational unit and invoke the same operation on each one. Using the workflow_queue object referred to in the second example above, administrators could write a simple Active Server Page script that enables users to query the status of all workflow queues in their department using a Web browser.

Applications that expose functionality through the ADSI Extension Model help lower TCO by providing a consistent and simple way for users, corporate developers and administrators to extract greater value from the applications using popular and powerful tools such as Visual Basic and Visual Basic, Scripting Edition.

The Active Directory Class Store

For companies that use applications built with COM+ technologies, two common challenges are:

• Making sure that users have all of the COM objects that they are allowed to use installed on their machine.

• Making sure that all users have the latest versions of their COM objects.

Historically, this has meant that administrators had to configure each machine carefully, and ensure that updated objects and settings were distributed to each machine affected by a change to prevent service interruptions. If documents contained references to objects that were not installed on a machine, the user was simply out of luck.

To address these issues, Active Directory provides a section of the directory tree called the Class Store. The Class Store is used by the COM+ run-time to store the names (such as Class ID or Program ID) and locations of COM objects installed on the network. When applications are written to use the Class Store, their clients can instantiate and make calls to any COM object created by the application. If the object is not installed on the user's workstation, the COM+ run-time knows how to automatically make a call to the Active Directory-based Class Store to locate and retrieve a Microsoft Installer (MSI) package for the object. The Microsoft Installer agent on the client then installs the object and lets the client continue with the call.

Applications that are written to use the Class Store can contribute to lower TCO by automating the process of locating, installing, and maintaining the COM objects required by users on their workstations.

Application Scenarios

The following section uses common scenarios to highlight ways that applications can deliver to companies more value and lower TCO through integration with Active Directory. They are meant to illustrate the ideas in previous sections on ways to achieve integration. The following scenarios are just examples of the possibilities.

Line-of-Business Applications

Line-of-Business (LOB) applications include a wide variety of applications that companies use to run the day-to-day business. They include applications for payroll, inventory management, and order entry. Many companies purchase integrated suites of applications, often referred to as enterprise resource planning (ERP) systems, which provide a significant percentage of LOB functionality. Because they are so widely deployed and provide so much of the average business's core transaction processing, LOB and ERP applications are ideal candidates for Active Directory integration. Opportunities include:

• Integration with Policy features to enable easier client-side application installation and configuration management.

• Service publication to allow clients to locate appropriate servers dynamically and to enable server redundancy and load balancing.

• Directory object extension so that configuration information about users can be stored and managed centrally. This also allows users to see a personalized environment regardless of which machine they are using.

• ADSI extensions to make it easy for corporate developers and administrators to integrate their applications and management utilities with LOB/ERP application functionality. For example, because concepts such as user spending limits are not static values and are typically defined and managed by ERP applications, ADSI extensions make it easy for ERP vendors to expose spending limit information by adding appropriate methods to existing user objects within ADSI. Developers could then select an instance of a user object using ADSI and invoke a method (such as get_spending_limit) on the object in order to get the current spending limit as defined by the ERP system.

• Integration with the Class Store enables vendors to identify the location of application components on the network so that client applications can locate and load the components on demand. For example, using the Class Store, ERP systems could embed expense report approval objects in e-mail to an employee's manager. When the manager opens the mail, the embedded objects locate their implementations dynamically and begin executing – even though the manager didn't have the components pre-loaded on his or her machine.

Database-Centric Client/Server Applications

Although databases are viewed primarily as places to store data, the remote data access features of databases form the backbone of the majority of client/server applications being run today. In their role as network-based resources, databases need to provide a number of services to clients. Opportunities for integration with Active Directory include:

• Integration with Group Policy features to enable client configuration and access to data to be based on a user's location within the organizational structure and membership in Windows security groups.

• Service publication to help clients locate appropriate database servers. The two-tiered and stored procedure architectures used by database-centric applications require clients to connect to a database server before they can begin operating. Because there can be many databases in a company, client applications typically need to be configured by administrators to use the appropriate server. Service publication through Active Directory enables clients to locate database servers by name dynamically, reducing configuration and maintenance costs.

• Directory object extension so that additional information that databases keep about users and resources can be stored and managed centrally.

• Providing ADSI extensions to make it easy for administrators to build database management utilities. For example, database systems could create database_server objects in Active Directory, and ADSI extensions would make it easy for administrators to manage servers by calling methods that affect just database_server objects. Administrators could write scripts that cause backup operations to begin by using ADSI features to invoke the start_backup method on all database_server objects in a given domain.

Storage Management Products

Advanced storage management systems permit administrators to implement sophisticated backup/restore and disk quota management procedures across machines in a network. A key requirement is the ability to implement different levels of operation based on a variety of policies and procedures. For example, the backup requirements might be different for the accounting department than the human resources department. Opportunities for integrating storage management applications with Active Directory include:

• Integration with Group Policy features to enable operations such as backups and quota management operations to be performed based on organizational affiliation and Windows security group membership. For example, users in the product development organization might have their data backed up nightly using incremental backup techniques. Members of a security group created to support a corporate merger project might get full backups instead. Policy integration could also be used to make sure that users are configured to use the backup servers in their departments when they are added to or moved between organizations.

• Service publication to help storage management agents on user machines to locate suitable backup/restore servers on the network. Because not every machine will have devices such as tape drives installed, or be monitored by an operator, storage management clients must be able to locate servers that can perform the required operation.

• Directory object extension so that information about computers that support backup operations can be kept in the Active Directory. The type of backup devices attached to the computer could be kept as an attribute of the object.

• Providing ADSI extensions to make it easy for administrators to build scripts that help manage backup, restore, and quota management operations. For example, using ADSI extensions, administrators could write a simple script that initiates a backup on all machines in a particular site or organizational unit.

Directory Synchronization Products

Realizing the number of application-specific repositories and directories in use within most companies today, a number of vendors have delivered products that automate directory synchronization functions. Although it is easy to see their role as operating between directories, directory synchronization products are also able to offer advanced features by using Active Directory. For example:

• Group Policy features can be used to automate the process of determining synchronization requirements. For example, agents running on servers in the accounting department could be configured automatically to send all add user events to the ERP synchronization agent so that the user gets added in both places.

• Directory synchronization agents can publish their services in Active Directory. When a directory update occurs, agents that detect the event can look up other agents that are interested in receiving the event in Active Directory. Events can then be sent to only those agents that need the information.

• Active Directory objects can be extended to include attribute information included in other repositories or directories that are not natively supplied by Active Directory Schema. Synchronization agents can then populate attributes automatically. Having this additional information in Active Directory enables greater levels of centralized management and sharing of information between applications.

• By providing ADSI extensions, directory synchronization products can expose functionality that is not inherently part of any one directory. For example, a product could define a meta_directory object that corresponds to a virtual combination of many directories. A create_user method on the object could then perform actual add-user functions in each of the physical directories.

Systems Management Products

Systems management products will play an important role in supplying companies with the means to manage their Active Directory infrastructures. For example, these products will help monitor and troubleshoot domain controllers hosting Active Directory replicas and integrate Active Directory into the total systems management picture. In addition to their role of helping to manage the Active Directory service, systems management products can also use the Active Directory to deliver greater application functionality and help lower TCO. For example:

• Group Policy features can be used to customize event collection and processing based on organizational affiliation and Windows security group membership. For example, administrators might define events coming from machines in the order entry department to be of higher priority than events from the human resources department because of the importance of taking orders.

• Most network-based systems management products use agents on individual machines to report events to server-based collection points. Service publication can help agents find collection points and locate alternative collection points when primary servers fail.

• System management products can extend directory objects so that configuration information can be kept about the systems management role played by each computer in the network. For example, some computers will just be agents and some will support collection point or analysis functionality. Having this information in Active Directory might enable master administration consoles to build a dynamic map of the network, promote agents to collection points, and reassign agents to different collection points more easily.

Middleware Products

The term 'middleware' is so overused that it is hard to know exactly what it means. For this White Paper, middleware is any technology that facilitates the process of building distributed applications. In that sense, middleware would include message queuing, distributed transaction processing and distributed application development technologies. Middleware integration with Active Directory is important because companies commonly use middleware to build distributed applications, and integration enables their applications to realize many Active Directory benefits automatically. Opportunities for integrating middleware products with Active Directory include:

• Use of Group Policy mechanisms to implement features such as automatic server redundancy. For example, distributed application development tools could automatically populate Registry keys with lists of acceptable servers and cause client requests to go to alternate servers automatically when primary servers fail.

• Service publication to help clients locate servers dynamically. For example, distributed transaction processing run-time libraries could publish the locations of application servers they are hosting. Then, when clients want to call the services, they can locate them dynamically via an automatic lookup operation. This would simplify systems management by reducing the need to do client-side configuration and increase deployment flexibility by making it easier to host servers on different machines.

• Directory object extension so that information about middleware-specific objects can be located by means of the Active Directory. For example, message queue objects could hold the location and attributes of actual queues. When an application wants to send or receive a message, they can locate the appropriate queue object in the directory using search operations and use its attributes (such as the name of the machine that actually holds the queue) to perform the send or receive operation. This reduces the need to embed queue location information in applications, helping to lower the cost of administration.

• Providing ADSI extensions to make it easy for administrators to build scripts that help manage objects created by the middleware product. For example, ADSI extensions would make it easier for administrators to write a script that gathers and then deletes the contents of all dead letter queues in a message queuing environment.

• Using the Active Directory Class Store to store information about the implementation of objects generated by distributed development environments. This would simplify the process of deploying objects to clients and would enable clients to load and configure only the objects that they actually need.

Document Management Products

Document management products allow companies to implement sophisticated workflow-based infrastructures for processing documents of all kinds. For example, car loan applications may be submitted in paper form and then scanned, whereas other documents may be submitted electronically through the Web. Once an application is submitted it may need to go through a number of processing steps that involve many people with various authorities. Ordinary reviewers may have the authority to process requests of under $20,000, whereas supervisors may be required to approve any amount that is higher. Because there are many different people, roles, and servers in a document management environment, Active Directory integration offers many benefits and opportunities to lower the cost of administration. For example:

• Workflow products typically define clients that work on documents and servers that are responsible for routing documents to the next processing step. Group Policy features can be used to set the authority levels of clients based on membership in Windows security groups and to assign clients to specific workflow servers.

• Workflow servers can publish their location in Active Directory. When a client needs to access a server of a specific type, such as an archival server, it can look up the server dynamically.

• Active Directory objects can be extended to include attribute information about users and servers. For example, the specific authorities of a given user could be kept in the directory and applied regardless of which machine he or she decides to use. Workflow server objects could be extended to store information about the types of services that they provide to simplify the process of finding a server.

• By providing ADSI extensions, document management products can allow developers or administrators to build extensions to core functionality. For example, an administrator could write a script that sends a query to all workflow queue objects in a domain and notifies an operator if queue depths exceed a certain level.

Conclusion

Many companies have begun to realize the value of directory services because of the ways that directories help to simplify user and machine management in a network environment. For example, storing information about users and machines hierarchically in a directory allows administrators to delegate management responsibilities to appropriate individuals within departments and groups. This frees administrators to focus on other tasks and gives more autonomy and control to users. Active Directory will offer these benefits — and many others — in the area of simplified administration.

Extending the role of Active Directory to include application integration enables companies extend these benefits: simplified management, enhanced network services, greater application functionality, lower TCO, and synergy between all directory-enabled components of the network-computing environment. This 'raises the bar' for what a directory service needs to be -- directories that offer just simplified administration or support a single application deny their users many important benefits.

Microsoft is in a unique position to deliver on the promise of integration and synergy because of the critical mass of users, infrastructure providers, and application developers that Microsoft has assembled to work together. For example, Microsoft is working to accelerate Active Directory adoption by working with leading independent software vendors to Active Directory-enable their applications. End-user companies can also help accelerate adoption by requesting Active Directory-enabled applications from their preferred vendors and remembering that the benefits outlined earlier compound and multiply as more Active Directory-enabled applications are deployed.

More Information

For the latest information on Active Directory, see Exploring Directory Services at https://www.microsoft.com/windows2000/technologies/directory/default.asp

For the latest information on Windows 2000 Server, check out our Web site at https://www.microsoft.com/windows2000.