10135b-enu-handbook.pdf

O F F I C I A L M I C R O S O F T L E A R N I N G P R O D U C T

10135B Configuring, Managing and Troubleshooting Microsoft Exchange Server 2010 Service Pack 2

1-1

Module 1 Deploying Microsoft Exchange Server 2010

Contents: Lesson 1: Overview of Exchange Server 2010 Requirements 1-3

Lesson 2: Installing Exchange Server 2010 Server Roles 1-18

Lab A: Installing Exchange Server 2010 1-38

Lesson 3: Completing an Exchange Server 2010 Installation 1-42

Lab B: Verifying an Exchange Server 2010 Installation 1-51

1-2 Deploying Microsoft Exchange Server 2010

Module Overview

This module describes how to prepare for, and perform, an installation of Microsoft Exchange Server 2010. The most important task in preparing for an Exchange Server 2010 installation is to ensure that the Active Directory Domain Services (AD DS) environment is ready. Exchange Server 2010 requires an Active Directory deployment because AD DS stores all configuration and recipient information that Exchange Server uses.

This module also provides details on the Exchange Server 2010 deployment. To install Exchange Server 2010 properly for your environment, you must be aware of the server roles that Exchange Server can install. Additionally, you should be aware of the infrastructure, hardware, and software requirements for introducing Exchange Server 2010 into a messaging environment. Finally, you should know how to verify, troubleshoot, and secure the installation.

After completing this module, you will be able to:

Describe the infrastructure requirements to install Exchange Server 2010.

Install Exchange Server 2010 server roles.

Complete an Exchange Server 2010 installation.

10135B: Configuring, Managing, and Troubleshooting Microsoft Exchange Server 2010 Service Pack 2 1-3

Lesson 1 Overview of Exchange Server 2010 Requirements

In this lesson, you will review the requirements for installing Exchange Server 2010. The most important requirement is the Active Directory deployment, but you also must ensure that you implement the appropriate Domain Name System (DNS) infrastructure. You also should be aware of the Exchange Server 2010 infrastructure requirements when you perform an installation, and when you need to troubleshoot deployment issues.

After completing this lesson, you will be able to:

Describe the Active Directory components.

Describe the Active Directory partitions.

Describe how Exchange Server 2010 uses AD DS.

Describe the DNS requirements for Exchange Server 2010.

Prepare AD DS for Exchange Server 2010.

Describe the integration of AD DS and Exchange Server 2010.


Reviewing Active Directory Components

AD DS consists of several components. Since Exchange Server deeply integrates with AD DS, it is important to understand the purpose of each of the following AD DS components:

Domains. An Active Directory domain is a collection of computers that a Microsoft Windows network administrator defines. These computers share a common directory database, security policies, and security relationships with other domains. An Active Directory domain provides access to the centralized user and group accounts that the domain administrator maintains. You can organize computer and user accounts within AD DS into a hierarchy based on organizational units (OUs).

Forests. A forest is a set of one or more domains that share common configuration and schema information. A tree is set of domains that share the same Domain Name System (DNS) namespace. When multiple domains exist in a forest, there is an automatic trust relationship between the domains, which enables users in one domain to access resources in another domain. There can be only one Exchange Server organization per forest. An Active Directory forest is a security boundary. By default, no security accounts outside of a forest have any access in the forest.

Trusts. Trusts enable users from a trusted domain to authenticate in another trusting domain. In a forest, all domains have trusts (either direct trusts or transitive trusts) with all other domains in the forest.

Domain controllers and global catalog servers. A domain controller holds a copy of the local domain database, which includes user accounts and computer accounts. It also is responsible for authenticating users and computers. Additionally, domain controllers respond to queries for information in AD DS. A domain controller has directory information only for the domain of which it is a member; it does not have information about users in other domains. A global catalog server is a domain controller that also holds a subset of information from other domains in the forest. For example, a global catalog server has limited information about all users in a forest.


Active Directory sites. Active Directory sites are defined as one or more IP subnets. Typically, all of the IP subnets in a given physical location are part of the same site. Sites do not typically encompass more than one physical location. All of the computers within a single site must have a fast network connection, which is usually 10 megabits per second (Mbps) or more, between them.

Active Directory replication. AD DS replicates information between domain controllers. It replicates domain information between domain controllers in the same domain and to global catalog servers in the forest. AD DS also replicates configuration data and the schema between all domain controllers in the same forest. Within an Active Directory site, replication of changes starts within a few seconds of the change being made on one domain controller. Between Active Directory sites, replication can be scheduled, and happens every three hours by default. Also, all replication traffic between sites is sent through a bridgehead server in each site.


Discussion: Reviewing Active Directory Implementations

AD DS is the integrated, distributed directory service that is included with the Windows Server 2008 R2, Windows Server 2008, Windows Server 2003, and Windows 2000 Server operating systems. Many applications, such as Exchange Server 2010, integrate with AD DS. This creates a link between user accounts and applications, which enables single sign-on for applications. Additionally, the Active Directory replication capabilities enable distributed applications to replicate application-configuration data.

Discussion Questions Based on your experience, consider the following questions:

Question: Under what circumstances would an organization deploy multiple domains in the same forest?

Question: Under what circumstances might an organization deploy multiple forests?

Question: What type of information do domains in a forest share?


Reviewing Active Directory Partitions

Active Directory information falls into four types of partitions: domain, configuration, schema, and application. These directory partitions are the replication units in AD DS.

Domain Partition A domain partition contains all objects in the domains directory. Domain objects replicate to every domain controller in that domain, and include user and computer accounts, and groups.

A subset of the domain partition replicates to all domain controllers in the forest that are global catalog servers. If you configure a domain controller as a global catalog server, it holds a complete copy of its own domains objects and a subset of attributes for every domains objects in the forest.

Configuration Partition The configuration partition contains configuration information for AD DS and applications, including Active Directory site and site link information. Additionally, some distributed applications and services store information in the configuration partition. This information replicates through the entire forest so each domain controller has a replica of the configuration partition.

When application developers choose to store application information in the configuration partition, the developers do not need to create their own mechanism to replicate the information. The configuration partition stores each type of configuration information in separate containers. A container is an Active Directory object similar to an OU that you use to organize other objects.

Schema Partition The schema partition contains definition information for all object types and their attributes that you can create in AD DS. This data is common to all domains in the forest, and AD DS replicates it to all domain controllers in the forest. However, only one domain controller maintains a writable copy of the schema. By default, this domain controller, known as the Schema Master, is the first domain controller installed in an Active Directory forest.


Application Partitions

An administrator or an application during installation creates application partitions manually. Application partitions hold specific application data that the application requires. The main benefit of application partitions is replication flexibility. You can specify the domain controllers that hold a replica of an application partition, and these domain controllers can include a subset of domain controllers throughout the forest. Exchange Server 2010 does not use application partitions to store information.


How Exchange Server 2010 Uses AD DS

To ensure proper placement of Active Directory components in relation to computers that are running Exchange Server, you must understand how Exchange Server 2010 communicates with AD DS and uses Active Directory information to function.

AD DS stores most Exchange Server 2010 configuration information.

Note The Exchange Server 2010 Edge Transport server role is the only Exchange Server role that does not use AD DS to store configuration information. Instead, the Edge Transport server role uses Active Directory Lightweight Directory Services (AD LDS) for this purpose. For more details, see Module 6, Implementing Messaging Security.

Forests

An Exchange Server organization and an Active Directory forest have a one-to-one relationship. You cannot have an Exchange Server organization that spans multiple Active Directory forests. You also cannot have multiple Exchange Server organizations within a single Active Directory forest.

Note In Exchange Server 2010, you can add multiple Exchange Server organizations in different forests to the Exchange Management Console. This enables you to manage multiple organizations from a single management console, but does not enable the integration of the two Exchange Server organizations.


Schema Partition

The Exchange Server 2010 installation process modifies the schema partition to enable the creation of Exchange Server-specific objects. The installation process also adds Exchange Server-specific attributes to existing objects.

