Planning the Exchange Server 2010 Infrastructure

You have probably heard the expression “Measure twice, cut once.” When it comes to the deployment of Exchange Server 2010, taking time with your organization’s deployment can save you a lot of trouble later. In this chapter you’ll learn about the different models for on-premises and cloud-based deployments, DNS requirements, how to translate Service Level Agreement (SLA) requirements into design decisions, and whether you need to plan Exchange federation. You’ll learn how to design an appropriate topology to meet your organization’s message routing requirements, design a Mailbox server deployment that is appropriate given your organization’s topology, design a Client Access Server deployment to support your proposed Exchange deployment, and plan a deployment to meet any transition and coexistence requirements. This chapter is primarily about design considerations prior to deploying Exchange Server 2010. Chapter 2, “Deploying the Exchange Server 2010 Infrastructure,” deals more with the specifics of configuring these technologies on the organizational network.

Objective 1.1: Design the Exchange Server 2010 Installation

Microsoft provides guidance for IT professionals on the factors they should consider when planning to deploy Exchange Server 2010. In this objective you’ll learn about the factors you need to consider when planning your Exchange deployment. In Chapter 2, “Deploying the Exchange Server 2010 Infrastructure,” you’ll learn about the practical steps you need to take to perform an Exchange Server 2010 deployment.

Choosing Exchange Server Locations

You can choose between three general Exchange design options when deploying Exchange Server 2010: an on-premises deployment, a cloud deployment, or a coexistence deployment. In the real world, decisions about whether to go with an on-premises or cloud-based deployment are rarely technical in nature. These decisions are usually driven by business needs and cost and you are unlikely to encounter a question on the 70-663 exam that directly asks you whether a cloud-based or on-premises deployment is appropriate. You are more likely to be asked about what design considerations are involved if it becomes necessary to configure your organization to support an on-premises and cloud-based coexistence scenario. You’ll need to know what steps you’d need to take to get such a deployment working, not whether an organization would be better off shunting everything to the cloud or keeping everything in-house.

On-Premises Deployments

The 70-663 exam primarily deals with the design of on-premises Exchange Server 2010 deployments and infrastructure. In part this is because a lot less design work is required if you go with an entirely cloud-based Exchange deployment than there is in deciding where to place hub transport, client access, and mailbox servers on a per-site basis. The focus is on local deployments because the vast majority of organizations who use Exchange still choose to go with on-premises rather than coexistence or entirely cloud-based deployments.

When choosing where to place Exchange servers, you need to take into account issues such as number of mailboxes, server capacity, and available bandwidth. While it might be possible to place an Exchange server that hosts the mailbox, client access, and hub transport server roles at each location, even in the biggest organizations such an approach isn’t always necessary. For example, one multinational company I know of has approximately 2,000 employees spread across the capital cities of Australia and another 500 or so in New Zealand. All of these employees use Exchange servers hosted in Singapore and there is no local Exchange deployment. Each office has local domain controllers and global catalog servers to handle authentication, but the client access, hub transport, and mailbox servers are thousands of miles away in another country.

Cloud-Only Deployments

A completely cloud-based deployment involves your organization’s Exchange server being hosted online, most likely through Exchange Online, which is a part of Microsoft Office 365. Cloud-only deployments have the following characteristics:

• The cloud-based Exchange deployment is completely separate from any local on-premises messaging system.

• Users need separate credentials to authenticate and access their cloud-hosted mailboxes.

• The local Active Directory infrastructure does not synchronize with the cloud-based deployments. User mailboxes and distribution groups are administered independently of any local on-premises mailbox and distribution groups.

Cloud-only deployments are often used for new organizations or organizations that want to move from a third-party mail system to a cloud-based Exchange mail system.

Coexistence

Coexistence deployments involve both an on-premises Exchange deployment and a cloud-hosted Exchange deployment. Coexistence is generally used when an organization wants to transition from an existing Exchange Server 2003 or Exchange Server 2007 deployment to an entirely cloud-hosted Exchange 2010 deployment, though it is possible to configure coexistence between a local Exchange 2010 deployment and a cloud-hosted Exchange 2010 deployment as well.

