The AD Administrator's Guide to Exchange 2007

While Exchange administrators are running around in a state of excitement about the latest version of Exchange, Active Directory (AD) administrators have to be content with patiently waiting for Windows Server 2008 (formerly code-named Longhorn) and the AD updates that it includes. The good news for those of you involved with AD and keen to get to grips with emerging Microsoft technologies is that you can get started learning about AD and Microsoft Exchange 2007 integration now. In fact, you’ll need to work more closely with your Exchange colleagues in future. Let’s take a look at the Exchange 2007 features that are most likely to be relevant to IT professionals working closely with AD.

AD Requirements
As with all Exchange versions after 5.5, Exchange 2007 requires AD. However, you can’t install Exchange 2007 in just any AD environment. First, the domain controller (DC) holding the Schema Master role must be running Windows Server 2003 SP1 or later. Second, the installation of Exchange 2007 requires at least one DC acting as a global catalog server to be available within the AD site. This global catalog server must also be running Windows 2003 SP1 or later.

With all the hype surrounding Exchange 2007 and 64-bit, AD administrators will be interested to know that DCs don’t have to run 64-bit versions of the OS; however, Microsoft recommends doing so, given the increased directory service performance available with 64-bit DCs. In fact, there are several case studies that show 64-bit DCs deliver significant consolidation and scalability benefits. Microsoft doesn’t support running Exchange 2007 on Server 2008 servers. Instead, you'll need to wait for Exchange 2007 SP1 for this support. Exchange 2007 also doesn’t support pre-RTM versions of Server 2008 DCs running in the same AD site. However, writeable DCs running Server 2008 will work with Exchange 2007. No versions of Exchange will work with Server 2008 Read-Only DCs.

Microsoft strongly recommends that you don’t install Exchange 2007 on a DC, which is consistent with the recommendations for previous versions of Exchange. Each domain into which you install Exchange 2007 or that will host Exchange 2007 recipients must be running at Windows 2000 native domain functional level or higher. There’s no similar requirement for a particular forest functional level.

Forest and Domain Preparation
Like its predecessors Exchange 2003 and 2000, Exchange 2007 is a heavy user of AD, and several changes to AD are required to support Exchange 2007 at both the domain and forest level. You won’t be surprised to learn that Exchange 2007 requires an extension to the AD schema. As with all changes to the schema, you should perform rigorous testing before deploying the schema change in your live environment. If you’re familiar with Exchange 2003’s and 2000’s ForestPrep and DomainPrep setup options, you should have little difficulty with the similar—although differently named—options in Exchange 2007.

One new setup parameter in Exchange 2007 is /PrepareLegacyExchangePermissions, which is required to prepare environments that already have an Exchange organization in place within the forest running either Exchange 2003 or 2000. You can run this option either for all the domains in the forest or for only specific domains.

Preparation of the forest and domains involves running the Exchange 2007 setup executable (setup.exe) with various command-line parameters. You can find setup.exe in the root folder of the Exchange 2007 setup media.

To prepare all domains in the forest, run the following command:

setup /PrepareLegacyExchangePermissions

Note that your account must be a member of the Enterprise Admins group to run this command. To prepare a single domain in the forest, run the following command:

setup /PrepareLegacyExchangePermissions 

For example, if your domain is named eastern.com, the command would be

setup /PrepareLegacyExchangePermissions eastern.com

For this option, your account must have Exchange Full Administrator rights at the organization level and must be a member of the Domain Admins group in the domain that you'll prepare.

If you want to extend the forest schema before running any other Exchange setup options, you can run setup.exe with the /PrepareSchema parameter by using the following command:

setup /PrepareSchema

Running this command incorporates /PrepareLegacyExchangePermissions if it hasn't already been. Note that your account must be a member of the Schema Admins and Enterprise Admins groups to run this command.

Preparing the schema involves importing several (99 to be precise) .ldf files into AD. If you want to see what these files contain, you can find them on the setup media under :SetupData.

