Chapter 4: Managing the Exchange Organization Topology

---

4.1 Understanding the Windows Server and Exchange hierarchy

An Exchange organization is a networked collection of servers, services, and objects layered on top of the Windows Server environment, which is also a networked collection of components. The organization of both the Windows Server and Exchange components is defined in the Active Directory. The Active Directory includes properties for every domain, every server, every user, every networked printer, and every file share in your organization. This is true regardless of whether your environment includes a single computer on a small local area network (LAN) or many systems and users on many wide area network (WAN)–connected networks.

The Active Directory replaces and is a major improvement from the Windows NT 4.0 directory services. The Active Directory also replaces the Exchange-specific directory service found in Exchange Server 5.5. As with Exchange 2000, Exchange 2003 relies completely on the Active Directory and does not have its own directory services.

The Active Directory provides considerable management flexibility to configure the administrative responsibilities to match your company’s organizational structure. Using the Active Directory management tools, you can centrally manage users and systems throughout your network regardless of their location. You can also design a directory structure that allows you to distribute or to delegate administrative responsibility to regional or departmental Information Technology (IT) groups using the standard Windows Server management tools.

The administrative flexibility of the Active Directory is due in part to the Windows and Exchange separation of the logical structure of the domain and Exchange hierarchy from the physical structure of the underlying network. For the most part, the logical structure and physical structure are defined and managed separately. The logical structure allows you to define and to group components so that they can be located by name rather than by physical location.

Exchange 5.5 combined the logical and physical structure in the same hierarchy of sites, servers, and objects. Defining Exchange 5.5 sites too often required a compromise between defining sites that supported your company’s organizational structure and defining sites that matched your physical network topology. Exchange 2003 separates the logical and physical structures. The appropriate administrative model can be logically defined using administrative groups, whereas the physical structure can be defined using routing groups.

Table 4.1 lists the Windows and Exchange logical and physical structures.

Table 4.1: Windows and Exchange Logical and Physical Structures

Logical Structure	Physical Structure
Objects	Domain controllers
Organizational units	Global catalog servers
Domains	Sites (Windows sites, not Exchange sites)
Trees	Schema
Forests	Exchange routing groups
Exchange administrative groups

Many of terms in Table 4.1 were introduced with Windows 2000 and Exchange 2000. Even the ones that seem familiar from previous versions of Windows and Exchange may have new meanings. Before you can effectively manage an Exchange 2003 organization, you must have a clear understanding of these basic Active Directory concepts and terms because they are key Exchange components. This chapter describes the basic Active Directory terms and concepts, and how Exchange relies on the Active Directory and is integrated with it.

4.1.1 Objects

An object, such as a system, a printer, or a user account, is the smallest identifiable item in the Active Directory. Active Directory objects contain attributes that describe the characteristics of the object. For example, a mailbox-enabled user is an object with attributes such as the user’s name, electronic mail (e-mail) address, mailbox location, storage restrictions, delivery restrictions, and security information.

Each Active Directory object has a distinguished name that is used to identify an object in the directory by a recognizable name. The object’s distinguished name can also be used to determine the object’s position within the Active Directory hierarchy. For example:

cn =mdaugherty, cn =users, dc = dallas, dc = company, dc = com 

Distinguished names must be unique, but an administrator can change the distinguished name for an object. This is not often required, but it might be necessary if you reorganize the Active Directory hierarchy.

Objects also have a globally unique identifier (GUID) that is assigned when the object is created. The GUID for an object is independent of the object’s position within the Active Directory hierarchy and does not change if you reorganize the Active Directory hierarchy. Applications can use either distinguished names or GUIDs to search for objects.

Although the GUID for an object does not change, moving a user object between domains within the same forest causes Security Identifier changes and, therefore, affects user access. This is largely by design because Microsoft considers moving a user object between domains to be a significant security change.

4.1.2 Organizational units

Active Directory objects, such as printers, file shares, user accounts, groups, and systems, are placed in containers called organizational units (OUs), which allow you to group similar objects so that they can be easily found and managed. An OU is the smallest object to which you can delegate administrative responsibility.

An OU can contain any object from within the domain, including other OUs. Because OUs can contain other OUs, you can create containers that model the hierarchical structure of your company. Creating a hierarchical set of OUs allows you to delegate administrative responsibility to the appropriate regional groups.

Several OUs are shown in Figure 4.1:

Figure 4.1: Organizational units

• Company, which contains the OUs Europe and North America

• Europe, which contains the OUs London and Valbonne

• North America, which contains the OUs Dallas and St. Louis

• London, which contains printer objects for printers located in London

• Valbonne, which contains a printer object for the printer located in Valbonne

• Dallas, which contains printer objects for the printers located in Dallas

• St. Louis, which contains a printer object for the printer located in St. Louis

