Exchange Server 2010 Introduction to

Supporting Administration
High Availability

Jonathan Runyon
Exchange 2010 BRE Content
Microsoft
1 1/1/2009 Microsoft Confidential - For Internal Use Only
 1

Module Overview
Before You Begin
Complete the module Managing Access to Exchange Server 2010
Administrative Tasks with RBAC from this course.
Be familiar with using Windows PowerShell commands to manage
an Exchange organization.
What You Will Learn
After completing this module you will be able to:
Describe mailbox high availability features for Exchange Server
2010.
Design, deploy and manage high availability features for Exchange
Server 2010.
Analyze and troubleshoot mailbox high availability features for
Exchange Server 2010.
 2

Lesson 1: Exchange 2010 High Availability

Overview
 2

Lesson 1: Exchange 2010 High Availability Overview

After completing this lesson you will be able to:
Understand the need for mailbox high availability solutions
in Exchange organizations.
Describe the challenges and limitations administrators
faced in deploying high availability features in earlier
versions of Exchange.
Discuss the benefits and advantages of the new high
availability features made available with Exchange Server
2010.
 3

High Availability Concepts

Terminology
See table in workbook
Scenarios
Highly Available Mailboxes
Site Resiliency
Disaster Recovery Contingency
 7

Exchange Legacy High Availability History

Features
Clustered Mailbox Server
Exchange Server 2003
Exchange Server 2007
Single Copy Cluster (SCC)
Cluster Continuous Replication (CCR)
Storage Groups
Recovery Storage Groups
Database Portability
Continuous Replication
Local Continuous Replication (LCR)
Cluster Continuous Replication (CCR)
Standby Continuous Replication (SCR)
 9

Challenges
Clustered Mailbox Server Setup and Administration
Clustered mailbox servers are complex and difficult to deploy
Shared Storage can be an Expensive Single Point of Failure
Clustered Mailbox Server Deployment Requires Careful Planning
Failovers Occur at the Server Level
Clustered Mailbox Servers are Limited to Mailbox Server Role
Database Resiliency
Site Resiliency
 12

Exchange 2010 High Availability

New Features
Incremental Deployment
Continuous Mailbox Availability
Database Mobility
Database Availability Groups
Backup-less Organizations
Self Healing Database Copies
Online Mailbox Moves
Catalog Index Improvements
 16

Lesson 2: Exchange 2010 High Availability

Architecture
 16

Lesson 2: Exchange 2010 High Availability Architecture

After completing this lesson you will be able to:
Describe incremental deployment of Exchange Server 2010
highly available mailbox features.
Discuss database mobility and continuous mailbox
availability concepts.
Discuss Inter-site continuous mailbox availability concepts.
Discuss backup and recovery scenarios for highly available
mailbox databases.
Discuss the implementation of content indexing for highly
available mailbox databases.
 17

Highly Availability Mailbox Servers

A New High Availability Model
Incremental Deployment
Database Redundancy
Server Availability
Client Connectivity
Messaging Resilience
 18

Incremental Deployment
Deployment Improvements
Setup and Management
Role Coexistence
Flexibility
 20

Database Availability Groups

Overview
DAG Components
Windows Failover Clustering Implementation
 20

Overview
DAG Requirements
General Requirements
Members must be in same AD domain
Not supported for Mailbox role on AD server
Hardware Requirements
No special hardware requirements different from mailbox server role
Software Requirements
Requires Windows Failover Clustering (WFC)
Requires all members to run same version OS
Network Requirements
Similar to previous implementations
 21

DAG networks
Each DAG can have multiple networks:
A single MAPI network, which is used by other Exchange 2010
servers to communicate with the Mailbox servers in the DAG
One or more Replication networks, which are used for log shipping
and seeding within the DAG
Each network must be on its own subnet
Multiple subnets must be routable as required to ensure
connectivity between members
No direct routing that allows heartbeat traffic from replication
network on one member to MAPI network on another member, or
vice versa
 22

DAG networks continued

Each member of the DAG must have round trip network
latency no greater than 250 ms between each other
member.
Total network load between datacenters must be considered
DAG networks support IPv4 and IPv6.
IPv6 is supported only when IPv4 is also used; a pure IPv6
environment is not supported.
 22

Dag Name and IP Addresses

Each DAG has a unique network name, and one or more IP
addresses (static or DHCP).
Requires a minimum of one IP address on the MAPI network.

