2.8 Exchange and the Active Directory schema

---

Schemas define the structure of a database, including the object classes and the attributes held for each object. The AD schema is extensible by applications or enterprises to allow it to hold additional information. For example, you could extend the directory to add a new "Birthday" attribute for user objects, and then write an AD-enabled application that ran when a user logged on to check whether it was his or her birthday, generating an appropriate message on the day in question. First-generation Exchange includes 15 "custom" attributes for mailboxes that you can use for similar purposes, but you cannot extend the schema of the Exchange directory.

Exchange 2000 was the first application to extend the AD schema by adding new attributes that can then be associated with recipients (users, contacts, and groups) as well as configuration information about Exchange, such as administrative and routing groups. Exchange 2000 makes over 1,800 changes to the default schema, and Exchange 2003 follows up with a further set of over 140 changes and additions. For example, Exchange 2000 extends the user object with storage attributes to allow users to be associated with the Store where their mailboxes are located as well as any quotas placed on the mailboxes. Exchange also changes a number of index attributes so that they participate in address resolution. Among the changes made by Exchange 2003 are those necessary to support Outlook Mobile Access, the iNetOrgperson structure, and new features such as recipient filtering and protected distribution groups. Because Exchange 2003 extends the schema even more than Exchange 2000, you need to run the Exchange 2003 version of ForestPrep to ensure that the forest is properly prepared before you install the first Exchange 2003 server.

Depending on your configuration, you might apply two sets of schema changes during an Exchange deployment. The ADC applies the first set of changes to extend the schema to add a number of attributes used to synchronize between the DS and the AD. The Exchange 2000 installation program applies the second set of changes to round off the extensions required by Exchange when it installs the first server in the forest. However, if you deploy Exchange 2003 and you have not updated the schema, the schema changes for the ADC and Exchange are identical, so you only have to update the schema once. Applying schema updates is a CPU-intense activity, so be prepared for the server to be very occupied for a half hour or so during this phase of the installation.

The changes applied by the ADC include Exchange-specific attributes to be included in GC replication. The ADC is only required for deployments that must accommodate legacy servers; green field implementations that only deploy new Exchange servers do not use the ADC. The Exchange 2000 installation procedure is, therefore, able to apply a complete schema update or just updates that are a superset of those already implemented by the ADC. Exchange 2003 applies a single set of schema changes to the AD, so there is no differentiation between the ADC and Exchange.

Several phases occur during the schema update to allow the AD to commit changes to the database in a controlled manner. It is necessary to apply the changes in a staged manner to avoid any potential problems that might occur if a schema update is unable to reference a change applied earlier.

The Exchange installation procedure checks the current schema version for the forest when it begins and determines if it has to update anything. The check looks at the value of the ms-Exch-Schema-Version-Pt object, which holds the current schema number in its rangeUpper attribute. If the schema version is less than the required value, the installation procedure updates the schema. The ADC installation procedure checks the ms-Exch-Schema-Version-ADC to determine whether it has to update the schema. You can look into the SCHEMA9.LDF file on the server kit to check the schema version that the installation procedure will look for, and then use ADSIEDIT to connect to the schema and check the current value of the rangeUpper attribute for MS-Exch-Schema-Version-Pt to see if the two match. Figure 2.24 shows how ADSIEDIT reports the current schema version.

Figure 2.24: Checking the schema version.

Future versions of Exchange service packs and hot fixes may include schema updates. The schema administrator (the person responsible for controlling changes made to the AD schema) may ask you to provide exact details of the updates before authorizing the update. This is a good example of how closely the base operating system administration team has to work with the messaging team.

2.8.1 The impact of updating the schema with new GC attributes

Whenever you update the schema with new attributes that you want to include in GC replication, the AD also modifies the isMemberOfPartialAttributeSet attribute. In Windows 2000, such a change forces full synchronization across all GC servers in the forest, an operation that can generate a lot of replication traffic. According to Microsoft, the net bandwidth consumption for each GC is equivalent to that consumed when you promote a DC to become a GC. You should not notice the impact on small or high-bandwidth networks, but this can certainly be an issue if you need to update the schema for organizations that include many GC servers spread across different capacity network connections, when the subsequent replication activity may take a long time to complete.

Best practice is, therefore, to generate a schema update plan early in a project and make sure that you apply schema changes as early as possible in a deployment to minimize replication. Ideally, you should try to make the schema changes immediately after you create the forest, so that all new controllers pick up the new schema when you promote them from normal servers through the DCPROMO process. Better still, upgrade your forest to Windows 2003 and take advantage of the fact that its replication mechanism suppresses unnecessary activity like this and only replicates the changed information.

2.8.2 Updating the schema with an installation

The easiest way to update the schema is to just go ahead with the first Exchange server installation in a forest, but you can update the schema beforehand by utilizing two options that are included in the Exchange installation procedure. You execute SETUP with these options from an administrator account that has full permission to modify the AD. Once the AD is prepared, you can perform subsequent installations of Exchange using accounts that have local administrative access, but are not privileged to change forest-wide settings such as updating the schema or adding the Exchange container to the configuration naming context.

