Growing with Your Applications

An important aspect of planning for scalability is taking in to account the impact of any applications that will eventually be taking advantage of Active Directory functionality. Some enterprise software vendors, such as Baan and SAP, have released product roadmaps that include leveraging Active Directory for profile management and other functionality. You should plan for additional capacity in Active Directory if your organization has these applications deployed.

If you are planning for integrating applications with Active Directory, it is important to focus on the strengths and weaknesses of Active Directory. Active Directory is a highly distributed and replicated directory and, as such, is ideal for storing information critical to distributed applications, such as sales force automation applications and enterprise planning applications. Because it is replicated, it is not ideal for storing large blocks of information that are modified on a frequent basis. If such blocks of information are stored in the directory, a significant amount of replication traffic results from the date being modified and the being replicated between DC in the domain.

Many Microsoft applications also begin to rely on Active Directory functionality. For example, Microsoft Exchange 2000 uses Active Directory for full directory functionality. Windows 2000 and Active Directory are required for Microsoft Exchange 2000 to be deployed. What does this mean for Active Directory planning? The biggest impact is to the sizing requirements for Active Directory.

For example, in Microsoft Exchange it is possible to use the directory for storing several different type of information about an individual. There are data fields for phone numbers, addresses, organizational structures, and pager numbers, just to name a few. In addition, it is possible to configure any one, or all ten, of the custom data fields. Consequently, the result is that a large set of data can be stored in the directory for any single individual.

In Active Directory, not all the data fields associated with a single object replicate automatically to the GC. It is necessary to select which properties of which object types are replicated to the GC. This becomes significant if implementing Active Directory with Microsoft Exchange because if Outlook, the Microsoft Exchange client application, initiates a directory lookup request from Active Directory, it does not pull data from Active Directory. Instead, it pulls data from the GC. This implies significant design considerations for the way in which Active Directory is used in an Exchange implementation to store information about users. If people in your organization typically use the Outlook Address Book as a phone book as well, you need to replicate phone information from Active Directory to the GC. This could result in a significant impact to the network. This is just one example of how applications that use Active Directory can affect your computing environment.