Two
SameSubnets
Subnet
 23
Switchovers

DAG mailbox server currently hosting active copy of

mailbox database copy is the database master
Administrative action that changes the master from one
DAG member to another is called a Switchover
Switchovers allow administrator to:
Load balance active databases across DAG members
Prepare DAG members for maintenance
 24

Failovers
A Failover occurs when one or more active database
copies become unavailable, and the DAG automatically
takes action to restore service
Failover actions can take place at the database level or
the server level
A single database failure does not affect availability of
other active databases on the same DAG member
Server level failures affect all database copies on the server
For every database copy that was active on the failed server, a
passive copy on another DAG member is selected and activated
 25

Site Resilience
DAG membership can extend across multiple datacenters
When a failure occurs at the datacenter level, complete
failover to resources in another datacenter can be initiated
This is a Datacenter Failover, and is considered a disaster
recovery event
Failover is a manually initiated procedure that follows a specific
process to restore availability
 25

DAG Components
DAG Cluster
Relies on Windows Failover Clustering “under the hood”
DAG can contain up to 16 members
DAG Processing
Microsoft Exchange Replication service (MSExchangeRepl.exe)
maintains DAG operation and is responsible for:
Continuous replication of databases
Automatic failover of databases and servers
 26
DAG Configuration Object

DAG properties are stored in AD on DAG configuration

object:
DAG Name - DAG name is also used for the DAG cluster name
File Share Witness server - Contains the UNC share path for the
File Share Witness of the DAG cluster
File Share Witness directory - Contains directory path for the
parent folder used to store the quorum information
Back-link to member servers - Populated with distinguished
name of each DAG member server
DAG network settings - Contains settings for network encryption
and compression for DAG networks
 26
DAG Networks

A DAG network is automatically created for each network

Replication port - Specifies the TCP port used by the DAG to replicate
database information (default is 64327)
Network compression and encryption settings - DAG networks can be
set to use compression and encryption always, only between subnets, or
only when seeding databases
DAG network names - Each DAG network is given a name upon
creation, can be changed to a meaningful name
Description - Administrator can specify a meaningful description for
each DAG network
Replication settings - Each DAG network can be set to enable or disable
replication (default is allow)
Subnet settings - Each DAG network specific subnet through which
connections are possible
Configuration information is stored in the cluster database
Configuration under key:
Computer\HKEY_LOCAL_MACHINE\Cluster\Exchange\DagNetwork
 27

DAG Network Encryption and Compression

Encryption leverages capabilities of Windows OS
Kerberos encryption between Exchange servers
Compression leverages XPRESS algorithm
Same compression used in MAPI RPC between Outlook and
Exchange
Encryption and Compression settings are DAG wide an
apply to all members
Setting Description
Disabled Network encryption is not used.
Enabled Network encryption is used on all DAG networks for
replication and seeding.
InterSubnetOnly Network encryption is used on DAG networks on the same
subnet.
SeedOnly Network encryption is used on all DAG networks for seeding
only.
 28
DAG Management

Exchange Management Console

DAG Creation
DAG Membership
DAG Properties
DAG Networks
Exchange Management Shell
*-DatabaseAvailabilityGroup
*-DatabaseAvailabilityGroupServer
*-DatabaseAvailabilityGroupNetwork
Task Logging
Log file is generated each time a specific task is executed
Records each action taken by the task, and the results of each action
Written by default in the %SystemDrive
%\ExchangeSetupLogs\DagTasks folder
 30

Windows Failover Clustering Implementation

Cluster core resource types – created when the DAG
cluster is formed and updated as DAG changes
Network Name Resource
IP Address Resource
File Share Quorum Witness resource
Cluster Name – uses the same name as the DAG
Cluster Name Object (CNO)
Can be pre-staged in AD before DAG is created
Cluster Networks – created when the DAG cluster is
formed, updated as network changes
 34

Cluster Quorum
Prevents split brain
Quorum Models
Node Majority
Node and File Share
Majority
Depends on the number
of DAG members
Automatically configured
by DAG management
 35
File Share Witness

Requirements for the Witness server are:

Witness server cannot be a member of the DAG
Witness server must be in the same forest as the DAG
Witness server must be running Windows Server 2003, Windows
Server 2008, or Windows Server 2008 R2
A single server can serve as a witness for multiple DAGs;
however, each DAG requires its own separate directory
%systemdrive%\DAGFileShareWitnesses
Example: C:\DAGFileShareWitnesses\condag1.contoso.com
Alternate File Share Witness
Used in site resiliency scenarios when main FSW is unavailable
 38
