Chapter 3: Understanding Core Exchange Server 2007 Design Plans

Sams

1 2 3 4 Page 2
Page 2 of 4

In short, a single "instance" of AD consists of a single AD forest. A forest is composed of AD trees, which are contiguous domain namespaces in the forest. Each tree is composed of one or more domains, as illustrated in Figure 3.1.

Figure 3.1

FIGURE 3.1

Multitree forest design.

Certain cases exist for using more than one AD forest in an organization:

  • Political limitations—Some organizations have specific political reasons that force the creation of multiple AD forests. For example, if a merged corporate entity requires separate divisions to maintain completely separate information technology (IT) infrastructures, more than one forest is necessary.

  • Security concerns—Although the AD domain serves as a de facto security boundary, the "ultimate" security boundary is effectively the forest. In other words, it is possible for user accounts in a domain in a forest to hack into domains within the same forest. Although these types of vulnerabilities are not common and are difficult to do, highly security-conscious organizations should implement separate AD forests.

  • Application functionality—A single AD forest shares a common directory schema, which is the underlying structure of the directory and must be unique across the entire forest. In some cases, separate branches of an organization require that certain applications, which need extensions to the schema, be installed. This might not be possible or might conflict with the schema requirements of other branches. These cases might require the creation of a separate forest.

  • Exchange-specific functionality (resource forest)—In certain circumstances, it might be necessary to install Exchange Server 2007 into a separate forest, to enable Exchange to reside in a separate schema and forest instance. An example of this type of setup is an organization with two existing AD forests that creates a third forest specifically for Exchange and uses cross-forest trusts to assign mailbox permissions.

The simplest designs often work the best. The same principle applies to AD design. The designer should start with the assumption that a simple forest and domain structure will work for the environment. However, when factors such as those previously described create constraints, multiple forests can be established to satisfy the requirements of the constraints.

Understanding the AD Domain Structure

After the AD forest structure has been chosen, the domain structure can be laid out. As with the forest structure, it is often wise to consider a single domain model for the Exchange 2007 directory. In fact, if deploying Exchange is the only consideration, this is often the best choice.

There is one major exception to the single domain model: the placeholder domain model. The placeholder domain model has an isolated domain serving as the root domain in the forest. The user domain, which contains all production user accounts, would be located in a separate domain in the forest, as illustrated in Figure 3.2.

Figure 3.2

FIGURE 3.2

The placeholder domain model.

The placeholder domain structure increases security in the forest by segregating high-level schema-access accounts into a completely separate domain from the regular user domain. Access to the placeholder domain can be audited and restricted to maintain tighter control on the critical schema. The downside to this model, however, is the fact that the additional domain requires a separate set of domain controllers, which increases the infrastructure costs of the environment. In general, this makes this domain model less desirable for smaller organizations because the trade-off between increased cost and less security is too great. Larger organizations can consider the increased security provided by this model, however.

Reviewing AD Infrastructure Components

Several key components of AD must be installed within an organization to ensure proper Exchange Server 2007 and AD functionality. In smaller environments, many of these components can be installed on a single machine, but all need to be located within an environment to ensure server functionality.

Outlining the Domain Name System (DNS) Impact on Exchange Server 2007 Design

In addition to being tightly integrated with AD, Exchange Server 2007 is joined with the Domain Name System (DNS). DNS serves as the lookup agent for Exchange Server 2007, AD, and most new Microsoft applications and services. DNS translates common names into computer-recognizable IP addresses. For example, the name http://www.cco.com translates into the IP address of 12.155.166.151. AD and Exchange Server 2007 require that at least one DNS server be made available so that name resolution properly occurs.

Given the dependency that both Exchange Server 2007 and AD have on DNS, it is an extremely important design element. For an in-depth look at DNS and its role in Exchange Server 2007, see Chapter 6, "Understanding Network Services and AD Domain Controller Placement for Exchange Server 2007."

Reviewing DNS Namespace Considerations for Exchange

Given Exchange Server 2007's dependency on DNS, a common DNS namespace must be chosen for the AD structure to reside in. In multiple tree domain models, this could be composed of several DNS trees, but in small organization environments, this normally means choosing a single DNS namespace for the AD domain.

There is a great deal of confusion between the DNS namespace in which AD resides and the email DNS namespace in which mail is delivered. Although they are often the same, in many cases there are differences between the two namespaces. For example, CompanyABC's AD structure is composed of a single domain named abc.internal, and the email domain to which mail is delivered is companyabc.com. The separate namespace, in this case, was created to reduce the security vulnerability of maintaining the same DNS namespace both internally and externally (published to the Internet).

For simplicity, CompanyABC could have chosen companyabc.com as its AD namespace. This choice increases the simplicity of the environment by making the AD logon user principal name (UPN) and the email address the same. For example, the user Pete Handley is pete@companyabc.com for logon, and pete@companyabc.com for email. This option is the choice for many organizations because the need for user simplicity often trumps the higher security.

Optimally Locating Global Catalog Servers

Because all Exchange directory lookups use AD, it is vital that the essential AD global catalog information is made available to each Exchange server in the organization. For many small offices with a single site, this simply means that it is important to have a full global catalog server available in the main site.