Administrative responsibility can be delegated to any of these OUs. For example, one administrator can be assigned responsibility for the printers in Dallas, whereas another administrator is assigned responsibility for the printer in St. Louis.

4.1.3 Domains

A typical corporate Active Directory environment has one or more domains that contain all objects and OUs, as shown in Figure 4.2. The domain can span multiple physical locations and may contain millions of objects. The domain boundary defines the namespace and includes one or more domain controllers (DCs). An Active Directory domain is a security boundary in the Windows network. Privileges granted in one domain do not apply in other domains.

Figure 4.2: Active Directory domain

Because the domain is a security boundary, it also defines the administrative scope. Unless an administrator is granted privileges for other domains, he or she will be limited to managing the resources within the domain.

A domain is also a unit of replication. Changes made to the Active Directory-on one DC can be replicated to other DCs. Even if Exchange organizations are layered on top of multiple domains, information will still be replicated.

Windows NT 4.0 made a distinction between Primary Domain Controllers (PDCs) and Backup Domain Controllers (BDCs). Changes could only be made to directory information held on the domain’s PDC. The BDCs merely held a copy of the PDC’s directory information. Starting with Windows 2000, all DCs now have a writable copy of the Active Directory, and changes can be made on any DC.

For the following reasons, you must carefully consider the first domain you deploy:

• The name of the tree is based on the Domain Name System (DNS) name given to the first domain created. For example, if the first domain is named company.com, all subsequent domains within the tree will be of the form domain. company.com.

• Domains added later cannot be added above the first domain in the domain tree. For example, if the first domain is named dallas.company.com, you cannot later create a domain called company.com.

  Note 

  This does not preclude you from adding additional domain trees with different names to create a forest.

• The first domain within an Active Directory forest can never be removed from the forest. The only way to remove the first domain from a forest is to start over (i.e., recreate the entire forest).

In most cases, it is best for the first domain to be a placeholder domain that establishes the DNS naming structure. This first domain would contain a minimal number of user accounts for administrative purposes and computer accounts for the DCs. Creating this placeholder domain is especially important in companies where IT responsibilities have been decentralized, and regional domains will be created without assistance or approval from a central IT group. It is best to create the placeholder domain before the regional groups begin creating their own domains in their own forests.

Typically, you design the Active Directory domain topology based primarily on the underlying network infrastructure and delegation of administrative responsibilities. Exchange requirements often are not considered unless the Active Directory environment is being implemented specifically to support Exchange. Luckily, Exchange can be made to work with almost any Active Directory domain topology. However, Active Directory domain design decisions regarding domain names and when to switch to native mode can affect Exchange.

Active Directory domain names

The Active Directory domain name becomes part of the Simple Mail Transfer Protocol (SMTP) e-mail addresses that will be used for Exchange users. In Windows NT 4.0, domain names were identified using NetBIOS-style names. For Active Directory, domains are identified using both NetBIOSstyle names and hierarchical DNS-style names. By default, the first component of the DNS-style name is used as the NetBIOS name, as in the following example:

NetBIOS domain name: dallas

DNS Domain Name: dallas.company.com

By default, the DNS domain name is part of each user’s logon name and e-mail address, such as [e-mail]. This default behavior may not be desirable in many companies. It is more common to have each user’s e-mail address be independent of the user’s Active Directory logon domain. For example, [e-mail] rather than john.smith@ dallas.company.com is preferable in most companies. There are three primary reasons for having the user’s e-mail address be independent of the logon domain:

• The shorter e-mail address that excludes the logon domain is more user friendly.

• Excluding the logon domain name from the e-mail address eliminates the need to change e-mail addresses when users move from one logon domain to another.

• Exposing the logon domain name provides additional information for hackers.

Mixed mode and native mode domains

An Active Directory domain can be in one of two modes: mixed mode or native mode.

A mixed mode domain includes both Active Directory DCs and Windows NT 4.0 DCs. All newly created Active Directory domains are initially in mixed mode. Because of the Windows NT 4.0 systems, a mixed mode domain functions like a Windows NT 4.0 domain and has the same scaling constraints and other limitations. The Active Directory DC essentially becomes the PDC for the NT 4.0–style domain. If there are multiple Active Directory DCs in a mixed-mode domain, the administrator can specify which server will serve as the Windows NT 4.0 PDC. In Windows 2000/2003 terminology, this DC is known as the PDC emulator.

A native mode domain can only have Active Directory DCs. No Windows NT 4.0 DCs are allowed, although Windows NT 4.0 member servers and other client systems are acceptable. Native mode domains take full advantage of the Active Directory capabilities and allow the directory to scale to millions of objects, eliminating one of the scalability limitations of Windows NT 4.0 domains. Switching to native mode not only provides additional capabilities and scaling for the domain but allows Exchange to take advantage of Universal Security groups, which are available only with native mode domains. It is not required that all domains be switched to native mode at the same time. Domains within the forest can be switched independently.

