Chapter 4 - Active Directory Design

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Sybil Wood, Technical Writer, Volt Technical Services
Markus Vilcinskas, Program Manager, Microsoft 

The Microsoft Windows 2000 Active Directory directory service extends the features of Windows-based directory services and adds entirely new features. This chapter describes the Active Directory namespace, including the forest and tree domain structure, organizational units, global catalog, trust relationships, and replication. This chapter also discusses how Microsoft Exchange 2000 Server uses the Active Directory namespace components, and how Domain Name System (DNS) influences the namespace.

Because the design of Active Directory has a tremendous effect on Exchange 2000 design and performance, information from the Microsoft Windows 2000 Server Resource Kit is included in this chapter along with information about Exchange-specific functionality and requirements.

Active Directory Overview

Active Directory is secure, distributed, partitioned, and replicated. It is designed to work well in any size installation, from a single server with a few hundred objects to thousands of servers with millions of objects. Active Directory adds many new features that make it easy to navigate and manage large amounts of information, saving time for both administrators and users. These features include a new domain model and hierarchical namespace.

The advantages of using one directory rather than several directories include centralized management, centralized administration, and a single replication mechanism. Most corporations that use multiple directories attempt to unify their directories either through complex replication algorithms or through the use of unified directories such as Active Directory. Exchange 2000 removes the complexity of creating a unified directory because it uses Active Directory as its sole directory for services and data storage.

When you install Windows 2000 Server, Internet protocol stacks such as Simple Mail Transfer Protocol (SMTP) and Network News Transfer Protocol (NNTP) are configured as part of the operating system. The operating system and other components use these stacks; for example, it is possible to replicate Active Directory information using SMTP rather than remote procedure call (RPC) communications. The Exchange 2000 installation extends these stacks with additional command verbs and advanced routing components to provide all of the functionality required for an enterprise-class messaging and collaboration system.

Namespaces in Your Company

A namespace is a set of unique names for resources or items used in a shared computing environment. Namespaces can be found in almost all systems (network operating systems, software tools, directories, DNS, messaging systems, database systems, and so on). The names in a namespace can be resolved to the objects they represent. For DNS, the namespace is the vertical or hierarchical structure of the domain name tree. For example, each domain label, such as host1 or example, used in a fully qualified domain name (FQDN), such as host1.example.microsoft.tld, indicates a branch in the domain namespace tree.

Active Directory is primarily a namespace, as is any directory service. A namespace is any bounded area in which a given name can be resolved. Name resolution is the process of translating a name into some object or information that the name represents. Active Directory forms a namespace in which the name of an object in the directory can be resolved to the object itself.

For Active Directory, namespace corresponds to the DNS namespace structure and it resolves Active Directory object names. The domain is a collection of resources on the network that includes one or more domain controllers. The domain namespace consists of domains, trees, and forests, and defines the boundary of the domain. All Active Directory domains are identified by a DNS-style naming convention and a name that is compatible with network basic input/output system (NetBIOS). For example:

DNS-style domain name: seattle.microsoft.tldNetBIOS name: SEATTLE

In general, the NetBIOS name will be similar to the first naming component of the DNS-style name; however, NetBIOS restricts the type and number of characters in the name and subsequently the two names may look different from one another. Upon creation of the domain, the Active Directory administrator can configure both the DNS-style and NetBIOS domain names.

Note In the initial release of Windows 2000 Server, Active Directory domains cannot be renamed.

A forest is a collection of one or more Windows 2000 domains that share a common schema, configuration, and global catalog and are linked with two-way transitive trusts.

Planning the DNS Namespace

The resolution of names through DNS is central to Windows 2000 Server operation. Without proper name resolution, users cannot locate resources on the network. It is critical that the design of the DNS namespace be created with Active Directory in mind and that the larger namespace that exists on the Internet not conflict with a company's internal namespace.

The recommended approach to DNS design is to design the Active Directory environment first and then support that design with the DNS structure. However, in some cases, the DNS namespace might already be in place. In such a configuration, the Active Directory environment should be designed independently and then implemented either as a totally separate namespace or as a subdomain of the existing namespace. If the namespace you choose already exists on the Internet, it might cause name resolution problems for internal clients. Consider the following when you plan the DNS namespace:

• Identify the DNS namespace that you will be using for your domain. Identify the name that your company has registered for use on the Internet (for example, company.tld). If your company does not have a registered name, but you will be connected to the Internet, you may want to register a name on the Internet. If you choose not to register a name, make sure that you choose a name that is unique on the Internet. 

  Note Throughout this chapter, the root domain name .tld is used to distinguish fictitious or sample domain names from actual domain names. Typically, the root domain name is .com, .edu, .org, and so on, rather than .tld. 

• Use different internal and external namespaces. Internally, you could use company.tld or a subdomain of the external name such as corp.company.tld. The subdomain structure could be useful if you already have an existing DNS namespace. Different locations or departments can be named with different subdomains such as nameone.corp.company.tld or nametwo.corp.company.tld to ease administration. 

• Make Active Directory child domains immediately subordinate to their parent domains in the DNS namespace. You can choose to create subdomains for departments or locations within your company. For example, leveltwo.levelone.corp.company.tld 

• Separate internal and external names on separate servers. External servers should include only those names that you want to be visible to the Internet. Internal servers should contain names that are for internal use. You can set your internal DNS servers to forward requests that they cannot resolve to external servers for resolution. Different types of clients require different kinds of name resolution. Web proxy clients, for example, do not require external name resolution because the proxy server does this on their behalf. 

  Overlapping internal and external namespaces are not recommended. In most cases, the end result of this configuration is that computers cannot locate needed resources because they receive incorrect Internet Protocol (IP) addresses from DNS. This is particularly a concern when network address translation is involved and the external IP address is in an unreachable range for internal clients. 

• When you run the Active Directory Installation Wizard (Dcpromo.exe), you can configure a DNS server on the local computer and configure the forward lookup zones. Active Directory Installation Wizard examines the TCP/IP configuration on the computer and determines whether the computer is configured to use any DNS servers. If so, Active Directory Installation Wizard queries the root servers. If the computer is not configured to use any DNS servers, Active Directory Installation Wizard queries the Internet root servers. If it cannot contact any root servers, it configures the local computer as a root server and creates the "." (root domain) zone. 

  Make sure that root servers are not created unintentionally. Active Directory Installation Wizard can create root servers, resulting in internal clients being able to reach external clients or parent domains. If the "." zone exists, a root server has been created. It may be necessary to remove this for proper name resolution to work. 

Defining the Namespace Architecture

When designing an Active Directory namespace architecture, you should consider the following design criteria:

• Replication traffic requirements 

• The ability to accommodate company restructuring without expensive domain changes 

• The ability to evolve the design as company needs change 

Domain Structure

The basic unit in Active Directory is the domain. An Active Directory domain allows you to group and administer a collection of resources on the network. The domain boundary defines the namespace and includes one or more domain controllers.

A single domain can span multiple physical locations or Windows 2000 Server sites. Unlike Windows NT 3.x and Windows NT 4.0, which used primary domain controllers (also known as PDCs) and backup domain controllers (also known as BDCs), Active Directory uses a multimaster peer controller model called the domain controller. All domain controllers that are authoritative for a given domain can receive changes directly and propagate those changes. This allows replication to occur between sites within a domain, even if a domain controller is down.

Domain Controller

A server that can authenticate users for a domain is called a domain controller. There must be at least one domain controller in each domain. Each domain controller holds a complete replica of the domain naming context for the domain to which it belongs, and a complete replica of the configuration and schema naming contexts for the forest. You can promote a member server to a domain controller using Active Directory Installation Wizard (Dcpromo.exe). In addition, you can demote a domain controller back to a member server by using Active Directory Installation Wizard.

The First Domain

The first domain within an Active Directory forest plays an extremely important role. In fact, the name of the entire forest is based on the DNS name of the first domain that is installed in the forest. There are two important factors to take into consideration when defining the first domain:

1. The first domain can never be removed from the forest. 

2. Other domains cannot be represented above the first domain in the domain tree. If the first domain is named cat.microsoft.tld, it is not possible to create microsoft.tld afterwards; however, other domain trees such as msnbc.tld can be installed in the forest afterwards. The key to remembering this is that you cannot create domains with names that are part of the first domain, but you can create domains that form other trees. 

The design strategy for most large companies is to create the first domain as a placeholder for the rest of the forest. The first domain contains only domain controller computer accounts. If you plan to create this domain and store it in a separate tree from the rest of the company, you should still have the domain name registered on the Internet, and it should not have an arbitrary name, such as firstdomain.tld.

Building this placeholder domain ensures that companies that have decentralized information technology departments can bring their domains online when they are ready without having to wait for other departments to catch up. This prevents departments from creating their own forests.

Additional Domain Controllers

The number of domain controllers you will create for a given domain is driven by two factors: fault tolerance requirements and load distribution requirements.

For each domain, use the following guidelines to determine if more domain controllers are necessary:

• Always create at least two domain controllers. 

  Even for small domains with small user populations, create at least two domain controllers so that there is no single point of failure for the domain. 

• For each Windows 2000 site that contains a single domain controller, decide if you trust the WAN for fail-over. 

  Should the single domain controller fail, clients in the Windows 2000 site can be serviced by domain controllers for that domain that are located in other sites. If network connectivity is unreliable or intermittently available, you might not want to trust the network to handle fail-over. In that case, place a second domain controller for that domain into the Windows 2000 site. 

• Place additional domain controllers for a domain into a Windows 2000 site to handle the client workload. 

The number of clients that a particular server can handle depends on the workload characteristics and the hardware configuration of the server. Client computers randomly select from the available domain controllers in a Windows 2000 site to distribute client load evenly.

Domain Mode

