1. Exchange 2010 Project Presentation/Discussion November 18, 2018
Project Team: Mark Dougherty – Design John Ditto – Project Manager Joel Eussen – Project Support Karen McLaughlin – Design

2. Major Goals Exchange 2010 Project

3. Major Goals Bring down statewide total cost of ownership:
Reduce server count
Reduce hardware costs
Reduce administration & support costs
Reduce power & real estate consumption
Provide higher availability of service and data statewide, with a focus on quick recovery
Support flexible delegation model
Accommodate the data center move with minimal downtime

4. Overview of Exchange 2010

5. Exchange Enterprise Topology
Enterprise Network
Gateway or Edge
Routing & AV/AS
Hub Transport
Routing & Policy
External
SMTP servers
Mailbox
Storage of mailbox items
Mobile phone
Situation:
In the past new versions of exchange sometimes meant a new architecture.
Talking Points:
No new architecture for exchange 2010 from 2007 (yes there are differences for High availability, and MAPI on the Middle-Tier but the overall 5 server design is the same).
Slide Objective:
No architectural change in terms of roles and firewall exposure from Exchange 2007.
Web browser
Client Access
Client connectivity
Web services
Outlook (remote user)
Outlook (local user)

6. Exchange 2010 High Availability Overview
AD site: Spokane
DB1
DB3
DB5
All clients connect via CAS servers
Client Access Server
Client
Mailbox Server 6
AD site: Olympia
Client Access Server
Easy to stretch across sites
Failover managed within Exchange
Mailbox Server 1
Mailbox Server 2
Mailbox Server 3
Mailbox Server 4
Mailbox Server 5
Talking Points:
Here is Tomas Navarro’s new Exchange 2010 environment. Tomas is the lead Exchange and Active Directory administrator for Contoso. He has overall responsibility for providing messaging and communications services to all of Contoso’s employees. Tomas’ primary challenge is to maintain high levels of availability with a flat or shrinking budget year-over-year.
There are 5 servers in the main datacenter in San Jose that host mailboxes. These mailbox servers are grouped to provide automatic failover. The group of servers is known as a Database Availability Group. Each mailbox database has 3 instances, which we’ll refer to as copies, placed on separate servers to provide redundancy. At any given time, only 1 of the 3 database copies is active and accessible to clients. This gives us database centric failover and all the failover is managed within Exchange.
The Client Access Server manages all communications between clients and databases. Outlook clients no longer connect directly to mailbox servers, as they did in previous versions of Exchange.
When a client such as Outlook connects to Exchange, it first contacts the CAS Server.
The CAS Server determines where the user’s active database is located ( in our case the user is on DB1 which is currently active on Mailbox Server 1), and forwards the request to the appropriate server.
When the client sends an , the active database is updated. Then, through log shipping , the other 2 passive copies of the database are updated.
Let’s say that a disk fails , affecting one of the databases on Mailbox Server 1. In previous versions of Exchange, the administrator would need to failover all the databases on Mailbox Server 1 to recover from this failure, or else restore the Database 1 from a tape backup. However, Exchange’s new architecture supports database-level failover, so Database 1 has automatically fails over to Mailbox Server 2 without affecting the other databases.
The Outlook client, having lost its connection to the database, automatically contacts the CAS Server to reconnect.
The CAS Server determines which mailbox server has the active copy of the users’ database. It connects the client to Mailbox Server 2.
When new mail is sent , the active database on Mailbox Server 2 is updated. The second copy of the database is also updated through log shipping. The end user is unaware that anything has happened, and Tomas can replace the failed disk drive at his leisure.
The administrator can set up to 16 copies per database to meet the Service Level Agreements for his users. For a special category of users, Tomas keeps a 4th database copy on a mail server in a geographically remote location . This server is located in a different Active Directory site, but is kept up-to-date over the Wide Area Network using the same replication technology as the other servers. (No stretching of subnets) If a hurricane, earthquake, or other catastrophe should shut down the main datacenter, this remote server can be activated and readied for client access in about 15 minutes.
Database Availability Group
DB1
DB1
DB4
DB2
DB5
DB3
DB2
DB5
DB3
DB1
DB4
Database centric failover
DB1
DB1
DB3
DB4
DB2
DB5

7. Databases Corruption and 1018s
Best case scenario:
> Move mailboxes to new database.
> ECC checksum automatically fixes
issues 40% of the time
Worst case scenario:
> Backups cease
> Must take database offline
> Eseutil or isinteg to fix
> May require restoring and log replay
Page patching process works constantly in the background to detect problems.
When found, bad pages are repaired automatically, taking information from all valid copies (using an arbitration algorithm).

8. Hard Drives & Servers Failuresx x
HOT SPARES
HOT SPARES
Drive failures covered by
RAID on SAN enclosure
Recovery Window = Instant
Drive failures covered by
RAID on DAS enclosure
Recovery Window = Instant
Server Failures require rebuilding the server, restoring Exchange Service, and restoring Exchange data from tape.
Recovery window
= 8-12 hours.
Server failures automatically transfer load to other servers in the DAG.
Recovery window
= 30 seconds.

9. Site Failures
Once site is rebuilt or relocated, all servers must be rebuilt or fixed and backup tapes for all servers must be restored from offsite location. Data restored to the point of most recent backup.
Recovery Window
8-40 hours for service restoration
Up to 300 hours for data restoration
Manual failover must be activated at the Spokane node site. Log files are replayed forward to restore the database up to the point of failure.
Recovery Window
About 4 hours for service and data restoration.