Datacenter Activation Coordination (DAC) Mode

DAC mode is a property setting for DAGs with three or

more members that are extended to multiple sites
DAC mode is designed to prevent split brain from
occurring by including a Datacenter Activation Protocol
(DAP)
After a catastrophic failure, DAG does not automatically mount
databases even though the DAG has quorum
Primary Active Manager (PAM) must coordinate with the Standby
Active Managers (SAMs) in the DAG to determine the current state
of the DAG and whether Active Manager should try to mount the
databases
 39

Database Mobility - Overview

Database Copies - There are significant changes in how
Exchange defines and utilizes mailbox databases
Continuous Replication - The log shipping technology
introduced in Exchange 2007 Cluster Continuous
Replication (CCR) and Standby Continuous Replication
(SCR) has been combined and improved
Self-Healing Databases - Exchange 2010 incorporates
functionality that detects and automatically corrects
divergence between database copies at the database page
level
 39

Database Copies
Flattened Schema
Database Property Details
Using Database Copies
 40

Flattened Schema
Legacy Exchange Mailbox
Database Directory
Objects
Exchange 2010 Mailbox
Database Directory Objects
 41

homeMDB
The homeMDB attribute ties the mailbox to the mailbox
database
The basic logic processed by the Client Access server is as
follows:
User 1 requests access to her mailbox
|
The mailbox for User 1 is in Database “A-D”
|
An active copy of Database “A-D” is on Server MBX01
|
Access User1’s mailbox from Database “A-D” on Server
MBX01
 44

Database Property Details

Database Object
Master Server or Availability Group
Database File and Transaction Logs
Maintenance
Client Settings
Quota
Content Indexing
Recovery
RPC Endpoint
Database Copy Object
Host Server Link
Activation Preference
Continuous Replication Settings
Replay lag and Truncation lag
 46

Using Database Copies

Copies can be created on multiple Mailbox servers in the
DAG
You cannot create two copies of the same database on a single
server
A mounted database copy is referred to as Active
All other copies of the same database are dismounted and referred
to as Passive
Only one copy of a given database can be active at a time
Exchange 2010 mailbox databases can be replicated only
between Exchange 2010 Mailbox servers in a DAG
You cannot replicate an Exchange 2010 mailbox database to a
server running Exchange 2007 or vice versa
 45

Using Database Copies continued

All database copies can be backed up using Exchange-
aware, Volume Shadow Copy Service (VSS) backup
applications
All copies of a given database use the same file path on
each server containing a copy
File paths for a given database copy on each Mailbox server must
be dedicated to that database and not conflict with any other
database file paths
Multiple database directories can share the same parent directory
Database copies can be created on DAG servers in the
same or different Active Directory Sites
DAG servers can be on the same or different network subnets
Database copies are not supported between DAG servers with
round trip network latency greater than 250 milliseconds (ms)
47
 48

Continuous Replication
Replication Architecture
Replication Processing
 48

Replication Architecture
Replication Service
Processing Overview
Replication Service Object Model
Administration and Processing
Replication Service Registry Values
Log Shipping and Log File Management
Log Truncation
Replay and Truncation Lag
 48

Replication Service
Installed by default as part of the Mailbox server role
MSExchangeRpl.exe, located in the <install path>\bin directory
Dependent upon only the Microsoft Exchange Active
Directory Topology Service
Configured to start automatically at startup, and to restart
in case of a failure or exception
Responsible for continuous replication
Whether the server is the source or the target of replication
Handles both instances simultaneously
Runs continuously on the mailbox server role
Even if there are no mailbox database copies set to replicate to or
from the server
 49

Processing Overview
Continuous Replication Pattern
First step, copy the source database to the destination server to
create a target passive database copy (initial seeding)
Periodically check for new transaction logs in the active database
log directory
Copy any new transaction log files to the target log directory.
Inspect the copied transaction log files at the destination to make
sure they are viable
Reject any transaction logs that fail inspection and then request
another copy from the source
Replay the transaction log files from the destination log directory
into the passive database
 51

Replication Service Object Model

