Managing the Exchange Organization Topology

Windows IT Pro

- Advertise

Managing the Exchange Organization Topology
View the book table of contents

Author:	Mike Daugherty
Published:	June 2000
Copyright:	2001
Publisher:	Digital Press

In other cases, divisions within the corporation may have their own IT staff, their own policies, and their own support organizations. While 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 Windows 2000, lack of planning, and lack of communication between departments. Remember, if a rogue department implements a Windows 2000 domain without joining the existing corporate forest, then the departmental domain is the root domain for its own forest. Rogue domains were a nuisance in a Windows NT 4.0 environment, but the affect of rogue domains is more significant with Windows 2000 because of the implications of DNS and name space 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 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 since there are some inherent limitations to communication between forests. If the two domains belong to the same forest, a common Exchange 2000 organization can be formed spanning both domains. However, an Exchange organization cannot span domains in multiple forests. Multiple forests present obstacles for your Exchange 2000 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 due to problems, limitations, or restrictions associated with the Global Catalog and message routing. These 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 Windows 2000 Global Catalog (GC). The Global Catalog only knows about objects within its own forest and the GC is only replicated to domains within the forest.

Included in the list of Global Catalog 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 2000, the user list is incorporated within the Windows 2000 Global Catalog. This has a direct impact on Exchange 2000 users since the list of users would not contain any users from other forests.

This was not a problem with Exchange 5.5 since 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 Global Address List 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 2000, the Global Catalog is owned and replicated by Windows 2000. Since the forest is the boundary for the Windows 2000 environment, it is also the boundary for the Exchange 2000 organization, and it is not possible for an Exchange organization to span multiple forests. (See Figure 5.)

If you must implement Exchange 2000 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 Windows 2000 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 X.400 connector or an SMTP connector between the organizations.

Instead of a routing group connector, you will need to implement an X.400 connector or an SMTP 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 mail-enabled contacts.

Intelligent message routing not supported with multiple forests
Exchange 2000 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 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.

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

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

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

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

Exchange servers are fairly directory-intensive, using the domain controller to authenticate users and to obtain routing configuration information about the other servers in the organization. Because of this, you may want to consider making your Exchange 2000 servers domain controllers.

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 since the front-end server handles client authentication. In this case, you may want to consider having the front-end server act as a domain controller.

Global catalog
A single global catalog (GC) exists for each forest, and it is the central repository for information about objects in the forest. The GC is where all Exchange 2000 information about users and mailboxes resides. There may be multiple global catalog servers within the forest. Only domain controllers can be global catalog servers. Each global catalog server contains:

All attributes of all the objects in the domain in which the global catalog server resides
A subset of all the attributes of all the objects in the other domains within the forest

Therefore, each global catalog server contains a partial replica of every object in each domain naming context within the forest. The attributes and objects from outside of the global catalog 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 global catalog 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 global catalog to locate any object in the forest without replicating all domain information between domain controllers.

The information kept in the global catalog includes user names, associated e-mail addresses, and other user-related information that was kept in the Exchange Global Address List for Exchange 5.5. In Exchange 2000 Server, the Global Address List is replaced by the global catalog. The global catalog is the most accessed Active Directory component and provides most of the directory services used by Exchange 2000 users and servers.

Windows 2000 automatically builds the global catalog based on information from the domains in the forest. The Active Directory also automatically builds the replication topology and replicates the global catalog using the normal replication process to all global catalog servers in the forest. Changes made to an Exchange user profile in one domain are automatically replicated to all the global catalog servers.

The global catalog contains the most commonly needed attributes for all objects in the forest. When Exchange 2000 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 2 describes some of the global catalog user attributes that are marked for replication in the global catalog.

TABLE 2: USER ATTRIBUTES REPLICATED BY GLOBAL CATALOG
User Attribute	Common Name	LDAP 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	physicalDeliveryOfficeName	Yes
Telephone number	Telephone-Number	telephoneNumber	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	postal Code	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	facsimileTelephoneNumber	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 upon the number, type, and size of addition attributes selected for replication. Typical replication is less than 100 bytes per modified attribute. Because Windows 2000 does replication on a per-attribute basis rather than a per-object basis, Windows 2000 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 should also 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 global catalog server. The attributes included in the global catalog are consistent across all domains in the forest. It is not possible to replicate different attributes to different global catalog servers.

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

You should not arbitrarily label domain controllers as global catalog servers since global catalog servers need to be able to support thousands or even millions of objects, depending upon the size of your environment.

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

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

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

TABLE 3: GLOBAL CATALOG SERVER TRADE-OFFS
	User and Application Access	Network
Fewer Global Catalog Servers	Fewer servers reduce the possibility that users will have access to a local copy of the global catalog. 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 wide area network.
More Global Catalog 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 global catalog servers.

The number of Windows 2000 sites also influences the number of global catalog servers. For scalability and redundancy, it is recommended that you have at least two global catalog 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 global catalog servers for every site. Some sites may be so small that you cannot justify allocating any global catalog servers to them. Windows 2000 uses a site coverage algorithm to automatically associate domain controllers and global catalog 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 2000 server caches the results from global catalog queries for a period of 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 global catalog server. Exchange makes heavy use of the global catalog and caching reduces the frequency with which the Exchange processes send the same query to the global catalog servers. This reduces network traffic, improves performance of the Exchange processes, and reduces the load on the global catalog servers.

There are two significant exceptions to this process. Address book look-ups from MAPI clients and certain portions of SMTP inbound and outbound routing do not use the DSAccess cache.

Windows 2000 uses DNS to locate available global catalog servers for a site. DNS must contain a Service Record (SRV) for each global catalog server, as shown in Figure 6.

Applications can obtain directory information using two different ports.

Port 3268. This port is used for queries specifically targeted for the global catalog. 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 global catalog can be returned. For example, a user’s department could not be returned using port 3268 since this attribute is not replicated to the global catalog.
Port 389. This port is used for requesting information from the local domain controller. LDAP requests sent to port 389 can be used to search for objects only within the global catalog’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 2000 normally uses port 3268 to request object information from the global catalog since the global catalog contains a complete list of objects, is fully indexed, and is cached, all of which improves performance.

Page: 1, 2 , 3, 4

ADS BY GOOGLE