The third setup option is /PrepareAD, which incorporates the /PrepareLegacyExchangePermissions and /PrepareSchema tasks, if you haven’t done so already. You must run /PrepareAD on a computer that’s in the same AD site and domain as the DC holding the Schema Master DC role. Your account must be a member of the Enterprise Admins group (as well as the Schema Admins group if you haven’t previously run /PrepareSchema) and have Exchange Full Administrator rights if you’re preparing an AD environment that already includes an existing Exchange 2003 or 2000 organization. The following command runs /PrepareAD:

setup /PrepareAD [/OrganizationName:  ]

For example, if you want your Exchange organization to be named Eastern, run the command

setup /PrepareAD /OrganizationName: Eastern

Note that you don’t need to include the /OrganizationName parameter if you have an existing Exchange 2003 or 2000 organization within the forest.

/PrepareAD performs several tasks, including setting Exchange-related permissions, configuring global Exchange objects within AD’s configuration partition, creating Exchange universal groups, and preparing the local domain. The command also creates an administrative group called Exchange Administrative Group (FYDIBOHF23SPDLT) and a routing group called Exchange Routing Group (DWBGZMFD01QNBJR).

The fourth setup option is to prepare the remaining domains in the forest using either the /PrepareDomain or /PrepareAllDomains parameters. Remember, you don’t need to do so if you have a single domain forest because /PrepareAD would have included these tasks. For /PrepareDomain, your account must be a member of Domain Admins for the domain being prepared, and for /PrepareAllDomains your account must be a member of the Enterprise Admins group. In addition, if the domains are being prepared after you’ve run /PrepareAD, your account must also be a member of the Exchange Organization Administrators group. To prepare the remaining domains, run the following commands:

setup /PrepareDomain 

setup /PrepareAllDomains

Domain preparation with /PrepareDomain and /PrepareAllDomains involves tasks such as setting the appropriate permissions on the Domain container, creating, if it doesn't exist, and setting permissions on the Microsoft Exchange System Objects container, and creating a new domain global group in the current domain named Exchange Install Domain Servers. /PrepareDomain and /PrepareAllDomains also add the Domain Servers group to the Exchange Servers Universal Group in the root domain. Because all of the setup command-line options I’ve outlined make changes to AD, you should allow time for replication to complete before proceeding with other setup steps. I recommend running setup from an Exchange server, rather than a DC, to complete the tasks because there are several prerequisites for running setup that you might not want to install on your DC, including the .NET Framework 2.0, Microsoft Management Console (MMC) 3.0 (if you aren’t running Windows 2003 R2 already), and PowerShell 1.0. Also, if your DCs aren’t running the 64-bit version of Windows 2003, you’ll need to download and run the 32-bit version of Exchange 2007 setup.

Global Catalog Availability
Exchange 2007 servers still require global catalog servers to be available within the same AD site. The recommended ratio for Exchange 2003 is to have one global catalog server processor for every four Exchange server processors (i.e., a ratio of 1:4 within the same AD site). For example, you might have two single-processor global catalog servers servicing eight single-processor Exchange 2003 servers, or one dual-processor global catalog server servicing four dual-core Exchange 2003 servers. The good news is that Exchange 2007 potentially requires fewer in-site Global Catalogs (GCs), assuming you meet one important criterion: You can work with a ratio of 8:1 as long as your global catalog server has sufficient RAM to cache the entire AD database (i.e., the ntds.dit file). You’re unlikely to be able to achieve this ratio with global catalog servers running a 32-bit OS because of inherent memory limitations—unless, of course, you have a very small AD database. But with 64-bit global catalog servers you have the ability to ramp up to a much larger amount of physical memory, which makes holding the AD database in cache more feasible.

Before you crack open the champagne and decommission a few of your global catalog servers, bear in mind that Exchange 2007 has several new components and features that can increase the demands on the GC. Remember that Microsoft’s ratio recommendations are only a design guideline, and given the relatively small number of Exchange 2007 deployments to date, it's probably too early to say whether the recommendation is reliable. You should monitor the performance of your DCs to ensure they’re keeping up with demand.