An Active Directory domain can be in either mixed mode or native mode. In mixed mode, the domain is restricted to limitations (such as 40,000 objects) imposed by the Windows NT 4.0 domain model. However, it is possible to place a Windows 2000 domain controller in a Windows NT 4.0 domain. For this to happen, the first Windows 2000 domain controller takes on the role of the Windows NT 4.0 primary domain controller. While a domain is in mixed mode, the Windows 2000 domain controller functions as a Windows NT 4.0 primary domain controller with the scaling constraints of a Windows NT 4.0 primary domain controller. Windows NT 4.0 backup domain controllers see the Windows 2000 domain controller as the primary domain controller. When multiple Windows 2000 domain controllers are present in a mixed-mode domain, you can dictate, through the administration interface, which Windows 2000 domain controller functions as the primary domain controller.

Note Microsoft Exchange 2000 Server also runs in either mixed mode or native mode. Although the concept of mode is similar in both Windows 2000 Server and Exchange 2000, the mode in Windows 2000 Server is different than the mode in Exchange 2000.

To gain the scalability benefits and functionality of an Active Directory domain, you must switch the Windows 2000 domain to native mode. Switching to native mode is irreversible and requires that all domain controllers be upgraded to Windows 2000. Native mode operation allows Active Directory to scale up to millions of objects and overcomes the constraints of the previous Security Accounts Manager (SAM). A domain in native mode allows for rich group creation and nesting, which is advantageous for Exchange 2000. A native-mode domain cannot include Windows NT 4.0 domain controllers, but can include Windows NT 4.0 member servers. Thus, Windows NT 4.0 clients do not need to be upgraded to belong to a native-mode domain.

Having your domains in native mode not only provides the operating system with additional scalability, but also simplifies the Exchange 2000 installation process, because it is possible to create and use universal security groups for public folder access.

Domain Tree

Domains are represented in a parent and child hierarchy known as a domain tree. A domain tree is a set of one or more Windows 2000 domains with contiguous names. Standard DNS domain names are used to represent the tree structure (for example, exchange.microsoft.com). Because microsoft.com does not have a parent domain, it is considered the tree root domain. The child domains of microsoft.com are exchange.microsoft.com and nwtraders.microsoft.com. A grandchild domain of microsoft.com is jp.nwtraders.microsoft.com. These domain names are contiguous because each name has only one label different from the name of the domain above it in the domain hierarchy. Figure 4.1 presents a single tree with a contiguous namespace.

 

Figure 4.1 Single tree with four domains 

Domains within the forest that do not have the same hierarchical domain name are in a different domain tree. When different domain trees are in a forest, the tree root domains are not contiguous. Disjoint namespace is the phrase used to describe the relationship between different domain trees within the forest. A multiple-tree forest is shown in Figure 4.2.

 

Figure 4.2 Forest with multiple trees 

Domain Name System Overview

The DNS namespace is a distributed database organized as a hierarchical tree. Each node of this tree is called a domain and has a name. The first node in this tree is the root node and has an empty string as a name. Each node can have at least one child, which is also known as a subdomain.

Resource Records

Each DNS database consists of a set of resource records, which have one of the following formats:

[TTL] [class] type RDATA
[class] [TTL] type RDATA

The basic goal of a resource record is to associate a value with an entry. In addition, each resource record has a type identifier. For example, if you want to know which host acts as a mail exchanger (MX) for a given domain, you can query a database for all MX resource record entries. The most common resource records are A (host) resource records and PTR (pointer) resource records. The objective of an A resource record is to associate a particular host name with an IP address, whereas a PTR resource record associates an IP address with a particular host name, a process known as reverse lookup.

Note The DNS servers used by Active Directory must support SRV (service) resource records, which are explained later in greater detail.

Zones

Ideally, the first DNS server should maintain the information for the entire tree. However, because the content size of the Internet namespace can result in more records than a single DNS server can maintain, it may be necessary to delegate the authority for a specific portion of a namespace to another DNS server. Delegation in this case is the process of adding an entry that points to another DNS server into the database on the first DNS server. The second DNS server has the authority for the records representing the contiguous set of DNS names that follow the pointer. The contiguous set of records a DNS server is responsible for is called a zone. A DNS server that contains a zone is said to be authoritative for the names in that zone. For more information about zones, see the Windows 2000 Server Deployment Planning Guide. For more information about DNS, see https://www.microsoft.com.

Active Directory Logical Structure

Active Directory is an enterprise-wide directory service that is used by both Windows 2000 and Exchange 2000. For organizations that use earlier versions of Exchange, there may be design considerations for Active Directory that are specific to Exchange. It is important to understand these design decisions when you are planning the namespace.

When you plan for and deploy Active Directory in an enterprise, you are defining a significant part of your company's network infrastructure. The way in which you design Active Directory determines:

• The availability and fault tolerance of Active Directory. 

• The network usage characteristics of Active Directory clients and servers. 

• How efficiently you can manage the contents of Active Directory. 

• The way users view and interact with Active Directory. 

• The ability of Active Directory to evolve as your Exchange organization evolves. 

Design considerations affect each part of Active Directory. These considerations can be broken into four major areas: the Active Directory domain structure, the forest, the organizational unit structure, and Windows 2000 site topology.

Domain Design

Each forest that you create contains one or more domains. Defining the domains that make up your forest, including the domains that support your enterprise, requires:

• Determining the number of domains in each forest 

• Choosing a forest root domain 

• Understanding the impact of changes to the domain plan after deployment 

How you design your domain also determines the availability of Active Directory on the network, the traffic characteristics of client queries, and the traffic characteristics of domain controller replication.

Determining the Number of Domains in Each Forest

To determine the number of domains you need in each forest, first consider having a single domain, even if you currently have more than one domain in your Windows NT 4.0 installation. Next, provide a detailed justification for each additional domain. Every domain that you create introduces some incremental cost in terms of additional management overhead. For this reason, be certain that each domain you add to a forest serves a beneficial purpose.

When to Create More Than One Domain

Three possible reasons for creating additional domains are:

• Preserving existing Windows NT domains 

  If you already have domains running Windows NT, you might prefer to keep them as they are instead of consolidating them into a smaller number of domains using Active Directory. Before you decide to keep a domain, be sure to weigh the costs against the long-term benefits of having fewer domains. 

• Administrative partitioning 

  More domains might be necessary to meet the administrative and policy requirements of your company. Consider the following issues:

  • Unique security policy requirements 

    You might want a set of users on your network to abide by a domain user security policy that is different from the security policy applied to the rest of the user community. For example, you might want your administrators to have a stronger password policy, such as a shorter password change interval, than the regular users on your network. To do this, you must place your administrators in a separate domain. 

  • Autonomous domain administration requirements 

    The members of the domain administrators group in a given domain have complete control over all objects in that domain. If you have a division in your company that will not allow outside administrators to have control over their objects, place those objects in a separate domain. For example, for legal reasons, it might not be advisable for a subdivision of a company that works on highly sensitive projects to accept domain supervision from a higher-level Information Technology group. Remember that all domains in the forest must share the Configuration container and schema. 

• Physical partitioning 

  Physical partitioning involves taking the domains you have in a forest and dividing them up into a greater number of smaller domains. Having a greater number of smaller domains allows you to optimize replication traffic by replicating objects only to places where they are most relevant. For example, in a forest containing a single domain, every object in the forest is replicated to every domain controller in the forest. This might lead to objects being replicated to places where they are rarely used, which is an inefficient use of bandwidth. For example, a user who always logs on at a headquarters location does not need the user account replicated to a branch office location. You can avoid replication traffic by creating a separate domain for the headquarters location and not replicating that domain to the branch office. 

Incremental Costs for an Additional Domain

Each domain in the forest introduces some amount of management overhead. When debating whether or not to add a domain to your domain plan, weigh the following costs against the benefits:

• More domain administrators 

  Because domain administrators have full control over a domain, the membership of the domain administrators group for a domain must be closely monitored. Each added domain in a forest incurs this management overhead. 

• More domain controller hardware 

  In Windows 2000, a domain controller can host only a single domain. Each new domain that you create requires at least one computer, and in most cases requires two computers to meet reliability and availability requirements. Because all Windows 2000 domain controllers can accept and originate changes, you must physically guard them more carefully than you did Windows NT 4.0 backup domain controllers, which were read-only computers. Note that the administration delegation within Active Directory domains reduces the requirement for resource domains. Some remote locations that currently must host two domain controllers (a master user domain and a local resource domain) now require only one domain controller, if you choose to consolidate to fewer Active Directory domains. 

• More trust links 

  For a domain controller in one domain to authenticate a user from another domain, it must be able to contact a domain controller within the second domain. This communication represents an added possible point of failure if, for example, the network between the two domain controllers is malfunctioning at the time. The more users and resources located in a single domain, the less an individual domain controller must rely on being able to communicate with other domain controllers to maintain service. 

• Greater chance of having to move users and groups between domains 

  The more domains you have, the greater the chance you have to move users and groups between two domains. For example, a business reorganization or a job change for a user can create the need to move a user between domains. To users and administrators, moving a user or group between organizational units inside a domain is a trivial and transparent operation.

  However, moving users and groups between domains is more involved and can impact the user. 

• Group Policy and access control do not flow between domains 

  Group Policy and access control applied within a domain do not flow automatically into other domains. If you have policies or delegated administration through access control that is uniform across many domains, they must be applied separately to each domain. 

Choosing a Forest Root Domain

After you have determined how many domains you will place in your forest, you need to decide which domain will be the forest root domain. The forest root domain is the first domain that you create in a forest. The two forest-wide groups, Enterprise Admins and Schema Admins, reside in this domain.

Note If all of the domain controllers for the forest root domain are lost in a catastrophic event, and one or more domain controllers cannot be restored from backup, the Enterprise Admins and Schema Admins groups will be permanently lost. There is no way to reinstall the forest root domain of a forest. If your forest contains only one domain, that domain is the forest root domain. If your forest contains two or more domains, consider the following two approaches for selecting the forest root domain:

• Using an existing domain 

  From the list of domains you have, select a domain that is critical to the operation of your company and make it the forest root domain. Because you cannot afford to lose this domain, it already requires the kind of fault tolerance and recoverability that is required for a forest root domain. 