The options are:

• SETUP /ForestPrep: This option runs in the root domain of the AD forest (or the domain that hosts the schema master—which is normally the root domain). /ForestPrep performs the set of changes to the schema, instantiates the Exchange organization, adds the Exchange container to the configuration naming context, and creates the Exchange Admins and All Exchange Servers universal groups. You cannot execute this command unless you are able to log on with Enterprise Admin and Schema Admin privileges. In addition, if you need to join an existing Exchange 5.5 organization, you must have at least read access to the DS. Note that if you plan to run a mixed-mode Exchange organization that includes both Exchange 2000/ 2003 and earlier servers, you must install the AD Connector (ADC) within the organization before you run /ForestPrep. Organizations that run in native mode and therefore do not include legacy Exchange servers do not require an ADC. ForestPrep also creates a public folder proxy container in the root domain of the forest. Exchange uses the public folder proxy to hold the email addresses for mail-enabled public folders.

  
  Figure 2.25: The Exchange configuration container.

• SETUP /DomainPrep: You run this option in every domain where an Exchange 2000/2003 server is located. The option performs tasks such as creating the global groups used for Exchange administration. You must be a domain administrator to be able to run this option.

The ForestPrep option is a useful thing to execute if you want to replicate schema updates throughout the forest before you begin server installations. The sheer number of changes applied to the schema is a good reason to perform the installation (or schema update) of the first Exchange server close to the schema master (at least in network terms), since this will speed up processing of the schema changes. Windows makes schema changes to the configuration container of the AD on the target controller and then replicates them to the other controllers throughout the forest. Figure 2.25 shows the ADSIEDIT utility examining the properties of the AD container used to hold configuration details for Exchange. Every object in the AD has a distinguished name, so the container used to hold Exchange data is named <domain-name> /Configuration/ Services/ Microsoft Exchange, and it holds a number of other containers to store details of entities, such as routing and administrative groups, address lists, connectors, and so on. See section 2.6 for information about how Exchange connects to controllers to access the configuration data.

Because it offers you the ability to view just about every property of an AD object, ADSIEDIT is the most powerful and flexible utility to view Exchange data in the configuration container. However, if you simply want to look at the overall shape of the organization, you can use the AD Sites and Services snap-in, as shown in Figure 2.26. To do this, open the snap-in and select the "Show Services Node" option from the View menu. You can then see information about the services configured in the AD, including the ADC. Be careful when viewing information like this, since it is all too easy to make a mistake and delete something important.

Figure 2.26: Using AD Sites and Services to view configuration data.

2.8.3 Changing the schema

The provision of an extendible schema is a major feature of the AD, but even though it is great to be able to customize the directory, the feature introduces some new issues for consideration. Updating the schema does not impose a performance penalty. The new attributes occupy no space in the database unless you populate the attributes with data. However, once you make a change to the schema, there is no way back (in Windows 2000). You cannot roll back the change, and the AD will replicate it throughout the forest. You can deactivate attributes by setting their isDefunct flag, but Microsoft does not support any way to remove them from the schema. In a fully functional Windows 2003 forest, you can reactivate a deactivated attribute.

Changing the schema is, therefore, something that you must treat very seriously and only perform when a change is justified and you fully understand the ramifications. For this reason, you should agree on any change up front with all of the domain administrators. Ideally, someone within the organization should take responsibility for arbitration of schema changes, and anyone who wishes to make a change should first consult that person. Schema anarchy is not a pretty sight! For this reason, some companies keep the membership of the Schema Admins group empty until they know they need to make a change, whereupon they add the necessary user to the group until after the change, when they revoke the membership.

It is also a good idea to apply as many schema changes as possible at the start of an implementation, since this means that every new DC will inherit the fully updated schema as part of the DCPROMO procedure. The alternative is to make schema changes as the need arises, but this means that you have to let the AD replicate each set of changes throughout the forest before you can proceed to deploy applications that depend on the schema update.

Attributes can be single valued (such as your home telephone number) or multivalued (such as the membership of a group). Before you change the schema to add a new attribute, you need the following information:

• The name of the new attribute and its purpose: In directory terminology, this is the common name. You can provide a separate description, although in many cases, for the standard AD attributes used by Windows or Exchange, the description is very similar to the name.

• Because the roots of AD are in X.500, each attribute and object has a unique X.500 object identifier, or OID. A national registration authority, such as the American National Standards Institute (ANSI),^[7] issues OIDs. You can make up the value for an OID, and as long as the value does not clash with the OID of another attribute, you will not have a problem. However, if an application comes along in the future and attempts to add an attribute with an existing OID, then you will have a problem and the application will not be able to add the new attribute to the schema. One method that is sometimes used is to take the base OID for the DSA provider and append your company's international telephone number plus some sequence number to it to create the new OID. This method usually guarantees uniqueness.

• The type or syntax of the attribute and its maximum and minimum range: For example, an attribute held as string values will be stored as unicode strings and can range in size from one to whatever number of bytes is required to hold the maximum string length.