When you deploy Exchange in a coexistence configuration, you need to deploy an on-premises coexistence server. A coexistence server is a computer running Exchange Server 2010 that you configure with the necessary Exchange Server 2010 roles that allow it to manage communication between the on-premises Exchange deployment and the cloud-based deployment. You also need to configure a directory synchronization server. This server synchronizes account information between the local and hosted Exchange deployments.

Hosted Exchange 2010 supports two types of coexistence. The difference between these is as follows:

• Simple coexistence Provides a unified Global Address List (GAL) and mail routing between the local and hosted Exchange organization.

• Rich coexistence Provides a unified GAL, mail routing, sharing availability information, and the ability to move mailboxes between the local and hosted Exchange organization. Rich coexistence requires that you configure a federation trust with the Microsoft Federation Gateway.

Planning Exchange DNS Support

Although it is possible to use Active Directory and Exchange with a third-party DNS solution such as BIND, doing so requires substantial administrative overhead. Microsoft recommends that you use Active Directory–integrated DNS zones to support your internal Active Directory and Exchange name resolution requirements. You should configure Active Directory–integrated zones to accept secure dynamic updates only, you should enable scavenging, and you should configure DNS zones to replicate to all domain controllers in the forest. Configuring DNS in this way ensures that internal DNS is updated appropriately when you introduce new servers hosting Exchange Server 2010 roles into your Active Directory environment.

Many organizations split the hosting of their externally resolvable DNS hosts from their internal DNS. For example, an organization might use the contoso.com Active Directory Integrated DNS zone to support the contoso.com forest. The problem is that while it will be fine for external clients to resolve hostnames like www.contoso.com and smtp.contoso.com, most organizations would not want internal host names such as SYD-FS1.contoso.com and SYD-EX1.contoso.com to be resolvable by hosts on the Internet.

You can deal with the problem by configuring DNS delegation to point to an externally hosted DNS zone that only holds records that you want available to hosts on the Internet, such as the host and MX records that point to your organization’s SMTP server. A separate internal DNS infrastructure holds all records that should be accessible to internal hosts.

Rather than having the same zone hosted in two different locations, another option is to configure a split DNS namespace, where your organization’s internal DNS domain name is a delegated sub-domain of the external DNS namespace. For example, the external DNS namespace might be adatum.com and the internal DNS namespace be configured as corp.adatum.com. When taking this approach it is necessary to ensure that you configure the root domain as an accepted domain, so that recipients can receive email using the root domain as their mail domain. For example, being able to accept email @adatum.com rather than only at @corp.adatum.com.

Common Shared Namespace

Some organizations use multiple mail systems, but only have a single address space. For example, an email message sent to kim.akers@contoso.com might need to be routed to an Exchange Server 2010 mailbox, whereas an email message to sam.abolrous@contoso.com might need to be routed to a mailbox hosted on a third-party messaging system. You can solve this design challenge within Exchange by configuring what is known as an internal relay domain and then creating a send connector to route email to the shared domain.

Disjointed Namespace

A disjointed namespace exists when the primary DNS suffix of a computer does not match the DNS domain name of the domain of which the computer is a member. Microsoft supports three different scenarios for deploying Exchange in an environment where there is a disjointed namespace:

• The primary DNS suffix of all domain controllers differs from the DNS domain name. Computers that are members of this domain may or may not be disjointed. In this situation, you can have Exchange servers that use either the primary DNS suffix or the DNS domain name.

• One or more member computers in the domain have primary DNS suffixes that differ from the DNS domain name even though all domain controllers are not disjointed. In this situation, you can have Exchange servers that use either the primary DNS suffix or the DNS domain name.

• The NetBIOS name of domain controllers differs from the subdomain of the DNS domain name of those domain controllers. For example, the NetBIOS name might be SOUTHPACIFIC, but the primary DNS suffix and the DNS domain name might be contoso.com.

For servers running Exchange Server 2010 to have access to domain controllers in environments that have a disjointed namespace, it is necessary to modify the msDS-AllowedDNSSuffixes Active Directory attribute on the domain object container so that it includes both the DNS domain name and the primary DNS suffix, as shown in Figure 1-1.

Figure 1-1 msDS-AllowedDNSSuffixes

You also need to ensure that the DNS suffix search list for computers includes all DNS namespaces used within your organization. This can be done by configuring the DNS Suffix Search List group policy item, located in the Computer Configuration\Policies\Administrative Templates\Network\DNS Client node.