For example, the installation process updates user objects with additional attributes to describe storage quotas and mailbox features.

Configuration Partition

The configuration partition stores configuration information for the Exchange Server 2010 organization. Because AD DS replicates the configuration partition among all domain controllers in the forest, configuration of the Exchange Server 2010 organization replicates throughout the forest.

The configuration partition includes Exchange Server configuration objects, such as global settings, email address policies, transport rules, and address lists.

Domain Partition

The domain partition holds information about recipient objects. This includes mailbox-enabled users, and mail-enabled users, groups, and contacts. Objects that are mailbox-enabled or mail-enabled have preconfigured attributes, such as email addresses.

Global Catalog When you install Exchange Server 2010, the email attributes for mail-enabled and mailbox-enabled objects replicate to the global catalog. The following is true:

The global address list is generated from the recipients list in an Active Directory forests global catalog.

Exchange Hub Transport servers access the global catalog to find the location of a recipient mailbox when delivering messages.

Exchange Client Access servers access the global catalog server to locate the user Mailbox server and to display the global address list to Microsoft Office Outlook, Microsoft Outlook Web App, or Exchange ActiveSync clients.

Note Because of the importance of the global catalog in an Exchange Server organization, you must deploy at least one global catalog serverin each Active Directory site that contains an Exchange 2010 server. You must deploy enough global catalog servers to ensure adequate performance.

Note Windows Server 2008 provides a new type of domain controllera read-only domain controller (RODC). Exchange Server 2010 does not use RODCs or RODCs that you configure as global catalog servers (ROGC). This means that you should not deploy an Exchange 2010 server in any site that contains only RODCs or ROGCs.


Reviewing DNS Requirements for Exchange Server 2010

Each computer that is running Exchange Server must use DNS to locate AD DS and global catalog servers. As a site-aware application, Exchange Server 2010 prefers to communicate with directory servers that are located in the same site as the computer that is running Exchange Server.

Role of DNS

Exchange Server services use DNS to locate a valid domain controller or global catalog. By default, each time a domain controller starts the Netlogon service, it updates DNS with service (SRV) records that describe it as a domain controller and global catalog server, if applicable.

To ensure that the domain controller updates DNS records properly, it is essential that all domain controllers use an internal DNS server that supports dynamic updates. After DNS records are registered, computers that are running Exchange Server can use DNS to find domain controllers and global catalog servers.

SRV Resource Records SRV resource records are DNS records. These records identify servers that provide specific services on the network. For example, an SRV resource record can contain information to help clients locate a domain controller in a specific domain or site.

All SRV resource records use a standard format, which consists of several fields. These fields contain information that AD DS uses to map a service back to the computer that provides the service.

SRV resource records use the following format:

_Service_.Protocol.Name Ttl Class SRV Priority Weight Port Target


The following table describes each field in an SRV resource record.

Field Description

_Service Specifies the name of the service, such as Lightweight DirectoryAccess Protocol (LDAP) or Kerberos, provided by the server that registers this SRV resource record.

_Protocol Specifies the transport protocol type, such as transmission control protocol(TCP) or User Datagram Protocol (UDP).

Name Specifies the domain name that the resource record references.

Ttl Specifies the Time to Live (TTL) value in seconds, which is a standard field in DNS resource records that specifies the length of time that a record is valid.

Class Specifies the standard class value for the DNS resource record, which usually is.IN, for the Internet system. This is the only class that Windows Server 2008 DNS supports.

Priority Specifies the servers priority. Clients attempt to contact the host that has the lowest priority.

Weight Denotes a load-balancing mechanism that clients use when selecting a target host. When the priority field is the same for two or more records in the same domain, clients randomly choose SRV resource records that have higher weights.

Port Specifies the port where the server is listening for this service.

Target Specifies the fully qualified domain name (FQDN) (also called the full computer name), of the computer that provides the service.

The SRV records for domain controllers and global catalog servers are registered with several different variations to allow locating domain controllers and global catalog servers in several different ways. One option is to register DNS records by site name, which enables computers that are running Exchange Server to find domain controllers and global catalog servers in the local Active Directory site. Exchange Server always performs DNS resource queries for the local Active Directory site first.

When a computer that is running Exchange Server is a member server, Exchange Server configures it dynamically with its site each time it authenticates to AD DS. As part of the authentication process, the registry stores the site name. When the Exchange server queries DNS for domain controller or global catalog server records, the Exchange server always attempts to connect to domain controllers with the same site attribute as the Exchange server.

Host Records

Host records provide a host name to IP address mapping. Host records are required for each domain controller and other hosts that need to be accessible to Exchange Servers or client computers. Host records can use IPv4 (A records) or IPv6 (AAAA records).


MX Records

A Mail Exchanger (MX) record is a resource record that allows servers to locate other servers to deliver Internet email by using the Simple Mail Transfer Protocol (SMTP). An MX record identifies the SMTP server that will accept inbound messages for a specific DNS domain. Each MX record contains a host name and a preference value. When you deploy multiple SMTP servers that are accessible from the Internet, you can assign equal preference values to each MX record to enable load balancing between the SMTP servers. You also can specify a lower preference value for one of the MX records. All messages are routed through the SMTP server that has the lower preference-value MX record, unless that server is not available.

Note In addition to SRV, Host, and MX records, you also may need to configure Sender Policy Framework (SPF) records to support Sender ID spam filtering. Module 6 provides more information on SPF records. Additionally, some organizations use reverse lookups as an option for spam filtering, so you should consider adding reverse lookup records for all SMTP servers that send your organizations email.


Preparing AD DS for Exchange Server 2010

To install Exchange Server 2010, you need to run the Exchange Server 2010 setup command for preparing the Active Directory forest for the installation. You can use the setup command with the following switches.

Setup switch Explanation

/PrepareAD /OrganizationName: organizationname

Prepares the global Exchange Server objects in Active Directory, creates the Exchange Universal Security Groups in the root domain, and prepares the current domain

Must be run by a member of the Enterprise Admins group

/PrepareLegacy ExchangePermissions

Necessary if the organization contains Exchange Server 2003 servers Modifies the permissions assigned to the Enterprise Exchange Servers

group to allow the Recipient Update Service to run

Must be run by a member of the Enterprise Admins group

/PrepareSchema Prepares the schema for the Exchange Server 2010 installation Must be run by a member of the Enterprise Admins and Schema

Admins groups

/PrepareDomain

/PrepareDomain domainname

/PrepareAllDomains

Prepares the domain for Exchange Server 2010 by creating a new global group in the Microsoft Exchange System Objects container called Exchange Install Domain Servers

Not required in the domain where /PrepareAD is run Can prepare specific domains by adding the domains fully qualified

domain name (FQDN), or prepare all domains in the forest

Must be run by a member of the Enterprise Admins and Domain Admins groups


Note You must prepare the Active Directory forest in the same domain and the same site as the domain controller that hosts the Schema Master role.

Options for Preparing Active Directory

You have the following options when you prepare AD DS for Exchange Server 2010:

In an organization that is not running an earlier Exchange Server version, and which has a single domain in the Active Directory forest, you do not need to prepare AD DS before installing the first Exchange server. In this scenario, you can just install Exchange Server 2010, and all of the Active Directory schema changes are implemented during the install.

If the user account that you are using to update the schema is a member of the Schema Admins and the Enterprise Admins group, you do not need to run /PrepareLegacyExchangePermissions and /PrepareSchema before running /PrepareAD. If your account has the right permissions, the /PrepareAD process also configures the legacy permissions and makes the required schema changes.

Functions Performed by /PrepareAD

Running Setup with the /PrepareAD parameter performs the following actions:

Prepares the schema if /PrepareSchema has not been run, and the command is run by a Schema Admins group member.

Prepares the permissions if /PrepareLegacyExchangePermissions has not been run, and the command is run by an Enterprise Admins group member.

Creates the Microsoft Exchange container in the Configuration partition in Active Directory, and populates the container with all the child containers required to install Exchange Server 2010 computers.

Creates a new OU in the Active Directory domain named Microsoft Exchange Security Groups, and then creates the security groups that are used to assign permissions in the Exchange organization.

