novell to microsoft conversion assessment: exchange 2010 design

Novell to Microsoft Conversion

Assessment:

Exchange 2010 Design

Presented To:

2/09/2011

1215 Hamilton Lane, Suite 200

Naperville, IL 60540

www.MoranTechnology.com

Voice & Fax: 877-212-6379

http://www.morantechnology.com/

Exchange Design

of 22

Version History

Ver. # Ver. Date Author Description

1.0 19-Jan-11 Brian Desmond Initial Draft

1.1 25-Jan-11 Scott Weyandt Edits

1.2 26-Jan-11 Brian Desmond Added Diagram

1.3 09-Feb-11 Brian Desmond Edits from review meeting

Exchange Design

of 22

Table of Contents Introduction .................................................................................................................................. 5

Background ............................................................................................................................... 5

Current Environment .............................................................................................................. 6

Design Goals ............................................................................................................................. 6

Exchange Topology Overview ................................................................................................... 7

Mailbox Server Topology ........................................................................................................ 9

Client Access Server Topology .............................................................................................. 9

Hub Transport Server Topology .......................................................................................... 10

Mailbox Server Configuration .................................................................................................. 12

High Availability Configuration ......................................................................................... 12

Operating System Configuration ......................................................................................... 12

Hardware Configuration ...................................................................................................... 12

Recommended HACC Mailbox Server (Local Storage) ............................................... 13

Storage Design ............................................................................................................................ 14

Database Placement ............................................................................................................... 14

Database Configuration ........................................................................................................ 14

Physical Storage Configuration ........................................................................................... 15

Backup and Restore ................................................................................................................... 16

Backup Schedule .................................................................................................................... 16

Recovery Targets .................................................................................................................... 16

Mailbox Data Recovery ......................................................................................................... 17

Exchange Design

of 22

Hub Transport Configuration .................................................................................................. 18



Client Access Server Configuration ........................................................................................ 20



SSL Certificates ....................................................................................................................... 21

Summary ..................................................................................................................................... 22

Exchange Design

of 22

Introduction

This document details design recommendations of Moran Technology

Consulting (MTC) for the design of Exchange 2010 at Harrisburg Area Community

College (HACC).

Background

HACC has engaged MTC to conduct a thorough and impartial evaluation of its

current network operating system and email environment (Novell NDS and

GroupWise). As part of this assessment, MTC will identify the pros and cons of

converting to a Microsoft Windows Server Active Directory and Exchange 2010 from

the current Novell NetWare and GroupWise products. In addition, MTC will develop a

project plan that identifies the total cost of conversion, including:

Estimates for hardware and software (licensing and support);

Resource, time, and cost estimates for implementing the new solution (upgrade

or migration);

Knowledge transfer and training of HACC to operate and maintain the new

solution.

As part of this effort, MTC has developed the following design for Exchange 2010 to

enable detailed pricing and planning information.

Exchange Design

of 22

Current Environment

HACC current operates a Novell GroupWise environment which provides

messaging service to HACC employees at each of the HACC campuses. The email

server environment consists of seven servers which support approximately 4,000 users.

Approximately 750GB of mailbox data is housed across these servers.

Design Goals

The primary goal of this design is to provide an Exchange infrastructure which

will meet the needs of HACC stakeholders while also conforming to current best

practice standards for Exchange. Additionally, substantial consideration will be given to

providing additional features and storage for end users while still staying within the

budgetary requirements of the school.

The following requirements developed during interviews with staff will also be

taken in to consideration:

Eliminate single points of failure in the messaging environment wherever

possible;

Improve backup and recovery efficiency and reduce the effort involved in

recovering lost items;

Provide additional functionality and value to end users.

Exchange Design

of 22

Exchange Topology Overview

There are a number of key components to a successful Exchange design. This

document addresses the following server roles in depth:

Mailbox

Hub Transport

Client Access

Perimeter Security

A baseline of 3,300 users across two profiles was used to calculate the design.

These profiles include employees and heavy-use employees. The expected server

requirements to support this design are detailed in the table below.