4.1.4 Trees

Often, a company may require more than one Active Directory domain. Multiple domains can be combined into structures called trees and forests. A tree is a parent–child hierarchical arrangement of Active Directory domains that share a contiguous DNS namespace and transitive Kerberos trust. A contiguous namespace simply means that all domains in the tree share a common root domain.

The first domain in a tree is called the root domain. When additional domains are added to the tree, they are known as child domains. Multiple levels of hierarchy are possible in a tree as shown in Figure 4.3. A domain immediately above another domain in the tree is known as the parent domain. For example, company.com is the parent domain for europe.company.com and us.company.com. Similarly, us.company.com is the parent domain for sales.us.company.com. Conversely, sales.us.company.com is a child domain of us.company.com, which in turn is a child domain of company.com.

Figure 4.3: Active Directory tree

Although it is possible for a company to implement multiple trees (see Section 4.1.5), a single tree is usually preferable for implementing Exchange.

4.1.5 Forests

Some corporations may need multiple, discontiguous namespaces. For example, a company may have multiple subsidiaries, each with its own identity. Forests allow companies such as this to group business units that operate independently but still need to be part of the same networked environment.

As shown in Figure 4.4, a forest is a collection of Active Directory domain trees that share a common schema, share a common configuration, share a common Global Catalog (GC), have a transitive Kerberos trust established between domains within every tree, but have a discontiguous namespace.

Figure 4.4: Active Directory forest

The first domain created in a forest is the root domain, and it is necessary for establishing trust relationships across the domain trees. You should carefully plan for the root domain because it cannot be renamed and it cannot be removed.

The common schema and configuration definition is replicated to all DCs in every domain within the forest. Because all domains share a common schema and common configuration information, an Exchange organization can span an entire forest. However, an Exchange organization cannot span multiple forests. This restriction needs to be considered when planning your Active Directory topology.

4.1.6 Multiple forest environments

A single corporate-wide forest is sufficient and preferable in most situations. A single forest is best for supporting a centralized administration model and provides the best security. There are several legitimate business reasons for implementing multiple forests.

The most obvious reason for having multiple forests is when two companies merge and they both have already implemented their own separate Active Directory forests. This is a difficult environment in which to implement Exchange. Unfortunately, there are currently no Microsoft tools for merging separate forests.

There are also situations where different divisions of the same company are legally required to maintain separate environments. This is also a difficult environment for a single Exchange organization. However, the legal restrictions that require network isolation probably also prohibit a common Exchange organization, therefore it is unlikely that you would be asked to implement a single Exchange organization during these conditions.

You may also want to create a test environment with its own forest. Test environments should almost always be isolated from your production network, and there is almost never a need to implement a single Exchange organization spanning both the test and production environments.

In other cases, divisions within the corporation may have their own IT staff, their own policies, and their own support organizations. Although this may appear to be a case for multiple forests, you should remember that you have considerable flexibility within a single forest to implement varying permissions and to delegate administrative responsibility. You do not need to deploy multiple forests to have multiple administration teams.

Unfortunately, the most common reasons that companies have multiple forests is lack of understanding about Active Directory, lack of planning, and lack of communication among departments. Remember, if a rogue department implements an Active Directory domain without joining the existing corporate forest, then that departmental domain is the root domain for its own forest. Rogue domains were a nuisance in a Windows NT 4.0 environment, but the effect of rogue domains is more significant with Active Directory because of the implications of DNS and namespace issues.

If you cannot avoid multiple forests, you can create manual trust relationships between specific domains in the different forests. However, these are nontransitive trusts, which means that you will have a domain model that resembles a Windows NT 4.0 environment, with multiple manual trusts between each domain.

In most cases, you should avoid having multiple forests because there are some inherent limitations to communication between forests. If the two domains belong to the same forest, a common Exchange organization can be formed spanning both domains. However, an Exchange organization cannot span domains in multiple forests. Multiple forests present obstacles for your Exchange design, and planning an Exchange organization in this type of environment requires working within certain restrictions. Two of the more significant Exchange design challenges are introduced because of problems, limitations, or restrictions associated with the GC and message routing. These challenges are explained in the following sections.

Global Catalog does not contain objects from multiple forests

The most user-visible problem with deploying Exchange in a multiple forest environment is the Active Directory GC. The GC only knows about objects within its own forest, and the GC is only replicated to domains within the forest.

Included in the list of GC objects is the list of e-mail users. In Exchange 5.5, the list of users was contained within the Global Address List (GAL). In Exchange 2003, the user list is incorporated within the GC. This has a direct impact on Exchange users because the list of users does not contain any users from other forests.