Note The security groups that are created in the Microsoft Exchange Security Groups OU are management role groups that use role-based access control (RBAC) to assign permissions in the Exchange organization. Module 9, Securing Exchange Server 2010 details these groups and RBAC.


Demonstration: Integration of AD DS and Exchange Server 2010

In this demonstration, you will review the integration of AD DS and Exchange Server 2010.

Demonstration Steps

1. On a domain controller, open Active Directory Users and Computers.

2. In the Active Directory domain, expand the Microsoft Exchange Security Groups organizational unit.

3. Review the description and membership of the following Active Directory groups:

Organization Management

Recipient Management

View-Only Organization Management

Discovery Management

4. Open ADSI Edit, and connect to the domain partition. Review the information in the domain partition.

5. Connect to the configuration partition. Review the information in the configuration partition, and in the CN=Services, CN=Microsoft Exchange, CN=Exchangeorganizationname container.

6. Connect to the schema partition. Review the information in the schema partition, and point out the attributes and class objects that begin with ms-Exch.


Question: How do you assign permissions in your Exchange organization? How will you assign permissions by using the Exchange security groups?

Question: Which Active Directory partition would you expect to contain the following information?

Users email address

Exchange connector for sending email to the Internet

Exchange Server configuration


Lesson 2 Installing Exchange Server 2010 Server Roles

Before you install Exchange Server 2010, you need to understand the concept of Exchange Server 2010 server roles. Each server role provides a specific set of functionality that an Exchange Server organization requires.

When you install Exchange Server 2010, you can install all server roles on the same computer, except for the Edge Transport server role. Alternately, you can distribute the roles across multiple computers. After you decide which server role to deploy in each Exchange server, you must ensure that the network infrastructure and servers are ready for the Exchange Server 2010 installation.


Describe the server roles included in Exchange Server 2010.

Describe the options for deploying Exchange Server 2010.

Describe the hardware recommendations for combining server roles in Exchange Server 2010.

Describe the options for integrating Exchange Server 2010 and Exchange Online Services in Microsoft Office 365.

Describe the infrastructure requirements for installing Exchange Server 2010.

Describe the server requirements for installing Exchange Server 2010.

Describe the considerations for deploying Exchange Server 2010 servers as virtual machines.

Describe the process for installing Exchange Server 2010.

Describe the options for performing an unattended installation.


Overview of Server Roles in Exchange Server 2010

Exchange Server 2010 provides functionality that falls into five separate server roles. When you install Exchange Server 2010, you can select one or more of these roles for installation on the server. Large organizations might deploy several servers with each role, whereas a small organization might combine all server roles except the Edge Transport server role on one computer, because of different configuration storage it uses, which will be discussed later.

Note Exchange Server 2010 server roles are a logical grouping of features and components that perform a specific function in the messaging environment. You can install all server roles, except the Edge Transport server role, on the same physical computer.

Exchange Server 2010 Server Roles The following server roles are included in Exchange Server 2010:

Hub Transport server role. The Hub Transport server role is responsible for message routing. The Hub Transport server performs message categorization and routing, and handles all messages that pass through an organization. You must configure at least one Hub Transport server in each Active Directory site that contains a Mailbox server or a Unified Messaging server, and the server running the Hub Transport server role must be a member of an Active Directory domain.

Mailbox server role. The Mailbox server role is responsible for managing mailbox and public folder databases. Mailboxes and public folders reside on the Mailbox servers. Mailbox servers contain mailbox and public folder databases. You can enable high availability by adding mailbox servers to a Database Availability Group (DAG). Because Mailbox servers require Active Directory access, you must install this role on a member server in an Active Directory domain.


Client Access server role. The Client Access server role enables connections from all available client protocols to the Exchange Server mailboxes. You must assign at least one Client Access server in each Active Directory site that contains a Mailbox server. Client protocols that connect through a Client Access server include:

Messaging Application Programming Interface (MAPI) clients

Outlook Web App clients

Post Office Protocol (POP) and Internet Message Access Protocol (IMAP) clients

Outlook Anywhere, which is known as remote procedure call (RPC) over HTTP in Exchange Server 2003

Exchange ActiveSync clients

Note In previous Exchange Server versions, MAPI clients connect directly to the Mailbox servers. In Exchange Server 2010, all clients, including MAPI clients, connect to the Client Access servers. MAPI clients still connect directly to Mailbox servers when accessing public folders.

Edge Transport server role. The Edge Transport server role is the Simple Mail Transport Protocol (SMTP) gateway server between your organization and the Internet. To ensure security, you should deploy the computer that runs the Edge Transport server role in a perimeter network, and it should not be a member of your internal Active Directory forest. Because the Edge Transport server is not part of an Active Directory domain, it cannot use AD DS to store configuration information. Instead, it uses AD LDS on Windows Server 2008 computers to access recipient and configuration information.

On the Edge Transport server, you create connectors to define message-flow paths into, and out of, your organization. You can define multiple Edge Transport servers to provide load balancing and high availability.

Note You cannot combine the Edge Transport server role with any other role on the same computer. The Hub Transport and Edge Transport servers both provide message routing and delivery capabilities to, and from, the Internet. However, some advanced transport features are available only on Edge Transport servers.

Unified Messaging server role. The Unified Messaging server role provides the foundation of services that integrate voice and fax messages into your organizations messaging infrastructure. This role requires the presence of three server roles: Hub Transport, Client Access, and Mailbox. The Unified Messaging server provides access to voice messages and faxes.


Deployment Options for Exchange Server 2010

You can deploy the server roles in Exchange Server 2010 in several different scenarios, depending on an organizations size and requirements. If you are an administrator, it is important to understand the deployment scenarios when you plan an Exchange Server system.

Exchange Server 2010 Editions

Exchange Server 2010 is available as Standard Edition and Enterprise Edition. The Standard Edition should meet the messaging needs of small and medium corporations, but also may be suitable for specific server roles or branch offices. The Enterprise Edition is for large enterprise corporations, and enables you to create additional databases apart from including other advanced features.

Feature Standard Edition Enterprise Edition

Database Support Five databases 100 databases

Database Storage Limit

No software storage limit; storage limit is hardware dependent

No software storage limit; storage limit is hardware dependent

DAG membership Supported Supported

Note If you want to use databases larger than 1TB on Exchange Server 2010 Standard Edition, you have to enable it in the registry. To learn how to modify the registry for this purpose, go to http://go.microsoft.com/fwlink/?LinkId=248378.


Exchange Server 2010 Client Access Licenses

Exchange Server 2010 has two client-access license (CAL) options:

Exchange Server Standard CAL. Provides access to email, shared calendaring, Outlook Web App, and ActiveSync.

Exchange Server Enterprise CAL. Requires a standard CAL, and provides access to additional features such as unified messaging, per-user and per-distribution-list journaling, managed custom email folders, and Microsoft Forefront Endpoint Protection for Exchange Server.

Deployment Scenarios for a Simple Organization

In a small organization, you can install all the server rolesexcept the Edge Transport server roleon a single computer. Small organizations might also consider using Exchange Online services.

Deployment Scenarios for a Standard Organization

Medium-sized organizations should consider installing the required services and Exchange server roles on multiple computers. A typical deployment scenario for a medium-sized organization may include:

Two domain controllers for each domain.

Two Exchange servers configured with the Mailbox server role and other server roles, except the Edge Transport server role.

Note In Exchange Server 2007, Mailbox servers that were part of a failover cluster could not run additional Exchange server roles. With Exchange Server 2010, Exchange servers that are part of a DAG also can host other Exchange server roles, except the Edge Transport server role.

One Exchange server configured with the Edge Transport server role.

Note You can add only Exchange Server 2010 running on Windows Server 2008 Enterprise Edition or Datacenter Edition or Windows Server 2008 R2 Enterprise Edition or Datacenter Edition to a DAG. If a standard organization uses the Windows Server 2008 or Windows Server 2008 R2 Standard Edition servers, the organization can deploy multiple Mailbox servers, but cannot configure high availability for the Mailbox server role.