Replay Manager – manages replication for all database
copies on the server
Replica Instances – one for each database copy
SourceReplicaInstance
TargetReplicaInstance
SingleCopyReplicaInstance
TargetReplicaInstance – drive replication for the copy
LogCopier
LogInspector
LogReplayer
LogTruncater
Incremental Reseeder – insures copies are not diverged
after failover
Seeder – responsible for creating baseline content of copy
 51

Administration and Processing

Takes place at the database level
Management tasks for
Creation of new copies
Configuration of copy instances
Monitoring of database continuous replication
 52

Replication Service Registry Values

Parameters – available for “tweaking”
State – stores the current replication state
DumpsterInfo – stores information for driving recovery
after “lossy” failover
StateLock – used to manipulate state values from within
replication service
See appendix for additional information (still under
development)
 52

Log Shipping and Log File Management

Log Shipping Directory Structure
Inspector - contains log files copied by the LogCopier
incseedInspect – used during incremental reseed operation to hold
temporary files
IgnoredLogs - keep log files that cannot be played for any reason
E00OutofDate
holds any old E00.log file that was present on the passive copy at the time
of a failover
InspectionFailed
Used to hold log files that have failed inspection (event 2013 is logged)
Log file is then moved to the InspectionFailed directory
ESE used to verify that a log file is physically valid
Exception returned by these checks is considered a failure
 53

Log Truncation
Log truncation is coordinated across multiple database
copies in a DAG
Information Store is responsible for truncating log files on
the active database using ESE.DLL or ESEBACK.DLL
Depends on whether continuous replication is enabled and
whether circular logging is enabled
ESE.DLL is responsible for log truncation when replication is not
enabled and “normal” circular logging is enabled
ESEBACK.DLL is responsible for log truncation When replication is
enabled
You can combine circular logging with continuous
replication
Continuous Replication Circular Logging (CRCL) is performed and
managed by the Replication service
 54

Log Truncation (continued)

In order for a log to be truncated on the active database
copy, the following criteria must be met
The log file has been backed up (ignored if circular logging is
enabled)
The log file generation sequence is below the log file checkpoint
for the database
All other database copies that are not using replay lag must have
successfully replayed the log file
All other database copies that are using replay lag must have
successfully inspected the log file
 54

Replay and Truncation Lag

Delayed Log Replay
Designed to minimize the chance of needing to reseed when the
source experiences a lossy failure
Delayed Log Truncation
Designed so that the logs on the target can be used to recover
from loss on the source database
Both replay and truncation settings are in d.hh.mm.ss and
are set on the database copy properties using
Set-MailboxDatabaseCopy
14 day maximum setting
Each feature can be used independently or together on
the same database copy.
 54
Lagged Replay and Logical Corruption

Database Logical Corruption

Database pages pass checksum verification, but the data on the
pages is wrong logically
The data either never makes it to disk or gets written to the wrong
place (lost flush)
Lost flush detection mechanism in the ESE database coupled with single
database page restore feature (page patching)
Store Logical Corruption
Data is added/deleted/changed in a way that the user does not
expect
Caused by 3rd party client and server applications
Only corruption in the sense that the user views it as corruption,
store simply sees it as a series of valid MAPI operations
When a user mailbox gets so “corrupted” on such a large scale, it is
easier to restore the database to a point back in time to a state
before the corruption occurred
 55

Lagged Truncation
The following criteria must be met in order for log
truncation to occur on a lagged database copy:
Must be below the checkpoint for the database
Must be older than ReplayLagTime + TruncationLagTime
Must have been truncated on the active copy
 55

Limitations
Lagged database copies should be thought of as disaster
recovery copies or backup copies
A database with a replay lag may take many hours to replay logs
Careful planning is required
To improve recoverability, when only one database copy is
lagged it should be stored on a RAID disk array
Lagged database copies are not patchable with the single
page restore feature
If a lagged database copy suffers page corruption (JET database
error -1018), the database must be reseeded, thus loosing the
lagged aspect of the copy.
 56

Replication Processing
Replication Monitoring
Initial Seeding
Log Replication
Status/Suspend/Resume operations
 56

Replication Monitoring
Current replication status for a database can be
determined using task Get-MailboxDatabaseCopyStatus
Also displayed in Work pane of EMC
Examples:
Healthy - Copy is successfully copying and replaying log files, or it
has successfully copied and replayed all available log files
Seeding - Is being seeded and/or the content index for the
mailbox database copy is being seeded
FailedAndSuspended - States have been set simultaneously by
the system because a failure was detected, and because resolution
of the failure explicitly requires administrator intervention
See table in workbook for full listing
 59