Name Role Location Physical/Virtual

XMB01 Mailbox Harrisburg Physical

XMB02 Mailbox Harrisburg Physical

XMB03 Mailbox Site 2 Physical

XSV01 Client Access

Hub Transport

Harrisburg Virtual

XSV02 Client Access

Hub Transport

Harrisburg Virtual

XSV03 Client Access

Hub Transport

Site 2 TBD1

XSV04 Client Access

Hub Transport

Site 2 TBD1

The following diagram provides a high level overview of the proposed architecture.

1 If a virtualization host is available in the secondary site, this server can be virtualized

Exchange Design

of 22

Internet

CAS/HT CAS/HT

OWA: mail.domain.comEAS: mail.domain.comOA: mail.domain.com

RPC: outlook.domain.com

RPC: outlook-Site2.domain.com

AD Site: Site2 (TBD)

DB01 – DB06

AD Site: Harrisburg

MBX

DB01 – DB06

100 Meg Link

Note: Failover of site will require manual change of RPC endpoint DNS record

Note: Failover of site will require manual change of RPC endpoint DNS record

CAS/HT

Exchange Design

of 22

Mailbox Server Topology

Mailbox servers comprise the heart of any Exchange environment. User data is

stored on mailbox servers. Mailbox servers store data in databases. Exchange Server

2010 provides high availability for the mailbox server role via Database Availability

Groups (DAGs). DAGs allow for the replication of mailbox databases across multiple

(up to sixteen) mailbox servers with automatic or manual failover. DAGs can also span

physical sites and subnets in order to provide for site resiliency in the event of a

disaster.

Determining the number of mailbox servers to deploy is a tradeoff between cost

and risk as well as the ability to meet service level objectives (SLOs) for recovery of

data. While Exchange Server 2010 can easily support upwards of ten thousand

mailboxes per server, this potentially comes at the expense of inconveniencing a great

number of users in the event of a service outage.

Client Access Server Topology

Client Access Servers (CAS’) are responsible for hosting Outlook Web Access

and Exchange Control Panel, Outlook Anywhere (formerly RPC/HTTPS) and Exchange

ActiveSync client applications. In addition, CAS servers also host the Post Office

Protocol (POP3) and Internet Message Access Protocol (IMAP4) services. Additionally

in Exchange Server 2010, the CAS server role hosts the RPC Client Access service which

provides MAPI access to mailboxes and NSPI access to the directory. This is a departure

from previous version of Exchange where mailbox access was provided via direct RPC

connection to the mailbox server.

Office Outlook 2007 and newer clients leverage CAS servers for a number of

additional services in addition to Outlook Anywhere and MAPI connectivity:

Exchange Autodiscover - This allows Outlook 2007 and newer clients to

automatically configure their access to a user’s mailbox data without

Exchange Design

of 22

prompting the user for Exchange configuration information.

Exchange Web Services (EWS) - The Exchange Web Services provide

access to enhanced calendaring and out of office assistant functionality in

Outlook 2007 and newer as well as an entry point for application

developers to access Exchange data. Entourage for Mac and Mac Mail also

leverage the Exchange Web Services heavily.

Offline Address Book (OAB) Distribution - Outlook 2007 and newer

clients obtain the OAB from CAS servers instead of public folder servers.

Given that access to Exchange data will not be possible without the availability of

a CAS server, a high availability plan for the CAS environment is crucial. The best way

to provide high availability for CAS servers is via a hardware load balancing solution

which load balances all of the ports used by the various protocols. It is also possible to

leverage Windows Network Load Balancing Services (WLBS) for this function. Note

that in the case of a multi-role server (e.g. a combined mailbox and client access server),

it is not possible to run NLB on the server if the mailbox server is also a member of a

DAG.

The recommended solution for HACC is to deploy two identically configured

CAS servers for remote access as well as RPC access to mailboxes. These servers should

be placed behind a hardware or software load balancing solution.

When planning to deploy CAS servers in a DMZ or another specialized network

subnet which is isolated from other Exchange servers via a firewall, it is recommended

