Workshop Agenda

Module 1 - Overview of Exchange 2010

Module 2 - Exchange Server 2010 Prerequisites
Module 3 - Exchange Deployment Guidelines
Module 4 - Upgrading Exchange roles
Module 5 - Additional Upgrade Tasks

1
 Exchange Deployment Guidelines – Overview

Client Access Server Role

Hub Server Role
Mailbox and Storage
Combining Server Roles
Unified Messaging Role
Hardware Selection

2
 Client Access Server Role

Changes from Exchange 2007:

• The CAS role now handles all client communication (OWA,
EAS, Outlook RPC, Outlook Anywhere, EWS, POP, IMAP)
• The DS Proxy component is gone. AD Lookups for Outlook
Clients are now served by the Address Book Service on the
CAS and no longer by direct DC/GC connections
• WebDAV is gone from Exchange (can affect Entourage on
Apple, PFDavAdmin is replaced by ExFolders)
• Middle Tier Throttling, Move Request Service
• Many enhancements to EWS: MailTips, Message Tracking,
Federated Sharing

3
 CAS Placement

CAS servers were designed to be placed in the internal

network. They require access to Active Directory access and
a numerous ports to be opened to the backend servers.  
Therefore, it is not supported or recommended to put the
CAS in the DMZ (use ISA/TMG/UAG/3rd party reverse
publishing solution).
http://msexchangeteam.com/archive/2009/10/21/452929.aspx
A CAS server is required in every Active Directory Site where
Exchange is being deployed.
To provide redundancy a minimum of two CAS servers
should be deployed.

4
 CAS Placement continued.

CAS servers require fast links to the mailbox servers (1

GigE) and infrastructure servers (GC/DC)

CAS coexistence with CAS 2007/Exchange 2003 FE is

covered later in the Upgrading module.

5
 CAS High Availability

To provide resiliency for two or more CAS boxes the use of

NLB or a 3rd Party hardware load balancer is required.
Preliminary guidance for load balancing configuration using
Windows NLB:
Service Ports Required Type of LB Affinity Unicast/Multicast
OWA TCP 443 Cookie Required
OA TCP 443 Client IP  
MAPI/RPC TCP 135 Client IP  
TCP 1024-65535

Single NIC: Multicast

Multiple NICs: Unicast
 
ActiveSync TCP 443 Client IP Note: Unicast works with a broader
EWS TCP 443 Client IP Required set of switches and won’t broadcast
to all ports on a VLAN
POP TCP 110 (no SSL) Client IP  
TCP 995 (SSL)
SMTP 587 (HUB)
IMAP TCP 143 (no SSL) Client IP  
TCP 993 (SSL)
SMTP 587

6
 CAS High Availability

You can use either Windows NLB or hardware load

balancers depending on the number of server and your HA
requirements.
• Use Windows NLB for small and medium sized deployments.
• Use Hardware Load Balancers for large deployments > 8 CAS
Servers.
o Using a Hardware NLB brings additional benefits:
- More intelligent handling of requests (Windows NLB will continue to
send requests as long as the server is reachable even if IIS is not
running, for example the Exchange services are not running but the
server still responds to a ping request)
- Can provides additional scalability options
- Win NLB cannot be used on multirole Server if DAG member

7
 CAS sizing guidelines

2-socket platform best for performance and TCO

CPU is typically the bottleneck, memory sizing is key as well
3 CAS CPU cores for every 4 Mailbox CPU cores (servicing
active users)
Load balancing is important for performance and high
availability
2GB RAM per CPU core is optimal

9
 Client Access Server Workloads

CAS Workload Relative Cost Comparison

Workload impact on CAS server
CPU Network
depends on user profiles & mix Workload Cost Cost
of workloads (MHz/user) (Kbytes/sec/user)

CPU & memory scale guidance Outlook 0.35 0.37

for CAS based on mixed-protocol Outlook Anywhere 0.80 0.44
heavy information worker profile Exchange
1.60 1.04
Consider other workloads and ActiveSync
adjust Exchange Web
0.71 0.54
All MAPI traffic now affects CAS Services
Outlook Web Access 0.86 0.88
Use Windows Server 2008 R2
for best CAS scale IMAP4* 0.86 0.14
• Major improvements in Outlook POP3* 0.33 0.79
Anywhere, potentially scaling to * IMAP4 & POP3 protocols do not support sending new mail, so the observed
costs do not reflect any sent messages within the user profile.
15k Outlook Anywhere users on
8-core CAS