10. High Availability & Quick Recovery Summary
2010
2003
Page 2 (32KB) X
DB Corruption: Unknown Immediate
Hard drives: Immediate Same
Databases: 4-8hrs sec
Server: 8-12hrs secs
Site: 2wks hrs

11. Deleted Item Retention
INBOX
INBOX
Del
Del
DELETED ITEMS
DELETED ITEMS
Del
Del
DELETED ITEM RETENTION
DELETED ITEM RETENTION
LEAD IN: What is the difference between Exchange 2003 and 2010 for Deleted Items
Key Benefits of 2010
31 Day minimum history guaranteed for all
Enterprise Vault picks up all non-deleted items within 30 days
Legal hold functionality puts users on a permanent, indefinite hold
Del
Or 14 Days
31 Days Later
GONE
GONE

12. Enhanced Legal Discovery
Discoverable mail is stored in multiple places
Delegation only on the vault store
Cannot guarantee completeness
Fewer discoverable sources
Delegation on both the mailbox and vault
2010 guarantees mailbox completeness
2003
Too many sources to search (tapes, vaults, inbox, deleted items, journal)
Too complicated and time consuming
No guarantees of completeness (forced us to backup)
2010
Fewer sources
Fully delegated
Guaranteed completeness

13. Delegation

14. Role Based Access Control (RBAC)
Role based controls
Situation:
Delegated administration has greatly improved with each release of Exchange Server, but Exchange 2007 still required modification of ACL’s to create specialized administrative roles (i.e. Compliance Officer role)
In Exchange 2003, managing permissions required customization of ACL’s (about 560 ACE’s in total). A whole whitepaper dedicated to ACL modification.
In Exchange 2007, property sets made it easier, but doing split permissions was still complicated and required ACL modification. A lengthy E2k7 whitepaper was written how to do this for Unified Messaging.
Permissions were focused on AD objects, and didn’t map 1:1 with tasks
Talking Points:
Roles-Based Access Control (RBAC), in Exchange “14”, simplifies the administrators ability to create specialized roles with specialized actions.
For example:
Creating a helpdesk administrator role who only has the ability to create new mailboxes or change mailbox quota or message size limits.
Creating a specialized Telephony Specialist role, who’s permissions are limited to managing UM dial plans.
Creating a specialized compliance officer role, who’s permissions are limited to performing cross-mailbox searches for legal discovery.
Creating a human resources role, where individuals assigned to this role are only able to update employee contact information.
Creating a branch office administrator role, where they only have permissions to modify details for mailboxes within the specific branch (Organizational Unit or OU).
Roles-Based Access Control is simple to manage. Administrators will use the Exchange Management Shell to:
Create Roles to define/grant the set of operations for a specific user (i.e. ability to create a new mailbox, or set mailbox quota limit)
Define Scope of where the operations can be run (i.e. a specific organizational unit, like North America OU or Finance Dept)
Assign the roles and scope to a set of users (i.e. Unified Messaging Admin, Helpdesk Admin, Compliance Officer, etc…)
What required an entire whitepaper (in E2k7) to create a specialized Unified Messaging role, can now be done in Exchange “14” with a single cmdlet in the Exchange Management Shell.
Access is based on What you do…. Not what you have access to.
Within an organization, roles are created for various job functions. The permissions to perform certain operations are assigned to specific roles. Members of staff (or other system users) are assigned particular roles, and through those role assignments acquire the permissions to perform particular system functions
RBAC differs from access control lists (ACLs) used in traditional discretionary access control systems in that it assigns permissions to specific operations with meaning in the organization, rather than to low level data objects.

15. Exchange Control Panel (ECP) What is it?
A browser based Management client for end users, administrators, and specialists
Simplified user experience for common management tasks
Accessible directly via URL, OWA & Outlook 14
Deployed as a part of the Client Access Server role
RBAC aware
Talking Points:
Exchange Control Panel - New self-service capabilities are accessible through a Web- based management portal aimed at enabling users to perform common tasks without having to call the helpdesk. This self–service facility enables users to be more productive and allows IT staff to deliver more, while reducing support costs.
Provide access to OWA options as well as new self-service functionality.
Accessible directly via URL, OWA ( Options link ) & Outlook 14
Deployed as a part of the Client Access Server role
Users only see features which they have access to – i.e. The ECP is RBAC aware

16. Simplify Administration
Lower Support Costs Through New User Self-Service Options
Track the status of sent messages
Situation:
The largest percentage of helpdesk calls incurred by an organization using Exchange include: Distribution Group management, message tracking, changes to personal information in address book, and other similar tasks.
The annual cost of helpdesk support staff for systems with 7,500 mailboxes is approximately $20/mailbox. This cost goes up the smaller the organization. (“ Support Staff Requirements and Costs: A Survey of 136 Organizations”, Ferris Research, June 2008).
Talking Points:
Roles-Based Access Control (RBAC), in Exchange “14”, allows IT administrators to move specific self-service tasks to end-users.
Distribution Group management – End-users can create new DG’s, manage memberships and ownership, as well as delete DG’s
Message tracking – End-users can track delivery receipt information of all messages sent
Editing personal information in address book – End-users can modify select user information, such as mobile phone number.
End-user self-service management is performed through a web-based management interface (aka. Exchange Control Panel)
Other typical end-user tasks/options will be moved from to this web-based management interface, such as: Out of Office, Inbox Rules, Mobile device management, etc…
Regular feedback from users of Exchange Labs (and other research) has helped frame the user experience with this web-base management interface
Create and manage distribution groups

17. Questions