This was not a problem with Exchange 5.5 because organizations could span multiple untrusted Windows NT 4.0 domains without relying on the underlying Windows NT security. In Exchange 5.5, Exchange was responsible for replicating Exchange directory information, including the GAL to all Exchange sites. Exchange did not require special permissions or accounts in the multiple untrusted domains because replication between sites was performed using e-mail messages. This allowed users in all sites— regardless of their Windows NT domain—to see the complete list of users for the organization.

In Exchange 2003, the GC is owned and replicated by Active Directory. Because the forest is the boundary for the Active Directory environment, it is also the boundary for the Exchange organization, and it is not possible for an Exchange organization to span multiple forests (Figure 4.5).

Figure 4.5: Exchange 5.5 intersite replication

If you must implement Exchange in a multiple forest environment, you will need to implement two separate Exchange organizations. You cannot use a routing group connector between the two organizations, and Active Directory will not automatically replicate directory information, including the list of users, between the two separate Exchange organizations. Instead of a routing group connector, you will need to implement an SMTP connector or an X.400 connector between the organizations.

It is also possible to synchronize the user lists from the two Exchange organizations using an Active Directory Connector (ADC), but the users in each Exchange organization will see the other organization’s users as mailenabled contacts.

Note 

Microsoft promotes the ADC as a migration tool, rather than a coexistence tool. You should use the ADC to move to the end state rather than for long-term coexistence. Other tools, such as Hewlett-Packard’s Lightweight Directory Access Protocol (LDAP) Directory Synchronization Utility or Microsoft Metadirectory Services, are better for long-term coexistence.

Intelligent message routing not supported with multiple forests

Exchange 2003 automatically passes link state information between routing group connectors in the Exchange organization. The link state information includes the status of each link. Link failures are automatically recorded and are made known to other routing group connectors. This information allows the routing group connectors to quickly bypass broken links in favor of alternate routes. Once the failed links are fixed, the link state information is automatically updated. This intelligent routing is available only for routing group connectors. Unfortunately, Routing Group Connectors cannot be used across forest boundaries.

4.1.7 Domain controllers and authentication

A DC is a Windows server that controls user access to the network, including logon authentication and access to shared resources. The Active Directory resides within the DCs. Each DC holds a complete copy of the Active Directory domain naming context for the domain to which it belongs. Unlike Windows NT 4.0, all DCs in a native mode Active Directory environment are equal; there are no PDCs and no BDCs. Changes to the domain’s Active Directory objects can be made using any DC, and the DC automatically replicates those changes to other DCs.

Each DC also holds a complete copy of the schema and configuration information for the entire forest. This information is automatically replicated between all DCs in the forest.

There must be at least one DC in each domain, but it is advantageous to add a second DC to each domain. Multiple DCs reduce authentication bottlenecks and provide redundancy in case a DC fails. Three DCs are recommended. If you only have two DCs, you are at risk whenever you take one DC offline for maintenance. With three DCs, you are still protected if one of the DCs fails while you have one temporarily offline for maintenance.

Any Windows 2003 member server can become a DC. You promote a Windows member server to a DC using the Dcpromo utility. This process also can be reversed using the same utility (i.e., the DC can be demoted to once again become a member server).

Exchange servers are fairly directory intensive, using the DC to authenticate users and to obtain routing configuration information about the other servers in the organization. Because of this, you should consider having your Exchange servers and DCs on the same LAN.

If you deploy Exchange using front end and back end servers, the front end server is actually more directory intense than the back end Exchange server because the front end server handles client authentication. In this case, you may want to consider having the front end server act as a DC.

4.1.8 Global Catalog

A single GC exists for each forest, and it is the central repository for information about objects in the forest. The GC is where all Exchange information about users and mailboxes resides. There may be multiple GC servers within the forest. Only DCs can be GC servers. Each GC server contains the following:

• All attributes of all the objects in the domain in which the GC server resides

• A subset of all the attributes of all the objects in the other domains within the forest

Therefore, each GC server contains a partial replica of every object in each domain naming context within the forest. The attributes and objects from outside of the GC server’s own domain are read-only and can be changed only within the domain that owns the objects.

By default, the attributes stored in the GC are those most frequently used in search operations and those necessary to locate a full replica of the object. As a result, programs and users can use the GC to locate any object in the forest without replicating all domain information between DCs.

The information kept in the GC includes user names, associated e-mail addresses, and other user-related information that was kept in the Exchange GAL for Exchange 5.5. In Exchange 2003, the GAL is replaced by the GC. The GC is the most accessed Active Directory component and provides most of the directory services used by Exchange users and servers.

The Active Directory automatically builds the GC on the basis of information from the domains in the forest. The Active Directory also automatically builds the replication topology and, using the normal replication process, replicates the GC to all GC servers in the forest. Changes made to an Exchange user profile in one domain are automatically replicated to all of the GC servers.