• Using a dedicated domain 

  Creating an additional, dedicated domain to serve solely as the forest root domain carries all the costs of an extra domain, but it has certain benefits that might apply to your company, such as:

  • The domain administrator in the forest root domain can manipulate the membership of the Enterprise Admins and Schema Admins groups. You might have administrators who require domain administrator privileges for some part of their duties, but you do not want them to manipulate the forest-wide administrators groups. By creating a separate domain, you avoid having to place these administrators into the domain administrators group of the forest root domain. 

  • Because the domain is small, it can be easily replicated anywhere on your network to provide protection against geographically centered catastrophes. 

  • Because the only role the domain has is to serve as the forest root domain, it never risks becoming obsolete. On the other hand, when you select a domain from your planned list of domains to be the forest root domain, there is always a chance that the domain you choose will become obsolete, perhaps due to a change in your company. However, you will never be able to fully retire such a domain, because it must serve as the forest root domain. 

Changing the Domain Plan After Deployment

Domain hierarchies are not easy to restructure after they have been created. For this reason, it is best not to create domains that are based on a temporary or short-lived organizational structure. For example, creating a domain that maps to a particular business unit in your company might create work for you if that business unit is split up, disbanded, or merged with another unit during a corporate reorganization.

However, there are cases where organization-based partitioning is appropriate. Geographic boundaries provide a relatively stable template for partitioning, but only if the organization does not frequently move across those boundaries. Consider a domain plan for an army, where the army has different divisions spread across a number of bases. It might be common for divisions to move between bases. If the forest were partitioned according to geographic location, administrators would have to move large numbers of user accounts between domains when a division moved between bases. If the forest were partitioned according to divisions, administrators would only have to move domain controllers between bases. In this case, organization-based partitioning is more appropriate than geographic partitioning.

Exchange 2000 and Active Directory Domain Design

The Windows 2000 Active Directory domain structure has more impact on Exchange 2000 than Windows NT 4.0 had on Exchange version 5.5. In Windows 2000 Server, the domain boundaries define the namespace and each domain includes one or more domain controllers.

It is possible for a Windows 2000 domain controller to be placed into a Windows NT 4.0 domain; this is called a mixed-mode domain. It is important to determine whether the environment is running in mixed mode or in native mode. In a mixed-mode environment, universal groups cannot be used, which impacts the use of security and distribution groups.

In addition, it is important to consider the domain tree structure and verify that Exchange fits properly in it and complies with security and administrative requirements. For example, consider a company that has four separate domains. (Technically, this company could have achieved the same results by using a single domain model and organizational units; however, the decision to create separate domains depends on political or geographical factors.) Multiple domains affect the Exchange design in a number of ways. One impact is user management and migration. Moving users between domains is not as transparent to the user as would be the case if the user were to be moved between servers within a domain. Users migrating from Lotus Notes to Exchange also need more consideration when migration is done in a multiple domain environment.

DNS Service

Clients in an Active Directory environment rely on the availability of the DNS service. Clients query the DNS service for the IP addresses of service providers for the Lightweight Directory Access Protocol (LDAP) and the Kerberos V5 services. Clients require at least one DNS server to locate the domain controllers that support elementary services.

In addition, clients need to locate at least one domain controller for the logon procedure. The client sends a query for a list of the domain controllers in its site to the DNS server. The client contacts all of the domain controllers that the DNS server sends back, and uses the first domain controller that responds to the client's logon procedure.

Advantages of DNS Service

The Windows 2000 DNS service provides the best integration with Active Directory. Additional benefits of using the Windows 2000 DNS service are:

• Increased fault tolerance 

• Easier management 

• Easier security administration 

• More efficient replication of large zones 

Windows 2000 Server and Berkeley Internet Name Domain (BIND) 8 implementation support dynamic update. Service (SRV) resource records are supported by the following DNS servers:

• Windows 2000 Server 

• Windows NT Server 4.0 Service Pack 4 and later 

• BIND 4.9.6 and later 

Security

Security is an elementary requirement of the highest importance for a modern computer network. Security guards against all types of illegal network access, including malicious attacks or user mistakes and interference. Security of the objects in a zone database is vital because a DNS database is a complete information system that can provide an intruder with the information needed to attack your network.

Dynamic Update

The Windows 2000 DNS service supports the concept of secure dynamic updates. Dynamic update, which is specified in RFC 2136, relieves administrators of the responsibility of keeping the entries in the zone databases consistent. If you are using the Windows 2000 DNS service, dynamic update allows an administrator to specify which users and computers are allowed to perform changes on the DNS zone databases. In addition, entries in a zone database can have access control lists (ACLs) assigned to them. However, if you are not using the Windows 2000 DNS service, dynamic update is not supported and zone database entries cannot have ACLs assigned to them.

Note Clients do not support dynamic update and must be configured to keep their records up to date. When a Dynamic Host Configuration Protocol (DHCP) server is integrated with dynamic update, it is possible to specify which part of the DHCP server is covered by dynamic update. The administrator can also specify the strategy to be used in the event a name conflict occurs. Unless specified otherwise, clients solve name conflicts by overriding an entry in a zone database.

Using Non-Windows 2000 DNS Service

Active Directory can operate without a Windows 2000 DNS server. However, using a Windows 2000 DNS server makes administration and maintenance easier. If you already have an implemented DNS structure that is running on a third-party DNS server, consider whether the advantages described earlier are worth the expenditure of a dedicated Windows 2000 DNS server. Also, compare the features supported by your DNS server with those features offered by a Windows 2000 DNS server.

If you do not use the Windows 2000 DNS service, you must plan the roles of the available DNS servers very carefully. The main DNS database that contains the records for a given company is known as the primary zone. An administrator can create secondary zones on other DNS servers where the content of the zones is determined by a backup mechanism known as "zone transfer." Using zone transfer guarantees fault tolerance.

Note RFC 9095 introduces the concept of "Incremental Zone Transfer" which reduces network traffic and minimizes the amount of data that must be transferred over the network to keep DNS server content consistent. Incremental zone transfer enables DNS servers to request only those changes that are necessary to keep the zone database up to date. However, the incremental zone transfer environment needs to be well planned.

If you use the Windows 2000 DNS service, it is not necessary to use primary and secondary zones and incremental zone transfer. Instead of configuring the backup roles of the DNS servers, it is possible to connect all DNS servers to a given Active Directory structure, perform zone database changes on each of them, and let the Active Directory replication mechanism update the content of the zone databases. Thus, by using the Windows 2000 DNS service, you can reduce administrative costs dramatically and maintain a very high level of fault tolerance.

Although it is possible to use Active Directory without Windows 2000 DNS servers, you must delegate the following zones to DNS servers if Windows 2000 DNS servers are not used:

• _tcp.Active Directory domain name 

• _udp.Active Directory domain name 

• _msdcs.Active Directory domain name 

For more information about Active Directory and DNS, see the Microsoft Windows 2000 Server Resource Kit TCP/IP Core Networking Guide, available from Microsoft Press.

Placing DNS Servers

At a minimum, place at least one DNS server in each Windows 2000 Server site. Depending on other considerations, such as the network bandwidth and resultant response times, it may be necessary to add additional DNS servers to your company.

Important The DNS service can run on a domain controller.

In order to reduce replication traffic, DNS servers can be configured as caching-only servers. A caching-only server forwards queries to DNS servers and builds up its cache from the resolved queries of which it is notified. A caching-only server is not responsible for a specific zone.

Besides the amount of network traffic, security must be considered. For example, it might be necessary to place a DNS server in front of a firewall if you don't want your main name server to be accessible from outside your company.

Domain Naming Recommendations

To create the domain hierarchy in a forest, assign a DNS name to the first domain, and then decide for every subsequent domain if it is a child of the first domain or if it is a new root domain. Based on that evaluation, assign names accordingly. Some recommendations for naming domains include:

• Use names relative to a registered Internet DNS name. 

  Names registered on the Internet are globally unique. If you have one or more registered Internet names, use those names as suffixes for the domain names in Active Directory. 

• Use Internet standard characters. 

  Internet standard characters for DNS host names are defined in RFC 1123 as 'A'-'Z', 'a'-'z', '0'-'9', and '-'. Using only Internet standard characters ensures that Active Directory complies with standards-based software. To support the upgrade of domains in Windows NT 4.0 or earlier that have non-standard names, Microsoft client computers and the Windows 2000 DNS service support almost any Unicode characters in a name. 

• Never use the same name twice. 

  Never give the same name to two different domains, even if those domains are on unconnected networks with different DNS namespaces. For example, if Northwind Traders decides to name a domain on the intranet nwtraders.tld, it should not also create a domain on the Internet called nwtraders.tld. If a nwtraders.tld client computer connects to both the intranet and Internet simultaneously, it selects the domain that answers first during the SRV record search. To the client, this selection appears random, and there is no guarantee that the client selects the intended domain. An example of such a configuration is a client computer that has established a virtual private network connection to an intranet over the Internet. 

• Use names that are distinct. 

  Some proxy client software, such as the proxy client built into Microsoft Internet Explorer or the Windows Sockets proxy client, uses the name of a host to determine if that host is on the Internet. Most software of this type provides, at minimum, a way of excluding names with certain suffixes as being local names, instead of assuming they are on the Internet. 

  If Northwind Traders wants to call an Active Directory domain on their intranet nwtraders.tld, they must enter nwtraders.tld in the exclusion list of their proxy client software. This prevents clients on the Northwind Traders intranet from seeing a host on the Internet called www.nwtraders.tld. 

  To avoid this problem, Northwind Traders can use a registered name that does not have a presence on the Internet, such as nwtraders-internal.tld, or establish a company policy that requires names ending in a specific suffix or nwtraders.tld. Thus, for example, corp.nwtraders.tld would never appear on the Internet. In both cases, it is easy to configure proxy client exclusion lists so that they can determine which names are on the intranet and which are on the Internet. 

  There are many different techniques for accessing the Internet from a private intranet. Before using any name, ensure that it can be properly resolved by client computers on your intranet given your specific Internet access strategy. 

