3.11 Third-party tools | Monitoring and Managing Microsoft Exchange 2000 Server (HP Technologies)

Chapter 4 - Managing the Exchange Organization Topology
Monitoring and Managing Microsoft Exchange 2000 Server
by Mike Daugherty
Digital Press 2001

4.1 Understanding the Windows 2000 and Exchange 2000 hierarchy

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

The Windows 2000 Active Directory replacesand is a major improvement overthe Windows NT 4.0 directory services. The Active Directory also replaces the Exchange-specific directory service found in Exchange Server 5.5. Exchange 2000 relies completely on the Windows 2000 Active Directory and no longer has its own directory services.

The Active Directory provides considerable management flexibility to configure the administrative responsibilities to match your companys 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 delegate administrative responsibility to regional or departmental IT groups using the standard Windows 2000 management tools.

The administrative flexibility of the Active Directory is due in part to the Windows 2000 and Exchange 2000 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 group components so they can be located by name rather than by physical location.

Table 4.1: Windows 2000 and Exchange 2000 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 2000 routing groups
Exchange 2000 administrative groups

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 companys organizational structure and defining sites that matched your physical network topology. Exchange 2000 separates the logical and physical structures. The appropriate administrative model can be logically defined using administrative groups, while the physical structure can be defined using routing groups.

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

Many of terms in Table 4.1 are new. Even the ones that seem familiar may have new meanings. Before you can effectively manage an Exchange 2000 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 upon 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 object 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 users name, e-mail address, mailbox location, storage restrictions, delivery restrictions, and security information.

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

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

Distinguished names must be unique, but an administrator can change the DN 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 objects position within the Active Directory hierarchy and does not change if you reorganize the Active Directory hierarchy. Applications can use either distinguished names or globally unique identifiers to search for objects.

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 (OU), which allow you to group similar objects so they can be easily found and managed. An OU is the smallest object to which you can delegate administrative responsibility.

An organization unit can contain any object from within the domain, including other organizational units. Because OUs can contain other organizational units, 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 organizational units are shown in Figure 4.1:

Figure 4.1: Organizational units

Company, which contains the organizational units Europe and North America Europe, which contains the organizational units London and Valbonne North America, which contains the organizational units Dallas and Saint 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 printer located in Dallas
Saint Louis, which contains a printer object for the printer located in Saint Louis

Administrative responsibility can be delegated to any of these organizational units. For example, one administrator can be assigned responsibility for the printers in Dallas, while another administrator is assigned responsibility for the printers in Saint Louis.

4.1.3 Domains

A typical corporate Windows 2000 environment has one or more domains that contain all objects and organizational units 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. A Windows 2000 domain is a security boundary in the Windows 2000 network. Privileges granted in one domain do not apply in other domains.

Figure 4.2: Windows 2000 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 domain controller (DC) can be replicated to other DCs. Even if Exchange 2000 organizations are layered on top of multiple domains, information will still be replicated.

In Windows NT 4.0, a distinction was made between Primary Domain Controllers (PDCs) and Backup Domain Controllers (BDCs). Changes could only be made to directory information held on the domains PDC. The BDCs merely held a copy of the PDCs directory information. With Windows 2000, all Domain Controllers (DCs) 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 DNS name given to the first domain created. For example, if the first domain is named compaq.com , all subsequent domains within the tree will be of the form domain .compaq.com .
Domains added later cannot be added above the first domain in the domain tree. For example, if the first domain is named dallas.compaq.com , you cannot later create a domain called compaq.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).
Active Directory domains cannot be renamed in the initial release of Windows 2000.

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 domain controllers. 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 Windows 2000 domain topology based primarily on the underlying network infrastructure and delegation of administrative responsibilities. Exchange 2000 requirements are often not considered unless the Windows 2000 environment is being implemented specifically to support Exchange. Luckily, Exchange can be made to work with almost any Windows 2000 domain topology. However, Windows domain design decisions regarding domain names and when to switch to native mode can affect Exchange 2000.

Windows 2000 domain names

