Active Directory and Exchange Server 2007

Active Directory is a grand repository for information about such objects as users, domains, computers, domain controllers, groups, contacts, and shared resources (such as files and printers). Active Directory lets you log into very large domains and use resources across the domain with ease. All objects in Active Directory are protected by a security system based on Kerberos, an industry-standard secret-key encryption network authentication protocol developed at the Mas-sachusetts Institute of Technology. (For more on Kerberos, see http://web.mit.edu/kerberos/www/.)

Windows Server controls who can see each object in Active Directory, what attributes each user can see, and what actions a user can perform on an object. The Windows Active Directory permissions model is richer and more complex under the hood than directory services permissions in earlier versions of Windows such as Windows NT 4, but it's quite easy to manage at the user interface level.

Exchange Depends on Active Directory

Exchange Server 2007, like Exchange 2000/2003, depends entirely on a healthy and functioning Active Directory and the availability of Domain Name Service (DNS) services. In order for Exchange servers to properly locate domain controllers and global catalogs, DNS must accurately resolve domain controller and global catalog service location records and host information as well as information about Active Directory sites. Exchange must retrieve configuration and recipient information from Active Directory as well; if either DNS or Active Directory does not respond to an Exchange 2007 server's queries, clients will not be able to authenticate, address lookups will not occur, and e-mail will not flow.

Almost the entire Exchange 2007 configuration is stored in the Active Directory; this information is stored in a partition of the Active Directory called the Configuration partition. The Configuration partition (Figure 2.1) is replicated to all domain controllers in the entire forest, not just the domain in which the Exchange server is installed.

Figure 2.1: Viewing the configuration from ADSI Edit

The information you see in Figure 2.1 represents the Exchange 2007 configuration as viewed using the Windows 2003 Support Tools utility ADSI Edit. This is a very primitive view of the Exchange configuration in much the same way that REGEDIT gives you an inside look at the Windows Registry. Actually configuring Exchange properties is much easier (and safer!) to do when you use the Exchange Management Console (EMC) or the Exchange Management Shell (EMS). You should only use ADSI Edit to manipulate your Exchange organization's configuration when you have specific guidance from Microsoft or a trustworthy source.

When an Exchange server starts running services such as the Microsoft Exchange System Attendant, the Microsoft Exchange Active Directory Topology service determines in which Active Directory site the Exchange server is located and then locates all domain controllers and global catalog servers in that site. Exchange Server then reads its configuration from Active Directory; this would include determining which roles that server supports, the mailbox databases to mount, and more.

When Exchange 2007 Hub Transport server is routing messages to Exchange recipients, t it must query a global catalog server in order to determine properties of the recipient such as proxy addresses, home mailbox server, and mailbox restrictions. Figure 2.2 shows the E-mail Addresses property page of a mailbox recipient; mail recipients are managed through the Exchange Management Console (EMC).

Figure 2.2: E-mail Addresses properties

All recipient information is stored in the Active Directory, so information regarding e-mail addresses, home server, mailbox limits, message size limits, and so on are found in the Active Directory. Exchange server must retrieve this information from an Active Directory global catalog server. Exchange server is dependent on the availability and health of domain controllers and global catalog servers; if Active Directory resources are not available, Exchange will not function.

Active Directory Site Membership

Exchange Server 2007 is an Active-Directory-site-aware application. Exchange 2007 uses Active Directory site information for a couple of purposes.

Exchange 2007 servers automatically learn the Active Directory topology and determine in which Active Directory site each Exchange 2007 server is located. Exchange Server uses the IP subnets to locate the sites; if the subnet information is incomplete or incorrect, Exchange Server will not be able to correctly determine site membership and mail may not be delivered properly.

Different Exchange Server 2007 server roles use the Active Directory site information in different ways:

• All Exchange 2007 server roles use the site architecture to locate domain controllers and global catalog servers closest to them from the network's perspective.

• Hub Transport servers determine the remote Hub Transport servers names in other Active Directory sites to which they need to transmit messages intended for remote Mailbox servers.

• Mailbox servers determine which Hub Transport servers are in their own site so they can notify those servers that they have messages that must be transferred.

• Unified Messaging servers submit voicemail messages and faxes to Hub Transport servers in their own site for routing to Mailbox servers. Unified Messaging servers do not transfer voicemail and fax messages directly to a Mailbox server.

• Client Access servers look for site information in order to determine if they are located in the same Active Directory site mailboxes that they are being asked to provide access to. If not, the Client Access server refers the client to a Client Access server that is in the same site as the required Mailbox server.

• Exchange Server refers Outlook 2000, 2002, and 2003 clients to global catalog servers that are in the same site as the Exchange server for global address list lookups.

If there are weaknesses in your Active Directory site design, Exchange 2007 will certainly expose them. You should ensure that for Active Directory forests with more than one Active Directory site, subnets are properly defined and associated with the appropriate site.

Warning 

Active Directory IP subnet information must be correct. If it's not, Exchange components might not function properly and messages might not be delivered.

Domain Controllers and Global Catalog Servers

The simplest way to describe the Exchange 2007 requirements for Active Directory is to say that all domain controllers should be running (at a minimum) Windows 2003 Service Pack 1 or later, each domain should be at Windows 2003 domain functional level, and the forest should be at Windows 2003 functional level. Although that is the best case scenario, it might not be practical and it is not correct. The following are the actual minimum requirements for Windows 2003 domain controllers and Active Directory:

• Each Active Directory site that has Exchange 2007 servers must have at least one Windows 2003 Service Pack 1 or later global catalog server. For redundancy, an additional global catalog server should be available. The recommended ratio of Exchange servers to global catalog servers is based on the number of CPUs; that ratio is 4:1. For each quad processor Exchange server, a single processor global catalog server should be available in the site, but that may not take in to consideration redundancy requirements.

• Each domain that will host Exchange 2007 servers or mail-enabled recipients must be at a minimum Windows 2000 native functional level.

• If you are supporting the Exchange 2007 Outlook Web Access browsable global address list, you must use Windows 2003 Service Pack 1 or later global catalog servers.

• The schema master flexible single master of operations role must be hosted on a domain controller running Windows 2003 Service Pack 1 or later.

• If you have Exchange organizations in multiple forests and require forest-to-forest trusts, then all forests involved in forest-to-forests trusts must be at Windows 2003 forest functional mode.

Tips for Healthy Interaction with Active Directory

Any experienced Exchange administrator will tell you that a healthy Active Directory goes a long way toward ensuring that Exchange Server is healthy and trouble free. We have learned a number of lessons (sometimes the hard way) over the years and can offer some useful tips for ensuring that Active Directory provides consistent and reliable directory services to Exchange.

• Even in small and medium-sized organizations, redundant domain controllers and global catalog servers help ensure higher availability.

• In large organizations, each Active Directory site that hosts Exchange servers should have at least two domain controllers that host the global catalog server role.

• In large organizations with many thousands of mailboxes, implementing dedicated domain controller/global catalog server sites that are exclusively for use by Exchange servers will ensure that Exchange does not interfere with Active Directory's other functions (such as authenticating users) and vice versa.

• All clients and member servers should have a primary DNS server and a secondary DNS server address configured.

• In large organizations, clients and member servers should have a primary, secondary, and tertiary DNS server IP addresses configured.

• Either Windows 2003 32-bit or 64-bit can be used for domain controllers and global catalog servers, but if the Active Directory database (NTDS.DIT)exceeds 1GB, then better performance will be achieved with 64-bit Windows 2003. For organizations with NTDS.DIT files larger than a few hundred megabytes, separating the database transaction logs to a RAID 1 volume array and the NTDS.DIT database file to a RAID 5 array can also improve performance.

• Installing the DNS service on all domain controllers and using Active Directory-integrated DNS zones on all domain controllers in the forest will improve the reliability of DNS and therefore Active Directory. If you have more than two domain controllers/DNS servers in your organizations, all domain controllers and member servers should be configured with a primary DNS server, a secondary DNS server, and a tertiary DNS server.