11
 Exchange Deployment Guidelines – Overview

Client Access Server Role

Hub Server Role
Mailbox and Storage
Combining Server Roles
Unified Messaging Role
Hardware Selection

12
 What‘s new in Hub Transport 2010?

Shadow Message Queue

• Maintain a shadow copy of messages until they are
confirmed delivered to the next hop (if next hop is shadow
transport aware).
• Delay SMTP complete commands until the message has
been delivered to the store.
Transport Dumpster
• Improved DAG failover scenarios
End-to-End Message Latency Tracking
• Provides comprehensive message latency tracking for
SLA‘s

13
 Hub Transport Role Placement

The Hub Transport Role is responsible for handling all mail

communication. It is required to have a Hub Transport server
in each AD site (that an Exchange 2010 server will reside).

Intrasite communication is handled by any available Hub

Transport server. They are picked in random order.

If the sender and recipient mailboxes are on the same server,

messages are still routed over a Hub Transport server.

18
 Sizing Hub Transport Servers

Processor core ratio – MBX:HT

• 7:1 (if no AV/Antispam processing is done on HT)
• 5:1 (if AV/Antispam is done on HT)
Processor recommendation:
• 4x Cores recommended, 12x cores maximum
Memory guidance:
• 1 GB memory per core, 4GB minimum, 8GB recommended
Size storage capacity for queue and Message Tracking Log
requirements

19
 Sizing Hub Transport Servers

Disk guidance:
• Hub Transport servers in 2007 created substantially I/O
on the disk containing mail.que database. Therefore, we
ran into memory pressure easily, especially when sending
and receiving huge amounts of mail.
• Exchange 2010 ESE engine on HT leads to a 50% I/O
reduction on the Hub Transport mail.que disk.
• Recommended: Put mail.que on a dedicated disk, away
from the Exchange installation
• Use battery-backed write cache disk controller

20
 Hub Transport High Availability

Bringing HA to Hub Transport

• By adding more Hub Transport servers to one AD site,
automatic load balancing and high availability is in place.
• If it is required to have high availability for port 25 (SMTP),
eg in case of a mail gateway or relay, you can use load
balancing to provided HA.
• It is not supported/recommended to load balance
Exchange 2010 internal communication.

21
 Exchange Deployment Guidelines – Overview

Client Access Server Role

Hub Server Role
Mailbox and Storage
Combining Server Roles
Unified Messaging Role
Hardware Selection

22
 What‘s new with the Mailbox role for 2010?

Reduced I/O footprint (70 % reduction from Exchange 2007,

90% from Exchange 2003)
Exchange 2010 was optimized for SATA disks
The SCR/CCR/LCR features have been replaced by DAG
(Database Availability Group)
Public Folder transaction log file replication is no longer
available (PF content replication is still available)

23
 What‘s new with the Mailbox role for 2010 continued

High Availability is provided by DAG

Additional DB copies possible up 16 (the two node CCR
limitation no longer applies)
The MBX role does not allow direct client connections all
connections must go through the RPC Client Access
• For mailbox access all communication is through CAS
• For PF the RPC Client Access service on the MBX server
Improved Site Resilience features provided
Much more!

24
 Sizing the Mailbox Role – Server HW

Overall available
megacycles per
processor (socket)
increasing rapidly
• Per core megacycles
constant or decreasing
to maintain power
requirements
Processor technology
improvements make
GHz comparison
somewhat
meaningless
25
 Sizing The Mailbox Role

2-socket platform best for performance and TCO

User profile determines resource requirements for IOPS,
memory, CPU
High Availability (Database Availability Groups)
• HA requires additional resources to provide resiliency and
protection
• Sizing a highly available system implies sizing for the
worst case scenario
Storage & memory are most critical

26
 Sizing the Mailbox Role – Storage

Estimated IOPS Per-Mailbox

Storage must be sized for Messages Database Estimated Estimated
• Performance (IOPS) per mailbox cache IOPS: IOPS:
per day per Single Multiple
• Capacity (GB) (~75KB mailbox database database
average
(MB) copy copies
Performance sizing based on message size)

user profile (message 50 3 .060 .050

throughput) 100 6 .120 .100

Capacity sized based on user 150 9 .180 .150

mailbox size 200 12 .240 .200

• Factor in whitespace, 250 15 .300 .250