The Windows 2000 domain name becomes part of the SMTP e-mail addresses that will be used for Exchange 2000 users. In Windows NT 4, domain names were identified using NetBIOS-style names. For Windows 2000, domains are identified using both NetBIOS-style names and hierarchical Domain Name System (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.compaq.com

By default, the DNS domain name is part of each users logon name and e-mail address, such as john.smith@dallas.compaq.com. This default behavior may not be desirable in many companies. It is more common to have each users e-mail address be independent of the users Windows logon domain. For example, john.smith@compaq.com rather than john.smith@ dallas.compaq.com is preferable in most companies. There are three primary reasons for having the users 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 Windows 2000 domain controllers and Windows NT 4.0 domain controllers. All newly created Windows 2000 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 Windows 2000 domain controller essentially becomes the PDC for the NT 4.0-style domain. If there are multiple Windows 2000 domain controllers in a mixed-mode domain, the administrator can specify which server is the PDC.

A native mode domain can only have Windows 2000 domain controllers. No Windows NT 4.0 domain controllers are allowed, although Windows NT 4.0 member servers and non-Windows 2000 client systems are acceptable.

Native mode domains take full advantage of the Windows 2000 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 2000 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 Windows 2000 domain. Multiple domains can be combined into structures called trees and forests. A tree is a parent-child hierarchical arrangement of Windows 2000 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, compaq.com is the parent domain for europe.compaq.com and us.compaq.com. Similarly, us.compaq.com is the parent domain for nsis.us.compaq.com. Conversely, nsis.us.compaq.com is a child domain of us.compaq.com, which in turn is a child domain of compaq.com.

Figure 4.3: Windows 2000 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 2000.

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 Windows 2000 domain trees that share a common schema, share a common configuration, share a common global catalog, have a transitive Kerberos trust established between domains within every tree, but have a discontiguous namespace.

Figure 4.4: Windows 2000 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 domain controllers 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 Windows 2000 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 have both already implemented their own separate Windows 2000 forests. This is a difficult environment in which to implement Exchange 2000. Unfortunately, there are currently no tools for merging separate forests.

There are also situations where different divisions of the same company are legally required to maintain separate environments. This would also be a difficult environment for a single Exchange organization. However, the legal restrictions that require network isolation probably also prohibit a common Exchange organization, so it is unlikely that you would be asked to implement a single Exchange organization under 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. 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 sitesregardless of their Windows NT domainto 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 4.5.)

Figure 4.5: Exchange 5.5 intersite replication

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 usersbetween 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.

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 organizations 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.

4.1.7 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 domains 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.

4.1.8 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 servers 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 attributesnot complete objectsare marked for replication. Table 4.2 describes some of the global catalog user attributes that are marked for replication in the global catalog.

Table 4.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	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	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 users 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 4.3.

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.

Table 4.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.

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 lookups from MAPI clients and certain portions of SMTP inbound and out-bound 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 4.6.

Figure 4.6: Global Catalog DNS service record

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 users 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 catalogs 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 users 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.

4.1.9 Sites

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

There is no direct relationship between Windows 2000 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 domain controllers within the same site is done using Remote Procedure Calls (RPCs). These RPCs are not scheduled, and the information is not compressed. Replication between domain controllers in different sites is done using SMTP. These replication messages can be scheduled and the data is compressed. Uncompressed RPCs generate quite a bit of network traffic, and if your domain includes domain controllers connected over a WAN, this can be quite slow. You can use site definitions to specify where RPC-based replication is used.
Logon authentication . Windows 2000 sites assist users in finding the closest domain controller to validate logon credentials. When a user requires logon authentication, the users workstation sends a request to the DNS server to locate domain controllers within the workstations site. The DNS server attempts to match the workstations IP address to a matching subnet defined in a site. If a match is found, the DNS server returns the names of the local domain controllers that can authenticate the logon. The client workstation will pick a domain controller and will attempt to ping the DC before logging on. If the domain controller fails to respond, the client workstation attempts to use another domain controller.

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

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

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

Table 4.4: Windows 2000 Sites and Exchange 5.5 Sites
Windows 2000 Site	Exchange 5.5 Site
A Windows 2000 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 Windows 2000 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 Windows 2000 site has no relationship 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 Windows 2000 site has no administrative implications.	An Exchange 5.5 site defines an administrative boundary.
Exchange 2000 uses routing groups to define message flow. Routing groups are independent of Windows 2000 site boundaries.	An Exchange 5.5 site defines message routing in the Exchange organization.