• Use the fewest number of trees possible. 

  There are some advantages to minimizing the number of trees in your forest. The following advantages might apply in your environment:

  • After you have been given control over a particular DNS name, you own all names that are subordinate to that name. The smaller the number of trees, the smaller the number of DNS names that you must own in your company. 

  • There are fewer names to enter in the proxy client exclusion list. 

  • Non-Microsoft LDAP clients might not use the global catalog server when searching Active Directory. Instead, to perform directory-wide searches, these client computers use deep searches. A deep search covers all of the objects in a particular subtree. The fewer trees in a forest, the fewer deep searches that are required to search the entire forest. 

• Make the first part of the DNS name the same as the NetBIOS name. 

  It is possible to assign entirely unrelated DNS and NetBIOS names to a domain. For example, the DNS name of a domain could be sales.nwtraders.tld, but the NetBIOS name could be "Marketing." 

  Computers that are not running Windows 2000 Server and Windows 2000 software will display and accept NetBIOS names, whereas computers running Windows 2000 Server and Windows 2000 software will display and accept DNS names. This can lead to confusion on the part of your users and administrators. You should only use unmatched NetBIOS and DNS names if:

  • You want to migrate to a new naming convention on your network. 

  • You are upgrading a NetBIOS name that contains non-standard characters but you want the DNS name to have all standard characters. 

• Review names internationally. 

  Names that have a benign or useful meaning in one language can sometimes be derogatory or offensive in another language. DNS is a global namespace; be sure to review your company's names globally. 

  If you have multiple localized versions of Windows running on your network, all computers, including Windows 2000 Professional and all versions of Windows 2000 Server, must use only Internet-standard characters in both their DNS and NetBIOS names. If you use characters other than Internet-standard characters, only computers with the same locale setting can communicate with each other. 

• Use names that are easy to remember. 

  Typically, administrators see domain names by using Windows 2000 Server administrative tools. Users typically work with global catalog servers that can be queried without knowledge of a domain or host name. However, users sometimes use the domain name. For example, domain names are used for user principal name logons or if the domain namespace matches an SMTP address. In general, choose domain names with components that are easy to remember. 

• Differentiate domain names and computer names. 

  In Windows NT 4.0 and earlier, a computer is identified primarily by a NetBIOS name, which is the name by which the computer is known on the network. In Windows 2000, a computer is identified primarily by its full computer name, which is a DNS fully qualified domain name (FQDN). The same computer can be identified by more than one FQDN. However, only the FQDN that is a concatenation of the host name and the primary DNS suffix is the full computer name. By default, the primary DNS suffix of a computer that is running Windows 2000 Server is set to the DNS name of the Active Directory domain to which the computer belongs. The primary DNS suffix can also be specified by Group Policy. For more information about Group Policy, see the Windows 2000 Server documentation. 

DNS and Exchange 2000

Although Windows 2000 domains use a DNS-style naming convention, a domain name such as europe.microsoft.tld does not dictate the SMTP address for Exchange mailbox-enabled users created within that domain. Although a user's logon name might be someone@europe.microsoft.tld, the e–mail address generation is controlled by recipient policies in the organization. Unlike Exchange 5.x, Exchange 2000 can automatically generate multiple addresses for users.

You can configure multiple recipient policies for the organization. Each one has an LDAP filter rule based on RFC 2254 associated with it. This allows administrators to generate proxy addresses, such as SMTP, based on fields within Active Directory. For example, all research and development personnel in the company can have a different (or additional) SMTP address from other members of the company.

Where possible, align the user's domain logon name with the SMTP address to reduce potential user confusion. You might need to use a combination of recipient policies and a user principal name to achieve this, as seen in Table 4.1.

Table 4.1 Domain logon name and SMTP address alignment 

Property	Value
Residing domain	example.microsoft.tld
Recipient policy	@microsoft.tld
SMTP address	firstname.lastname@microsoft.tld
Pre-Windows 2000	example\firstname.lastname
User principal name logon	firstname.lastname@microsoft.tld

Note The Recipient Update Service generates SMTP and proxy addresses. The Recipient Update Service checks whether any other object in the forest has the same address, based on mail nickname and SMTP domain/proxy root. If a duplicate is found, the Recipient Update Service appends a number to the duplicate address to make it unique. For example: bob@microsoft.tld, bob2@microsoft.tld, and bob3@microsoft.tld. When users are created, Active Directory verifies that the user principal name is unique. Active Directory does not allow you to create a user if the user principal name is not unique.

Configuring a Unified Namespace

Recipient policies are tightly integrated with DNS. To configure a unified namespace, first configure DNS to identify the appropriate Exchange 2000 server by creating a mail exchanger (MX) record for each e-mail domain you plan to define in your organization. For example, if you have three Exchange servers and each one processes incoming mail for multiple departments, and each user has multiple valid SMTP addresses, you need to define each Exchange server in DNS with a mail exchanger (MX) record to identify the three domains to be handled by a particular Exchange server. Table 4.2 shows what your DNS records might look like for the zone nwtraders.microsoft.

Table 4.2 DNS record example 

Department	Record Type	Record Value	Location
London	A	172.19.240.2
Tokyo	A	172.19.241.2
Seattle	A	172.19.242.2
Engineering	MX	10	London
Personnel	MX	10	London
Sales	MX	10	London
Manufacturing	MX	10	Seattle
Headquarters	MX	10	Seattle
Exporting	MX	10	Tokyo
Support	MX	10	Tokyo

In this scenario, all mail sent to user@nwtraders.microsoft.tld will be delivered to the London server. Backup mail deliveries will be made to Tokyo and Seattle, based on the priority. Additionally, mail sent to user@engineering.nwtraders.microsoft.tld, user@personnel.nwtraders.microsoft.tld, and user@sales.nwtraders.microsoft.tld will be delivered to the London server. Mail sent to .tld and user@headquarters.nwtraders.microsoft.tld will be delivered to Seattle. Mail sent to user@exporting.nwtraders.microsoft.tld and user@support.nwtraders.microsoft.tld will be sent to Tokyo.

User Principal Name

A user principal name is an e-mail-like name that uniquely represents a user. A user principal name consists of two parts, a user identification portion and a domain portion. The two parts are separated by an "@" symbol, to form user@DNS-domain-name, for example, suzan@nwtraders.microsoft.tld. Every user is automatically assigned a default user principal name, where the user portion of the name is the same as the user's logon name, and the DNS-domain-name portion of the name is the DNS name of the Active Directory domain where the user account is located. When logging on using a user principal name, users no longer have to choose a domain from a list on the logon dialog box.

You can set user principal names to arbitrary values. For example, even if Suzan's account is in the nwtraders.microsoft.tld domain, her user principal name could be set to suzan@nwtraders.tld. When the user logs on, the user account to be validated is discovered by searching the global catalog for a user account with a matching user principal name value. By making user principal name values independent from domain names, administrators can move user accounts between domains, leaving user principal name values unchanged and making moves between domains more transparent to users.

The user principal name logon is an attribute of the Active Directory account and can be set up so that a user can log on to the network by a short and recognizable name, thus hiding the complexity of the underlying domain infrastructure. The user principal name attribute is replicated to the global catalog.

Some companies choose to make their user's logon alias and SMTP alias the same so that users need to remember only one alias when logging on or when referring to their SMTP address. Other companies purposefully avoid having the user logon name and alias be the same and make it as difficult as possible for hackers by making each user's SMTP alias and logon alias different.

Organizational Unit Structure

Objects in Active Directory exist within domains. They can be further subdivided within a domain by using organizational units. While the domain defines the replication and security context, the organizational units within the domain define the location of objects and how they are administered, and provide a method of applying Group Policy to different groups of objects in an efficient way.

Organizational Unit Characteristics

The following characteristics of organizational units are important to consider when creating structure in a domain:

• Organizational units can be nested. 

  An organizational unit can contain child organizational units, enabling you to create a hierarchical tree structure inside a domain. 

• Organizational units can be used to delegate administration and to control access to Active Directory objects. 

  When you use a combination of organizational unit nesting and access control lists, you can delegate the administration of objects in the directory in a very detailed manner. For example, you could grant a group of help desk technicians the right to reset passwords for a specific set of users, but not the right to create users or modify any other attribute of a user object. 

• Organizational units are not security principals. 

  You cannot make organizational units members of security groups, nor can you grant users permission to a resource because they reside in a particular organizational unit. Because organizational units are used for delegation of administration, the parent organizational unit of a user object indicates who manages the user object, but it does not indicate the resources a user can access. 

• Group Policy can be associated with an organizational unit. 

  Group Policy enables you to define desktop configurations for users and computers. You can associate Group Policy with sites, domains, and organizational units. Defining Group Policy on an organizational unit basis allows you to use different policies within the same domain. 

• Users will not navigate the organizational unit structure. 

  It is not necessary to design an organizational unit structure that will appeal to users. Although it is possible for users to navigate the organizational unit structure of a domain, it is not the most efficient way for a user to discover resources. The most efficient way to find resources in the Active Directory is by querying the global catalog. 

Organizational Unit Planning Process

Create an organizational unit structure plan to document the specific reason for creating each organizational unit for a domain. Note the specific reason for creating an organizational unit each time you add one to the plan. This will help you make sure that every organizational unit has a purpose, and it will help the readers of your plan to understand the reasoning behind the structure.

The steps to creating an organizational unit structure for a domain are:

1. Create organizational units to delegate administration. 

2. Create organizational units to hide objects. 

3. Create organizational units for Group Policy. 

4. Understand the impact of changing organizational unit structures after deployment. 

It is important to create organizational units in the order presented above. An organizational unit structure designed specifically for delegating administration is shaped differently from an organizational unit structure designed specifically for Group Policy. Because there are multiple ways of applying Group Policy, but only one way to delegate administration, create organizational units for delegating administration first.