dumpster, etc. 300 18 .360 .300
350 21 .420 .350
Design will either be
performance- or capacity- 400 24 .480 .400
bound 450 27 .540 .450
500 30 .600 .500

27
 Sizing the Mailbox Role – Memory (1)

Mailbox Role Cache

Services need base memory for ongoing Memory Sizing
operations: Messages Database
• Basic overhead for user requests per mailbox per cache per
day mailbox
• Content indexing (~75KB average
(MB)
message size)
• Mailbox assistants 50 3
Store process needs per-user memory for 100 6
database cache, based on user profile 150 9
• Properly sized database cache memory 200 12
required for IOPS reduction 250 15
Deep checkpoint depth + 32KB pages allow 300 18
E2010 to benefit from larger memory 350 21
configurations than E2K7 400 24
450 27
500 30

28
 Sizing the Mailbox Role – Memory (2)

Default Mailbox DB Cache Sizes

Cache size defaults based on Server Installed Database Cache Database
installed RAM Physical Size (Mailbox Role Cache Size
Memory Only) (Multi-role)
• Size per-mailbox memory, then
Not
map to fit in default cache 2GB 512MB
supported
• Remaining memory reserved for Not
base service requirements 4GB 1GB
supported
For example: 8GB 3.6GB 2GB
• 4000 users with the 200 profile 16GB 10.4GB 8GB
(12MB per mailbox): 4000*12MB 24GB 17.6GB 14GB
= 48GB 32GB 24.4GB 20GB
• 48GB fits in 53.6GB default 48GB 39.2GB 32GB
cache 64GB 53.6GB 44GB
• Deploy 64GB server 96GB 82.4GB 68GB
128GB 111.2GB 92GB

29
 Sizing the Mailbox Role – CPU

Estimated Per-Mailbox CPU

Proper CPU sizing is critical:
Consumption
sizing of other roles depends on it
Messages Megacycles for
Megacycle values provided are per mailbox active or stand- Megacycles
per day alone mailbox for passive
based on a particular reference (~75KB average (increase by 10% for mailbox
platform, newer CPUs differ message size) each passive copy)

50 1 .15
• Megacycle adjustment based on
100 2 .3
SPECint may be required
150 3 .45
Sizing process & calculation can
200 4 .6
get somewhat complex
250 5 .75
• Use calculator tools to simplify this
300 6 .9
process
350 7 1.05
Recommend disabling
400 8 1.2
hyperthreading
450 9 1.35
• May cause capacity planning &
500 10 1.5
monitoring challenges
30
 Sizing the Mailbox Role - HA

Size for double failures

Do not overcommit resources
• Spread node failure across all available nodes not one or two
• Distribute database (DB) copies across nodes in a matrix
Improved DB seed/log shipping performance across WAN
• Log Shipping compression/encryption (opt in)
• New log shipping architecture (Transport Control Protocol (TCP)
socket based as opposed to Server Message Block (SMB))
• Improved high latency capability
Use multiple 1GB networks or 10GB network
• Improves LAN re-seed/log replication queue drain performance
• Especially with large servers and/or large databases

31
 Exchange IOPS Trend

DB IOPS/Mailbox
+90%
1 Reduction!

0.8

0.6
IOPS/Mailb
ox
0.4

0.2

0
Exchange 2003 Exchange 2007 Exchange 2010

33
 Sizing Storage - Storage options

34
 Interesting Storage Configuration Best Practices

Description Stand-Alone High Availability

File Placement: for recoverability Isolation of logs and
Database/Log Isolation separate database file databases not required
(.edb) and logs
NTFS Allocation Unit Size 64 KB for both database and log volumes
GUID Partition Table (GPT) Use GPT partitions

Access of Volumes Mount point host volume must be RAID'ed.

.
Windows Bitlocker (volume Supported for all Not Supported for all
encryption) Exchange database Exchange database and
and log files log files

35
 Sizing Storage – Consideration points

When sizing, take into account all the potential factors for
your storage implementation:
• Mailbox Count
• Concurrency
• Mailbox Size
• Usage Profile
• Client Types
• Client Extensions (Search, OCS,….)
• Server Applications
• HA Requirements
• DB Whitespace
• Recoverable Items and Mailboxes

36
 Sizing Storage - Tools

Exchange Profile Analyzer