• Whether or not the AD should replicate the attribute to GCs: Clearly, the more attributes that are replicated, the more data that is transmitted across the network. Some attributes are not required enterprise-wide and can be restricted to an object's home domain. The AD has to replicate others, such as the attribute that holds details of an Exchange user's home mailbox server, throughout the forest to enable specific functionality, such as message routing. The impact of adding attributes to the Partial Attribute Set replicated to GCs is much less in Windows 2003.

• Whether the AD indexes the attribute and includes it in the Ambiguous Name Resolution (ANR) process: Exchange has supported ANR since Exchange 4.0.

Before we look at the details of how to change the schema, we need to update the system registry on the server where we want to apply the change. Ideally, you should apply all updates to the schema at the schema master. If not, the server that you use to make the change needs a fast connection to the schema master to make the change. Applications such as Exchange often include commands to update the schema in their installation procedures, but in this instance we update the schema via the AD Schema snap-in. By default, Windows does not activate the AD Schema snap-in, and you must register it before you can load the snap-in into an MMC console. Type the following command to register the snap-in:

C:> \WINNT\SYSTEM32\REGSVR32 SCHMMGMT.DLL

Figure 2.27: Viewing Exchange attributes in the AD schema.

After the command successfully completes, you can start MMC with a blank console and load the Schema snap-in. You can then browse through the schema, as shown in Figure 2.27, which displays some of the additional attributes used for Exchange.

To protect administrators against accidental changes, the Windows 2000 version of the schema console allows read-only access by default, so you need to update the registry to enable write access. To update the registry, go to the following key and insert the values shown in Table 2.10. You do not need to do this on a Windows 2003 server.

HKLM\System\CurrentControlSet\Services\NTDS\Parameters 

Table 2.10: Registry Values to Allow Schema Changes

Value	Notes
Schema Update Allowed (DWORD)	Set to 1

The schema is loaded into memory on every DC in an area called the schema cache. To ensure that clients access changes promptly, the AD reloads the schema cache from disk every five minutes. If you change the schema, you can force the AD to reload the cache immediately from an option in the Schema snap-in. This ensures that all the changes are active before you attempt to use them.

2.8.4 Updating the schema for ambiguous name resolution

Ambiguous name resolution (ANR) is the process used by Exchange to search the AD to find addresses that match information provided by users. In other words, Exchange searches the AD against a number of different fields to find any matching addresses. If Exchange finds a number of matching addresses, we have an ambiguous name, and Exchange prompts the client to present the addresses to the users in a dialog for them to make the final selection.

Exchange checks attributes such as the first name, surname, display name, and mailbox alias during the ANR process. ANR is invoked whenever a user presses the CTRL/K sequence, or when an unresolved address is detected in the TO:, CC:, or BCC: fields of a message header. MAPI and Outlook Web Access (Figure 2.28) clients support ANR. Outlook Express also performs ANR, if you configure the client to check names against the AD before sending messages.

Figure 2.28: Ambiguous names detected by Outlook Web Access.

It may be advantageous to alter the schema to include a customized field in the ANR process. First-generation Exchange servers allocate 15 fields in the directory for site customization purposes. The AD provides a similar set, called extensionAttribute1 through extensionAttribute15. You could populate one of these fields with details such as a department code and add this attribute to the ANR process, if this makes sense within the company. Remember that changes to the schema are forest-wide, and you cannot reverse a change once made, so be sure to consider all aspects of making the change before implementation.

Three different properties govern whether Exchange can use an attribute for ANR. Figure 2.29 shows the properties of one of the custom attributes inherited from Exchange 5.5. Instead of "custom attribute 1" through "custom attribute 15," the attributes are ms-Exch-Extension-Attribute-1 through -15.

Figure 2.29: Where to enable ANR resolution for a selected attribute.

Looking at Figure 2.29, you might wonder why I say that three properties govern ANR when only one is marked as such. The reason is simple. The "Ambiguous Name Resolution" property determines whether the ANR process uses the attribute, but it is not very smart to mark an attribute for ANR if it is not indexed, and only slightly smarter to keep an attribute used by ANR out of the GC. After all, if the AD does not index the attribute, any attempt to check a name against the attribute will be very slow and frustrate users, and if the attribute is restricted to one domain, its value is useless anywhere else in the forest. For best effect, check all the properties.

2.8.5 Exchange-specific permissions

Along with an upgraded schema, Exchange also adds a set of permissions to AD to allow administrators to perform operations such as managing databases. The permissions, which Microsoft refers to as "extended rights," exist in the configuration container under "Extended-Rights," as shown in Figure 2.30. All of the rights that Exchange uses have an "ms-Exch" prefix, so they are easy to find.

Figure 2.30: Extended AD permissions used by Exchange.

Property sets are a special type of extended right. A property set is a group of object properties that you can use to define access control on an object by manipulating multiple permissions in a single operation. For example, if you enable the Read Public Information (a property set) permission on a user object, you actually enable users to see the values in the object's email addresses, manager, and common name attributes. Exchange uses property sets extensively to simplify administrative operations. If it did not, we would be constantly updating permissions on AD objects to try to assign the necessary rights to get work done.

^[7] . See http://www.ansi.org/public/services/reg_org.html.

---