|   Register   |  
Search  

Monitoring and Managing Microsoft Exchange 2000 Server

Last Updated 2/3/2009 3:43:00 PM


Abstract


This chapter will help you better understand the Windows 2000 and Exchange 2000 hierarchy, so that you can more easily manage your Exchange environment.




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 replaces — and is a major improvement over — the 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 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 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.

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 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 1 lists the Windows 2000 and Exchange 2000 logical and physical structures.

TABLE 1: WINDOWS 2000 AND EXCHANGE 2000 LOGICAL AND PHYSICAL STRUCTURES
Logical StructurePhysical Structure
ObjectsDomain controllers
Organizational unitsGlobal catalog servers
DomainsSites (Windows sites, not Exchange sites)
TreesSchema
ForestsExchange 2000 routing groups
Exchange 2000 administrative groups  

Many of terms in Table 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.

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 user’s 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 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=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 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 globally unique identifiers to search for objects.

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 1:

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

Domains


A typical corporate Windows 2000 environment has one or more domains that contain all objects and organizational units as shown in Figure 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.

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 domain’s PDC. The BDCs merely held a copy of the PDC’s 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 user’s 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 user’s e-mail address be independent of the user’s 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 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 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.

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

Although it is possible for a company to implement multiple trees (see the next section), a single tree is usually preferable for implementing Exchange 2000.=

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

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.

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.



Page: 1, 2, 3, 4

next page

Rate this:
Recent Comments
There are currently no comments. Be the first to make a comment.