Creating Organizational Units to Delegate Administration

In Windows NT, delegation of administration within a domain was limited to the use of built-in local groups, such as the account administrators group. These groups had predefined capabilities, which in some cases did not fit the needs of a particular situation. As a result, there were situations where administrators in a company needed high levels of administrative access, such as domain administrator rights.

In Windows 2000 Server, delegation of administration is more powerful and flexible. This flexibility is achieved through a combination of organizational units, per-attribute access control, and access control inheritance. Administration can be delegated arbitrarily by granting a set of users the ability to create specific classes of objects or modify specific attributes on specific classes of objects.

Delegating administration in your company has several benefits. Delegating specific rights enables you to minimize the number of users who must have high levels of access. Accidents or mistakes made by an administrator with restricted capability will only have an impact within the administrator's area of responsibility. Previously, in your organization it might have been necessary for groups other than IT to submit change requests to high-level administrators, who would make these changes on their behalf. By delegating administration, you can delegate responsibility to the individual groups in your organization and eliminate the overhead of sending requests to high-level administrative groups.

Three ways to delegate administration are:

• By physical location. For example, administration for objects in Europe can be handled by an autonomous set of administrators in Europe. 

• By business unit. For example, administration of objects belonging to the engineering department can be handled by an autonomous set of administrators in the engineering department. 

• By role or task. For example, a set of administrators might be responsible for computer account objects. 

Modifying Access Control Lists

The access control entries (ACEs) in the access control list (ACL) of an object determine who can access that object and what kind of access they have. When an object is created in the directory, a default ACL is applied to it. The default ACL is described in the schema definition of the object class. To delegate administration, grant a group specific rights over an organizational unit by modifying the ACL of the organizational unit.

ACEs can be inherited by child objects of a container object. If any of the child objects are also containers, the ACEs are applied to the children of those containers as well. With inheritance, you can apply a delegated right to an entire subtree of organizational units instead of a single organizational unit. You can also block ACE inheritance on an object to prevent ACEs from a parent container from applying to that object or any child objects. Inheritable ACEs apply only within a domain and do not flow down to child domains.

Always reference groups in ACLs, not individual users. Managing the membership of a group is simpler than managing an ACL on an organizational unit. When users change roles, it is much easier to discover and change their group memberships than to check the ACLs on every organizational unit. Where possible, delegate to local groups instead of global or universal groups. Unlike global groups, local groups can have members from any trusted domain, making them better suited for granting resource permissions. Unlike universal groups, local group membership is not replicated to the global catalog, making local groups less resource intensive.

Creating Organizational Units to Hide Objects

Even if a user does not have the right to read the attributes of an object, that user can still see that the object exists by enumerating the contents of that object's parent container. The easiest and most efficient way to hide an object or set of objects is to create an organizational unit for those objects and limit the set of users who have the List Contents right for that organizational unit.

Creating Organizational Units for Group Policy

In Windows NT 4.0, you can use the System Policy Editor to define user and computer configurations for all of the users and computers in a domain. With Windows 2000 Server, you use Group Policy to define user and computer configurations, and associate those policies with sites, domains, or organizational units. Whether or not you need to create additional organizational units to support the application of Group Policy depends on the policies you create and the administrative delegation options you select.

Changing the Organizational Unit Structure After Deployment

Moving an object or subtree of objects changes the parent container of those objects. ACEs that were inherited from the old parent no longer apply, and there might be new inherited ACEs from the new parent. To avoid unexpected changes in access, evaluate in advance what the changes will be and determine whether those changes will have any impact on the users that currently access and manage those objects.

Moving a user object, computer object, or a subtree containing user or computer objects can change the Group Policy that is applied to those objects. To avoid unexpected changes in client configurations, evaluate the changes in Group Policy and ensure that they are acceptable for users.

Exchange 2000 and Organizational Units

The location of a user or server within a domain does not affect Exchange 2000. This means that regardless of how you choose to design your organizational unit structure, whether you base it on administrative delegation requirements or Group Policy requirements, Exchange 2000 is not affected.

Active Directory objects that can be mailbox-enabled do not have to be in the same organizational unit or even in the same domain as the Exchange 2000 server on which the mailbox physically resides. With Exchange 2000 and Active Directory, moving an object from one organizational unit to another is a simple operation that does not affect the associated mailbox. Mailboxes can be moved between mailbox stores on an Exchange server and between servers, independently of whether the user object is moved in Active Directory.

In some companies running earlier versions of Exchange, Exchange servers are members of Windows NT resource domains. During the migration from Windows NT to Windows 2000 Server it is likely that resource domains will be collapsed into Active Directory–based domains that contain both users and resources. These companies may choose to locate the objects in Active Directory in a single domain organizational unit. However, this will have little effect on the Exchange server or how it is managed. Administration of server objects can be delegated separately from administrator permissions on the server itself.

Note The organizational unit structure is not shown in the Exchange 2000 address book.

Forest

A forest is a collection of one or more Windows 2000 Active Directory trees, organized as peers and connected by two-way transitive trust relationships between the root domains of each tree. All trees in a forest share a common schema, configuration, and global catalog. When a forest contains multiple trees, the trees do not form a contiguous namespace.

Important The forest represents the boundary for the Exchange 2000 organization. An Exchange 2000 organization cannot span multiple Windows 2000 forests. If a company has multiple forests, multiple Exchange organizations are required.

When multiple domains exist in the forest, you can change the mode of each domain one at a time. Therefore, you can switch your parent or child domains to native mode without the other being in native mode.

When a collection of domains and domain trees are joined together to form a single Active Directory, this is called a forest. A forest uses a single schema and configuration definition, which is replicated to all domain controllers in every domain.

Number of Forests

The decision to use more than one forest has significant resource and functionality effects. Carefully consider the best course of action for your situation.

Creating a Single-Forest Environment

A single forest environment is simple to create and maintain. All users see a single directory through the global catalog, and do not need to be aware of the underlying directory structure. When adding a new domain to the forest, no additional trust configuration is required. Configuration changes need to be applied only once to affect all domains.

Creating a Multiple-Forest Environment

Because forests have shared elements, such as schemas, it is necessary for all the participants in a forest to agree on the content and administration of those shared elements. Organizations such as partnerships and conglomerates might not have a central body that can drive this process. In short-lived organizations like joint ventures, it might not be realistic to expect administrators from each organization to collaborate on forest administration.

If administration of your network is distributed among many autonomous divisions, it might be necessary to create more than one forest. If your company chooses to create multiple forests, it is important to understand the implications of having multiple forests and the limitations this imposes on users and objects.

Although non-transitive trust relationships can be implemented between domains that reside in different forests (including Windows NT 4.0 domains), a multiple-forest environment can present certain challenges to Exchange 2000 designs.

Exchange 2000 and the Forest

The Active Directory forest determines the boundaries of the Exchange 2000 organization. It is not possible to have Exchange 2000 servers within the same Exchange 2000 organization in different forests.

There are two ways to implement Exchange 2000:

• In a single forest by using Active Directory, knowing that all domains trust one another. 

• In multiple forests by using Active Directory, establishing coexistence between earlier versions of Exchange and Active Directory. 

In a multiple-forest environment, an Exchange 2000 organization must be created for each forest. This has the following effects on Exchange 2000:

• There is more than one Exchange 2000 organization to administer. 

• There is no automatic Active Directory replication between multiple forests. Therefore each forest has a separate global address list. (Users can see only one global address list). 

• You cannot configure routing group connectors between Exchange 2000 organizations. (You must use SMTP connectors or X.400 connectors instead). 

• No link state information transfers between Exchange 2000 organizations because routing group connectors cannot connect organizations. 

Deploying Active Directory Forests

Having multiple forests causes additional administrative work and can affect the deployment of Exchange 2000. In this scenario, you can create manual trusts between domains in separate forests. However, these domains are non-transitive, which means that you can have a domain model that resembles a Windows NT 4.0 deployment, with multiple manual trusts between domains. Additionally, the global catalog servers only show objects within their own forest; this determines what Microsoft Outlook users see when they perform searches.

If you deployed Exchange in the past, you could create a single Exchange Server 5.5 organization across two Windows NT 4.0 domains with no trusts between them. This organization could include multiple sites and be deployed across these two domains without relying on the underlying security structure. Because Exchange Server 5.5 performed mail-based directory replication between sites, users in both domains were able to see all users within the same organization through one global address list.

Synchronizing Data Between Forests

If Outlook users and Exchange 2000 servers are deployed in multiple forests, you may need to replicate certain data between the two systems to achieve the functionality you need.

You can use Microsoft Metadirectory Services or third-party products, such as the Compaq LDAP Synchronization Utility (LDSU), ISOCOR's MetaConnect, or Siemens' DirX. For more information about Microsoft Metadirectory Services, see "Inter-Organization Replication and Directory Synchronization" in this book and the Microsoft Web site at https://www.microsoft.com.

Important Synchronization of directory data between forests changes the target object class. For example, a mailbox-enabled user in organization A is a mail-enabled contact in organization B.

Exchange 2000 includes the Public Folder Inter-organization Replication Tool, which can synchronize public folders between different organizations. However, replicating public folders between different organizations creates additional administration overhead compared to replicating public folders in a single organization.

The Public Folder Inter-organization Replication Tool can also replicate information such as Free/Busy System folders. This information allows users from different forests to schedule meetings with one another and view free and busy time slots on their calendars.

Important There is no automatic solution for replicating users' calendars between organizations; therefore, users cannot open calendars that exist in another organization.

Windows 2000 Site Topology

A Windows 2000 site is a local, logical collection of Internet Protocol (IP) subnets. All computers that are in the same site have high-speed connectivity—local area network (LAN) speeds—with one another. Unlike an Exchange 5*.x* site, a Windows 2000 site does not correspond to a specific part of the namespace. For example, multiple sites can exist within a single domain, and conversely, a single site can span multiple domains. Synchronous remote procedure calls (RPC) replicate the domain naming context within a domain.