The global catalog is an index of the AD database that contains a partial copy of its contents. All objects within the AD tree are referenced within the global catalog, which enables users to search for objects located in other domains. Every attribute of each object is not replicated to the global catalogs, only those attributes that are commonly used in search operations, such as first name and last name. Exchange Server 2007 uses the global catalog for the email-based lookups of names, email addresses, and other mail-related attributes.

Because full global catalog replication can consume more bandwidth than standard domain controller replication, it is important to design a site structure to reflect the available WAN link capacity. If a sufficient amount of capacity is available, a full global catalog server can be deployed. If, however, capacity is limited, universal group membership caching can be enabled to reduce the bandwidth load.

Understanding Multiple Forests Design Concepts Using Microsoft Identity Integration Server (MIIS) 2003

Microsoft Identity Integration Server 2003 enables out-of-the-box replication of objects between two separate AD forests. This concept becomes important for organizations with multiple Exchange implementations that want a common Global Address List for the company. Previous iterations of MIIS required an in-depth knowledge of scripting to be able to synchronize objects between two forests. MIIS 2003, on the other hand, includes built-in scripts that can establish replication between two Exchange Server 2007 AD forests, making integration between forests easier.


Note - The built-in scripts in MIIS 2003 enable synchronization only between two forests that have a full Exchange Server 2007 or Exchange Server 2003 schema. In other words, if synchronization between an Exchange 2000 forest or an Exchange 5.5 directory is required, customized scripts must be developed.


Determining Exchange Server 2007 Placement

Previous versions of Exchange essentially forced many organizations into deploying servers in sites with greater than a dozen or so users. With the concept of site consolidation in Exchange Server 2007, however, smaller numbers of Exchange servers can service clients in multiple locations, even if they are separated by slow WAN links. For small and medium-sized organizations, this essentially means that one or two servers should suffice for the needs of the organization, with few exceptions. Larger organizations require a larger number of Exchange servers, depending on the number of sites and users. Designing Exchange Server 2007 placement must take into account both administrative group and routing group structure. In addition, Exchange Server 2007 introduces new server role concepts, which should be understood so that the right server can be deployed in the right location.

Understanding Exchange Server 2007 Server Roles

Exchange Server 2007 introduced the concept of server roles to Exchange terminology. In the past, server functionality was loosely termed, such as referring to an Exchange server as an OWA or front-end server, bridgehead server, or a Mailbox or back-end server. In reality, there was no set terminology that was used for Exchange server roles. Exchange Server 2007, on the other hand, distinctly defines specific roles that a server can hold. Multiple roles can reside on a single server, or multiple servers can have the same role. By standardizing on these roles, it becomes easier to design an Exchange environment by designating specific roles for servers in specific locations.

The server roles included in Exchange Server 2007 include the following:

  • Client access server (CAS)—The CAS role allows for client connections via nonstandard methods such as Outlook Web Access (OWA), Exchange ActiveSync, Post Office Protocol 3 (POP3), and Internet Message Access Protocol (IMAP). CAS servers are the replacement for Exchange 2000/2003 front-end servers and can be load balanced for redundancy purposes. As with the other server roles, the CAS role can coexist with other roles for smaller organizations with a single server, for example.

  • Edge Transport server—The Edge Transport server role is unique to Exchange 2007, and consists of a standalone server that typically resides in the demilitarized zone (DMZ) of a firewall. This server filters inbound SMTP mail traffic from the Internet for viruses and spam, and then forwards it to internal Hub Transport servers. Edge Transport servers keep a local AD Application Mode (ADAM) instance that is synchronized with the internal AD structure via a mechanism called EdgeSync. This helps to reduce the surface attack area of Exchange.

  • Hub Transport server—The Hub Transport server role acts as a mail bridgehead for mail sent between servers in one AD site and mail sent to other AD sites. There needs to be at least one Hub Transport server within an AD site that contains a server with the Mailbox role, but there can also be multiple Hub Transport servers to provide for redundancy and load balancing.

  • Mailbox server—The Mailbox server role is intuitive; it acts as the storehouse for mail data in users' mailboxes and down-level public folders if required. It also directly interacts with Outlook MAPI traffic. All other access methods are proxied through the CAS servers.

  • Unified Messaging server—The Unified Messaging server role is new in Exchange 2007 and allows a user's Inbox to be used for voice messaging and fax capabilities.

Any or all of these roles can be installed on a single server or on multiple servers. For smaller organizations, a single server holding all Exchange roles is sufficient. For larger organizations, a more complex configuration might be required. For more information on designing large and complex Exchange implementations, see Chapter 4.

Understanding Environment Sizing Considerations

In some cases with very small organizations, the number of users is small enough to warrant the installation of all AD and Exchange Server 2007 components on a single server. This scenario is possible, as long as all necessary components—DNS, a global catalog domain controller, and Exchange Server 2007—are installed on the same hardware. In general, however, it is best to separate AD and Exchange onto separate hardware wherever possible.

Identifying Client Access Points

At its core, Exchange Server 2007 essentially acts as a storehouse for mailbox data. Access to the mail within the mailboxes can take place through multiple means, some of which might be required by specific services or applications in the environment. A good understanding of what these services are and if and how your design should support them is warranted.

Outlining MAPI Client Access with Outlook 2007

Related:
1 2 3 4 Page 2
Page 2 of 4
The 10 most powerful companies in enterprise networking 2022