Exchange Server 2010 requirements: Hardware, Active Directory

Solutions provider takeaway: Exchange Server 2010's hardware and Active Directory (AD) requirements are crucial considerations for solutions providers before installation and deployment. This chapter excerpt offers information on hardware requirements, such as the amount of memory needed for an Edge Transport Server, and discusses how important AD sites and services are to Exchange Server 2010.

Exchange Server 2010 Hardware Requirements

Microsoft maintains a list of minimum hardware requirements to install Exchange Server 2010. For the latest list of requirements, go to https://technet.microsoft.com/en-us/ and search for "Exchange 2010 System Requirements."

Table 7.1 shows the minimum and recommended hardware requirements for Exchange Server 2010, as stated by Microsoft.

Note:
These hardware requirements from Microsoft are the bare minimum and should not be used in best-practice scenarios. In addition, hardware requirements can change because of features and functionality required by the company, for example, the implementation of Unified Messaging voice mail services or clustering on an Exchange Server 2010 server can require more memory. See Chapter 34, "Optimizing an Exchange Server 2010 Environment," for more tips and best practices on sizing the server for your environment.

About the book: This chapter excerpt on Installing Exchange Server 2010 (download PDF) is taken from the book Exchange Server 2010 Unleashed. This book provides expert advice on designing, deploying, managing, troubleshooting and supporting Exchange Server 2010. Solutions providers will learn about Exchange 2010's newest features, including Microsoft Operations Manager, Database Availability Group replication and other new backup and disaster recovery features.

Understanding the Active Directory Requirements for Exchange Server 2010

An Active Directory (AD) infrastructure running on Windows Server 2003 or Windows Server 2008 must be in place before an organization can deploy Exchange Server 2010. Exchange Server depends on the services provided by AD to successfully function and the design and implementation of the AD environment can have an enormous impact on the success of the Exchange Server deployment. Mistakes made in the planning or implementation of AD can be costly and difficult to correct later.

If AD is already deployed, it is important that the team designing the Exchange Server infrastructure have a solid understanding of the existing AD environment. Organizations with an AD infrastructure already in place need to evaluate how Exchange Server can fit into their environment. If AD has not been deployed, the organization or team designing Exchange Server needs to plan their implementation with a thought as to what their messaging infrastructure will look like.

This section is designed to give a basic understanding of the AD infrastructure required to support an Exchange Server 2010 implementation. Many facets are involved when planning a production AD infrastructure -- forest model, domain model, group policies and delegation of administration to name a few, and the information needed to design an AD infrastructure from end to end is beyond the scope of this book.

Some of the AD factors that should be considered when deploying Exchange Server 2010 include the following:

• Global Catalog Server Placement
• AD Sites and Services
• Forest and Domain Functional Levels
• Flexible Single Master Operations Role Placement
• Permissions Needed to Install Exchange
• Bandwidth and Latency in the Network

Note:
For in-depth guidance on designing, implementing, and maintaining an AD infrastructure, refer to Windows Server 2003 Unleashed, R2 Edition, by Sams Publishing (ISBN: 0-672-32898-4), or Windows Server 2008 Unleashed, by Sams Publishing (ISBN:0-672-32930-1).

Global Catalog Server Placement

As was the case in Exchange 2000 Server through Exchange Server 2007, Exchange Server 2010 requires a global catalog infrastructure to function. The global catalog maintains an index of the Active Directory database for objects within its domain. Additionally, it stores partial copies of data for all other domains within a forest.

Just as important, Exchange Server relies on global catalog servers to resolve email addresses for users within the organization. Failure to contact a global catalog server causes emails to bounce, as the recipient's name cannot be resolved.

Sizing a global catalog infrastructure and server placement is discussed in depth later in this chapter in the section entitled "Establishing a Proper Global Catalog Placement Strategy."

Active Directory Sites and Services

In Exchange Server 2003 and earlier, Exchange Server utilized dedicated routing topology for transporting messages throughout the organization. Beginning with Exchange Server 2007, Microsoft redesigned the product to be a "site-aware" application. This continues in Exchange Server 2010.