Windows 2000 sites help to define the physical structure of a network. When a change occurs in Active Directory, sites can be used to optimize replication traffic and to enable users to connect to a domain controller by using a reliable, high-speed connection.

Distinguishing Windows 2000 Sites from Exchange 5.5 Sites

Windows 2000 sites only define zones in the underlying network where high bandwidth is present. A site in Exchange 5.5 or earlier defines the unit of administration and namespace and dictates message routing. Unlike the Exchange 5.5 site, a Windows 2000 Server site does not correspond to a specific part of the namespace and is not a partition for administration.

Active Directory Logical and Physical Structure

In Active Directory, the logical structure is separate from the physical structure. You use the logical structure to organize your network resources, and you use the physical structure to configure and manage your network traffic. The physical structure of Active Directory is composed of sites and domain controllers and defines where and when replication and logon traffic occur. Understanding the physical components of Active Directory is critical to optimizing network traffic and the logon process. In addition, this information can help in troubleshooting replication and logon problems.

Domains define the logical structure of your company, whereas sites define the physical structure of your network. The logical and physical structures of Active Directory are independent of each other. This means:

• There is no necessary correlation between your network's domain structure and its physical structure. 

• Active Directory allows multiple domains in a single site and multiple sites in a single domain. 

• There is no necessary correlation between domain namespaces and sites. 

Creating a Windows 2000 Site Topology

A Windows 2000 site topology describes a physical network for a forest. Creating the site topology requires taking the physical topology of your network and describing it in terms of available bandwidth and network reliability. Active Directory clients and servers use the site topology of a forest to route queries and replication traffic efficiently. A site topology also helps you decide where to place domain controllers on your network.

When you create your Windows 2000 site topology, it is useful to have a complete map of the physical topology of your network. That map should include the list of physical subnets on your network, the media type and speed of each network, and the connections between each network.

Site and Site Topology Information

Sites, site links, and subnets are all stored in the configuration container, which is replicated to every domain controller in the forest. Every domain controller in the forest has complete knowledge of the site topology. A change to the site topology causes replication to every domain controller in the forest.

Note Site topology is separate and unrelated to domain hierarchy. A site can contain many domains, and a domain can appear in many sites.

Keep the following key concepts in mind when designing your site topology:

• Create a site for each LAN, or set of LANs, that is connected by a high-speed backbone, and assign the site a name. Connectivity within the site should be reliable. 

• Create a site for each location that does not have direct connectivity to the rest of your network and is only reachable by SMTP mail. 

• Determine which sites will not have local domain controllers, and merge those sites with other nearby sites. Sites help efficiently route traffic between clients and domain controllers, and between domain controllers and other domain controllers. Without a domain controller in a site, there is no traffic to be routed. 

• Client computers attempt to communicate with domain controllers in the same site as the client before trying to communicate with domain controllers in any other site. Anytime bandwidth between a set of networks is plentiful enough that you do not care if a client on one network communicates with a server on a different network, then consider those networks all to be in one site. 

• If your entire network consists of fast, reliable connectivity, the entire network can be considered to be a single site. 

• Anytime two networks are separated by links that are heavily used during parts of the day and idle during other parts of the day, those networks should be put into separate sites. You can schedule replications between sites to prevent replication traffic from competing with other traffic during high usage hours. 

Note If a client computer is on a subnet that is not defined in Active Directory, it is not considered part of a site, and it selects randomly from all domain controllers for a given domain. You may encounter situations where not all subnets are defined in Active Directory, such as when new subnets are being added to your network.

Site Links

Site links are used to model the amount of available bandwidth between two sites. As a general rule, any two networks connected by a link that is slower than LAN speed are considered to be connected by a site link. A fast link that is near capacity has a low effective bandwidth and can also be considered a site link. Site links have four parameters:

• Cost The cost value of a site link helps the replication system determine when to use the link when compared to other links. Cost values determine the paths that replication takes through your network. 

• Replication schedule A site link has an associated schedule that indicates at what times of day the link is available to carry replication traffic. 

• Replication interval The replication interval indicates how often the system polls domain controllers on the other side of the site link for replication changes. 

• Transport The transport that is used for replication. 

Connect sites with site links to reflect the physical connectivity of your network. Assign each site link a name. Site links are transitive, so if site A is connected to site B, and site B is connected to site C, then the Knowledge Consistency Checker will assume that domain controllers in site A can communicate with domain controllers in site C. You need to create a site link between site A and site C only if there is, in fact, a distinct network connection between those two sites. A backbone network that connects many sites can be represented by a single site link that connects many sites, instead of by separate links between sites. Reducing the number of site links that need to be created and managed is particularly useful when many sites have the same characteristics.

For each site link, record the following:

• Link speed and current usage levels. 

• Whether the link is pay-by-usage. 

• Whether the link is historically unreliable. 

• Whether the link is only intermittently available. 

Exchange 2000 and Windows 2000 Site Design

Whereas Windows 2000 sites group domain controllers together for purposes of replication and client access, Exchange 2000 employs routing groups to group Exchange 2000 servers together so that message routing can be managed and scheduled.

Important Routing groups perform a function similar to Exchange sites in earlier versions of Exchange. Be careful to distinguish between Windows 2000 sites and Exchange sites in earlier versions of Exchange; they serve different purposes.

Message Routing and Group Expansion

All message routing information, including routing groups and bridgeheads, is held within the configuration naming context of Active Directory. To determine routing, the Exchange 2000 server contacts a local domain controller and retrieves this information.

If a message is sent to a universal group, the SMTP virtual server, which is configured to perform the expansion, uses LDAP to contact a global catalog and populate the message header with the group membership. If the message is for a domain local or global group, the expansion server should be in the same domain as that group and should be configured to use only global catalogs from the local domain where the group resides. By default, every Exchange server tries to use global catalogs from its local domain and site; however, if there are not enough global catalogs in the local domain and site, Exchange requests global catalogs from any domain in the local site. To ensure correct expansion of domain local and global groups, any expansion server for these types of groups should be located in a Windows 2000 site that contains only global catalogs from the same domain as both the expansion server and the groups.

Placement of Sites and Routing Groups

Whether you are defining Windows 2000 sites or Exchange routing groups, you must:

• Have permanent and reliable network connections between all servers. 

• Provide adequate network bandwidth between servers. 

• Focus on reducing communication latency within the site and network bandwidth utilization between sites. 

Note The location of domain controllers in your site topology has a direct effect on the availability of services provided by Active Directory.

Trust Relationships

Active Directory provides security across multiple domains through trust relationships between domains. When there are trust relationships between domains, the authentication mechanism for each domain trusts the authentication mechanism for all trusted domains. If a user or application is authenticated by one domain, its authentication is accepted by all other domains that trust the authenticating domain. Users in a trusted domain have access to resources in the trusting domain, subject to the access controls that are applied in the trusting domain.

Note Access to resources in any discussion of trust relationships always assumes the limitations of access control. Trust relationships allow users and computers to be authenticated by an authentication authority. Access control allows authenticated users to use the resources that they are authorized to use and prohibits them from using resources that they are not authorized to use.

Transitive and Non-transitive Trust

In Windows 2000 Server, domains can be joined to a domain tree or forest, and each child domain has an automatic two-way trust relationship with the parent domain. This trust relationship is also transitive. Transitive trust means that the trust relationship extended to one domain is extended automatically to any other domain that is trusted by that domain. Transitive trust is applied automatically for all domains that are members of the domain tree or forest. Therefore, when a grandchild domain is created, the trust relationship between the parent and child domains is accepted by the grandchildren domains, and vice versa. For example, if a user account is authenticated by the parent domain, the user has access to resources in the grandchild domain. Similarly, if the user is authenticated by a child domain, the user has access to resources in the parent domain, as well as in the grandparent domain.

The effect of transitive trust in Windows 2000 Server is that there is complete trust between all domains in an Active Directory forest—every domain has a transitive trust relationship with its parent domain, and every tree root domain has a transitive trust relationship with the forest root domain.

Complete trust makes managing multiple domains simpler in Windows 2000. In previous versions of Windows NT, a popular model for deploying domains was the multiple master domain model. In that model, a domain containing primarily user accounts was called a master user domain, and a domain that contained primarily computer accounts and resources was called a resource domain. Adding a new domain to the deployment required several trusts to be created. With Active Directory, when you add a domain to a forest it is automatically configured with two-way transitive trust. This eliminates the need to create additional trusts with domains in the same forest.

Limiting Trust Relationships

If there are two entities in a forest within a conglomerate or partnership that do not trust one another, there is no way of breaking the trust between domains. Also, there are accounts and groups within the forest that have rights to affect the forest. These groups, such as Exchange Administrators, contain users that are trusted across all partners or companies. It might be necessary to create more than one forest if:

• Individual entities do not trust each other's administrators. 

  Entities such as partnerships and conglomerates may not be able to decide on administrative roles and responsibilities. Or they may not be able to agree on the content and administration of shared elements, such as the schema. In short-lived entities like joint ventures, it might not be realistic to expect administrators from each entity to collaborate on forest administration. 

• Individual entities cannot agree on a forest change policy. 

  Schema changes, configuration changes, and the addition of new domains to a forest have forest-wide impact. Each of the participating entities in a forest must agree on a process for implementing these changes, and on the membership of the schema administrators and enterprise administrators groups. If participating entities cannot agree on a common policy, they cannot share the same forest. 

• You want to limit the scope of a trust relationship. 

  Every domain in a forest trusts every other domain in the forest. Every user in the forest can be included in a group membership or appear on an access control list on any computer in the forest. If you want to prevent certain users from ever being granted permissions to certain resources, then those users must reside in a different forest from the resources. If necessary, you can use explicit trust relationships to allow those users to be granted access to resources in specific domains. 

Multiple domains within Active Directory are linked to a domain tree. Users in the linked domains can access resources in other domains by way of transitive trust relationships that exist hierarchically among all of the domains in the domain tree. However, administrative rights are not inherently transitive. Thus, an additional layer of security is added by limiting the scope of domain administrative rights.