that a reverse proxy solution such as Microsoft Forefront Threat Management Gateway

(TMG) be used instead. The Microsoft TMG Servers are deployed in the DMZ and are

then used to “publish” the CAS servers. Microsoft does not support placing CAS

servers directly in a DMZ network.

Hub Transport Server Topology

Exchange Design

of 22

Hub Transport Servers are critical to the flow of messages inside and outside the

Exchange organization. Every single message or item a user submits must pass through

a Hub Transport server. When a user submits a new item, the mailbox server notifies a

Hub Transport server which picks the message up and processes it as necessary. Note

that this even applies to messages which are sent to a mailbox housed in the same

database or server as the sender. Hub Transport servers also route messages towards

their final destination either directly or via other transport servers. In scenarios where

multiple Active Directory sites contain mailbox or unified communications servers, a

Hub Transport server must exist in these sites in order for messages to be routed

between sites.

Hub Transport servers allow for messages to be processed prior to being

forwarded to their next hop destination. This functionality is exposed with transport

rules which provide an API for application developers to plug custom functionality into

the Exchange pipeline. While disabled by default, Hub Transport servers can also

execute message hygiene rules (such as SPAM filtering).

For routing mail outside of the Exchange organization, Hub Transport servers

depend on send and receive connectors to provide routing hints and next hop

information. Send connectors specify next hop destinations for external domains (such

as other email systems or the Internet) while receive connectors allow Hub Transport

servers to listen for SMTP traffic.

Based on the criticality of the Hub Transport role and the expected load upon the

role at HACC, it is recommended that the hub transport role be collocated with the

client access server role servers.

Exchange Design

of 22

Mailbox Server Configuration

The mailbox server role is the foundation of an Exchange environment and as

such it is critical that mailbox servers both be properly sized as well as configured for

high availability in a manner than meets the requirements of the organization.

High Availability Configuration

The HACC Exchange Server 2010 environment will depend on a single Database

Availability Group (DAG) to provide mailbox database failover for all users. HACC

will host two mailbox servers in their Harrisburg datacenter to provide server and

database level redundancy to end users. An additional mailbox server will be located in

a second geographically separate datacenter to provide for site-level disaster recovery.

Operating System Configuration

In order to implement the high availability plans specified in this document, the

Windows Server 2008 R2 Enterprise Edition operating system SKU is required for

mailbox servers which will be members of a Database Availability Group. Client Access

and Hub Transport servers can use the Windows Server 2008 R2 Standard Edition SKU.

The following table details the required operating System SKU for each server:

Server Name SKU

XMB01 Windows Server 2008 R2 Enterprise Edition



XSV01 Windows Server 2008 R2 Standard Edition




Hardware Configuration

Exchange Design

of 22

Standardizing on the hardware platform for Exchange servers across an

organization will inevitably reduce administration cost through simplification.

Administering a limited number of hardware platforms will reduce the need for testing

different configurations as well as make planning for hardware refreshes and upgrades

much easier.

Recommended HACC Mailbox Server (Local Storage)

Quantity Description

1 PowerEdge R710 Chassis for Up to Eight 2.5-Inch Hard Drives

2 Intel® Xeon® E5620, 2.40Ghz, 12M Cache, Turbo, HT, 1066MHz Max Mem

1 24GB Memory (6x4GB), 1333MHz Dual Ranked RDIMMs for 2 Processors, Optimized

1 PERC H200 Integrated RAID Controller, x8

8 1TB 7.2K RPM SAS 2.5" Hot Plug Hard Drive

2 High Output Power Supply, Redundant, 870W

1 iDRAC6 Enterprise

1 3Yr Basic HW Warranty Repair with SATA Ext: 5x10 HW-Only, 5x10 NBD Onsite

Exchange Design

of 22

Storage Design

The bulk of the storage used for the Exchange 2010 environment will either be

local (internal) or directly attached storage. Exchange 2010 provides vast improvements

over previous versions which greatly reduce (up to 70%) the I/O footprint of the

Exchange database engine. As a result, slower, higher capacity drives can be utilized in

