Microsoft® Windows® 2000 Scripting Guide
« Previous | Next »
Active Directory is well suited for handling a large number of read and search operations, and a significantly smaller number of changes and updates. The data in Active Directory is replicated, meaning that updates occurring to the Active Directory on one domain controller are sent to other domain controllers in the network. Because the data is replicated, Active Directory is not well suited for dynamic data that frequently changes for example, CPU utilization and Internet stock prices.
Note
A critical part of managing Active Directory with ADSI scripts is knowing where directory objects are replicated. Active Directory is divided into partitions to reduce replication. Partitions are either fully replicated (full replicas) or partially replicated (partial replicas). Full replicas are partitions that are replicated to every domain controller in the forest and can be read or written to from any domain controller. Partial replicas are read-only partitions that contain a subset of data contained in Active Directory.
The three full replicas found on each domain controller are the:
Note
All domain controllers designated as Global Catalog servers contain a partial replica of all other domain directory partitions in the forest. This partial replica, appropriately named the Global Catalog, contains all of the objects in the domain directory partition, but only a subset of the attributes of these objects. Knowing which attributes are contained in the Global Catalog is critical to creating scripts that perform search operations efficiently. For example, if you write a script to request an attribute that is not in the Global Catalog and you want the script to return results from more than one domain, you must use referral chasing. Referral chasing increases network congestion and can cause the script to respond slowly. For information about referral chasing, see "Searching Active Directory" earlier in this chapter.
To avoid referral chasing, read attributes that are contained in the Global Catalog. By doing so, you ensure that the script contacts a single domain controller designated as a Global Catalog server to fulfill the request of the script.
The isMemberOfPartialAttributeSet attribute contains a True or False value indicating whether an attribute is replicated to the Global Catalog. Listing 5.50 shows how to determine whether an attribute is replicated to the Global Catalog.
In this example, the script tests the given-name attribute. To test other attributes, simply initialize the attribute with the common name of a different attribute.
Listing 5.50 Reading the isMemberOfPartialAttributeSet Attribute of an Attribute
|
|
When this script runs, it echoes a message indicating that the attribute is contained in the Global Catalog, as shown:
cn=given-name is replicated to the Global Catalog.
After you have determined that an attribute is in the Global Catalog, you specify GC instead of LDAP when constructing a query string. For information about creating a query string that uses the Global Catalog, see "Searching Active Directory" earlier in this chapter.
In Listing 5.50, you might have noticed that the script searches for an attribute (isMemberOfPartialAttributeSet) in an attribute (givenName or cn=given-name). This illustrates the fact that attributes can contain attributes. In fact, if you view the schema from a tool such as the ADSI Edit snap-in, you will see that attributes and classes are viewed as objects. As you know, Active Directory objects contain attributes.
Another important aspect to consider when performing a search operation is whether the attribute to be sorted is indexed. Indexed attributes are already sorted, which reduces the processing requirements placed on a domain controller when you perform a search operation that includes sorting the result set. For information about enabling a sort operation in a search, see "Searching Active Directory" earlier in this chapter.
The searchFlags attribute contains an integer value indicating, among other things, whether an attribute is indexed. Listing 5.51 shows how to determine whether an attribute is indexed. This script is similar to Listing 5.50, so only steps that differ are shown here.
Listing 5.51 Reading the searchFlags Attribute to Determine Whether an Attribute Is Indexed
|
|
When this script runs, it echoes a message indicating that the given-name attribute is indexed, as shown:
cn=given-name is indexed.
Ideally, search operations should use attributes that are both replicated to the global catalog and indexed. To retrieve a result set containing all attributes that meet both of these criteria by default, it is more efficient to perform a search operation than it is to bind to each attribute individually. For more information about performing efficient search operations, see "Optimizing Search Performance" earlier in this chapter.
Caution
Listing 5.52 shows how to perform a search operation to retrieve a result set of all attributes that are both replicated to the Global Catalog and indexed. The steps to complete this task are similar to the search tasks shown earlier in this chapter; therefore, steps are summarized.
The objectCategory=AttributeSchema returns objects in the schema that are defined as attributes.
If both conditions are true, display the lDAPDisplayName of the attribute (stored in the strAttribute variable).
Listing 5.52 Locating Attributes That Are in the Global Catalog and Indexed
|
|
When this script runs, it echoes the lDAPDisplayName of the attributes that are both contained in the Global Catalog and indexed, as shown in the following abbreviated result set:
Attributes in Global Catalog and indexed: AltSecurityIdentities cn displayName mail ... name sAMAccountName sAMAccountType servicePrincipalName sIDHistory sn
Send us your feedback | « Previous | Next » |