Initial Seeding
Choosing what to seed
Database and Content Index Catalog
Selecting the Source for Seeding
Any copy can be used as a source (active, passive, local, remote)
Seeding and DAG Networks
Can specify network to use for seeding, else default behavior
applies (see rules)
Can override compression and encryption settings
Manual Seeding
Rarely needed but possible using the Update-
MailboxDatabaseCopy task
Postponed Seeding
Creates the copy configuration object, but seeding is not
performed automatically
 59

Initial Seeding
 62

Log Replication
 65

Status/Suspend/Resume operations
Get-MailboxDatabaseCopyStatus
 67

Status/Suspend/Resume operations (continued)

Suspend/Resume-MailboxDatabaseCopy
 70

Active Manager
Overview
Active Manager Architecture
 70

Active Manager Overview

Mount and Dismount Databases
Determines the best available database copies to mount and takes
action as needed
Provide Database Availability Information
Maintains a cache of database availability information used by Rpc
Client Access (RpcCA)
Propagated between servers that share copies of the same
databases
Provide Interface for Administrative Tasks
Monitor for Failure
Monitors for database level failures reported by the information
store, and server level failures reported by WFC
Maintains Database and Server State Information in the
registry
Active Manager Architecture
Active Manager Startup and Processing
Master Database Cache
Persistent Database and Server State Information
Database Actions
 69

Active Manager Startup and Processing

Active Manager Roles
Standalone – server not member of DAG
Primary Active Manager (PAM) - master of all DAG operations
Secondary Active Manager (SAM) – receives actions from PAM
Role Determination
Cluster Group owner is the PAM
PAM ownership changes when Cluster Group ownership changes
Members constantly monitor for change in ownership as reported by
WFC
Coordinated between DAG members to make sure the right server
becomes the PAM
 71

Master Database Cache

The DatabaseLocationCache is an in-memory cache (table)
maintained by AM
The DatabaseLocationCache contains information about
which database is currently mounted on which server
Anytime a database is mounted on a server, the local
DatabaseLocationCache is updated first and then this
information is propagated to all other servers which can
have a copy of the database
 72

Persistent Database and Server State Information

DAG database/server state information
Used by PAM to determine state
HKLM\Cluster\ExchangeActiveManager\*

Standalone database/server state information

Used by AM on standalone server to determine state
HKLM\SOFTWARE\Microsoft\ExchangeServer\v14\ActiveManager\*

DbState Database State Information

ActiveServer
LastMountedServer
LastMountedTime
MountStatus
IsAdminDismounted
IsAutomaticActionsAllowed
 74

Database Actions
Standalone Mailbox Server Database Actions
AutoMount Database
Mount Database
Dismount Database
DAG Database Actions
AutoMount Database
Mount Database
Dismount Database
Move Database
AutoDismount Database
 78

Active Manager Best Copy Selection

Case Criteria

1st Content index with a status of Healthy

Copy queue length that is less than 10 log files
Replay queue length of less than 50 log files
2nd Content index with a status of Crawling
Copy queue length that is less than 10 log files
Replay queue length of less than 50 log files
3rd Content index with a status of Healthy
Replay queue length of less than 50 log files
4th Content index with a status of Crawling
Replay queue length of less than 50 log files
5th Replay queue length of less than 50 log files
6th Content index with a status of Healthy
Copy queue length that is less than 10 log files
7th Content index with a status of Crawling
Copy queue length that is less than 10 log files
8th Content index with a status of Healthy
9th Content index with a status of Crawling
 80

Continuous Mailbox Availability

Handling Unscheduled Outages
Self Healing Databases (Incremental Resync)
Switchover and Failover
 80

Handling Unscheduled Outages

When unscheduled outage occurs, the PAM selects the
best passive copy to activate
Before PAM locates the best copy, Attempt Copy Last Logs
(ACLL) occurs
PAM identifies which copy is the best source for copying
log files
ACLL calls each Mailbox server in the DAG with copy to
examine the value of InspectorGenerationNumber (from
state)
The copy with the highest value is the best source
If all missing log files are copied, the database mounts
without data loss (lossless failure)
 81

Handling Unscheduled Outages (continued)