Site-aware applications are able to determine what site they (and other servers) belong to by querying Active Directory. The site attribute of all Exchange server objects is maintained by the Microsoft Exchange Active Directory Topology Service. Additionally, Exchange Server 2010 servers utilize site membership to identify which Domain Controllers and Global Catalog servers should be utilized to process Active Directory queries.

The Exchange Server 2010 servers utilize Active Directory site membership as follows:

Hub Transport Servers -- Gather information from Active Directory to determine mail routing inside the organization. When a message hits the Microsoft Exchange Transport service, the Hub Transport server resolves the recipient's information and queries Active Directory to match an email address to the recipient's account. The result of this query includes the fully qualified domain name (FQDN) of the user's mailbox server.

From the FQDN, the AD site of the recipient's Mailbox server is determined and, if the Mailbox server is in the same site as the Hub Transport server, the message is delivered. If the Mailbox server is in another site, the message is relayed to a Hub Transport server in that site, and the message is then delivered to the user's mailbox server.

Client Access Servers -- When a client access server receives a connection request from a user, it contacts AD to determine which mailbox server houses the user's mailbox and which site that server belongs to. If the mailbox server is in a different site, the connection is redirected to a client access server in the same site as the mailbox server.

About the authors: Rand Morimoto has been in the IT industry for more than 25 years and is the president of Convergent Computing, an IT consulting firm. Morimoto has also co-authored Windows Server 2008 R2 Unleashed.   Michael Noel is an IT expert and a partner at Convergent Computing. Noel has also written Microsoft SharePoint 2007 Unleashed. Chris Amaris cofounded Convergent Computing and also serves as the chief technology officer. Amaris is the co-author of Microsoft Exchange Server 2007 Unleashed. Andrew Abbate has been in the IT industry for more than 10 years and specializes in Active Directory and Microsoft Exchange Server migration planning and implementations. Mark Weinhardt has worked in the IT world for more than 20 years and has also authored Network Security for Government and Corporate Executives.

Mailbox Servers -- Query Active Directory to determine which Hub Transport servers are located in their site. Messages are submitted to local Hub Transport servers for routing and transport.

Unified Messaging Servers -- Utilize Active Directory site membership information to determine what Hub Transport servers are located in the same site as the UM server. Messages for routing and transport are delivered to a Hub Transport server in the same site as the UM server.

Forest and Domain Functional Levels

With each new edition of the Windows Server and Exchange Server operating systems, new functionalities are introduced. Some of these enhancements require that the Active Directory infrastructure be upgraded before you can take advantage of the new capabilities. At times, these capabilities cannot be implemented until all domain controllers in an environment have been upgraded to the same level.

To support this, Active Directory has Forest and Domain functional levels that determine what enhancements are enabled or disabled. By raising the functional level of an environment, new functionalities are enabled. By maintaining an older functional level, interoperability with older domain controllers is supported.

Forest Functional Levels

Windows Server 2003 supports three forest functional levels:

• Windows 2000 Native -- Required while any Windows Server 2000 domain controllers remain in your forest. Supports domain controllers running Windows NT 4.0, Windows 2000 server, and Windows Server 2003.
• Windows Server 2003 Interim -- A special functional level only implemented during NT 4.0 to Windows 2003 upgrades.
• Windows Server 2003 -- All DCs in the forest must be running Windows Server 2003, and all domains in the forest must be at the Windows 2003 Domain functional level before you can raise your forest functional level to Windows Server 2003.

Windows Server 2008 supports three forest functional levels:

• Windows 2000 Native -- Supports Windows 2000, Windows Server 2003, and Windows Server 2008 domain controllers.
• Windows Server 2003 -- Allows for a mix of Windows Server 2003 and Windows Server 2008 functional level domains.
• Windows Server 2008 -- Ensures all domain controllers in the forest are running Windows Server 2008 and all domains have been raised to the Windows Server 2008 domain functional level.

Note:
To install Exchange Server 2010, the Active Directory forest functional level MUST be Windows Server 2003 or higher.

Windows 2000 Native and Windows Server 2003 Interim modes are NOT supported.

Domain Functional Levels

Windows Server 2003 supports four domain functional levels:

• Windows 2000 Mixed -- Allows Windows Server 2003 domain controllers to interoperate with other domain controllers running Windows Server 2003, Windows 2000 Server, and Windows NT 4.0.
• Windows 2000 Native -- Allows domain controllers running Windows Server 2003 to interact with domain controllers running either Windows Server 2003 or Windows 2000 Server.
• Windows Server 2003 Interim -- Supports only domain controllers running Windows Server 2003 and Windows NT 4.0.
• Windows Server 2003 -- Supports only Windows Server 2003 domain controllers.

Windows Server 2008 supports three domain functional levels:

• Windows 2000 Native -- Allows domain controllers running Windows Server 2008 to interact with domain controllers running either Windows Server 2008, Windows Server 2003, or Windows 2000 Server.
• Windows Server 2003 -- Supports an environment comprised of a mixture of Windows Server 2003 and Windows Server 2008 domain controllers.
• Windows Server 2008 -- Only available after all domain controllers in a domain are running Windows Server 2008.

Note:
To install Exchange Server 2010, the Active Directory domain functional level MUST be Windows Server 2003 or higher for each domain in the Active Directory forest that will house an Exchange Server 2010 server.

Windows 2000 Mixed, Windows 2000 Native, and Windows Server 2003 Interim modes are NOT supported.

Understanding Flexible Single Master Operations Roles

Active Directory uses a multimaster replication scheme for replicating directory information between domain controllers; however, certain domain and enterprise wide operations are not well suited for a multimaster model. Some services are better suited to a single master operation to prevent the introduction of conflicts while an Operations Master is offline. These services are referred to as Operations Master or Flexible Single Master Operations (FSMO) roles.

FSMO roles can be either "forestwide" or "domainwide." The forestwide roles consist of the Schema Master and the Domain Naming Master. The domainwide roles consist of the Relative ID (RID) Master, the Primary Domain Controller (PDC) Emulator, and the Infrastructure Master. A brief description of each is as follows:

• Schema Master -- Maintains all modifications to the schema throughout the Active Directory forest, as no other domain controller is allowed to write to the schema. The schema determines what types of objects are permitted in the forest and the attributes of those objects.
• Domain Naming Master -- Maintains a list of the names of all domains in the forest and is required to add any new domains (or to remove existing ones).
• RID Master -- Allocates security RIDs to domain controllers to assign to new AD security users, groups, or computer objects. RIDs are the part of the Security Identifier (SID) that identifies an account or group within a domain. The RID master also manages objects moving between domains.
• PDC Emulator -- Processes all password changes in the domain. If a user logon attempt fails due to a bad password, the request is forwarded to the PDC emulator to check the password against the most recent one. This allows a user to log in immediately after a password change instead of having to wait for that change to replicate throughout the active directory.
• Infrastructure Master -- Maintains security identifiers, GUIDs, and DNS for objects referenced across domains. This role is also responsible for ensuring that cross-domain group-to-user references are correctly maintained.

When designing the FSMO role placement of an Active Directory environment, the following best practices should be considered:

• If a domain has only one domain controller, that domain controller holds all the domain roles. However, this configuration is not recommended (even for smaller organizations), as it creates a single point of failure.
• The Schema Master and Domain Naming Master should be placed on the same domain controller in the root or placeholder domain. This server can (and should) also be configured as a global catalog server.
• Place the RID and PDC emulator roles on the same domain controller. If the load on this server justifies separating the roles, place them on domain controllers in the same domain and AD site and ensure the two domain controllers are direct replication partners of each other.
• As a general rule, the infrastructure master should be deployed on a domain controller that is NOT also a global catalog server. This domain controller should have a direct connection to a GC server, preferably in the same Active Directory site. Global catalog servers hold a partial replica of every object in the forest and the infrastructure master, when placed on a global catalog server, will never update anything as it does not contain any references to objects that it does not hold. There are two exceptions to this rule:

1. Single domain forest: In a forest with a single AD domain, there are no phantoms and the infrastructure master has no work to do. In this case, the infrastructure master can be placed on any domain, including those that are also global catalog servers.
2. Multidomain forests where every domain controller is a global catalog server. When every domain controller in a domain that is part of a multidomain forest is configured as a global catalog server, there are no phantoms or work for the infrastructure master to do. The infrastructure master can be placed on any domain controller in the domain.

