- Mapping the Design Components
- Evaluating Different Design Options
- Active Directory Design Details
- Defining Storage Groups and Multiple Databases
- Defining Administrative and Routing Groups
- Designing Remote Access to Exchange 2000
- Exchange 2000 Support and Maintenance Tasks
- Case Study for SmallCompany Inc.
- Case Study for MediumCompany Inc.
- Case Study for LargeCompany Inc.
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Evaluating Different Design Options
As previously discussed, the Active Directory and the Exchange 2000 design topology may differ depending on the functional design requirements set by the organization. The infrastructure on which the installation resides will also dictate the design decisions.
Before developing the Exchange 2000 design, the functional requirements of the organization need to be determined. More often than not, these requirements directly reflect the organization's business requirements. In general, the functional requirements are the technical specifications outlined to satisfy the stated business objectives.
DNS Implementation
It is important to have a comprehensive DNS and Active Directory implementation in place prior to deploying Exchange 2000. In many cases, organizations need to make decisions regarding how they will integrate existing DNS implementations with Windows 2000 and the Active Directory. Because Windows 2000 and Exchange 2000 are so heavily reliant on DNS, it is important that the organization coordinates at the highest level to ensure that these installations are properly designed and implemented.
The following sections discuss three scenarios: Active Directory-integrated DNS, coexistence, and third-party DNS implementation.
Active Directory-Integrated
Unlike previous versionsof the Windows operating system, which used the proprietary Windows Internet Naming System (WINS), Windows 2000 Active Directory integrates the industry standard domain name system (DNS) into the naming resolution process of the directory system. Windows 2000 uses DNS for name resolution and for locating Domain Controllers and/or other related Active Directory components such as printers or shared resources.
The basic concept behind the role of DNS is to maintain resource records (RR) contained within a database called a zone file. The zone file includes all the DNS information about one or more defined namespaces. This database contains records that map IP addresses to hostnames (A Records), Mail Exchange (MX), and Canonical Names (CNAME). Users query DNS servers to resolve hostnames to IP addressees. In summary, this is the basic principle behind the role of DNS.
If you elect to install Windows 2000 DNS and enable it for Active Directory integration, the following features are provided:
Dynamic registration of hostnames and IP addresses to the database.
Active Directory-integrated zones. Active Directory-integrated zones operate as multimaster databases and are replicated through the robust Active Directory replication process, removing the need for a separate DNS replication mechanism for zones transfers and allowing updates to be made by all servers.
The Active Directory-integrated strategy is relatively simple and straightforward. You not only reap the benefits and features of traditional DNS implementations, but you also gain the ability of directly integrating it into the Active Directory.
Coexistence
Many organizations that have established DNS implementations prefer to maintain their existing installation rather than replace it with a different solution. In most cases, these organizations are heavily reliant on the current installation and choose not to migrate to a different installation due to the inherent risks associated with that task. However, it is not uncommon for them to have it coexist with Windows 2000 DNS. Following is a short checklist that can be used to qualify all Unix BIND DNS servers when considering this option:
The installations must be BIND 8.1.2 or later. This version supports Dynamic DNS and Service Records (SRV).
Optionally, if you want to take advantage of the incremental zone transfer feature, upgrade all BIND servers to version 8.2.1 or later.
It is recommended that the Windows DNS installation be configured as primary and non-Windows DNS as secondary.
Third-Party DNS Implementation
There are third-party vendors that offer alternatives to the DNS choices just listed. These products can be leveraged to manage the implementation(s) that will be deployed. They can also be used in place of Unix BIND, Windows 2000, or other existing DNS installations. Another option is to use the product to manage the implemented solution.
This option works best when deployed in a complex environment. For example, in an enterprise environment with a multiplatform DNS installation, the capability to centralize the management of all the different installations may be a requirement.
AD Domain Design Model Used
When making decisions regarding which domain model to deploy, there are a number of key elements that need to be considered. The organization business requirements, the business model, and the current environment are key components when deciding which Active Directory domain model to use. The delegation of administrative responsibilities and the enforcement of security policies also play an integral part in the process.
Single Domain Model
When planning the Active Directory domain model, it is generally recommended that you start simple. Begin with the single domain model as shown in Figure 3.1, and from there determine whether the design will satisfy all of the established business and functional requirements.
){kind=link}
Figure 3.1 Single domain model.
The single domain model design is the least difficult to implement and manage. To manage users and resources, Organizational Units (OUs) can be created to organize and control the way resources are managed. Group Policies can easily be defined and applied to all users, computers, printers, and other related objects throughout the domain.
There are specific scenarios in which the single domain model would best fit. However, there are limitations with this design model that should be taken into consideration before choosing it. For example, the limitations include that security policies will apply domain-wide and SMTP cannot be used as the transport for site-to-site replication. The single domain model will be discussed within the context of each company design scenario.
Placeholder Root Domain Model
The placeholder root domain model, shown in Figure 3.2, includes the creation of a placeholder root domain that is the root of the tree for the subordinate domains. The objects that would exist in this domain would be the enterprise and schema admin groups. It would also maintain copies of the Global Catalog. Subordinate or child domains would be created to include users, servers, printers, and other related objects. Administrative groups can be created to delegate administration to the child domains.
){kind=link}
Additional domains might be necessary depending on the organization's administrative and policy requirements. For example, the design team may want to have a set of users on the network abide by a domain user security policy that is different from the security policy applied to the rest of the organization.
Figure 3.2 Placeholder root domain model.
Peer Root/Peer Resource Domain Model
The peer root/peer resource domain model shown in Figure 3.3 is similar to the previously described placeholder root domain model with the exception that the first established root domain in the forest would not host any subordinate or child domains. Multiple domains can be created at the forest level, resulting in a "peer" root configuration of different trees. Since the domains are contained within the same forest, a two-way transitive trust connects the domains no matter what tree they reside in. Access between the domains is available providing the administrator has been assigned permissions in both domains.
){kind=link}
Figure 3.3 Peer root/peer resource domain model.
The peer root domain contains the Schema Operations Master and also holds copies of the Global Catalog. The creation of a peer root domain allows for a higher degree of security and control on the schema. In order to perform forest-wide operations, such as adding domains to the forest or modifying the schema, administrators must authenticate to the root domain. The peer root domain model provides the following services:
Reduces the likelihood of accidental or unauthorized schema changes that could destroy the Active Directory forest.
Allows for future changes to be made to the forest. Since the first domain in a forest can never be removed, company acquisitions and/or name changes could prove problematic without a peer root domain.
Comparable permission(s) assignments can be made within a single domain to protect the schema but it should be noted that in a single domain model, the impact of reorganization would be much larger.
This design provides the most flexibility within the forest. This design also allows an organization to add future domains or reconfigure the namespace to support business or network needs.