If ACLL process is unsuccessful, then
AutoDatabaseMountDial is consulted
Specifies the automatic database mount behavior for a database
after a failover
Lossless - all logs on the source server have been copied and replayed
GoodAvailability – mounts if copy queue length is < or = to 6
BestAvailability - mounts if copy queue length is < or = to 12 (default)
If lost logs < or = AutoDatabaseMountDial, database is
mounted
If lost logs > AutoDatabaseMountDial, then database is
not mounted
Not until missing log files are recovered or until administrator
explicitly mounts the database and accepts data loss
 81

Handling Unscheduled Outages (continued)

Move-ActiveMailboxDatabase task with
MountDialOverride parameter instructs the target
database master to override mount dial settings
Corresponding number of lost logs overridden for each
value is as follows:
None
Lossless = 0 logs (default)
GoodAvailability = 6 logs
BestEffort = 10 logs
BestAvailability = 12 logs
 82

Transport Dumpster
Transport Dumpster maintains queue of messages
delivered to replicated databases
Automatically re-delivers recent e-mail messages sent to users on
the lossy failed database
It is possible for active mailbox database to move between AD
sites
Re-delivery request upon lossy database failover is issued to
servers in both source and target AD sites
Transport Dumpster receives feedback from the replication
pipeline
Aware of log generation of replicated databases, and the logs that
contain the messages in the Transport Dumpster
When logs holding messages in Transport Dumpster have been
replicated to all database copies, message are removed
 83

CAS Interaction
Client MAPI access and directory access transferred to the
CAS via Microsoft Exchange RPC Client Access service
Service acts as a client to the Active Manager and is aware
of the location of each active database copy in the site
In a *over scenario, the client is disconnected for the least
amount of time as possible thanks to the coordination
between CAS server and Active Manager
As soon as the CAS server is able to establish from the
Active Manager the location of a given active database
that is needed to service a client request, the connection is
made
 84

Determining Mailbox Connection Point

Client connects to CAS or CAS Array
CAS array is load balanced cluster of CAS servers in an AD site
If one server in array fails, other members carry on service
Outlook determines MAPI endpoint:
homeMDB on user account points to mailbox database
legacyExchangeDN on mailbox database refers to CAS or CAS
array
CAS or CAS Array is derived from the legacyExchangeDN
Mailbox database automatically takes legacyExchangeDN
from random CAS or CAS Array at creation time
Value can be updated after using Set-MailboxDatabase
 83

Self Healing Databases (Incremental Resync)

Incremental Resync automatically corrects divergences in
database copies under the following conditions:
After an automatic failover for all of the configured copies of a database
When a new copy is enabled and some database and log files already exist
at the copy location
When replication is resumed following a suspension or restarting of the
Microsoft Exchange Replication service
Page Patching
When divergence between active and passive copy is detected, Incremental
Resync performs the following tasks:
Searches historically in the log file stream to locate the point of divergence
Locates changed database pages on diverged copy
Reads the changed pages from active copy and then copies necessary log
files from active copy
Applies database page changes to diverged copy.
Runs recovery on diverged copy and replays necessary log files into
database copy
 84

Page Patching
 86

Switchover and Failover

Database Switchover
Server Failover
Database Failover
 86

Database Switchover
 87

Server Failover
 89

Database Failover
 91

Backup and Recovery

Overview
Backup and Recovery
 91

Database Backup and Recovery

To back up and restore Exchange 2010, you must use an
Exchange-aware application that supports the VSS writer
for Exchange 2010, such as:
Microsoft System Center Data Protection Manager
A third-party Exchange-aware VSS-based application.
Windows Server Backup (with the Exchange VSS plug-in)
See page 94 for details
Recovery Database
Replaces Recovery Storage Group functionality
Special kind of mailbox database that allows you to mount a
restored mailbox database and extract data as part of a recovery
operation
Use the Restore-Mailbox cmdlet to extract data from an RDB
 95

Backup-Less Organizations
Flexible Mailbox Protection eliminates the need to make
traditional backups of Exchange database data
Disaster Recovery – handled by multiple replicated database
copies
Recovery of Accidentally Deleted Items – handled by Dumpster 2.0
Long Term Data Storage – handled by User Archive
Point in Time Database Snapshot- handled by lagged database
copies
There are serious considerations when planning FMP
Hardware requirements vs. cost of sustaining backups
Number of database copies
Recovery Time Objective (RTO) and Recovery Point Objective (RPO)
goals
 99