To view the primary DNS suffix and DNS domain name of a computer running Windows Server 2008 or Windows Server 2008 R2, click the Computer Name tab of the System Properties dialog box, as shown in Figure 1-2. In the figure the namespace is disjointed as the primary DNS suffix is adatum.internal where the domain name is adatum.com.

Figure 1-2 Disjointed namespace

Service Level Agreement Considerations

A Service Level Agreement (SLA) is an arrangement between the IT service provider and an organization that specifies measurable infrastructure performance levels. Although SLAs vary from organization to organization, they most commonly include goals related to the following service characteristics:

• Availability A way of defining how reliable the service is in terms of the amount of time the service may be unavailable in a given period. For example, an SLA might specify that Exchange has an allowable downtime for planned maintenance and unplanned faults for a total of five hours a month.

• Performance A way of defining minimum performance characteristics of the infrastructure. For example, an SLA might specify a maximum number of concurrent connections to a mailbox server. Performance may influence your design with relation to the hardware specifications of servers hosting Exchange.

• Recovery This is a way of defining how quickly data or services can be recovered in the event of an outage. For example, an SLA might specify a maximum recovery time for deleted mailbox items. Recovery objectives influence the data protection technologies that you include in your Exchange design.

You must explicitly define each performance characteristic in the SLA. For example, you might be designing an Exchange deployment for an organization that has a head office and two branch offices. The branch offices are so small that you decide not to deploy Exchange at those sites, but instead have users connect to Exchange servers located at the head office site. If the site link between the head office and one of the branch office sites fails, blocking access to Exchange for the users at that branch office site, but all other users in the organization are able to access the centrally located Exchange servers, how will that outage be measured by the terms of the SLA?

Internal SLAs are arrangements between an organization’s IT department and business units within the organization. In most organizations, internal SLAs tend to be less formal and the performance metrics less explicitly defined. External SLAs are contracts created between the organization and a third-party provider, such as a cloud service provider. External SLAs tend to be a lot more complicated and are generally legally binding contracts including cost, bonus, and penalty clauses. External SLAs are increasingly important for organizations that use a hybrid approach to their Exchange deployment, with some services hosted internally and other services hosted in the public cloud.

When you have an SLA in place, you will need to regularly attend to certain ongoing tasks, including:

• Service catalog maintenance A service catalog defines the services provided to the organization. It provides detailed descriptions of the service components and the IT functionality utilized by the business. You need to ensure that this is both comprehensive and up to date.

• Service level monitoring It is important to have a monitoring solution in place that verifies that the IT service provider is complying with the conditions of the SLA. Products such as System Center Operations Manager 2012 are designed to monitor Exchange Server 2010 deployments.

• Service level reporting You should regularly generate and distribute reports. These reports should describe metrics related to the performance levels specified in the SLA. SLA objectives must be specific and measurable. If you cannot measure an SLA objective, it is impossible to impartially determine whether that objective has been met. Having an SLA objective that is open to interpretation can lead to disagreements between the IT department and the organization as to whether the objective has been met.

• SLA review Plan to review the SLA periodically with all involved stakeholders. Use these reviews to determine whether you should modify the SLA to better meet the needs of the organization.

You should have an SLA in place before you complete the Exchange design process. Knowing what goals you need to meet allows you to ensure that your Exchange design suits the needs of your organization. For example, you might meet availability requirements by deploying multiple hub transport servers at each site, using Database Availability Groups and Client Access Server arrays. The terms of the SLA also impact the cost of the deployment. It is important to ensure that the terms of the SLA are realistic given the budgets involved. You can’t realistically provide highly available redundant Exchange servers if your budget only allows you to deploy a single computer running Exchange at one central site.

Active Directory and Network Topology

Exchange Server 2010 generates its network topology information by querying Active Directory for site information. Each Active Directory site is defined as a collection of IPv4 or IPv6 networks. Usually that collection is a single local high-speed network. Most organizations have configured Active Directory so that each physical location is its own distinct Active Directory site. For example, you might have one site that represents a branch office at Sydney and another site that represents a branch office in Melbourne. As Active Directory does not automatically create additional sites, you may occasionally encounter organizations where Active Directory hasn’t been properly maintained and there is only one site even though the organization itself is spread across multiple branch offices.