As your organization expands, you should consider adding dedicated servers for roles like the Hub Transport server, the Client Access server, or the Unified Messaging server. This provides scalability and redundancy.

Deployment Scenarios for a Large or Complex Organization A large or complex organization needs to deploy dedicated servers for each server role, and may have to deploy multiple servers for each role. A typical deployment scenario for a large organization can include:

Two domain controllers and global catalog servers for each organizational domain. If the organization includes multiple Active Directory sites, and you are deploying Exchange servers in a site, you should deploy global catalog servers in the site.

One or more Exchange servers configured with the Mailbox server role. You can deploy multiple Mailbox servers in each Active Directory site.


One or more Exchange servers dedicated to each of the other server roles. You must deploy at least one Hub Transport server and Client Access server in each Active Directory site that includes a Mailbox server.

If the organization has a smaller branch office, you can deploy multiple Exchange servers hosting all the server roles except for the Edge Transport server role, and configure the Mailbox servers to be part of a DAG.

One or more Exchange servers configured with the Edge Transport server role. Multiple servers provide redundancy and scalability.

Hybrid Deployment with Office 365 In Exchange Server 2010 Service Pack 2 (SP2), it is possible to create a hybrid deployment between on-premises Exchange Server and Exchange Online from Office 365. A hybrid deployment offers organizations the ability to extend the user experience and administrative control they have with their existing on-premises Microsoft Exchange organization to the Office 365 cloud. A hybrid deployment provides you with a view of a single Exchange organization between an on-premises organization and a cloud-based organization. In addition, a hybrid deployment can serve as an intermediate step to moving completely to a cloud-based Exchange organization.

A hybrid deployment of Exchange Server and Office 365 provides the following features:

Mail routing with a shared domain namespace. For example, both on-premises and cloud-based organizations use the @contoso.com SMTP domain.

A unified global address list, also called a shared address book. With this address list, users can view all contacts from both on-premises Exchange and Office 365.

Free/busy and calendar sharing between on-premises and cloud-based organizations.

Centralized control of mail flow. The on-premises organization can control mail flow for the on-premises and cloud-based organizations.

A single Outlook Web App URL for both the on-premises and cloud-based organizations.

The ability to move existing on-premises mailboxes to the cloud-based organization.

Centralized mailbox management using the on-premises Exchange Management Console.

Message tracking, MailTips, and multi-mailbox search between on-premises and cloud-based organizations.

In Exchange Server 2010 SP2, there is a Hybrid Configuration Wizard that allows you to perform hybrid deployment and integrate your local Exchange server with Office 365. Before you start deploying Exchange in a hybrid scenario, you should make sure that you have a proper Office 365 license. Office 365 is examined in greater detail in Module 13.


Hardware Recommendations for Combining Server Roles

Small and medium-sized companies, and large organizations that have a small number of users in a single location, may choose to combine multiple Exchange Server 2010 server roles on a single computer.

Combining Server Roles You can install all roles, except the Edge Transport server role, on a single computer. When you design the hardware configuration for servers on which you install multiple server roles, consider the following recommendations:

You should plan for at least two processor cores, at a minimum, for a server with multiple server roles. The recommended number of processor cores is eight, while 24 is the maximum recommended number.

You should design a server with multiple roles to use half of the available processor cores for the Mailbox role and the other half for the Client Access and Hub Transport roles.

You should plan for the following memory configuration for a server with multiple server roles: 8 gigabytes (GB) and between 2 megabytes (MB) and 10 MB per mailbox. This can vary based on the user profile and the number of storage groups. We recommend 64 GB as the maximum amount of memory you need.

To accommodate the Client Access and Hub Transport server roles on the same server as the Mailbox server role, you should reduce the number of mailboxes per core calculation, based on the average client profile by 20 percent.

You can deploy multiple Exchange server roles on a mailbox server that is a DAG member. This means that you can provide full redundancy for the Mailbox, Hub Transport, and Client Access server roles on just two Exchange servers. Be aware, however, that you cannot use DAG together with NLB on the same servers; therefore, if you want to achieve full redundancy with just two servers, you will need a hardware load balancer.


Options for Integrating Exchange Server 2010 and Exchange Online Services in Office 365

One deployment option available in Exchange Server 2010 is to integrate your messaging system with Exchange Online Services. Exchange Online Services is part of the Office 365 services that Microsoft offers.

Office 365

Office 365 is a set of Microsoft-hosted messaging and collaboration solutions, including Microsoft Exchange Online, Microsoft SharePoint Online, Microsoft Office Web Apps, and Microsoft Lync Online. These services are available on a subscription basis.

Exchange Online Services When you subscribe to Exchange Online Services in Office 365, you can take advantage of the following features:

Email and calendar functions. Exchange Online delivers email services, including spam filtering, antivirus protection, and mobile-device synchronization. Through Microsoft Office Outlook and Outlook Web App, you can use the advanced email, calendar, contact, and task management features of Exchange Online.

Email coexistence and migration tools. The Office 365 Suite includes email coexistence and migration tools. If you have AD DS and Microsoft Exchange Server, the Microsoft Online Services Directory Synchronization tool synchronizes your user accounts, contacts, and groups from your local environment to Microsoft Online Services. This tool also makes your Microsoft Exchange Global Address List (GAL) available in Exchange Online.


Exchange Online Services and Exchange Server 2010

Exchange Server 2010 provides additional functionality with Exchange Online Services. With Exchange Server 2010, you can host some of the mailboxes in an internal Exchange organization, which displays as the On-Premise Exchange organization in the Exchange Management Console. Additionally, you can host some of your organizations mailboxes on Exchange Online. You can use the Exchange Management Console to move mailboxes to the Exchange Online Services and manage those mailboxes.


Infrastructure Requirements for Exchange Server 2010

Before you deploy Exchange Server 2010 in your organization, you need to ensure that your organization meets AD DS and DNS requirements.

Active Directory Requirements You must meet the following Active Directory requirements before you can install Exchange Server 2010:

The domain controller that is the schema master must have Windows Server 2003 Service Pack 1 (SP1) or newer, Windows Server 2008, or Windows Server 2008 R2 installed. By default, the schema master runs on the first Windows domain controller installed in a forest.

In each of the sites where you deploy Exchange Server 2010, at least one global catalog server must be installed and run Windows Server 2003 SP1 or newer, Windows Server 2008, or Windows Server 2008 R2.

The Active Directory domain and forest functional levels must run Windows Server 2003, at the minimum.

If you have a resource forest configuration, or multiple forests, and users from different forests need to access mailboxes in an Exchange 2010 organization, you must configure a trust between the forests. In this case, the minimum forest functional level must be Windows Server 2003.

DNS Requirements Before you install Exchange Server 2010, you must configure DNS correctly in your Active Directory forest. All servers that run Exchange Server 2010 must be able to locate Active Directory domain controllers, global catalog servers, and other Exchange servers.


Server Requirements for Exchange Server 2010

Exchange Server 2010 requires a minimum level of hardware, and specific software, before you can install it.

Hardware Requirements You can deploy Exchange Server 2010 only on 64-bit versions of Windows Server 2008 or Windows Server 2008 R2 that are running on 64-bit hardware.

Resource Requirement

Processor x64 architecture-based computer with Intel processor that supports Intel 64 architecture (formerly known as Intel EM64T).

AMD processor that supports the AMD64 platform. Intel Itanium IA64 processors not supported.

Memory A minimum of 2 GB of system memory, plus 2 to 6 MB per mailbox. This recommendation is based on the number of mailbox databases and the user-usage profile.

Disk 1.2 GB disk space for Exchange Server files and 200 MB of free disk space on the system drive.

File system Drives formatted with NTFS file systemfor all Exchange Serverrelated volumes.

Note Exchange Server 2010 is available only in 64-bit versions, which means that you can install all components, including the Exchange Management tools, only on 64-bit operating systems.


Exchange Server 2010 Prerequisite Software

All Exchange Server 2010 servers must have the following software installed:

Active Directory Domain Services (AD DS) management tools, which is required on all Exchange Server 2010 servers, except for Edge Transport servers

Microsoft .NET Framework 3.5 (SP1) or newer

Windows Remote Management (WinRM)

Windows PowerShell Version 2

Note The Net.Tcp Port Sharing Service must be configured to start automatically before starting the Exchange server installation. This will be configured as a part of the setup process in Exchange Server 2010 SP1 or later.

On Windows Server 2008 R2 all these software components can be installed from Server Manager. However, on Windows Server 2008, you should manually download and install them. Exchange Server 2010 SP2 setup provides the appropriate download links for missing software, and also enables automatic installation of missing software components during Exchange installation.

Server Role Installation Requirements

Each server role in Exchange Server 2010 has slightly different installation requirements. All server roles, except for the Edge Transport server role, require some Web Server components, such as Internet Information Services (IIS).

The following table summarizes the requirements for each server role.

Server Role Software Requirements

Mailbox server role 2010 Office System Converter: Microsoft Filter Pack Install the default Web Server (IIS) server role along with the following

role services:

IIS 6 Metabase Compatibility IIS 6 Management Console Basic Authentication Windows Authentication .NET Extensibility

Client Access server role

Install the default Web Server (IIS) server role and the following role services:

ISAPI Extensions IIS 6 Metabase Compatibility IIS 6 Management Console Basic Authentication Windows Authentication Digest Authentication Dynamic Content Compression .NET Extensibility Install the Windows Communication Foundation (WCF) HTTP

Activation feature

Install the RPC over HTTP Proxy feature


(continued)

Server Role Software Requirements

Hub Transport server role



Edge Transport server role

Must have a DNS suffix configured Install the AD LDS server role

Unified Messaging server role

Install the Desktop Experience feature. This installs the required Microsoft Windows Media Player audio/video codecs.



Note Installing Exchange Server 2010 on a Windows Server 2008 computer might add additional roles or role services to the server. For example, when you perform a typical installation, the File Server server role is added along with additional Web Server (IIS) role services.

Installation Requirements for Installing Management Tools on Windows Vista or Windows 7 You can install the Exchange Server 2010 management tools on computers that are running 64-bit versions of Windows Vista or Windows 7. Before installing the management tools, you will need to ensure that the following components are installed:

Microsoft .NET Framework 3.5 Service Pack 1or later

Windows Remote Management (WinRM)

Windows PowerShell Version 2

IIS 6 Management Console


Considerations for Deploying Exchange Server 2010 As a Virtual Machine

One option with Exchange Server 2010 is to deploy the servers as virtual machines.

Benefits of Using Virtual Machines

Deploying Exchange Server 2010 servers as virtual machines provides the same advantages as deploying other servers as virtual machines. You can deploy all Exchange Server 2010 SP2 server roles as virtual machines.

The benefits of deploying Exchange Servers as virtual machines include:

Increases hardware utilization and decreases the number of physical servers. In many organizations, the servers deployed in data centers have very low hardware utilization. Frequently, servers use less than 10 percent of the available hardware resources. By deploying multiple virtual machines on a single physical server, you can increase the hardware utilization, while decreasing the number of physical servers deployed. This can result in significant cost savings.

Deploying Exchange Servers as virtual machines provides server-management options that are not available for physical servers. Because virtual machines are just a set of files, you may have additional management options with virtual machines. For example, to increase a virtual machines hardware level, you can assign more of the host resources to the virtual machine, or move the virtual machine files to a more powerful host server.

Note Microsoft supports Exchange Server 2010 running as virtual machines for all virtualization vendors that are validated through the Windows Server Virtualization Validation Program. See http://go.microsoft.com/fwlink/?LinkId=248379 for details.


Microsoft supports Exchange Server 2010 in production on hardware virtualization software only when all the following conditions are true:

The hardware virtualization software is running one of the following:

Windows Server 2008 with Hyper-V technology

Windows Server 2008 R2 with Hyper-V technology

Microsoft Hyper-V Server 2008

Microsoft Hyper-V Server 2008 R2

Any third-party hypervisor that has been validated under the Windows Server Virtualization Validation Program.

The Exchange Server guest virtual machine is running Microsoft Exchange 2010. This includes Exchange 2010 Hosting Mode, available in Exchange 2010 SP1 or later.

The Exchange Server guest virtual machine is deployed on Windows Server 2008 with SP2 (or later) or Windows Server 2008 R2 RTM or later.

Considerations for Deploying Exchange Server 2010 Servers as Virtual Machines

While running Exchange Server 2010 as a virtual machine provides some benefits, you also should consider the following issues:

Exchange servers can be designed to ensure that that the servers fully utilize the available hardware. For example, in a large organization, you can deploy several thousand mailboxes to a Mailbox server or deploy a Client Access server with sufficient client connections so that your organization fully utilizes all hardware resources.

One of the benefits of running virtual machines is that you can configure high availability within the virtual machine environment. For example, you can deploy Quick Migration in Windows Server 2008 Hyper-V or Live Migration in Windows Server 2008 R2 Hyper-V. However, Microsoft does not support running both DAGs and a virtual machine-based high availability solution. If you require high availability, you should use the Exchange Server 2010 solution. DAGs provide failover features that are not available in virtual machine-based, high-availability solutions. Some of the DAG features include multiple copies of the database, backing up the database on the passive node, and application-aware clustering.

The storage used by the Exchange Server guest machine can be virtual storage of a fixed size, SCSI pass-through storage, or Internet SCSI (iSCSI) storage. Pass-through storage is storage that is configured at the host level and dedicated to one guest machine. To provide the best performance for Exchange server storage, use either pass-through disks or fixed-size virtual disks.

You must allocate sufficient storage space for each Exchange Server guest machine on the host machine for the fixed disk that contains the guest's operating system, any temporary memory storage files in use, and related virtual machine files that are hosted on the host machine. Additionally, for each Exchange Server guest machine, you must also allocate sufficient storage for the message queues on Hub Transport and Edge Transport servers and sufficient storage for the databases and log files on Mailbox servers. You should host the storage used by Exchange Server in disk spindles that are separate from the storage that is hosting the guest virtual machine's operating system.


You can deploy only management software such as antivirus software, backup software, virtual machine management software, and so on, on the physical root machine. You should not install any other server-based applications such as Exchange Server, Microsoft SQL Server, AD DS, and so on, on the root machine. The root machine should be dedicated to running guest virtual machines.

Running Exchange servers as virtual machines can complicate performance monitoring. The performance data between the host and virtual machine is not consistent because the virtual machine uses only some part of the hosts resources.

One of the most common performance bottlenecks for Mailbox servers is network input/output (I/O). When you run Mailbox servers in a virtual environment, the virtual machines have to share this I/O bandwidth with the host machine and other virtual machine servers deployed on the same host. If a single virtual machine is running on the physical server, the network I/O that is available to the virtual machine is almost equivalent to the I/O available to a physical server. A heavily utilized Mailbox server can consume all of the available I/O bandwidth, which makes it impractical to host additional virtual machines on the physical server.

If you are planning to deploy Exchange Server 2010 as a virtual machine, ensure that you plan the virtual hardware requirements carefully. Running Exchange Server 2010 as a virtual machine does not change the Exchange Server hardware requirements. You must assign the same hardware resources to the Exchange Server virtual machine as you would assign to a physical server that is running the same workload.


Process for Installing Exchange Server 2010

The Exchange Server 2010 graphical setup program guides you through the installation process. The following steps provide a high-level installation overview:

1. Install the prerequisite software. For all server roles, you must install Microsoft .NET Framework 3.5, or later, Windows Remote Management (WinRM) 2.0, and Windows PowerShell version 2. If you install Exchange Server on Windows Server 2008 R2, the correct versions of Windows PowerShell and Windows Remote Management are installed already.

2. To start the installation, run setup.exe from the installation source. The setup program checks to ensure that the correct software is installed on the computer. If prerequisite software is not installed, you can use the links provided on the Start page to download and install the software.