Exchange 2000 Server uses Windows 2000 sites to locate domain controllers or global catalog servers for address book lookups and to access configuration information. Beyond this, Exchange relies only minimally on Windows 2000 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 was also 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 2000 Server with two separate concepts: administrative groups and routing groups.

An Exchange 2000 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 2000 and Exchange 5.5 servers, an administrative group operates just like an Exchange 5.5 site.

You define an administrative group so 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 2000 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 based on the administrative group in which the users mailbox resides. If you move a user mailbox from one administrative group to another, the users distinguished name will change, and users will not be able to reply to e-mail messages that the user sent prior to being moved.

Note	You can work around the inability to reply to messages sent prior to 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 users SMTP address does not change, users will not have any problem 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:

Launch the System Manager from the Windows 2000 Start menu by selecting Programs Microsoft Exchange System Manager.
Right-click on the Exchange organization and select Properties to display the organization properties (Figure 4.7).

Figure 4.7: The organization properties
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.
You must restart the Exchange System Manager after enabling display of administrative groups and routing groups.

Creating an administrative group

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

Launch the System Manager from the Windows 2000 Start menu by selecting Programs Microsoft Exchange System Manager.
Right-click on Administrative Groups, and select New Administrative Group.
On the General tab, enter a name for the administrative group (Figure 4.8).

Figure 4.8: The General tab of the Properties window
Use the Administrative note field on the Details tab to enter additional information about the administrative group.
Select OK when finished.

4.1.11 Routing groups

Exchange 2000 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, high bandwidth, 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 senders routing group, then to a bridgehead server in the recipients routing group, and finally to the recipients 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:

Launch the System Manager from the Windows 2000 Start menu by selecting Programs Microsoft Exchange System Manager.
Select Administrative Groups, select the administrative group that will contain the routing group, and select Routing Groups.
Right-click on Routing Groups and select New Routing Group.
On the General tab, enter a name for the new routing group, and then select OK.

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 domain controller 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 global catalog. 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 Windows 2000 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:

Insert the Exchange 2000 Server CD-ROM into your CD-ROM drive.
Select Run from the Windows 2000 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 (LDIF) files are applied. The Schema Master for the forest must be available for the duration of this process, which can often take a half an hour or longer depending upon the server and network speed. The ForestPrep procedure extends the schema to include over 150 additional classes and over 800 additional attributes such as the users display name and location. In addition, 270 attributes are marked for replication to the global catalog. 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 Windows 2000 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 DomainPrep:

Insert the Exchange 2000 Server CD-ROM into your CD-ROM drive.
Select Run from the Windows 2000 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 users department in the global catalog. A change such as this 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 (ACLs).

Schema changes may also be made by other applications. Like Exchange 2000, 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 global catalog. All objects and all attributesnot just the modified or added attributeswill be replicated to every global catalog server. Depending upon the number of global catalog 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 done during the early part of your Windows 2000 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, so the snap-in is not available by default. Use the following procedure to enable the snap-in and create a Schema Manager MMC console:

Select Run from the Windows 2000 Start menu. Enter regsvr32 schmmgmt.dll as the command to run. The system will display a dialog box that says DllRegisterServer in schmmgmt.dll succeeded. Select OK.
Start the Microsoft Management Console from the Windows 2000 Start menu by selecting Run. Enter MMC as the command to run and select OK. An empty MMC console window will be displayed.
Select Add/Remove Snap-in from the Console menu.
Select Add to display a list of the available MMC snap-ins (Figure 4.9).

Figure 4.9: A list of the available MMC snap-ins
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.
Select OK on the Add/Remove Snap-in window.
Select Options from the Console menu.
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.
- Select Enable context menus on taskpads in this console to display pop-up context-sensitive menus.
- Select Allow the user to customize views if you want to allow customizing by the user.
Select OK when you have completed entering options.
Select Save As from the Console menu.
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 Global Catalog replication using the following procedure.

Start the Schema Manager console from the Windows 2000 Start menu by selecting Programs Administrative Tools Schema Manager.
Select Active Directory Schema Attributes in the left pane.
In the right pane, locate and double-click on the attribute that you wish to replicate to the Global Catalog to display the attribute properties (Figure 4.10).

Figure 4.10: Schema attributes
Select the Replicate this attribute to the global catalog check box to tag this attribute for replication, and then select OK.