By using the Active Directory site topology, Exchange can determine how to transport messages and which global catalog servers and domain controllers should be used for processing Active Directory queries. When deploying Exchange, you don’t need to worry about configuring routing topologies—this is all handled by using the Active Directory site topology. The only exception to this is if you are introducing Exchange 2010 into an environment that has Exchange 2003.

When considering your Exchange design, you should ensure that your organization’s Active Directory site configuration is appropriate and reflects the realities of your organization’s network infrastructure. At a minimum this means ensuring that IP networks at each branch office site are associated with and appropriate site within Active Directory. You associate IP networks with Active Directory sites by using the Active Directory Sites and Services console.

Multiple Domains

Exchange is designed to be deployed and used in multiple domains across a single forest. A single Exchange organization can span a forest that has a single or multiple domain trees. That means that you can have one Exchange organization supporting domains with different names, such as wingtiptoys.com and tailspintoys.com, as long as those domains are a part of the same Active Directory forest.

If you do have multiple domain trees in your forest, you might want to configure Exchange to accept email for more than one authoritative domain. That means that you can design a single Exchange organization so that it will be able to receive and process email for separate mail domains representing different trees in the same forest, such as wingtiptoys.com and tailspintoys.com, as long as Exchange has been properly configured. You configure accepted domains on transport servers. You will learn more about configuring accepted domains in Chapter 2.

Multiple Forests

Some organizations have more than one Active Directory forest, with trust relationships configured between forests to allow users who have accounts in one forest to access resources in another forest. As you are aware, a single Exchange Server 2010 organization can only span a single forest. If your organization has more than one forest, you will need to use one of the supported multiple forest topologies when you create your deployment design. Exchange Server 2010 supports the following multiple forest topologies:

• Cross-forest The cross-forest topology involves multiple Active Directory forests with an Exchange Server 2010 organization in each forest. When designing an Exchange deployment to support a cross-forest topology you need to configure recipient synchronization so that the GAL in each forest holds information for recipients in all forests. You also need to configure the Availability service so that users in each forest are able to view availability information for users in all of your organization’s other forests.

• Resource-forest The resource-forest topology involves one Active Directory forest that has Exchange deployed and other Active Directory forests that host user accounts. In the resource-forest model, the forest that hosts Exchange often does not host user accounts and the accounts which have Exchange mailboxes are disabled. At least one forest that does not have an Exchange organization must host user accounts. Disabled user accounts in the forest that hosts Exchange are associated with user accounts in the account forest.

Microsoft recommends that you use a product such as Forefront Identity Lifecycle Manager (ILM) 2010 to ensure that the GAL in each forest in a cross-forest Exchange topology contains all the mail recipients from other forests. Enabling GAL synchronization requires that you create management agents that import mail-enabled groups, contacts, and users into a centralized metadirectory where they are represented as mail users. The management agents then synchronize these mail users to a specially configured OU in each target forest.

Directory Synchronization with the Cloud

Active Directory synchronization allows you to configure an ongoing relationship between your organization’s Active Directory infrastructure and a cloud service provider such as Office 365. Microsoft recommends that you configure single sign-on prior to setting up directory synchronization. Single sign-on allows a user to log on to cloud service providers, such as Office 365, using their organizational credentials. If single sign-on is not configured, it will be necessary to add and verify your organization’s domains, and local password changes will not be synchronized with the hosted Exchange organization.

To configure your organization to support single sign-on, you need to take the following general steps:

1. Ensure that your organization’s forest functional level is set to Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2.

2. Ensure that the domain that you will be federating can be resolved by hosts on the Internet.

3. Configure User Principle Names (UPNs) for all users. UPNs used for single sign-on can only contain letters, numbers, periods, dashes, and underscore characters. The UPN domain suffix must be a publicly registered domain. Microsoft recommends using a user’s email domain as her account’s UPN suffix.

4. Deploy Active Directory Federation Services (AD FS) 2.0. AD FS is required to support single sign-on to cloud service providers such as Office 365. Microsoft recommends deploying two federation services in a load balanced configuration. Federation server proxies will be required if you want to support roaming clients or smartphone access to hosted Exchange.

   More Info: Deploy AD FS to Support Hosted Exchange

   To learn more about deploying AD FS to support Hosted Exchange, consult the following article: http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652539.aspx.