3. The setup program provides the option to install additional language packs that will enable the Exchange Server 2010 management tools to display in languages other than English.

4. The setup program provides the option to perform a Typical Exchange Server Installation or a Custom Exchange Server Installation. The typical installation option installs the Hub Transport server role, the Client Access server role, the Mailbox server role, and the Exchange Management tools. The custom installation option allows you to choose the roles you want to install.

Choose this option if you want to install an Edge Transport server or a Unified Messaging server, or install just the Exchange Management Tools.

5. If this is the first Exchange Server 2010 server in the deployment, and you do not run setup /PrepareAD, you are prompted for the Exchange organization name.

6. If you chose the Mailbox server role, the Exchange setup program prompts you if you have any Office Outlook 2003 or Entourage clients in the organization. If you choose Yes, Exchange setup creates the public folders required by these clients for the offline address book and for sharing calendar information.


7. If you choose to install the Client Access server role, you also can configure the external domain name for the Client Access server. Clients use this external domain name to connect to the server from the Internet.

Note Exchange Server 2010 supports Office Outlook 2003 SP1 or later clients. The only Entourage version supported by Exchange Server 2010 is Entourage 2008, Web Services Edition. This version of Entourage requires public folders.

Exchange Server setup program then checks that the organizational prerequisites and server prerequisites are met for each server role that you select. If all the prerequisites are met, Exchange Server 2010 is installed on the computer. If this is the first Exchange server in the organization, and you have not run /PrepareAD, Exchange Server setup modifies AD DS, and then installs each selected server role.

You can use the Exchange Server 2010 Service Pack Setup wizard to upgrade your current version of Exchange Server 2010. If you have the RTM version of Exchange Server 2010 installed, you can upgrade to either Exchange Server 2010 Service Pack 2 (SP2) or Exchange Server 2010 Service Pack 1 (SP1). If you have Exchange Server 2010 SP1 installed, you can upgrade to Exchange Server 2010 SP2. We strongly recommended that you upgrade to Exchange 2010 SP2.


Unattended Installation Options

You can use the command line to perform an unattended Exchange Server 2010 installation. When you use the command line, you can use parameters to install specified roles or configure other setup options. The table below lists the most commonly used command-line setup parameters.

Parameter Options Explanation

/mode, /m Install Upgrade Uninstall RecoverServer Default: Install

Use this parameter to control what the setup program does.

You can use the Upgrade mode only to upgrade from a previous prerelease version of Exchange Server 2010.

/roles, /r The following is the list of valid role names:

HubTransport, HT, H ClientAccess, CA, C EdgeTransport, ET, E Mailbox, MB, M UnifiedMessaging, UM, U ManagementTool, MT, T

Use this parameter to specify which roles you want to install. If you specify multiple roles, separate them with commas. Note that you cannot combine the Edge Transport role with any other.

/OrganizationName organizationname

Use the parameter to specify the name to give the new Exchange organization. This parameter is required if you are installing the first server in an organization and you have not run /PrepareAD.


(continued)

Parameter Options Explanation

/targetdir, /t A valid path Use this parameter to specify in which folder to install Exchange Server. Default: %%programfiles%% \Microsoft\Exchange Server.

/PrepareAD, /p None Use this parameter to prepare AD DS for installation.

/DomainController, /dc The name of a suitable domain controller

Use this parameter to specify which domain controller setup will be read and written from during installation.

/NewProvisionedServer, /nprs

Server name Use this parameter to create a placeholder server object in AD DS so that you can delegate setup of a server.

/ServerAdmin User or group Use this parameter to specify an account that will have permissions to a provisioned Exchange server.

/Hosting Use this parameter to install and enable hosting functionality and features. For example, to specify the Hosting mode, specify the following: Setup.com /roles: Mailbox /Hosting.

This parameter is available for multi-tenant deployments. It is not available for on-premises deployments.

Note To run an unattended installation with setup parameters, you must run setup.com or setup rather than setup.exe. To see all the parameters available for use with setup.com, run the command with the /? parameter.

The following is the syntax for this command.

Setup.com [/roles:] [/mode:] [/console] [/?][/targetdir:] [/prepareAD] [/domaincontroller]

For example, if you want to install Exchange Server 2010 into the default path, and specify the roles of Hub Transport, Client Access, and Mailbox, you would enter the following command.

Setup.com /r:H,M,C

Additionally, you should consider using the /InstallWindowsComponents switch with Setup.com, which will automatically add required roles and features for Exchange Server. You can use this switch in Exchange Server 2010 SP1 or later.


Lab A: Installing Exchange Server 2010

Lab Setup

For this lab, you will use the available virtual machine environment. Before you begin the lab, you must:

1. On the host computer, click Start, point to Administrative Tools, and then click Hyper-V Manager.

2. In Hyper-V Manager, click 10135B--NYC-DC1, and in the Actions pane, click Start.

10135B- NYC-DC1: Domain controller in the Contoso.com domain.

3. In the Actions pane, click Connect. Click the CTRL+ALT+DELETE button in the top-left corner of the Virtual Machine Connection window.

4. Log on using the following credentials:

User name: Administrator

Password: Pa$$w0rd

Domain: Contoso

5. Repeat these steps to start, and log on to the 10135B-NYC-SVR1 virtual machine.

10135B- NYC-SVR1: Member server in the Contoso.com domain.

Lab Scenario You are working as a messaging administrator in Contoso Ltd. Your organization is preparing to install its first Exchange Server 2010 server. Contoso Ltd. is a large multinational organization that includes offices in Seattle, Washington, in the United States, and in Tokyo, Japan.

Contoso Ltd. does not have a previous version of Exchange Server deployed so you do not have to upgrade a previous messaging system. Before installing Exchange Server 2010, you must verify that the Active Directory environment is ready for the installation. You also must verify that all computers that will run Exchange Server 2010 meet the prerequisites for installing Exchange.


Exercise 1: Evaluating Requirements for an Exchange Server Installation

Scenario

The Active Directory administrators at Contoso Ltd. are testing the Exchange Server 2010 deployment by deploying a domain controller in a test environment. The server administration team has deployed a Windows Server 2008 R2 server that you can use to deploy the first Exchange Server 2010 server in the test organization.

You need to verify that the Active Directory environment and the server meet all prerequisites for installing Exchange Server 2010. Use the following checklist to verify that the prerequisites are met:

Prerequisite Achieved?

Active Directory domain controllers: Windows Server 2003 SP2 or later

Yes or No

Active Directory domain and forest functional level: Windows Server 2003 or higher

Yes or No

DNS requirements Yes or No

Exchange Server 2010 schema changes Yes or No

Active Directory Domain Services (AD DS) management tools

Yes or No

Microsoft .NET Framework 3.5 or later Yes or No

Windows Remote Management (WinRM) Yes or No

Windows PowerShell Version 2 Yes or No

2010 Office System Converter: Microsoft Filter Pack Yes or No

Web Server (IIS) server role along with the following role services:

ISAPI Extensions IIS 6 Metabase Compatibility IIS 6 Management Console Basic Authentication Windows Authentication Digest Authentication Dynamic Content Compression .NET Extensibility

Yes or No

Windows Server 2008 features

WCF HTTP Activation RPC over HTTP Proxy

Yes or No

The main tasks for this exercise are:

1. Evaluate the Active Directory requirements.

2. Evaluate the DNS requirements.

3. Evaluate the server requirements.


X Task 1: Evaluate the Active Directory requirements 1. On NYC-DC1, evaluate whether the domain controller requirements are met.

2. Evaluate whether the domain and forest functional level requirements are met.

3. Use Adsiedit.msc to evaluate whether the Exchange schema changes are applied.

X Task 2: Evaluate the DNS requirements On NYC-SVR1, use Ipconfig, Ping, and NSLookup to evaluate DNS name resolution functionality.

X Task 3: Evaluate the server requirements 1. On NYC-SVR1, evaluate whether the required Windows Server 2008 features, including the required

AD DS administration tools, are installed.

2. Evaluate whether the Microsoft Internet Information Services (IIS) components are installed.