AD Sites and Exchange Routing
The Exchange 2003 routing group was specific to Exchange, and the configuration was completely separate from the underlying AD site topology. Microsoft has simplified matters, and Exchange 2007 uses the underlying AD site topology for routing. Exchange 2007 Mailbox servers use Hub Transport servers from within the same site to submit email messages for delivery to a recipient mailbox. The Hub Transport server then delivers the email message directly to a local Mailbox server if the recipient is within the same site. If the recipient’s mailbox is in a different site, the Hub Transport server relays the email message directly to a Hub Transport server in the remote site, from which the email message is delivered to the appropriate target Mailbox server. In the event that the default direct relay behavior between Hub Transport servers isn’t optimal for routing, Exchange administrators have the ability to tailor it to their needs. For example, Exchange administrators can configure an AD site as a routing hub by using the Set-AdSite PowerShell cmdlet, thereby overriding the default direct relay behavior between Hub Transport servers in different sites. The good news is that the Set-AdSite cmdlet doesn't require the account to be a member of the Enterprise Admins group in AD—a level of permission typically required to make changes to the AD site topology.

What does this mean for AD administrators? Well, not a great deal, as long as you’ve defined your AD sites well and have correctly registered your subnets. Missing subnet registrations can cause real problems in any environment, but especially for Exchange scenarios where routing relies on the correct configuration.

A design approach that was somewhat popular with Exchange 2003 was to create a separate AD site for Exchange. The rationale was to provide dedicated AD DCs and global catalog servers for Exchange to use. This design had the benefit of ensuring Exchange didn’t compete with other services that use AD—an approach that could guarantee a certain level of performance. The downside was the added cost of providing and supporting additional DCs. Given that Exchange 2007 routing now maps directly onto the AD site topology, the separate-site-for-routing concept no longer applies. If you have a burning desire to keep certain DCs dedicated to Exchange, you can modify the weight and priority of the DNS SRV records to separate Exchange usage from client logons.

DSAccess and DSProxy Changes
In Exchange 2003, DSAccess ran as a component within the System Attendant service. It had several functions, including building the topology of DCs and global catalog servers for the Exchange server to use, querying AD, and maintaining a cache of the queried information. With the exception of DSProxy (which I’ll discuss shortly), all queries against AD from an Exchange server were routed through DSAccess. Exchange 2007 changes the role of DSAccess so that it no longer maintains the cache. Instead, individual components that require information from AD via DSAccess maintain their own cache. Exchange 2007 also removes the AD topology function from the System Attendant service and creates a new service called the Microsoft Exchange Active Directory Topology service (MSExchangeADTopology). The new service is used by Exchange components that require knowledge of the underlying AD topology.

The Exchange 2003 DSProxy feature provided Messaging API (MAPI) clients with the name of a nearby GC for address book lookups. DSProxy also provided legacy MAPI clients with an address book lookup service if they were unable to communicate directly with a GC. Exchange 2007 DSProxy is mostly the same as it was in Exchange 2003 SP2. However, Exchange 2007 now includes the AD-integrated Autodiscover service, which extends functionality for Microsoft Office Outlook 2007 clients by providing them with the URLs that they need to access new Web services offered by Exchange 2007 via the Client Access Server role.

The Edge Transport Server Role
AD administrators should be aware that the Exchange 2007 Edge Transport Server role exists outside the domain environment, which means you install the role on a standalone server, not a member server. The Edge Transport server is an optional Exchange 2007 component and typically resides within the perimeter network to handle the mail flow between the internal Exchange servers and Internet recipients. Many organizations won't require the Edge Transport server if they already have infrastructure deployed to cleanse email messages being sent between the Exchange server and the outside world. As with all Exchange servers, the Edge Transport server requires routing and configuration information from AD. To protect the AD infrastructure from possible compromise, the Edge Transport server has no direct connection to DCs within the internal network. Instead, a component called EdgeSync on an Exchange 2007 server holding the Hub Transport role provides a one-way replication of recipient and configuration information from AD to an instance of Active Directory in Application Mode (ADAM) residing on the Edge Transport server. EdgeSync updates the information according to a configurable schedule.

Tight Integration with AD
As with previous Exchange versions since Exchange 2000, Exchange 2007 is tightly integrated with AD and updates the schema, configuration, and domain partitions. Before installing Exchange 2007, make sure that you meet all the AD prerequisites and that you prepare the forest and domain in accordance with the recommendations. The bar has been lowered for GC availability requirements, but only if you’re running the 64-bit version of the OS on your global catalog server.