Lesson 3: Planning, Deployment and

Management of Exchange 2010 HA Features
 99
Lesson 3: Planning, Deployment and Management of Exchange 2010 HA Features

After completing this lesson you will be able to:

Describe incremental deployment of Exchange Server 2010
highly available mailbox features.
Discuss database mobility and continuous mailbox
availability concepts.
Discuss Inter-site continuous mailbox availability concepts.
Discuss backup and recovery scenarios for highly available
mailbox databases.
 99

Deployment and Management Topics

Deploying Database Availability Groups
Deploying Mailbox Databases and Database Copies
Final Configuration and Testing
Managing HA features with EMS and EMC
Datacenter Site Activation
Backup and Recovery
Moving Log and Database Paths
 100

DAG Deployment in a nutshell

Create a DAG.
Add two or more Mailbox servers to the DAG
Configure the DAG properties, as needed
Optionally configure DAG encryption and compression, replication
port, DAG IP addresses, and other DAG properties
If the DAG contains three or more Mailbox servers, Datacenter
Activation Coordination (DAC) mode should be enabled
Configure Database Availability Group Network Properties
Add mailbox database copies across Mailbox servers in the
DAG
Example Contoso Organization
 100

Deploying Database Availability Groups

Watch This: DAG Deployment and Management
 109

Deploying Mailbox Databases and Database Copies

Watch This: Deploying Mailbox Databases
Watch This: Deploying Mailbox Database Copies
 163

Deploying DAGs for Site Resiliency

High Level Steps for Datacenter Site Activation
Failure Scenario: Primary Data Center Failure
Activating the Failover Datacenter
Recovering Primary Datacenter
 164

Additional Management Topics

Backup and Recovery using Windows Server Backup
Moving Logs and Databases on DAG members
Lesson 4: Diagnostics and Troubleshooting
 172

Lesson 4: Diagnostics and Troubleshooting

After completing this lesson you will be able to:
Describe common tools for troubleshooting issues related to
Exchange 2010 High Availability features
 173

Diagnostic Logging for HA

There are two categories that can be configured to
generate diagnostic logging events for the Replication
service (MSExchange Repl):
Service - Events related to the operation of the Replication service.
Exchange VSS Writer - Events related to the VSS writer as driven by
the Replication service.
 174

HA EXTRA Tracing
Use the Cluster.Replay component for troubleshooting
issues that are related to continuous replication and DAG
operation
See pages 175 – 177 for tags available for tracing DAG
operation
 177

Performance counters for HA features

Replica Seeder
Replication
Active Manager
Active Manager Server
Active Manager Client
See pages 177 - 181 for counter details
 183

Lab: Scenario Based High Availability Labs

Appendix
High Availability Application Log Events
High Availability Registry Values
Replay Registry Values
Replay Parameters
Replica Instance State
Replica Instance DumpsterInfo
Replica Instance StateLock
Active Manager Registry Values
Databases
 Questions

99 1/1/2009 Microsoft Confidential - For Internal Use Only

 © 2009 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

Microsoft Confidential - For Internal Use Only

Conditions and Terms of Use
Microsoft Confidential - For Internal Use Only

This training package content is proprietary and confidential, and is intended only for users described in the training materials. Content and
information designated for limited distribution is provided to you under a Non-Disclosure Agreement and cannot be distributed. Copying or
disclosing all or any portion of the content and/or information included in such packages is strictly prohibited.
The contents of this package are for informational and training purposes only and are 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.
Training package content, including URLs and other Internet Web site references, is subject to change without notice. Because Microsoft
must respond to changing market conditions, the content should not be interpreted to be a commitment on the part of Microsoft, and
Microsoft cannot guarantee the accuracy of any information presented after the date of publication. Unless otherwise noted, the 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.

Copyright and Trademarks

© 2009 Microsoft Corporation. All rights reserved.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this
document. Except as expressly provided in 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.
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 “Use of Microsoft Copyrighted Content “at http://www.microsoft.com/about/legal/permissions/.
Microsoft®, Internet Explorer, and Windows® are either registered trademarks or trademarks of Microsoft Corporation in the United States
and/or other countries. Microsoft products mentioned herein may be either registered trademarks or trademarks of Microsoft Corporation in
the United States and/or other countries. All other trademarks are property of their respective owners.