Novell to Microsoft Conversion Assessment: Exchange 2010 Design

Transcription

1 Novell to Microsoft Conversion Assessment: Exchange 2010 Design Presented To: 2/09/ Hamilton Lane, Suite 200 Naperville, IL Voice & Fax:

2 Version History Ver. # Ver. Date Author Description Jan-11 Brian Desmond Initial Draft Jan-11 Scott Weyandt Edits Jan-11 Brian Desmond Added Diagram Feb-11 Brian Desmond Edits from review meeting Page 2 of 22

3 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 Mailbox Server Configuration High Availability Configuration Operating System Configuration Hardware Configuration Recommended HACC Mailbox Server (Local Storage) Storage Design Database Placement Database Configuration Physical Storage Configuration Backup and Restore Backup Schedule Recovery Targets Mailbox Data Recovery Page 3 of 22

4 Hub Transport Configuration Operating System Configuration Hardware Configuration Client Access Server Configuration Operating System Configuration Hardware Configuration SSL Certificates Summary Page 4 of 22

5 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 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. Page 5 of 22

6 Current Environment HACC current operates a Novell GroupWise environment which provides messaging service to HACC employees at each of the HACC campuses. The 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. Page 6 of 22

7 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 Harrisburg Virtual Hub Transport XSV02 Client Access Harrisburg Virtual Hub Transport XSV03 XSV04 Client Access Hub Transport Client Access Hub Transport Site 2 TBD 1 Site 2 TBD 1 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 Page 7 of 22

8 Internet OWA: mail.domain.com EAS: mail.domain.com OA: mail.domain.com CAS/HT CAS/HT RPC: outlook.domain.com AD Site: Harrisburg MBX DB01 DB06 Note: Failover of site will require manual change of RPC endpoint DNS record 100 Meg Link DB01 DB06 CAS/HT RPC: outlook-site2.domain.com AD Site: Site2 (TBD) Note: Failover of site will require manual change of RPC endpoint DNS record Page 8 of 22

9 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 Page 9 of 22

10 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 Page 10 of 22

11 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 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. Page 11 of 22

12 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 XMB01 XMB02 XMB03 XSV01 XSV02 XSV03 XSV04 SKU Windows Server 2008 R2 Enterprise Edition Windows Server 2008 R2 Enterprise Edition Windows Server 2008 R2 Enterprise Edition Windows Server 2008 R2 Standard Edition Windows Server 2008 R2 Standard Edition Windows Server 2008 R2 Standard Edition Windows Server 2008 R2 Standard Edition Hardware Configuration Page 12 of 22

13 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 Page 13 of 22

14 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 DB01 DB02 DB03 DB04 DB05 DB06 Database Configuration Replica Servers XMB01, XMB02, XMB03 XMB01, XMB02, XMB03 XMB01, XMB02, XMB03 XMB01, XMB02, XMB03 XMB01, XMB02, XMB03 XMB01, XMB02, XMB03 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) MB Page 14 of 22

15 It is assumed that the vast majority of part time (e.g. adjunct) employees will make limited use of the 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 XMB01,XMB02,XMB03 567GB DB02 XMB01,XMB02,XMB03 567GB DB03 XMB01,XMB02,XMB03 567GB DB04 XMB01,XMB02,XMB03 567GB DB05 XMB01,XMB02,XMB03 567GB DB06 Page 15 of 22

16 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 Page 16 of 22

17 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. Page 17 of 22

18 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. Operating System Configuration 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 Hardware Configuration 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 Page 18 of 22

19 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. Page 19 of 22

20 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. Operating System Configuration 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 Hardware Configuration 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 Page 20 of 22

21 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 ( has a particularly easy to use utility for generating certificates for Exchange Server 2010 and is a recommended vendor. Page 21 of 22

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. Page 22 of 22