some scenarios to reduce the overall storage cost while increasing the mailbox storage

available to end users.

Since some of the storage required for the environment was procured in advance

of the preparation of this document, the specifications for that equipment has been

included here. Any deficiencies in the existing storage with regard to recommended or

required configurations highlighted as necessary. Furthermore any additional storage

requirements have been specified and highlighted in the document.

Database Placement

Based on output from the Microsoft Exchange 2010 Storage Calculator as well as

industry best practices, the following layout for databases was prepared:

Database Name Replica Servers

DB01 XMB01, XMB02, XMB03






Database Configuration

Mailbox databases will house varying numbers of users with standardized

quotas based on the user’s mailbox profile as shown in the following table.

User Type Quantity Quota

Large Mailbox (FTE) 300 2GB

Standard Mailbox (Part Time) 3000 250MB

Exchange Design

of 22

It is assumed that the vast majority of part time (e.g. adjunct) employees will make

limited use of the email system.

Physical Storage Configuration

The following table details the LUNs required for the mailbox server design as

well as which databases and logs the LUNs will house. This configuration will be

duplicated on each mailbox server.

Server(s) LUN Size Description

XMB01,XMB02,XMB03 567GB DB01






Exchange Design

of 22

Backup and Restore

While complete backup and restore planning is outside of the scope of this

engagement, a number of observations and recommendations with respect to this

design and backup and recovery have been made. Backups are a critical step in the

lifecycle of Exchange databases. Transaction logs are not truncated until a successful

backup of the database occurs. If backups do not succeed for a prolonged period of

time, not only will restore capabilities be impacted, but databases will begin

dismounting if LUNs reach capacity due to transaction log explosion.

Backup Schedule

It is recommended that HACC backup their databases on a daily basis at a

minimum. Various backup tools such as Microsoft Data Protection Manager (DPM) and

Symantec Backup Exec support incremental backup models which may be

advantageous to implement in order to enable more granular data recovery scenarios.

The storage solution has been sized to tolerate a maximum of three consecutive days of

backup (or network) failure which would cause transaction logs not to be truncated. In

the event that backups are succeeding but database replication is not, Exchange will not

truncate logs upon the successful culmination of a backup in order to preserve the log

stream necessary for replication.

Recovery Targets

Many organizations set various service level objectives (SLOs) for the restoration

of messaging services in the event of a failure. There are two stages to restoration in

many incidents - dial tone and complete mailbox recovery. Dial tone recovery simply

provides users with an empty mailbox from which they can send and receive mail.

Once mailboxes are completely recovered via a Recovery Storage Group, the changes to

the dial tone mailbox will be merged back into the user’s actual mailbox. Users who are

Exchange Design

of 22

using Office Outlook 2003 or newer clients in cached mode will automatically begin

repopulating a dial tone database from the local OST (cache) file.

Complete mailbox recovery is the point at which all of the user’s data is available

to them as was the case prior to the failure. In the event of a catastrophic failure of a

single database, it is likely that that database can simply be switched over to another

copy in the database availability group (DAG). It should only be necessary to perform a

complete restore of a database in the event of a catastrophic failure which replicates

throughout the DAG.

Mailbox Data Recovery

Recovery Storage Groups were introduced with Exchange 2003 and allow

administrators to perform granular database restores to an online mailbox server

without impacting service to users or requiring a standalone restore server. Once a

mailbox has been restored to a recovery storage group, individual mailboxes can be

extracted to a PST or merged back in to the primary mailbox store.

End users have the ability to recover items they have deleted for up to thirty

days via the Recover Deleted Items functionality in Outlook and Outlook Web App

(OWA). Exchange Server 2010 introduces the concept of Single Item Recovery. Single

Item Recovery saves copies of all changes (such as edits and deletes) to an item for an

administrator defined period of time. This design calls for Single Item Recovery to be

enabled for all mailboxes, allowing administrators to recover any damaged or deleted

item from a user’s mailbox for a period of thirty (30) days. This functionality further

lessens the likelihood that an administrator will need to restore a mailbox from tape in