3. Evaluate whether the prerequisite software is installed.

Results: After this exercise, you should have evaluated whether your organization meets the AD DS, DNS, and server requirements for installing Exchange Server 2010. You should have identified the additional components that need to be installed or configured to meet the requirements.

Exercise 2: Preparing for an Exchange Server 2010 Installation

Scenario

Now that you have identified which prerequisites are not met in the current AD DS and server configuration, you need to update the environment to meet them.

The main tasks for this exercise are:

1. Install the Windows Server 2008 server roles and features.

2. Prepare AD DS for the Exchange Server 2010 installation.

X Task 1: Install the Windows Server 2008 server roles and features 1. On NYC-SVR1, in Server Manager, install the prerequisite server roles and features for Exchange

Server 2010.

2. Configure the Net.Tcp Port Sharing Service to start Automatically.


X Task 2: Prepare AD DS for the Exchange Server 2010 installation 1. In Hyper-V Manager, connect C:\Program Files\Microsoft Learning

\10135\Drives\Exchange2010SP2.iso as the DVD drive for NYC-SVR1.

2. From a command prompt, run the Exchange Server setup program with the /PrepareAD parameter. Configure an Exchange organization name of Contoso.

Results: After this exercise, you should have prepared the AD DS and server configuration for the Exchange Server 2010 installation.

Exercise 3: Installing Exchange Server 2010

Scenario

After you prepare the environment, continue with the Exchange Server 2010 server installation.

The main task for this exercise is:

Install Microsoft Exchange Server 2010.

X Task 1: Install Microsoft Exchange Server 2010 1. Start the Exchange Server 2010 installation.

2. Perform a Typical Exchange Server Installation.

3. Choose to automatically install required roles and features.

4. Choose to enable access for Outlook 2003 or Entourage clients.

Results: After this exercise, you should have prepared the AD DS and server configuration for the Exchange Server 2010 installation.


Lesson 3 Completing an Exchange Server 2010 Installation

After you install the necessary server roles in Exchange Server 2010, you should verify the installation and perform post-installation tasks, including securing Exchange Server 2010 and installing additional third-party software, if necessary. This lesson describes the post-installation tasks that you should perform.


Verify an Exchange Server 2010 installation.

Verify an Exchange Server 2010 deployment.

Describe how to troubleshoot an Exchange Server 2010 installation.

Describe how to finalize an Exchange Server 2010 installation.


Demonstration: Verifying an Exchange Server 2010 Installation

If all prerequisites are met, the Exchange Server installation should complete successfully. However, you should verify that the installation was successful.

Demonstration Steps 1. On VAN-EX1, open the Services management console, and review the Microsoft Exchange services

that were added during the installation.

2. Open Windows Explorer, and browse to C:\ExchangeSetupLogs.

3. Review the contents of the ExchangeSetup.log file.

4. Describe some of the other files in this folder.

5. Browse to C:\Program Files\Microsoft\Exchange Server\V14. Describe the contents of the folders in this location.

6. Open the Exchange Management Console.

7. Under Server Configuration, verify that the server that you installed is listed.

8. Click Toolbox and review the installed tools.

9. In the left pane, click Recipient Configuration. Create a new mailbox.

10. Open Windows Internet Explorer, and connect to the Outlook Web App site on a Client Access server. Log on using the credentials for the new mailbox that you created.

11. Send an email to the mailbox that you created. Verify that the messages delivery.


Additional Tests to Verify Installation

After the Exchange Server 2010 installation finishes, you also can take the following steps to verify that the installation was successful:

Check the Exchange setup log files. The installation process creates several log files that the C:\ExchangeSetupLogs directory stores. Review the setup logs for errors that occur during installation.

Ensure that the Exchange Management Console opens and displays the installed Exchange server.

Create a user account with a mailbox and connect to that mailbox by using an Office Outlook client or Outlook Web App.

Note For detailed information about each of the log files created during the installation, see Exchange Server Help.


Demonstration: Running the Exchange Best Practices Analyzer

The Microsoft Exchange Server Best Practices Analyzer Tool automatically examines an Exchange Server deployment and determines whether the configuration meets with Microsoft best practices. Microsoft performs periodic updates on the definitions that the Exchange Server Best Practices Analyzer uses, so they typically reflect the latest version of the Microsoft best practices recommendations. We recommend running the Exchange Server Best Practices Analyzer after you install a new Exchange server, upgrade an existing Exchange server, or make configuration changes. You can find the Exchange Server Best Practices Analyzer in the Toolbox node of the Exchange Management Console.

In this demonstration, your instructor will run the Exchange Server Best Practices Analyzer and review the generated reports.

Note For more information about the Exchange Server Best Practices Analyzer, view the Exchange Server Best Practices Analyzer Help that is available with the Exchange Server Best Practices Analyzer Tool.

Demonstration Steps

1. On VAN-EX1, open Exchange Management Console, and then click Toolbox.

2. Start the Best Practices Analyzer, and clear the options to check for updates and to join the customer improvement program. Go to the Welcome page.

3. Start a new scan. Choose to perform a Health Check scan to scan the server that you just installed.


4. When the scan finishes, view the following tabs and reports:

Critical Issues

All Issues

Recent Changes

Informational Items

Tree reports

Other reports


Troubleshooting an Exchange Server 2010 Installation

The Exchange Server installation should complete successfully if you meet all prerequisites. However, if the installation does not complete properly, it is important for you to follow a consistent troubleshooting process as this ensures that you do not miss steps and problems are resolved quickly.

Your troubleshooting process should include the following best practices:

1. Identify the problem. Before you begin to apply any fixes to your Exchange Server installation, be sure that you identify exactly what is the problem. Applying inappropriate fixes could create additional problems. To identify an installation problem you should check the setup and event logs for errors.

2. Identify potential fixes for the problem. You cannot always fix problems by using the most obvious solution. Your search for potential fixes should be methodical and include multiple sources, such as Microsoft TechNet, the Microsoft Knowledge Base, and suggestions in event logs.

After you identify a list of potential fixes, prioritize them based on how likely they are to fix the problem and how long implementation will take. In most cases, try quick fixes before long and involved fixes, even if the longer fix is more likely to resolve the problem.

3. Test only one fix at a time. It is essential that you test only one fix at a time. Do not implement three fixes, and then see if the problem is fixed. Implementing one fix at a time ensures that you understand what solution fixed the problem. When you implement multiple fixes, the first fix may resolve the problem, but another one may introduce additional problems.

When you implement a fix, be sure to document the changes you make. Then, if the fix does not resolve the problem, you can undo the changes before trying another solution.

4. Document the problem resolution. Documentation is an essential part of problem resolution. If the same problem occurs later, documentation of the previous solution makes it easier to address the current issue. Disseminating that knowledge to others in the organization may prevent the problem from occurring again.


Potential Problems and Resolutions

Some common installation problems and solutions are:

Net.TCP Port Sharing Service is not set to start automatically. You must set this service to start automatically.

Insufficient disk space. Your server might not have the necessary disk space to install Exchange Server 2010. To resolve this, either increase your servers disk space or remove unnecessary files to create more free space.

Missing software components. Your server might not have all of the required software components for the server roles you want to implement. To resolve this, determine the required software components, download them if necessary, and install them.

Incorrect DNS configuration. Exchange Server 2010 relies on global catalog servers to perform many operations, and uses DNS to find global catalog servers. If the DNS configuration is incorrect, your server might not be able to find a global catalog server. To verify the problem, use the dcdiag tool. To resolve the problem, ensure that the Exchange server and domain controllers are all using the appropriate internal DNS servers.

Incorrect domain functional level. All domains with Exchange Server 2010 recipients or servers must be at Windows Server 2008 R2, Windows Server 2008, or Windows Server 2003 functional level. To resolve this problem, raise the domain functional level to the appropriate functional level.

Insufficient Active Directory permissions. When you install Exchange Server 2010, you need sufficient permissions to extend the Active Directory schema and modify the Active Directory configuration partition. To perform the initial schema extension, you must be a member of the Enterprise Admins and Schema Admins groups.