Note:
As stated by Microsoft, to install Exchange Server 2010, the Schema master should have "the latest 32-bit or 64-bit edition of the Windows Server 2003 Standard or Enterprise operating system or the latest 32-bit or 64-bit edition of the Windows Server 2008 Standard or Enterprise operating system."

Additionally, in each Active Directory site where you plan to install Exchange Server 2010, you must have at least one Global Catalog server that meets the same criteria.

Understanding How DNS and AD Namespace Are Used in Exchange Server 2010

The first step in the actual design of the AD structure is the decision on a common domain name system (DNS) namespace that AD will occupy. AD revolves around (and is inseparable from) DNS and this decision is one of the most important ones to make. The namespace chosen can be as straightforward as companyabc.com, for example, or it can be more complex. Multiple factors must be considered, however, before this decision can be made. Is it better to register an AD namespace on the Internet and potentially expose it to intruders, or is it better to choose an unregistered, internal namespace? Is it necessary to tie in multiple namespaces into the same forest? These and other questions must be answered before the design process can proceed.

Impact Forests Have on an Exchange Server 2010 Design

An AD forest and an Exchange Server organization are tightly integrated. Exchange Server relies on AD as its directory repository for mailboxes, mail-enabled objects, Exchange servers, and much more. An AD forest can only host a single Exchange organization and an Exchange organization can only span one AD forest.

It is recommended that a single AD forest should be utilized to minimize complexity and administration when designing and implementing a company's Exchange Server implementation. However, there will be times when a single AD forest will not meet the company's business, security, or political requirements.

If multiple AD forests are necessary to satisfy the company's requirements, it must be decided on which forest the Exchange organization will be hosted. It is possible to have an Exchange Server reside in a single forest, a dedicated resource forest, or to implement multiple Exchange organizations in multiple forests.

The Role of a Domain in Exchange Server 2010

After the AD forest structure has been laid out, the domain structure can be contemplated. Unlike the forest structure, an Exchange Server 2010 organization can span multiple domains within the forest if needed. Therefore, a user mailbox, Exchange server, or other Exchange object can reside in any domain within the forest where Exchange Server 2010 has been deployed. A company can plan its domain model structure (single domain model or multiple domain model) based on their business and security requirements without a direct negative impact to the Exchange Server 2010 design.

While a single domain model is often considered due to its simplicity, most organizations prefer 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 7.1.

FIGURE 7.1 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. Smaller organizations may have a difficult time justifying the extra infrastructure costs to provide the increased security, but whenever the budget allows, this model should definitely be considered.

Planning a Proper Sites and Services Architecture

As stated earlier, one of the major features of Exchange Server 2007 and Exchange Server 2010 is the ability to natively utilize Active Directory Sites and Services for routing mail, rather than having to implement and maintain an independent routing topology using connectors. To take advantage of this capability, you must first remove all pre-Exchange Server 2007 servers from your environment.

If Exchange Server 2010 will be installed into an existing Exchange Server 2003 organization, the administrators must configure routing group connectors to ensure that the Exchange Server 2010 servers are communicating to legacy servers.

For more information on coexistence of Exchange Server 2010 with legacy versions, review Chapter 15, "Migrating from Active Directory 2000/2003 to Active Directory 2008."

Administrators should be aware of the best practices for designing a proper Sites and Services architecture to support Exchange Server 2010. From a high-level perspective, within AD it is necessary for administrators to create sites, allocate subnets to sites, and then create site links between sites for communication to occur. Similar to Exchange 2000 and 2003, it is possible to set up redundant links between sites and allocate costs to control communication priorities.

Active Directory Sites

The basic unit of AD replication is known as the site. Not to be confused with physical sites or Exchange Server 5.5 sites, the AD site is simply a group of domain controllers connected by high-speed network connections. Each site is established to more effectively replicate directory information across the network. In a nutshell, domain controllers within a single site will, by default, replicate more often than those that exist in other sites. The concept of the site constitutes the centerpiece of replication design in AD.