5. Install and configure the Microsoft Online Services Module for Windows PowerShell for Single Sign On. This module requires a host running Windows 7 or Windows Server 2008 R2 with the Microsoft .NET Framework 3.51 feature enabled.

6. Each domain that you want to synchronize with the cloud service provider must be added as a single sign-on domain or converted to become a single sign-on domain. To perform this conversion you use the Connect-MsolService, Set-MsolAdfscontext, and Convert-MsolDomainToFederated cmdlets.

Once you have configured single sign-on, you will need to designate a computer as your organization’s directory synchronization computer. This computer can be a virtual machine, but it must meet the following criteria:

• The synchronization computer must be a member of the Active Directory forest that will host the Exchange organization.

• The synchronization computer cannot be a domain controller.

• The synchronization computer must have the .NET Framework 3.5 or later installed.

• The computer must run a 32-bit version of the Windows Server 2003, Windows Server 2003 R2, or Windows Server 2008 operating systems. At present the directory synchronization tool cannot be installed on a computer running Windows Server 2008 R2 because 64-bit environments are not supported.

You will also need to configure an Exchange Server 2010 coexistence server to support the coexistence scenario.

Exchange Federation

Exchange federation allows people in your organization to configure your Exchange infrastructure so that contact information and calendar availability can be shared with external recipients, vendors, and partners. If you want to configure Exchange federation, you need to set up a one-time federation trust between your organization and the Microsoft Federation Gateway. The Microsoft Federation Gateway is a cloud-based service that functions as a trust broker between a locally hosted Exchange 2010 organization and other organizations that have configured Exchange federation.

When creating a federation trust between your organization and the Microsoft Federation gateway, you need to either create a self-signed certificate or install an X.509 certificate signed by a trusted CA on the Exchange 2010 server that you will use to create the trust. Microsoft recommends using a self-signed certificate, which the New Federation Trust Wizard will automatically create and install, vastly simplifying this process.

After you have configured this trust relationship, the Microsoft Federation Gateway will issue Active Directory authenticated users in the local forest special Security Assertion Markup Language (SAML) delegation tokens. SAML delegation tokens allow organizations that have configured Exchange federation to trust users from other organizations that have configured Exchange federation. Instead of having to create each inter-organizational trust relationship separately, each organization configures a single trust with the Microsoft Federation Gateway, enabling them to share availability information with other organizations that have a trust with the Microsoft Federation Gateway.

When you establish a federation trust between your organization and the Microsoft Federation Gateway, an application identifier (AppID) is generated that will be used by the Federation Gateway to uniquely identify your Exchange organization. You use the AppID in conjunction with a text (TXT) record in DNS to prove that your organization is associated with the domain that is used with the Microsoft Federation Gateway. It is necessary to create a TXT record in the DNS zone for each federated domain in your organization.

You define which authoritative accepted domains in your organization are enabled for federation through the federated organization identifier (OrgID). Only those recipients that have email addresses associated with the OrgID will be able to use federated delegation features by the Microsoft Federation Gateway. Federation delegation uses a domain namespace for the OrgID that differs from the primary SMTP domain. This domain namespace should not be used for mailboxes, and Microsoft recommends that the namespace be called exchangedelegation. This subdomain works as the federated namespace for the Microsoft Federation Gateway, allowing it to manage unique identifiers for those recipients that need SAML delegation tokens. If you want to enable or disable all federation features for your Exchange organization, you can either enable or disable the OrgID.

Exchange Pre-Deployment Analyzer

The Exchange Pre-Deployment Analyzer is a tool that allows you to perform a readiness scan of your organization’s environment to determine what modifications need to be made prior to the deployment of Exchange Server 2010. This tool will also perform a deep analysis of an existing Exchange 2003 and Exchange 2007 organization to determine whether the configuration will support an in-place upgrade to Exchange 2010. The end report includes critical and warning notifications. A critical notification is one that will block Exchange Server 2010 from being deployed and includes items such as the forest not running in Windows Server 2003 functional mode or higher. A warning notification indicates that some Exchange Server 2010 functionality may not be present if a deployment is performed given the current conditions.

Exchange Deployment Assistant

The Exchange Deployment Assistant, also known as ExDeploy and shown in Figure 1-3, is a web-based tool that you can use in the early stages of planning an Exchange Server 2010 deployment. ExDeploy works by asking a series of questions about your organization’s current environment. Based on these questions, ExDeploy generates advice and a custom checklist to assist you with that deployment. Links are provided to relevant TechNet documentation and the output of ExDeploy can be saved for later review.