The GC contains the most commonly needed attributes for all objects in the forest. When Exchange is installed, the installation process adds additional attributes that are known to be important to Exchange users.

Individual object attributes—not complete objects—are marked for replication. Table 4.2 describes some of the GC user attributes that are marked for replication in the GC.

Table 4.2: User Attributes Replicated by Global Catalog

User Attribute	Common Name	Lightweight Directory Access Protocol Attribute Name	Global Catalog
First name	Given-Name	givenName	Yes
Initials	Initials	initials	Yes
Last name	Surname	sn	Yes
Display name	Display-Name	displayName	Yes
Office	Physical-Delivery- Office-Name	physicalDelivery OfficeName	Yes
Telephone number	Telephone-Number	telephone Number	Yes
E-mail	E-mail-Addresses	mail	Yes
Street	Street-Address	street	Yes
P.O. Box	Post-Office-Box	postOfficeBox	Yes
City	Locality-Name	l	Yes
State/province	State-Or-Province- Name	st	Yes
Zip/Postal Code	Postal-Code	postalCode	Yes
Country/region	Country-Name	c	Yes
Home telephone number	Phone-Home- Primary	homePhone	Yes
Pager telephone number	Phone-Pager- Primary	pager	Yes
Mobile telephone number	Phone-Mobile- Primary	mobile	Yes
Fax telephone number	Facsimile-Telephone- Number	facsimileTelephone Number	Yes
IP phone number	Phone-Ip-Primary	ipPhone	Yes
Title	Title	title	Yes
Department	Department	department	Yes
Company	Company	company	Yes
Manager	Manager	manager	Yes
Direct reports	Reports	directReports	—
Alias	ms-Exch-Mail- Nickname	mailNickname	Yes

The default list does not include some attributes that may be needed by users, such as the user’s direct reports. The list of attributes can be extended if the default set is inadequate for users or applications in your environment. However, you should take care when changing the default set of replicated attributes.

Adding attributes will increase the network bandwidth required for replication. The precise network bandwidth impact depends on the number, type, and size of addition attributes selected for replication. Typical replication is less than 100 bytes per modified attribute. Because Active Directory does replication on a per-attribute basis rather than a per-object basis, Active Directory replication should require less bandwidth than replicating the same information in an Exchange 5.5 environment. Exchange 5.5 replicated all attributes for an object whenever even a single attribute for the object was changed. Thus, anywhere from 1,000 to 5,000 bytes is replicated for each object where an attribute was changed.

Removing attributes also should be done only after careful consideration. If Exchange is already deployed in your organization, you do not want to remove attributes that users have become accustomed to using. If you must remove attributes, you should ask your users and application developers which ones they rely on to ensure that you do not remove any critical attributes.

The Schema Manager is used to specify additional attributes that should be replicated to each GC server. The attributes included in the GC are consistent across all domains in the forest. It is not possible to replicate different attributes to different GC servers.

By default, when you create the first DC in a new forest, that DC is designated as a GC server for the forest. This is true only for the first DC in a new forest. When additional DCs are added (even in new domains), they do not automatically become GC servers; they only act as DCs. Once a server becomes a DC, you can designate it to be a GC server using the Active Directory Sites and Services Microsoft Management Console (MMC) console.

You should not arbitrarily label DCs as GC servers because GC servers need to be able to support thousands or even millions of objects, depending on the size of your environment.

Configuration and replication of the GC are automatic and require minimal management. The most important design decision regarding the GC is the number and placement of GC servers within the forest. Exchange makes heavy use of the GC servers and will attempt to balance the load of requests among available GC servers.

The most easily understood forest is one consisting of a single domain. For a single domain forest, the contents of the GC are the same as the contents of the DC itself because the GC contains all attributes of all the objects in the domain in which the GC server resides. Because all Active Directory objects are automatically replicated between all DCs within the single domain, there is no additional server or network bandwidth impact if you choose to label all DCs as GC servers. Having multiple GC servers within the domain would provide users and applications with access to a local server for GC information.

If you have a forest with multiple domains, you should configure at least one GC server for each domain where you plan to have Exchange servers or users. You also may want to configure additional GC servers. However, there is a tradeoff between network bandwidth demands and user/application access to the GC as shown in Table 4.3.

Table 4.3: Global Catalog Server Tradeoffs

	User and Application Access	Network
Fewer GC Servers	Fewer servers reduce the possibility that users will have access to a local copy of the GC. Users will be subjected to slower response times as inquiries must be performed over the network.	Fewer servers will require that an increased number of inquiries be sent over the WAN.
More GC Servers	More servers increase the possibility that applications and users will be able to have local access to the information they require.	Network bandwidth required for replication is directly related to the number of GC servers.