order to recover items for an end user.

Exchange Design

of 22

Hub Transport Configuration

Hub Transport servers have a number of configuration settings both individually

and organization wide which control the flow of messages throughout the organization.

Accepted Domains are used to define what domains the organization delivers mail for

while Send and Receive Connectors define the endpoints for sending and receiving

SMTP connections across the organization.

It is crucial to understand the critical role that hub transport servers play in the

flow of data in an Exchange environment. In order to enforce organization level rules

for the processing of messages as well as to provide fault tolerance in the event of a loss

or failover of a DAG member, every message in the organization passes through a Hub

Transport server. Consequentially, if there is no Hub Transport server available in a

mailbox server’s site, there will be no mail flow (including messages are to be delivered

to another user on the same mailbox server).

Additionally, when multiple Hub or Edge Transport servers are involved in the

flow of a message, Shadow Redundancy ensures that a message is never lost if a Hub or

Edge Transport server fails prior to delivering a message to its next hop destination.


In order to implement the plans specified in this document, the following

operating system SKU is required for Hub Transport servers:

Windows Server 2008 R2 Standard Edition






Exchange Design

of 22

much easier.

It is recommended that the Hub Transport/Client Access server roles be

virtualized where possible.

Due to the size and scope of the Exchange deployment discussed in this

document, the Hub Transport role will be collocated with the Client Access role across

the HACC organization.

Exchange Design

of 22

Client Access Server Configuration

The Client Access Server (CAS) role is the endpoint for nearly all client

communications with the Exchange environment. Different from previous versions of

Exchange is the termination of MAPI connections on the CAS server rather than on the

Mailbox server. This new design affords significant flexibility and increased availability

since clients are able to reconnect substantially quicker in the event of a mailbox

database or mailbox server failover.

In addition to MAPI connectivity, Outlook Anywhere (RPC/HTTPS), Outlook

Web App (OWA) and the Exchange Control Panel (ECP), Exchange Web Services

(EWS), POP3 and IMAP4, ActiveSync, and the Offline Address Book are hosted on the

CAS server. In order to provide for high availability of these services, it is necessary to

deploy multiple CAS servers behind a load balancing device or service.

There is a remarkably amount of configuration flexibility when it comes to the

various services exposed by Client Access Servers. The vast majority of these features

can be enabled, disabled, or managed by policy. This is particularly important when

considering features with security implications such as Exchange ActiveSync.


In order to implement the plans specified in this document, the following

operating system SKU is required for Client Access servers:

Windows Server 2008 R2 Standard Edition






Exchange Design

of 22

much easier.

It is recommended that the combined Client Access/Hub Transport servers be

deployed on a virtualized platform where possible. The specifications below are a

minimum recommended virtual machine configuration.

4x CPU Cores

8GB RAM

2x NIC

60GB Disk Storage

SSL Certificates

One of the more complicated and unfortunately painful parts of deploying Client

Access Servers (CAS’) is properly configuring the necessary SSL Certificates to encrypt

the communications with the CAS servers. Exchange Server 2010 requires certificates to

support a number of different principal names (similar to URLs) in order to provide

access to all of the services via one IP address. In order to support this requirement,

certificates with Subject Alternate Names or wildcard certificates must be used. The

downside of wildcard certificates is that some mobile devices in particular don’t

support them.

Subject Alternate Name certificates are frequently branded as Unified

Communications certificates and are available from many of the major certification

authorities. One certification authority, DigiCert (www.digicert.com) has a particularly

easy to use utility for generating certificates for Exchange Server 2010 and is a

recommended vendor.

Exchange Design

of 22

Summary

This document represents the recommendations of Moran Technology

Consulting (MTC) for a new Exchange Server 2010 environment for HACC. These

recommendations are based upon MTC’s formidable experience and understanding of

messaging and directory services environments. Substantial time and effort was spent

collecting requirements and feedback from the HACC IT community in an effort to

ensure that all of the stakeholders needs were represented and taken in to

consideration.

novell to microsoft conversion assessment: exchange 2010 design

Documents