ExDeploy can provide you with a checklist and advice in the following scenarios:

• Locally hosted on-premise deployments:

  • Upgrade from Exchange Server 2003

  • Upgrade from Exchange Server 2007

  • Upgrade from mixed Exchange 2003 and Exchange 2007 environment

  • New Exchange Server 2010 deployment

• Coexistence of locally hosted on-premise and cloud:

  • Exchange 2003

  • Exchange 2007

  • Exchange 2010

  • Cloud-only deployments

Figure 1-3 Exchange Deployment Assistant

Objective Summary

• Exchange Server 2010 can be installed in an on-premise, cloud, or a coexistence configuration.

• The Active Directory Sites and Services console allows you to associate specific IP networks with specific Active Directory sites.

• SLA requirements determine parts of your Exchange design, primarily around high-availability features such as Database Availability Groups and Client Access Server Arrays.

• In multiple-forest environments, the resource-forest topology has Exchange deployed in one forest and accessed by users in other forests. The cross-forest topology has Exchange deployed in all forest and uses Forefront Identity Life Cycle Manager for GAL synchronization.

• Exchange Federation allows people in your organization to share contact and calendar availability information. Federation requires setting up a one-time federation trust between your organization and the Microsoft Federation Gateway.

• The Exchange Deployment Assistant (ExDeploy) is an online tool that provides advice and checklists to assist with planning an Exchange deployment based on answers to a set of questions about the current and intended environments.

Objective Review

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

1. You are in the process of planning an Exchange Server 2010 installation. Which console should you use on a Windows Server 2008 R2 domain controller to verify that branch office network subnets are associated correctly with branch office sites in Active Directory?

   1. Active Directory Administrative Center

   2. Active Directory Users and Computers

   3. Active Directory Domains and Trusts

   4. Active Directory Sites and Services

2. Your organization has a single domain forest. The DNS domain name of the domain is contoso.com. The primary DNS suffix of all domain controllers is contoso.com, but the primary DNS suffix of all member servers—including the servers on which you intend to deploy Exchange Server 2010—is contoso.internal. Which of the following steps must you take to ensure that Exchange Server 2010 will function properly when deployed in this environment? (Choose all that apply.)

   1. Set the msDS-AllowedDNSSuffixes Active Directory attribute so that it only includes contoso.internal.

   2. Modify the msDS-AllowedDNSSuffixes Active Directory attribute on the domain object container so that it includes both contoso.com and contoso.internal.

   3. Configure the DNS suffix search list group policy item so that it includes both contoso.com and contoso.internal.

   4. Configure the DNS suffix search list group policy item so that it only includes contoso.internal.

3. You are in the process of consulting on an Exchange design for two companies. The first, Tailspin Toys, has a three-forest Active Directory infrastructure. The second company, Wingtip Toys, has a two-forest Active Directory infrastructure. You are in the process of determining which multiple-forest topology would suit each company. Tailspin Toys would be best suited by deploying Exchange in each forest. Wingtip Toys would be best suited by deploying Exchange in one forest and keeping user accounts in the other forest. Which of the following Exchange multiple-forest topology models best suits each organization? (Choose all that apply.)

   1. Tailspin Toys should use the cross-forest topology.

   2. Tailspin Toys should use the resource-forest topology.

   3. Wingtip Toys should use the cross-forest topology.

   4. Wingtip Toys should use the resource-forest topology.

4. You are interested in measuring service availability as a part of monitoring compliance with a Service Level Agreement (SLA). Which of the following products could you use to monitor service availability, configuring alerts to be sent in the event that any component in the Exchange infrastructure fails?

   1. System Center Configuration Manager 2012

   2. System Center Data Protection Manager 2012

   3. System Center Virtual Machine Manager 2012

   4. System Center Operations Manager 2012

5. Which of the following products can you use to assist with global address list (GAL) synchronization if your organization is intending to deploy Exchange Server 2010 in a cross-forest topology?

   1. Forefront Threat Management Gateway 2010

   2. Forefront Endpoint Protection 2012

   3. Forefront Identity Life Cycle Manager 2010

   4. Forefront Unified Access Gateway 2010