The number of Active Directory sites also influences the number of GC servers. For scalability and redundancy, it is recommended that you have at least two GC servers per site. This will improve availability and response time for applications and users. Of course, if you have many sites, it may not be practical to have two GC servers for every site. Some sites may be so small that you cannot justify allocating any GC servers to them. Active Directory uses a site coverage algorithm to automatically associate DCs and GC servers with sites that do not have them. The algorithm is based on the cost that is defined in the site link topology.

Every Exchange server caches the results from GC queries for a time in a cache called DSAccess. Almost all directory access queries from server-based Exchange processes first search the DSAccess cache before submitting the query to the GC server. Exchange makes heavy use of the GC, and caching reduces the frequency with which the Exchange processes send the same query to the GC servers. This reduces network traffic, improves performance of the Exchange processes, and reduces the load on the GC servers.

There are two significant exceptions to this process: address book lookups from MAPI clients and certain portions of SMTP inbound and outbound routing do not use the DSAccess cache.

Windows uses DNS to locate available GC servers for a site. DNS must contain a service record for each GC server, as shown in Figure 4.6.

Figure 4.6: Global Catalog Domain Name System service record

Applications can obtain directory information using two different ports:

• Port 3268. This port is used for queries specifically targeted for the GC. LDAP requests sent to port 3268 can be used to search for objects in the entire forest. However, only the attributes marked for replication to the GC can be returned. For example, a user’s department could not be returned using port 3268 because this attribute is not replicated to the GC.

• Port 389. This port is used for requesting information from the local DC. LDAP requests sent to port 389 can be used to search for objects only within the GC’s home domain. However, the requesting application can obtain all of the attributes for those objects. For example, a request to port 389 could be used to obtain a user’s department.

Exchange normally uses port 3268 to request object information from the GC because the GC contains a complete list of objects, is fully indexed, and is cached, all of which improves performance.

4.1.9 Sites

Active Directory sites are based on physical network topology. A site is a collection of Windows servers that can communicate over a highly reliable, high bandwidth, permanent connection. Typically, this translates to a range of Internet Protocol (IP) subnets or a collection of subnet ranges that have LAN speeds.

There is no direct relation between Active Directory sites and domains. A domain is a logical concept, and a site is a physical concept. Multiple sites can exist within a single domain, and a single site can include multiple domains. A site has boundaries based on the physical network topology, not on the logical domain topology.

Because communication between computers in the same site is reliable, fast, and efficient, you can use site definitions to take advantage of the physical network. There are two primary ways that sites enable you to optimize network traffic across the WAN:

• Replication. Replication of directory information between DCs within the same site is done using Remote Procedure Calls (RPCs). These RPCs are not scheduled, and the information is not compressed. Replication between DCs in different sites is done using SMTP. These replication messages can be scheduled, and the data are compressed. Uncompressed RPCs generate quite a bit of network traffic, and if your domain includes DCs connected over a WAN, this can be quite slow. You can use site definitions to specify where RPC-based replication is used.

• Logon authentication. Active Directory sites assist users in finding the closest DC to validate logon credentials. When a user requires logon authentication, the user’s workstation sends a request to the DNS server to locate DCs within the workstation’s site. The DNS server attempts to match the workstation’s IP address to a matching subnet defined in a site. If a match is found, the DNS server returns the names of the local DCs that can authenticate the logon. The client workstation will pick a DC and will attempt to ping the DC before logging on. If the DC fails to respond, the client workstation attempts to use another DC.

You define sites and build site links to describe the network using the Active Directory Sites and Services MMC console. The Knowledge Consistency Checker then automatically creates connections to establish an efficient, reliable replication topology.

The terminology chosen by Microsoft is unfortunate because previous versions of Exchange Server had used the term site to describe a logical grouping of servers. With Exchange, the concept of an Exchange site has been replaced by administrative groups and routing groups, but some confusion is likely to remain.

Although the Active Directory site concept has been inherited from previous versions of Exchange, there are some important conceptual differences, as described in Table 4.4.

Table 4.4: Active Directory Sites and Exchange 5.5 Sites

Active Directory Site	Exchange 5.5 Site
A site requires high-bandwidth, reliable, permanent network connections between all servers.	An Exchange 5.5 site requires high-bandwidth, reliable, permanent network connections between all servers.
A site is a collection of IP subnets based on the physical network topology.	An Exchange 5.5 site is a logical grouping of servers for administrative purposes.
A site has no relation with the Active Directory domain structure and does not include a unit of namespace.	An Exchange 5.5 site includes a unit of namespace in the X.500 structure.
A site has no administrative implications.	An Exchange 5.5 site defines an administrative boundary.
Exchange uses routing groups to define message flow. Routing groups are independent of site boundaries.	An Exchange 5.5 site defines message routing in the Exchange organization.

Exchange 2003 uses Active Directory sites to locate DCs or GC servers for address book lookups and to access configuration information. Beyond this, Exchange relies only minimally on sites.

4.1.10 Administrative groups