• Used to determine the Information Worker profile (eg average,
heavy,..)
• http://technet.microsoft.com/en-us/library/bb508856(EXCHG.65).aspx
Perfmon
• Used to determine User concurrency etc.
• Included with every Windows installation
Storage Calculator for Exchange 2010
• Used to determine the I/O needs of the solution, required
database and log LUN sizes, etc.
• http://msexchangeteam.com/archive/2009/11/09/453117.aspx

37
 Sizing Storage – Tools cont.

Jetstress
• Used to determine the I/O capability and reliability of a storage
solution before putting it in production.
• http://
www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=13267
027-8120-48ed-931b-29eb0aa52aa6
Loadgen
• Used to test the whole Exchange deployment before putting it
in production – end to end.
• Simulates real client traffic – OWA, Outlook, Outlook Https,
ActiveSync,….
• http://
www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=cf464
be7-7e52-48cd-b852-ccfc915b29ef

38 Don‘t run Jetstress or Loadgen in production

 Tools Process Flow

User
Profile Exchange Load Generator

Mailflow
Exchange Profile Analyzer & Other Stats

Exchange Storage Calculator

User
Profile

IOPS
Performance Monitor
Exchange Jetstress

39
 Exchange Deployment Guidelines – Overview

Client Access Server Role

Hub Server Role
Mailbox and Storage
Combining Server Roles
Unified Messaging Role
Hardware Selection

40
 Combining Server Roles - Hub/CAS

2-socket platform best for performance and TCO

CPU is typically the bottleneck, memory sizing is key as well
1 Hub/CAS CPU core for every 1 Mailbox CPU core
2GB RAM per CPU core is optimal
Potentially optimal hardware utilization
• Hub and CAS roles are relatively well balanced given resource requirements

Server consolidation – minimize physical servers

41
 Combining Server Roles - Hub/CAS/MBX

Recommend maximum 4-socket platform (8—24 cores)

Use 8GB RAM plus 3-30MB per mailbox (see Mailbox role sizing details)
Mailbox, CAS, and Hub Transport roles recommended
• UM supported, but not recommended
Excellent solution for high core configurations
Half of cores for Mailbox, half for CAS+Hub
Typical deployment scenarios:
• Simple unit of scale (brick) model
o Each multi-role server represents a building block
o Servers with on-board SATA storage (10-16 disks) are optimal
• Small organization/branch office – server consolidation
o Minimize the number of physical servers, operating system instances, and
Exchange server instances to manage

42
 Exchange Deployment Guidelines – Overview

Client Access Server Role

Hub Server Role
Mailbox and Storage
Combining Server Roles
Unified Messaging Role
Hardware Selection

43
 Unified Messaging

2-socket platform best for performance and TCO

2GB RAM per core is optimal
CPU is typically the bottleneck, particularly when Voice Mail
Preview is being used
Default 100 concurrent calls per server (inbound or
outbound)
Voice Mail Preview is CPU intensive: ~1 message/min/core
Scale out UM servers based on concurrent call requirements
Size CPU based on requirements for Voice Mail Preview

44
 Exchange Deployment Guidelines – Overview

Client Access Server Role

Hub Server Role
Mailbox and Storage
Combining Server Roles
Unified Messaging Role
Hardware Selection

45
 Hardware Selection - Exchange Solution Reviewed
Program

ESRP encourages storage vendors to properly test storage

solutions with Exchange workloads
Results are published in the form of solution whitepapers for
a particular user count & profile
Overall test process validated by Microsoft prior to posting
link to completed whitepaper
Many Exchange 2010 solutions posted from Dell, EMC, HDS,
HP, IBM, NetApp, and Xiotech and others
http://technet.microsoft.com/en-us/exchange/ff182054.aspx

46
 Terms of Use

© 2010 Microsoft Corporation. All rights reserved.

Information in this document, including URL and other Internet Web site references, is subject to change without notice.
Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people,
places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain
name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright
laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced,
stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical,
photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
For more information see Microsoft Copyright Permissions at http://www.microsoft.com/permission
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject
matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this
document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
The Microsoft company name and Microsoft products mentioned herein may be either registered trademarks or trademarks of
Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned
herein may be the trademarks of their respective owners.
THIS DOCUMENT IS FOR INFORMATIONAL AND TRAINING PURPOSES ONLY AND IS PROVIDED "AS IS" WITHOUT
WARRANTY OF ANY KIND, WHETHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED
WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT.

47