Associating Subnets with Sites

In most cases, a separate instance of a site in AD physically resides on a separate subnet from other sites. This idea stems from the concept that the site topology most often mimics, or should mimic, the physical network infrastructure of an environment.

In AD, sites are associated with their respective subnets to allow for the intelligent assignment of users to their respective domain controllers. For example, consider the design shown in Figure 7.2.

FIGURE 7.2 Sample Exchange Server and Client site assignment.

In this example, Server-EX01 is a physical member of the 192.168.115.0/24 subnet. Server-EX02 and Client01 are both members of the 192.168.116.0/24 subnet. Based on the subnets, Server-EX01 will automatically be assigned to the domain controller Server-DC01 in SITE01 and Server-EX02 and Client01 will be assigned to the domain controller Server-DC02 in SITE02.

Using Site Links

By default, the creation of two sites in AD does not automatically create a connection linking the two sites. This type of functionality must be manually implemented by the creation of a "site link."

A site link is essentially a connection that joins together two sites and allows for replication traffic to flow from one site to another. Multiple site links can be set up and should normally follow the wide area network (WAN) lines of your organization. Multiple site links also assure redundancy so that if one link goes down, replication traffic has an alternate path.

Site link replication schedules can be modified to fit the requirements of your organization. If, for example, the WAN link is saturated during the day, a schedule can be established to replicate information at night. This functionality allows you to easily adjust site links to the needs of any WAN design.

Exchange Server 2010 and Site Membership

After the AD site topology has been created, including adding the appropriate subnets to sites and creating site links between sites, an administrator can now take Exchange Server placement into consideration.

Similar to AD domain controllers, Exchange Server 2010 servers will be associated with sites in AD based on their IP address and subnet mask. As stated earlier, there should be at least one domain controller/global catalog server residing in each site that an Exchange Server 2010 server will be in.

For more information on creating an Exchange Server routing topology, refer to Chapter 4, "Architecting an Enterprise-Level Exchange Server Environment."

Note:
If an AD infrastructure already exists prior to the design of the Exchange Server 2010 environment, there might be a need to make changes to the AD routing topology to support the Exchange routing requirements.

Establishing a Proper Global Catalog Placement Strategy

Another area of importance is the design and placement of global catalog servers within the environment. The importance of the global catalog server cannot be overstated. The global catalog is used for the address list that users see when they are addressing a message and by Exchange servers every time a message is delivered. If a global catalog server is not available, the recipient's address will not resolve when users address a message, and the message cannot be delivered.

There should be at least one global catalog server in every AD site that contains an Exchange Server 2010 server. The recommendation from Microsoft is as follows:

If Active Directory is running on a 32-bit system, the recommendation is 4:1 -- for every four processor cores in your mailbox servers, you should have one processor core in a global catalog server. For example, if you have 2 mailbox servers, each with dual quad-core processors, that is 16 processor cores. You should have at least 4 processor cores worth of global catalog computing, so 1 quad core server, or 2 dual core servers should do the trick.

If Active Directory is running on a 64-bit system, the recommended ratio is 1:8. However, you must have enough memory installed on the server to cache the entire Active Directory database in memory. To confirm the size of your Active Directory database, look at the size of the %WINDIR%NTDSNTDS.DIT file.

For optimization, plan on having a global catalog server close to the clients to provide efficient address list access. Making all domain controller servers global catalog servers is recommended for an organization that has a single AD domain model and a single site. Otherwise, for multidomain models, all domain controllers can be configured as global catalog servers except for the domain controller hosting the Infrastructure Master FSMO role.

Note:
It is a best practice to have a minimum of at least two global catalog servers within an AD infrastructure.

Installing Exchange Server 2010
  Exchange Server 2010 server roles, prerequisites, high availability
  Exchange Server 2010 requirements: Hardware, Active Directory
  Exchange Server 2010 role-based access control

Printed with permission from Sams Publishing. Copyright 2009. Exchange Server 2010 Unleashed by Rand Morimoto, Michael Noel, Chris Amaris, Andrew Abbate and Mark Weinhardt. For more information about this title and other similar books, please visit Sams Publishing.