An Exchange 5.5 site was used to organize servers for two often contradictory purposes. An Exchange site was a logical administrative boundary used to delegate management responsibility for particular servers. A site also was used to layer the Exchange organization on top of the physical network topology; it defined the message routing boundaries. The Exchange 5.5 site concept has been replaced in Exchange 2003 with two separate concepts: administrative groups and routing groups.

An Exchange administrative group defines a logical administrative boundary.-An administrative group is a collection of Exchange servers and configuration objects that are grouped together because they will be managed by a common IT management group. An administrative group can contain multiple Exchange servers, routing groups, policies, and public folder trees.

Note 

If you have a mixed environment that contains both Exchange 2003 and Exchange 5.5 servers, an administrative group operates just like an Exchange 5.5 site.

An administrative group is defined so that you can delegate administrative responsibility. For example, if you have three regional IT management teams that each manage the Exchange servers in their respective regions, you can create three administrative groups containing the appropriate servers.

You can then grant the separate IT management teams appropriate permissions to the administrative groups. The Active Directory then automatically assigns these permissions to servers and other objects within the administrative groups.

Administrative groups need to be carefully planned because Exchange administrative groups have one of the same limitations that was a problem with Exchange 5.5 sites: Once you assign servers and mailboxes to an administrative group, it is difficult and requires special utilities to move the servers and mailboxes to another administrative group.

MAPI clients store sender addresses as distinguished names that are constructed on the basis of the administrative group in which the user’s mailbox resides. If you move a user mailbox from one administrative group to another, the user’s distinguished name will change, and users will not be able to reply to e-mail messages that the user sent before being moved.

Note 

You can work around the inability to reply to messages sent before moving a user by inserting an X.500 address type on the moved entity to match the previous location of the user.

This problem does not exist for Internet clients because they use SMTP addresses rather than distinguished names. As long as an Internet user’s SMTP address does not change, users will not have any problems replying to e-mail messages.

Enabling display of administrative groups and routing groups

Viewing administrative groups is disabled by default. The following procedure can be used to enable displaying administrative groups and routing groups:

1. Start the Exchange System Manager (ESM) console from the Windows Start menu by selecting All Programs →Microsoft Exchange →System Manager.

2. Right-click on the Exchange organization and select Properties to display the organization properties (Figure 4.7).

   
   Figure 4.7: Organization properties

3. Select the Display administrative groups check box to allow the administrative groups to be displayed and select the Display routing groups check box to display the routing groups.

4. You must restart ESM after enabling display of administrative groups and routing groups.

Creating an administrative group

The following procedure can be used to create an administrative group:

1. Start ESM from the Windows Start menu by selecting All Programs →Microsoft Exchange →System Manager.

2. Right-click on Administrative Groups and select New →Administrative Group.

3. General tab On the General tab, enter a name for the administrative group (Figure 4.8).

   
   Figure 4.8: New Administrative-Group window

4. Details tab Use the Administrative note field on the Details tab to enter additional information about the administrative group.

5. Select OK when finished.

4.1.11 Routing groups

Exchange routing groups define physical routing boundaries and are based on the underlying physical network connectivity and network bandwidth. All Exchange servers within a routing group communicate over reliable, highbandwidth, permanent network connections.

Messages sent from one Exchange server to another within the same routing group go directly between the two servers. However, if the two Exchange servers are in different routing groups, messages must be routed to a bridgehead server in the sender’s routing group, then to a bridgehead server in the recipient’s routing group, and finally to the recipient’s Exchange mailbox server. Unlike administrative groups, it is not difficult to move an Exchange server from one routing group to another.

Creating a routing group

You must create a routing group container under your administrative groups container before you can create a routing group. The following procedure can be used to create a routing group container:

1. Start ESM from the Windows Start menu by selecting All Programs →Microsoft Exchange →System Manager.

2. Select Administrative Groups, select the administrative group that will contain the routing group, and select Routing Groups.

3. Right-click on Routing Groups and select New →Routing Group.

4. General tab On the General tab, enter a name for the new routing group (Figure 4.9).

   
   Figure 4.9: New Routing Group window

5. Details tab Use the Administrative note field on the Details tab to enter additional information about the routing group.

6. Select OK when finished.

4.1.12 Schema

The schema defines all of the objects, called classes, that can be stored in the Active Directory. For each object class, the schema defines the attributes that must be included in an instance of the class, the additional attributes that each instance may have, and the object classes that may be the parent of the object. The schema itself is also stored in the Active Directory. This allows applications to query the Active Directory to identify the available objects and attributes that can be used to administer the object.

A default schema is created when you install the first DC in a new forest.-This default schema contains class definitions for commonly used objects attributes such as systems, printers, groups, and users.