Optimizing Authentication with Shortcut Trust Relationships

When a user requests access to a network resource, a domain controller from the user's domain must communicate with a domain controller from the resource's domain. If the two domains are not in a parent-child relationship, the user's domain controller must also communicate with a domain controller from each domain in the trust tree between the user's domain and the resource's domain. Depending on the network location of the domain controllers for each domain, each extra authentication hop between the two domains can increase the chance of a possible failure or increase the likelihood of authentication traffic having to cross a slow link. To reduce the amount of communication necessary for such interactions, you can connect any two domains with a shortcut trust relationship.

For example, if you have multiple trees in a forest, you might want to connect the group of tree roots in a complete mesh of trust. Remember that in the default arrangement, all tree roots are considered children of the forest root from a trust perspective. That means authentication traffic between any two domains in different trees must pass through the forest root. Creating a complete mesh of trust allows any two tree root domains to communicate with each other directly.

Active Directory Logical Components

Active Directory consists of components that function to organize it into a logical structure. This section describes three of these logical components: naming contexts, the global catalog server, and groups.

Naming Contexts

A naming context is a self-contained section of the Active Directory hierarchy that can have its own properties, such as replication configuration and permissions structure. Active Directory uses naming contexts to define the boundaries for information held within the database structure. The information stored in Active Directory on every domain controller in the forest is partitioned into three categories: domain, configuration, and schema data. These naming contexts are the units of replication in Active Directory. If the domain controller is also a global catalog server, it holds a fourth category of data as well. In multi-domain forests, domain controllers belonging to different domains have a common configuration and schema naming context, but they have a domain unique domain naming context.

Domain Naming Context

The domain naming context contains all of the objects in Active Directory for a domain. Domain data in each domain is replicated to every domain controller in that domain, but not beyond that domain. Domain objects include recipient objects, such as users, contacts, and groups.

Configuration Naming Context

The Configuration container is replicated to every domain controller in the forest. For example, Active Directory stores information about the physical network in the Configuration container and uses it to guide the creation of replication connections between domain controllers. The enterprise administrators security group has full control over the Configuration container. Sharing a single, consistent configuration across the domains of a forest eliminates the need to configure domains separately.

The configuration container contains replication topology and related metadata. Applications that use Active Directory, like Exchange 2000 Server, store the configuration of the Exchange 2000 organization in the Configuration container. Because Active Directory replicates the configuration container between all domains in the forest, the configuration of the Exchange 2000 organization is also replicated throughout the forest. The Configuration container defines the topology, connectors, protocols, and service settings for the Exchange 2000 organization.

Schema Naming Context

The schema naming context defines the object classes and the attributes of object classes that can be created in Active Directory. Object classes are the types of objects that can be created in Active Directory. The schema naming context contains all object types (and their attributes) that can be created in Active Directory. This data is common to all domains in the forest, and is replicated by Active Directory to all domain controllers in the forest. The schema administrators security group has full control over the schema.

Exchange 2000 and Naming Contexts

During the installation of the first Exchange 2000 server in the forest, the Active Directory schema is extended with new attributes for Exchange 2000, which have names that start with ms-Exch-attribute—for example, ms-Exch-OAB-Default. Simultaneously, existing Active Directory attributes are modified, some of which affect how Outlook presents information. Many LDAP Data Interchange Format (LDIF) files are imported as part of the installation process for the first Exchange 2000 server in Active Directory. This process can take an extended period of time to complete.

Active Directory is used to store Exchange 2000 data such as recipient objects, configuration data, schema attributes, and the global address list. A separate directory for Exchange is no longer necessary because Exchange 2000 is fully integrated with Active Directory. Exchange 2000 stores the majority of its information in the configuration container naming context. The configuration container naming context is replicated to every domain controller in the forest, simplifying global administration.

Important Because Exchange 2000 uses Active Directory, it is critical to review and understand the Windows 2000 naming conventions. Any issues with the naming convention should be resolved with Windows administrators. Attributes that are relevant to only Exchange, such as e–mail address attributes, should be defined and added to the naming convention.

Global Catalog Server

A global catalog is a Windows 2000 Server domain controller that stores a writable copy of the domain naming context for its domain and the forest-wide configuration and schema naming contexts. The global catalog also contains a select set of the attributes for every object from every domain in the forest. In addition, it provides a complete replica of the configuration and schema naming contexts for the forest.

By default, the partial set of attributes stored in the global catalog includes those attributes most frequently used in search operations, because one of the primary functions of the global catalog is to support clients querying Active Directory. The global catalog makes directory structures within a forest transparent to users and enables fast, efficient searches that span the entire forest.

The availability of global catalog servers is crucial to the operation of Active Directory. For example, a global catalog server must be available when processing a user logon request for a native-mode domain, or when a user logs on with a user principal name.

When processing a logon request for a user in a native-mode domain, a domain controller sends a query to a global catalog server to determine the user's universal group memberships. Since groups can be explicitly denied access to a resource, complete knowledge of a user's group memberships are necessary to enforce access control correctly. If a domain controller of a native-mode domain cannot contact a global catalog server when a user wants to log on, the domain controller refuses the logon request.

Global Catalog Server Placement

It is very important to understand how Active Directory usage affects global catalog server load, and how to efficiently deploy your global catalog servers. Use the same fail-over and load distribution rules that you used for individual domain controllers to determine whether additional global catalog servers are necessary in each site.

For best results, monitor the use of the global catalog by Exchange 2000 and add servers as necessary to gain optimal performance. Because LDAP is a standard protocol and the LDAP data is not encrypted, it is possible to view the traffic going to and from an Exchange 2000 server and the global catalog server by using Network Monitor (unless Exchange 2000 is installed on the global catalog server).

Exchange 2000 balances requests between available global catalog servers. Each time an address book search occurs and each time a message is routed, Exchange uses the closest global catalog server. When deciding on the number of global catalog servers required to support an Exchange 2000 deployment, consider the power of your servers, the number of users, the volume of messages sent, and other factors that affect your users and the load carried by your servers.

Note In a single domain environment, global catalog servers are not required to process a user logon request. However, as a general rule, you should designate at least one domain controller in each site as a global catalog server. Client computers still seek global catalog servers for search operations. Also, having global catalog servers already in place allows your system to adapt gracefully if you add more domains later.

Exchange 2000 and Global Catalog Server

Users running Outlook 2000 directly query a global catalog server to get addressing information. For other clients, Exchange 2000 acts as a proxy to the global catalog server. Global catalog servers are the primary locations for users to access information about Active Directory and Active Directory services available for Exchange 2000.

It is important to review which fields are set to be replicated to the global catalog servers and update that list based on your organization's requirements. For example, the Department attribute is not replicated by default. However, there may be a need to make the Department attribute available due to a workflow application that depends on that attribute.

Exchange 2000 uses LDAP to query and update Active Directory, making heavy demands on the global catalog servers. For this reason, global catalog servers should be strategically positioned so that Exchange 2000 can perform quick searches and users can access resources with minimum delays. Exchange 2000 has a directory access mechanism that allows it to share the results of LDAP queries among the Exchange 2000 components.

Important Exchange 2000 servers should be installed as member servers of the domain and not as domain controllers or global catalog servers, mainly for performance reasons. A server that is a domain controller or global catalog uses a lot of processing power and memory, competing with Exchange 2000 for the same processing power and memory. However, if you have sufficient hardware, you can use an Exchange 2000 server as a domain controller or global catalog, especially if the Exchange server is lightly used or if there is a need in remote office scenarios to consolidate servers onto fewer, more powerful hardware systems.

Clients can access Active Directory information by communicating directly with a global catalog server or by using DSProxy. Active Directory supports both Messaging Application Programming Interface (MAPI) and LDAP queries (for backward compatibility with older MAPI clients). Exchange 2000 provides a communication process for Microsoft Outlook Web Access clients making directory queries using HTTP. For more information about DSProxy, see "Active Directory Integration and Replication" in this book.

Global Address List

When Outlook users want to find a person within the organization, they usually search the global address list (GAL), which represents an aggregation of all messaging recipients in the enterprise. Because Exchange 2000 servers no longer host their own directory service, all data is retrieved from the global catalog servers in Active Directory. Because a global catalog server can support the MAPI protocol as well as LDAP, Outlook clients can communicate with Active Directory using the same protocol employed by the Exchange Server 5.5 directory service.

Getting Directory Data

Depending on the type of request being made, an Exchange 2000 server can go to different Active Directory servers to retrieve data. An Exchange 2000 server usually establishes a number of LDAP connections to nearby domains controllers and global catalog servers. An Exchange 2000 server performs two main Active Directory activities: address book searches and configuration data searches. For an address book search, the Exchange 2000 server queries the closest available global catalog server.

When an Exchange 2000 server needs to read configuration data such as routing information, it can connect to any domain controller within the local domain to get this information. This is possible because the configuration container naming context is replicated to every domain controller in the forest. An Exchange 2000 server would rather use the same domain controller for these requests than switch between different domain controllers.

Active Directory Groups

In Exchange 2000, an Active Directory group is the equivalent of an Exchange Server 5.x distribution list. Active Directory contains two types of groups: a security group and a distribution group. Each group type has a scope attribute. The scope of a group determines who can be a member of the group, and where you can use that group in the network. Three group scopes are available: domain local, global, and universal. The domain mode limits the choice of group type and group scope.

Group Types

Both security groups and distribution groups can be mail-enabled and used as the equivalent of distribution lists. Use these group types to create distribution lists for the various groups within your company. In addition, consider the following factors when working with groups:

• Group Names The naming standards for mail-enabled groups should follow the Windows 2000 naming standards. 

• Group Ownership Group ownership is assigned to the user that requested the group in order to reduce administrative overhead. 

• Group Size Keep the number of members in a group of either type below 5,000. Although this is not a hard limit within Active Directory, a listing of 5,000 should work in all circumstances. For efficiency and scalability, you should consider nesting groups that are above 500 members. 