Insufficient Exchange permissions. To install Exchange Server 2010 into an existing organization, you must be a member of the Exchange Admins group. You also must run Setup.exe with the /PrepareLegacyExchangePermissions switch. Wait for replication throughout the Exchange Server organization before you continue.


Finalizing the Exchange Server Installation

After finishing the Exchange Server installation, you might need to perform additional steps to finalize the server deployment.

Configuring Exchange Server Security Security is important for all the servers in your environment. However, security is even more important for computers that are running Exchange Server. For most organizations, messaging is a critical part of the network. People rely on messaging to perform their jobs. Sensitive and private information often is sent through, and stored in, the messaging system. Unlike many other servers, computers that are running Exchange Server all communicate with the Internet in some way. Even Mailbox servers with no direct Internet communication are exposed to messages that originally came from the Internet.

Use the following steps to secure computers that are running Exchange Server 2010:

Restrict physical access. Like all servers, physical access to a computer that is running Exchange Server should be restricted. Any server that you can access physically also can be compromised easily.

Restrict communication. You can use firewalls to restrict the communication between servers, and between servers and clients. Limiting communication to only specific IP addresses, or ranges of IP addresses, reduces the risk that a hacker will access or modify the system. An Edge Transport server must be available to anonymous Internet connections, but firewalls can restrict access to specific ports.

Reduce the attack surface. To limit software flaws that hackers can use, eliminate unnecessary software and services from your Exchange servers. In particular, Edge Transport servers should have only the necessary services and software running because they are exposed to the Internet.


Restrict permissions. Evaluate who has permissions to manage Active Directory in your organization. Users who are domain administrators can add themselves to any group, and so they could manage all Exchange Server recipients and computers that are running Exchange Server in that domain. Reduce delegated Active Directory management permissions in a more granular way if you do not want all of the domain administrators to be capable of managing Exchange Server as well.

Configure Additional Software Before you install any additional software, ensure that Microsoft certifies it for use with Exchange Server 2010. Failure to verify certification for Exchange Server 2010 could result in data or availability loss. Products specifically designed for use with Exchange Server 2010 take advantage of new features.

Some of the additional software you might want to install or configure includes:

Antivirus software. Antivirus software can be used with the Edge Transport server and internal servers. You can install Forefront Protection for Exchange Server on Exchange Server 2010, or deploy and configure non-Microsoft antivirus solutions.

Anti-spam software. Anti-spam software can significantly reduce unsolicited commercial email messages that your users receive, and have to manage. Exchange Server 2010 provides anti-spam features on the Edge Transport server role and the Hub Transport server role. Most organizations that deploy anti-spam software on Exchange Server 2010 will deploy it on the Edge Transport server, but you also can enable and configure anti-spam features on Hub Transport servers. Many organizations choose to deploy third-party anti-spam solutions.

Backup software. To back up Exchange Server 2010 servers, you must deploy backup software that uses Volume Shadow Copy Service (VSS) to perform the backup.

Monitoring tools and agents. One example of a monitoring tool is Microsoft System Center Operations Manager. Operations Manager allows you to proactively monitor and manage your Exchange servers by installing monitoring agents on them.

Note There are additional tasks that you must perform for each server role. Later modules cover these tasks.


Lab B: Verifying an Exchange Server 2010 Installation

Lab Setup

For this lab, you will use the available virtual machine environment. Before you begin the lab, you must:

1. On the host computer, click Start, point to Administrative Tools, and then click Hyper-V Manager.

2. Ensure that the 10135B-NYC-DC1 and the 10135B-NYC-SVR1 virtual machines are running.

10135B- NYC-DC1: Domain controller in the Contoso.com domain.

10135B- NYC-SVR1: Member server in the Contoso.com domain.

3. If required, connect to the virtual machines.

Lab Scenario

You have completed the installation of the first Exchange Server at Contoso Ltd. You now need to verify that the installation completed successfully. You also should ensure that the installation meets the best practices that Microsoft suggests.

Exercise 1: Verifying an Exchange Server 2010 Installation The main tasks for this exercise are:

1. View the Exchange Server services.

2. View the Exchange Server folders.

3. Create a new user, and send a test message.

4. Run the Exchange Server Best Practices Analyzer Tool.


X Task 1: View the Exchange Server services 1. Open the Services console.

2. Review the status for each Exchange Server service.

X Task 2: View the Exchange Server folders. Using Windows Explorer, browse to C:\Program Files\Microsoft\Exchange Server\v14. This list of

folders includes ClientAccess, Mailbox, and TransportRoles. The three roles were installed as part of the typical setup.

X Task 3: Create a new user, and send a test message 1. Open the Exchange Management Console.

2. Under Recipient Configuration, create a new mailbox with a new user account named TestUser and a password of Pa$$w0rd.

3. Using Internet Explorer, open https://NYC-SVR1/owa.

4. Log on as TestUser, and send a message to Administrator.

5. Log on to Outlook Web App as Administrator, and verify that the message was delivered.

X Task 4: Run the Exchange Server Best Practices Analyzer tool 1. Start the Exchange Server Best Practices Analyzer.

2. Run a Health Check scan with a name of Post-Installation Test. Scan only NYC-SVR1.

3. Review the information in the Exchange Server Best Practices Analyzer report.

Results: After this exercise, you should have verified that the Exchange Server 2010 server installation completed successfully.

X To prepare for the next module When you finish the lab, revert the virtual machines back to their initial state. To do this, complete the following steps:

1. On the host computer, start Hyper-V Manager.

2. Right-click the virtual machine name in the Virtual Machines list, and then click Revert.

3. In the Revert Virtual Machine dialog box, click Revert.

4. In the Virtual Machines pane, click 10135B-VAN-DC1, and then in the Actions pane, click Start.

5. To connect to the virtual machine for the next modules lab, click 10135B-VAN-DC1, and then in the Actions pane, click Connect.

Important Start the VAN-DC1 virtual machine first, and ensure that it is fully started before starting the other virtual machines.

6. Wait for 10135B-VAN-DC1 to start, and then start 10135B-VAN-EX1. Connect to the virtual machine.

7. Wait for 10135B-VAN-EX1 to start, and then start 10135B-VAN-EX3. Connect to the virtual machine.


Module Review and Takeaways

Review Questions

1. The installation of Exchange Server 2010 fails. What information sources can you use to troubleshoot the issue?

2. What factors should you consider while purchasing new servers for your Exchange Server 2010 deployment?

3. How would the deployment of additional Exchange Server 2010 servers vary from the deployment of the first server?

Common Issues Related to Installing Exchange Server 2010

Identify the causes for the following common issues related to installing Exchange Server 2010 and explain the troubleshooting tips. For answers, refer to relevant lessons in the module.

Issue Troubleshooting tip

You start the Exchange installation and get an error message stating that you do not have sufficient permissions.

You start the Exchange installation and the prerequisite check fails.

You run setup with /PrepareAD parameter and receive an error message.


Real-World Issues and Scenarios

1. An organization has a main office and multiple smaller branch offices. What criteria would you use to decide whether to install an Exchange server in a branch office? What additional factors should you consider if you decide to deploy an Exchange server in the branch office?

2. An organization has deployed AD DS within two different forests. What issues will this organization experience when they deploy Exchange Server 2010?

3. An organization is planning to deploy Exchange Server 2010 servers as virtual machines running on Hyper-V in Windows Server 2008 R2. What factors should the organization consider in their planning?

Best Practices for Deploying Exchange Server 2010 Supplement or modify the following best practices for your own work situations:

Plan the hardware specifications for your Exchange Server 2010 servers to allow for growth. In most organizations, the amount of email traffic and the size of the user mailboxes are growing rapidly.

Consider deploying at least two Exchange Server 2010 servers. With two servers, you can provide complete redundancy for the core Exchange server roles.

When deploying multiple Exchange servers with dedicated server roles for each server, deploy the server roles in the following order:

a. Client Access server

b. Hub Transport server

c

10135b-enu-handbook.pdf

Documents