Subsequent changes to the schema, including those required for Exchange process, result in a complete replication of the GC. This includes all objects and all attributes, not just the attributes that have been changed or added. For this reason, you should apply the Exchange-specific schema updates while your Active Directory forest is still small. In fact, before you can install Exchange, you must apply the Exchange-specific schema updates. Before you can install Exchange, you must first prepare the forest and each domain that will contain an Exchange server. You can use the following procedure to prepare the forest:

1. Insert the Exchange Server 2003 CD-ROM into your CD-ROM drive.

2. Select Run from the Windows Start menu. Enter x:\setup\i386\setup.exe/ ForestPrep, where x is your CD-ROM drive. Select OK to start the setup program.

You must run ForestPrep only once per forest. Updating the schema to add the Exchange takes a considerable amount of the time while several LDAP Directory Interface Format files are applied. The Schema Master for the forest must be available for the duration of this process, which often can take half an hour or longer depending on the server and network speed. The ForestPrep procedure extends the schema to include more than 150 additional classes and more than 800 additional attributes, such as the user’s display name and location. In addition, 270 attributes are marked for replication to the GC. All of the Exchange-specific attributes have names that begin with ms-Exch. Table 4.2 lists some of these common Exchange user attributes.

You must run the DomainPrep procedure for every Active Directory domain that will contain an Exchange server. DomainPrep is used to identify the address list server and to set permissions within the domain. You do not need to run DomainPrep in a domain until you are ready to install Exchange. You can use the following procedure to run Domain-Prep:

1. Insert the Exchange Server 2003 CD-ROM into your CD-ROM drive.

2. Select Run from the Windows Start menu. Enter x :\setup\i386\ setup.exe/DomainPrep, where x is your CD-ROM drive. Select OK to start the setup program.

As your needs change, you may decide to modify the schema to accommodate your changing requirements. For example, you may want to include an additional user attribute such as the user’s department in the GC. This type of change is quite easy using the Schema Manager, if you have the appropriate permissions. Every Active Directory object, including schema objects, is protected by Access Control Lists.

Schema changes also may be made by other applications. Like Exchange, other applications may automatically extend the schema to support their requirements.

Regardless of whether you make the schema changes or an application makes the schema changes, you should be aware that the schema changes will force a complete replication of the GC. All objects and all attributes—not just the modified or added attributes—will be replicated to every GC server. Depending on the number of GC servers and the size of the active directory, this complete replication process can cause significant network overhead. For this reason, schema updates should not be done frequently. If possible, they should be performed during the early part of your Active Directory implementation while the forest is still small.

Creating a Schema Manager MMC console

Improper use of the Schema Manager snap-in can cause serious problems; therefore, the snap-in is not available by default. Use the following procedure to enable the snap-in and create a Schema Manager MMC console:

1. Select Run from the Windows Start menu. Enter regsvr32schmmgmt.dll as the command to run. The system will display a dialog box that says “DllRegisterServer in schmmgmt.dll succeeded.” Select OK.

2. Start the MMC from the Windows Start menu by selecting Run. Enter MMC as the command to run and select OK. An empty MMC console window will be displayed.

3. Select Add/Remove Snap-in from the File menu (Figure 4.10).

   
   Figure 4.10: Microsoft Management Console Add/Remove Snap-in Window

4. Select Add to display a list of the available MMC snap-ins (Figure 4.11).

   
   Figure 4.11: Available Microsoft Management Console snap-ins

5. Select the Active Directory Schema snap-in and select Add. The selected snap-in will be added to the list of snap-ins for this MMC console. Select Close to return to the Add/Remove Snap-in window.

6. Select OK on the Add/Remove Snap-in window.

7. Select Options from the File menu to display the MMC snap-in options window (Figure 4.12).

   
   Figure 4.12: Microsoft Management Console snap-in options window

8. Set the following options on the Console tab:

   • Enter Schema Manager as the name for the new MMC console in the field at the top of the Options window.

   • Use the Console mode drop-down list to select User mode—full access. This mode grants users full access to all window management commands and to the console tree provided. It prevents users from adding or removing snap-ins or changing console properties.

   • Clear the Do not save changes to this console check box.

   • Select Allow the user to customize views if you want to allow customizing by the user.

9. Select OK when you have completed entering options.

10. Select Save As from the File menu.

11. Enter Schema Manager.msc into the File name field and select Save to save the new MMC console.

Tagging attributes for Global Catalog replication

You can mark additional attributes for GC replication using the following procedure:

1. Start the Schema Manager console from the Windows Start menu by selecting All Programs →Administrative Tools →Schema Manager.

2. Select Active Directory Schema →Attributes in the left pane.

3. In the right pane, locate and double-click on the attribute that you wish to replicate to the GC to display the attribute properties (Figure 4.13).

   
   Figure 4.13: Schema object attributes

4. Select the Replicate this attribute to the Global Catalog check box to tag this attribute for replication, then select OK.

---