Security Groups

Security groups provide the following advantages:

• They can be mail-enabled by assigning an SMTP address, allowing the group to act as a distribution list equivalent. 

• They can be used for assigning permissions to public folders in Exchange 2000. 

• They can be useful if you want to also assign network permissions to the group members. 

• They can lower the number of groups and the amount of maintenance required for Active Directory and the messaging system, because they can act as pseudo-distribution groups. 

Security groups provide the following disadvantages:

• Users might gain unauthorized access to network resources if they are accidentally placed in the wrong group. 

Distribution Groups

Distribution groups provide the following advantages:

• They can be used for bulk mailing. 

• They can be used as universal groups even in a mixed-mode domain. 

Distribution groups provide the following disadvantages:

• Permissions cannot be assigned to network resources. 

• Permissions cannot be assigned to public folders in Exchange 2000. 

Group Scopes

Universal groups offer the greatest flexibility in a company. However, because their membership is stored in the global catalog server, changes to universal groups are replicated between all global catalog servers in the company. For this reason, it is recommended that universal groups remain fairly static.

Domain local or global groups are the best choice for groups with dynamic membership because group replication occurs only within the domain. However, because their membership is not included in the global catalog server, these groups are not visible to users in other domains.

Domain Local Scope

Groups with the domain local scope have the following attributes:

• In a native-mode domain, they can contain user accounts, global groups, and universal groups from any domain in the forest, as well as domain local groups from the same domain. 

• In a mixed-mode domain, they can contain user accounts and global groups from any domain. 

• You can grant permissions to domain local groups only for objects within the domain in which the domain local group exists. Permissions cannot be assigned to network resources or public folders in other domains. 

• They can be converted to a universal group when they exist in a native-mode domain, as long as they do not contain another domain local group. 

• The group object is listed in the global catalog, but the group membership is not. 

• Outlook users in other domains cannot view the full membership. 

• Group membership must be retrieved on demand if expansion takes place in a remote domain. 

Global Scope

Groups with the global scope have the following attributes:

• They can contain user accounts from the same domain and global groups from the same domain, when in native-mode domains. 

• They can contain user accounts from the same domain, when in a mixed-mode domain. 

• You can grant permissions to global groups for all domains in the forest, regardless of the location of the global group. 

• They can be converted to a universal group when in a native-mode domain, as long as they are not a member of any other global group. 

• They can only contain recipient objects from the same domain. 

• The group object is listed in the global catalog, but the group membership is not. 

• Outlook users in other domains cannot view the full membership. 

• Group membership must be retrieved on demand if expansion takes place in a remote domain. 

Universal Scope

Groups with the universal scope have the following attributes:

• They can contain user accounts from any domain, global groups from any domain, and universal groups from any domain in the forest, when the domain is in native mode. 

• Universal security groups can only be used in native-mode domains; universal distribution groups can be used in mixed-mode and native-mode domains. 

• You can grant permissions to universal groups for all domains in the forest, regardless of the location of the universal group. 

• They cannot be converted to any other group scope. 

• Outlook users in any domain can view full membership. 

• Membership never has to be retrieved from remote domain controllers. 

• Membership modifications are replicated to the global catalog servers. 

Limiting the membership of universal groups to groups only, rather than individual user accounts, enables you to adjust the user accounts that are members of the universal group by adjusting the membership of the groups that are part of the universal group. Because this does not directly affect the membership of the universal group, no replication traffic is generated.

Mail-Enabling Groups

Suggested guidelines for mail-enabling a group are:

• Use security groups as the primary type, but only mail-enable the groups when appropriate. 

• Use distribution groups for lists that include non-trusted recipients. 

• Use universal groups when the ability to view membership is important. In Windows 2000 mixed mode, distribution groups must be used. 

Each type of distribution group can be further divided into three categories, depending on whether you want the group to be accessible to specific domains or to all users. Exchange 2000 servers can route mail to group members regardless of which group or category is used. The group type used is more relevant when considering how Outlook users will view them and how access to secure resources will be granted. For more information on recipients and groups, see the Windows 2000 Server and Exchange 2000 Server documentation.

Exchange 2000 and Groups

The type and scope of the group that you use for Exchange 2000 depends on your business and user requirements. For full flexibility, implement universal security groups. Although this is a security group definition, it can be mail-enabled by adding an SMTP address and viewed in the global address list. However, a disadvantage of universal security groups is that they can only be created in native-mode domains. You can move from mixed-mode to native-mode domain by upgrading the domain controllers to Windows 2000 Server. Moving to native-mode domains simplifies the upgrade and deployment process for Exchange 2000 and provides additional directory scalability.

Another point to consider when deploying universal groups is that their membership is listed in the global catalog servers, so any membership change causes replication traffic. Although Active Directory supports property-level replication, the membership for a group is held in a multi-valued property on the group object. Therefore, if the group is large, a significant amount of replication traffic can be generated. To mitigate this risk, place user objects in other universal groups and then nest these groups under an umbrella universal group. When the membership changes for a user in the group, the large universal group object is not changed and no replication traffic is created.

When you implement universal groups, Outlook users can still view full membership of both the umbrella group and its subgroups. You can use global groups instead of universal groups. However, global groups do not have their membership listed in the global catalog servers and this can impact the ability of an Outlook client to view membership at the recipient level.

When a message is sent to a group, the SMTP service must expand the membership of the group object. If it is a domain local or global group defined in the local domain, the membership list can be retrieved from any local domain controller. In addition, if it is a universal group and users appear directly on the list, the membership can be obtained from any local global catalog server.

If a message is sent to a domain local or global group that has been created in another domain, or if a universal group contains global groups that are in other domains, then the group must specify an expansion server that exists in its domain. That expansion server must use the global catalog from the same domain as the local or global group in order for the expansion to be successful.

A decision has to be made as to whether it is better to create a universal group or use domain local and global groups and set the membership retrieval to remote domains when the group needs to be expanded. Consider the following questions when deciding upon the group scope:

Keep in mind that, when you implement domain local or global groups, Outlook users cannot view the membership of the group unless you define the domain local or global groups within the same domain as the user.

You must also remember that groups are used for determining public folder access. Unlike previous versions of Exchange, the store does not need to expand a group when a user accesses a public folder. Because all ACLs for public folders are based in Active Directory, group membership is carried in a user's access token and is presented to the Exchange server upon connection to the resource.

Note When the administrator attempts to create a new group in a mixed-mode domain, by default it is configured as a security group with a domain local scope. A new group in a native-mode domain defaults to a security group with a universal scope. In mixed-mode domains, you cannot change a group's scope after you have created it.

Group Creation Decision Process

Implementing the correct group type for Exchange 2000 mailing and public folder access is very important. Before you create the group, make sure you fully understand how it will be used. The scope, size, and membership of the group are key factors when implementing different group types. Use the scenarios in the next section to help guide you through your decision process.

Coexisting with and Upgrading from Earlier Versions of Exchange

In a coexistence scenario, the Active Directory Connector (ADC) replicates Exchange distribution lists to Active Directory groups. In Exchange 2000, Exchange Server 5.x distribution lists replicate to Active Directory as a universal distribution group.

If the ADC has not been configured, the Exchange 2000 server upgrade process converts any existing distribution lists in Exchange 5.5 to universal distribution groups if the Active Directory domain is in mixed mode, and universal security groups if the Active Directory domain is in native mode.

Exchange 2000 Scenarios

Requirement To allow the sales team in Toronto to e–mail one another with lead information.

Solution Create a global distribution.

Reasoning If all of these members are in the same domain, you can use a global group. The purpose of the group is to enable members to send e–mail to each other, so access to network resources is not a consideration. If access to network resources is a consideration, create a security group instead. This will prevent having two groups with the same membership if requirements change in the future. The list will be used only by team members in the same domain, so membership does not need to be retrieved from remote domain controllers.

Requirement The worldwide product marketing unit wants to have a list created so that anyone within the company can e–mail them. Users do not need to know who is on the mailing list.

Solution Create a domain local distribution group.

Reasoning You cannot use global groups because the members of the group are in a multitude of domains. Because network access is not desired and the membership does not need to be published to the global catalog, you do not need to create a universal group. The marketing unit also sees frequent changes to their group; therefore, it is not appropriate to create a universal group. However, to prevent membership from being remotely retrieved when a user in a remote domain sends a message to the group, the list is set to expand on a server in the domain in which the group is defined.

Requirement To create a small mail-based discussion forum for a new company product and to give the team access to all of the Web sites and network shares that contain information about the product.

Solution Create a universal security group.

Reasoning Members of the discussion forum can be located anywhere in the world. Because there is a strong possibility that members are in different domains, it is necessary to use universal scope for the group. The team is quite small and it is not envisaged that membership will change on a frequent basis, so it is appropriate to put the user membership directly within the universal group. This increases usability because members can see who is on the list before they send sensitive or confidential information. The group created is a security group because network resource access is also a requirement. Note that the domain in which the universal group is created must be in native mode.

Requirement To create a mailing list to mail security announcements and important information in bulk to the entire company.

Solution Create a global distribution group in every user domain, and then nest these global groups into a universal group.

Reasoning Access to network resources is usually controlled on a per-team basis or through the default access control entry, which grants permissions for users who have not been explicitly defined on the ACL. As a result, it is extremely unlikely that you will need to grant permissions on network resources for these groups. Membership for this group will change fairly frequently, making it inappropriate to populate full membership into a single universal group. When a membership change takes place, only the domain controllers within that domain need to be updated with the modification. Global catalog servers do not need to replicate any data. From a user's viewpoint, it is extremely unlikely that they will want to see the membership of this group. The global groups are nested within the universal group, so it is very easy for users to e–mail the entire company (permissions permitting) by using a single address instead of selecting each individual team or region. Another advantage of this method is that users can send e-mail to an individual group very easily. (Note that domain local groups cannot be used in this scenario because they cannot exist within universal groups.)