Engagement Findings and Recommendations - Exchange 2013

Microsoft Software Assurance Skype for Business and Exchange Deployment Planning Services

Findings and Recommendations

Planning Services Findings and Recommendations

Revision and Signoff Sheet

Change Record

Date Author Version Change reference

Initial draft for review/discussion

Reviewers

Name Version approved Position Date

Software Assurance | Skype for Business and Exchange Deployment Planning Services 2


Table of Contents

Document Purpose..................................................................................................................5

Session Participant Record......................................................................................................5

Problem Statement / Project Drivers.......................................................................................5

Solution Statement..................................................................................................................6

Current State Review..............................................................................................................6

Clients.................................................................................................................................6

Network Topology...............................................................................................................7

Internet Access...................................................................................................................7

Active Directory Environment.............................................................................................7

Current Messaging Environment.........................................................................................7

Requirements..........................................................................................................................9

Business Requirements.....................................................................................................10

Operational Requirements................................................................................................10

Technical Requirements...................................................................................................11

Solution Concept Components..............................................................................................11

Solution Concept Architecture..........................................................................................11

Assumptions.....................................................................................................................13

Constraints.......................................................................................................................14

Issues and Risks................................................................................................................14

Custom Objectives and Results.............................................................................................15

Custom Objectives............................................................................................................15



Custom Objective Results.................................................................................................15

Engagement Schedule..........................................................................................................15

Next Steps.............................................................................................................................16

Tools and Best Practices Reference.......................................................................................17

Document Guidance – Delete before Providing to Customer

Note to xDPS consultant: any text in italic blue is there to assist you in determining how to answer a question. You should delete that text, and any areas which have a title that starts with “xDPS Consultant”.

At the beginning of each numbered section you will see if the section is required or optional with a large blue text such as this:

<<REQUIRED SECTION>>

It will also provide you with any additional comments for the requirements of that section. This document is intended to represent your effort and accomplishments at the customer. Feel free to delete anything (other than required sections) and add any sections necessary to reflect the engagement.

Remember to delete all blue text.

Note to xDPS consultant: any text in italic brown is there to highlight areas that you need to fill with data. In many areas we provide you examples of the type of information that should be in each section. If data is provided it is provided solely as an example. Although you can leverage provided items, anything provided is not a complete list and you should definitely not limit yourself to only that sample data. Remember to delete or replace all brown text.



Document Purpose<<REQUIRED SECTION for all engagements>>The following document is a summary of the X-day <Platform – e.g. Exchange> Deployment Planning Session (xDPS) held for <<Customer>>. It documents the findings and tasks accomplished during this engagement. <<Customer>>can use this document to engage internal IT teams, partners and vendors in deployment planning discussions and proposal or statement of work generation.

Session Participant Record<<REQUIRED SECTION for all engagements>>The following table lists the participants of the engagement.

Name Role Session Participation

[Name1] [Role]

[Name1] [Role]

[Name1] [Role]

[Name1] [Role]

[Name1] [Role]

[Name1] [Role]

[Name1] [Role]

Problem Statement / Project Drivers<<REQUIRED SECTION for all engagements>>

Guidelines for writing a problem statement:

Provides a business description of the customer’s situation that will become the focus for the rest of the engagement. This could include actual technical problems or other business drivers. A business driver should be high level. Some common examples would be improve operational efficiency, reduce costs, improve business integration, reduce risk exposure, etc.

Be as detailed as necessary to describe the problem / driver Be as clear as possible Here is an example:

o Contoso is currently using Exchange 2003 and has significant challenges with server stability. High levels of paged and non-paged pool memory consumption are resulting in complete cluster failures. In



addition, the lack of a legal hold facility in their current environment is causing compliance issues. Finally, Exchange 2003 is nearing the end of its support lifecycle.

<<Customer>> is facing the following challenges in their existing environment….

Solution Statement<<REQUIRED SECTION for 1 DAY engagements>>

Guidelines for writing a solution statement:

Provides a high level description of the platform features that can be used to solve the customers problem(s) as identified in the problem statement

For a 1 day engagement be as detailed as you can in the time allowed For engagements that go beyond 1 day, you skip this section because you will be writing a solution concept

that goes into more detail. Be as clear as possible Here is an example:

o Contoso’s paged and non-paged memory issues can be addressed by moving to a 64-bit platform. Because Exchange 2013 runs on a 64 bit platform it has been designed to scale much higher than Exchange 2003.

o In addition, Exchange 2013 has a variety of “hold” mechanisms that Contoso can leverage to address its compliance concerns. In particular, Contoso in extremely interested in learning more about the new “in-place hold” feature of Exchange 2013 and the SharePoint eDiscovery Center.

o Finally, and most obvious, upgrading to Exchange 2013 relieves the Exchange 2003 support lifecycle issue.

The solution statement could be something that indicates more research is needed. As an example:o Contoso has expressed significant interest in Exchange 2013’s Data Loss Protection feature. This

could be a replacement for their existing DLP solution. Additional research and a proof-of-concept are required to determine if the Exchange 2013 feature is a fit for Contoso’s environment.

Note – this example is a lead in for Next Steps…

Current State Review<<REQUIRED SECTION for all engagements>>xDPS Consultant: This is a summary of what the customer’s environment looks like. This is intended to be a summary of the highlights only. Please mention all changes planned for short term. Add / remove sections as needed to describe the environment.

Clients

xDPS Consultant: Describe the clients that are in use. This should include data from the “Clients” section of the pre-engagement questionnaire.



Network Topology

xDPS Consultant: Shortly describe the network topology. This should include data from the “Network” section of the pre-engagement questionnaire.

Insert a copy of the network diagram, if available.

Internet Access

xDPS Consultant: Shortly describe the network topology. This should include data from the “Internet Access” section of the pre-engagement questionnaire.

Insert a copy of the Internet access diagram, if available.

Active Directory Environment

xDPS Consultant: Briefly describe the Active Directory environment. This should include data from the “Active Directory” section of the pre-engagement questionnaire.

The table below lists the Active Directory forests of the environment:

Forest name Forest Functional Level Exchange installed in forest?

contoso.com Yes

adatum.com No

User accounts are located in the following Active Directory Domains:

Domain name Number of Users Comments

europe.contoso.com

Current Messaging Environment

Messaging ArchitectureThe current messaging environment consists of…

S&EDPS Consultant: Insert a diagram of the current messaging topology if the client has one available. Describe the customer messaging environment. Provide information that is useful to gauge the complexity of this deployment and



would assist in scoping or work order generation. Include information such messaging product, as number of servers, users per server, server role, physical location, clusters, SAN, etc… Add areas below as necessary…

Client AccessS&EDPS Consultant: Describe the various messaging clients and how they access Exchange. Outlook versions, 3rd party, ActiveSync…

Mail Servers

L&DPS Consultant: This should include data from the “Mail Servers” section of the pre-engagement questionnaire.

PKI and Certificates

L&DPS Consultant: This should include data from the “PKI and Certificates” section of the pre-engagement questionnaire.

Message HygieneS&EDPS Consultant: Briefly describe topics such as: What is being used for anti-spam? Hosted or onsite? What program(s) is used for anti-virus? Where are messages scanned by anti-virus software? Are there anti-virus exclusions in place for messaging servers? Is protocol inspection done on incoming and exiting message streams? Is the IT-staff satisfied with the current solution(s)? Is the user satisfied with the current solution(s)?

This should include data from the “Message Hygiene” section of the pre-engagement questionnaire.

Co-Existence and Transition

L&DPS Consultant: This should include data from the “Co-Existence and Transition” section of the pre-engagement questionnaire.

Mailbox Configuration

L&DPS Consultant: This should include data from the “Mailbox Configuration” section of the pre-engagement questionnaire.



ComplianceS&EDPS Consultant: Briefly describe topics such as: Are there existing archiving solutions? Is it compatible with Exchange 2013? Is there an existing e-Discovery solution, and if so, what is it used for? Is it compatible with Exchange 2013? Are their ethical walls between departments of the organization, such that one department is not allowed to communicate with another department on certain topics? If so, how is this enforced? Is the solution compatible with Exchange 2013? Are messages inspected for content prior to leaving the organization? If so, how, and is the solution compatible with Exchange 2013? Are their rules in place about how long messages can/must be retained? How are these rules enforced? Are PST’s in use, if so how are they backed up? Is the client subject to any set of compliance regulations, such as HIPAA?

This should include data from the “Compliance” section of the pre-engagement questionnaire.

Public Folders

L&DPS Consultant: This should include data from the “Public Folders” section of the pre-engagement questionnaire.

Address Lists and Admin Groups

L&DPS Consultant: This should include data from the “Address Lists and Admin Groups” section of the pre-engagement questionnaire.

Internet Email

L&DPS Consultant: This should include data from the “Internet Email” section of the pre-engagement questionnaire.

Other Server Services

L&DPS Consultant: This should include data from the “Other Server Services” section of the pre-engagement questionnaire.

Management and OperationsL&DPS Consultant: This should include data from the “Management and Operations” section of the pre-engagement questionnaire.

Briefly describe topics such as: Is the messaging administration centralized or decentralized? Do messaging administrators require domain admin privileges? Is there a separation between AD and Messaging administration? Are there read-only administrators? Is a resource forest in use? What political or delegation of privilege requirements led to that decision? Who manages the messaging servers? Is it the same people that manage the main organization directory (Active Directory)? Are the messaging servers managed separately or does a single group manage them all? Or is there strict segregation of responsibilities (like Network, hardware, OS, applications…) Describe roles, responsibilities and processes for provisioning. Are their policies for configuring new employees and terminating employee? Attach if available.



Service and Data Availability L&DPS Consultant: This should include data from the “Service and Data Availability” section of the pre-engagement questionnaire.

Briefly describe topics such as: High availability implementation. Monitoring implementation. How often are backups executed? How often do they need to restore data? Which kind of data? Are streaming backups used, snapshots, or brick-level? What are the SLA’s regarding data recovery (from single item restore to complete disaster scenario)? What programs/agents are used to perform backups? What is the backup media (disk/tape)? What is the data retention policy? Are deleted item recovery and deleted mailbox recovery configured, and if so, what are their values? Has environment recovery been tested and practiced? Is the process documented? Are backups verified?

Briefly describe topics such as: Mailbox recovery – what does the client do? Single item recovery – what does the client do? Full server failure - what does the client do? Data-center failure - what does the client do? Has the disaster recovery scenario ever been tested and verified?

Requirements

<< REQUIRED SECTION for 3/5/10/15 day engagements >><<Customer>> has the following requirements that were identified during the <Platform – e.g. Exchange>DPS workshops and will therefore be addressed and reflected in the architecture and recommendations. Requirements will be divided into several types. Each type and its accompanying requirements are detailed below:

xDPS Consultant: Requirements identify what the solution must deliver. We have provided example requirements to help you understand the type of requirements desired for each section. They are only samples and should be replaced with the ones discussed during the xDPS engagements. Be sure the requirements address the problems / drivers listed earlier in this document.

Business Requirements

Business requirements are the most important drivers for a project and the solution architecture. They define what the solution must deliver in order to meet a business challenge or opportunity. Following are the business requirements discussed during the engagement:

Customer is in the process of re-branding all business units under a new unified brand. As such all mailboxes must reflect the new brand.

Customer has recently acquired several new organizations. Each of these organizations is in the process of being integrated into Customer’s organization. To support this effort, all of the newly acquired messaging environments must be consolidated into Customers Exchange organization.

In order to meet compliance requirements, Customer needs to deploy a legal hold mechanism that can provide scoped-immutability across mailboxes.



Operational Requirements

Operational requirements describe the supportability and usability of a solution. They are formulated from the perspective of those who will administer or support the solution in addition to end users who will utilize the solution. Following are the operational requirements discussed during the engagement:

<<Customer>> has defined the following service level objectives for the messaging environment:

<TABLE BELOW INCLUDES EXAMPLES. REPLACE WITH CUSTOMER OBJECTIVES>

Service/Data Recovery Time Objective Recovery Point Objective

Message recovery 1 hour 24 hours

Mailbox recovery 12 hour 24 hours

Database recovery 12 hours 24 hours

Server recovery 24 hours 24 hours

Site recovery 72 hours 24 hours

… …

Centralized Management: <<Customer>> requires a deployment that is centrally managed but allows granular delegation.

Full Outlook email without VPN: <<Customer>> has a large remote workforce that needs full client access without the requirement of establishing a VPN session.

Technical Requirements

Technical requirements specify the technical parameters and feature characteristics of the solution. They are formulated from the perspective of the IT personnel. They are secondary to and dependent on the business requirements. Following are the technical requirements discussed during the engagement:

Support for mailbox quotas of 500MB with 30 days for deleted items.

Customer must maintain a copy of all emails from the following business groups: group 1, group 2 and group 3.

The messaging solution must support Blackberry clients

Users must have the ability to wipe their own ActiveSync clients



Solution Concept Components<<REQUIRED SECTION for 3/5/10/15 day engagements>>

Solution Concept Architecture

xDPS Consultant: This is a description of the high level solution ideas that were derived from the various Envisioning Workshops. It should describe how product features could work together to solve the problem statement and meet the requirements as defined earlier in the document. A diagram illustrating the solution components and their relationships to one another is recommended. You should provide as detailed of a description as possible given the time allowed in the engagement.

Example follows:Overview

The following figure illustrates the solution CONCEPT that was discussed during the engagement. This solution concept IS NOT A FULL DESIGN and may not address all of Contoso’s requirements. This concept is a model that should be used as a starting point for future more detailed design discussions. The concept may change over time with more detailed discussions and as requirements evolve.

High Availability / Site ResiliencyThe Exchange 2013 DAG concept is used to provide high availability and site resiliency. This addresses Contoso’s main business need to have a site resilient mail system. This concept does not address redundancy of 3rd party applications; this is a gap that needs to be addressed by Contoso. Multiple CAS servers are necessary in each location to provide high availability for that role. Each database is envisioned to have 3 copies in the Redmond datacenter and a 4 th copy in the Dublin datacenter.

Storage and BackupsContoso has not made a decision to use DAS or SAN with the DAG model. To avoid having a single point of failure for the database storage, each copy of a given mailbox database should be configured on different storage arrays (i.e. different SANs if you are using SAN storage). If more than one copy of a given database is stored on a given storage array you are creating a single point of failure within the DAG.Contoso is currently experiencing backup issues in their Notes environment. Backups for Notes are exceeding their backup windows and impacting work hours. Because Contoso has expressed an interest to increase the mailbox sizes to 1GB it is highly likely that using the existing daily full backup model will not be tenable. This will need to be addressed in the planning phase of the project. Given that the solution concept has 4 copies of each database, utilizing Exchange Native Backup protection is an option.

Routing



Contoso will need to modify its inbound / outbound Internet mail topology to support adding the second datacenter.

Anti-Spam / Anti-MalwareAs part of this workshop, replacing the existing perimeter anti-spam / anti-virus solution with Edge or Exchange Online Protection was discussed but no decisions were made. Contoso would like to see a proof-of-concept of EOP before making a decision.

Unified MessagingContoso’s voice mail system currently integrates with Notes. The integration requirements for Exchange 2013 Unified Messaging are still being explored by Contoso.

xDPS Consultant: This follow sub-sections of the Solution Concept Architecture are here for you to fill in any specific details of the solution concept the conversations you had during the individual sessions. See the example above. Remove the sections you don’t need.

OverviewThe following figure illustrates the solution CONCEPT that was discussed during the engagement. This solution concept IS NOT A FULL DESIGN and may not address all of <<Customer’s>> requirements. This concept is a model that should be used as a starting point for future more detailed design discussions. The concept may change over time with more detailed discussions and as requirements evolve.

Deployment / Co-Existence / Migration

High Availability / Site Resiliency

Hybrid

Anti-Spam / Anti-Malware

Messaging Policy and Compliance

Public Folders / Site Mailboxes

Virtualization

Storage and Backups

Sizing

OWA / Mobility



Transport

RBAC and Management Tools

Unified Messaging

Federation

Assumptions

xDPS Consultant: This is a description of the assumptions that were made as part of the solution concept.

The following assumptions were made and need to be considered as part of the full Exchange design:

Insert assumptions here

Constraints

xDPS Consultant: This is a description of the business, project, or technical restrictions / limitations that need to be considered as part of the solution concept.

The following constraints were identified that need to be considered as part of the full Exchange design:

Insert constraints here

Issues and Risks

xDPS Consultant: Document issues and risks identified during the project.

The following issues and risks were identified:

Issue or Risk Description Mitigation or Impact

Issue Datacenter does not have enough rack space to accommodate new servers

Virtualization?

Risk Because Customer has already ordered hardware for the new environment, the hardware may not be properly sized.

May need to work with the hardware vendor to update or change server hardware

Issue Customer cannot dedicate staff full time to the messaging project.

The project time line will need to be extended.





Custom Objectives and Results<<REQUIRED FOR 10/15 DAY CUSTOM ENGAGEMENTS>>

Custom Objectives

Note to xDPS consultant: Here you will define any CUSTOM objectives and additional documentation that is part of this engagement. If this is a 10/15 day or a customized engagement this section is required. If it is a 1/3/5 day engagement and you are using the standard offering, you can delete this section. Anything not part of the baseline 1/3/5 day content should be here.

List any additional documentation with the document name and a description. Any documentation that is not a separate document should be defined as a task. The actual task results or content (for example a lab environment diagram) will be placed under the “Custom Objective Results” section of this document. It is preferable to try to keep all documentation as part of this single deliverable. Nevertheless, in some cases (such as a full Vision/Scope document), it is impractical.

Please not that customer feedback forms will refer to these objectives and tasks. Make sure your customer is aware of what is and is not part of the engagement and what tasks you are working on.

The deployment team has determined the following custom objectives to be part of the xDPS offering:

Custom objective 1

Custom objective 2

Custom objective 3

These objectives will be met by completion of the following tasks/documents:

Task/Document name and description

Task/Document name and description

Custom Objective Results

Note to xDPS consultant: Here you will provide any recommendations, results, diagrams, or additional documentation that supports the custom scope and documentation for this engagement. If the documentation does not fit well into this deliverable it can be a separate document but must be referenced in the Custom Objectives section of this document. If this is a 10/15 day or a customized engagement this section is required. If it is a 1/3/5 day engagement and you are using the standard offering, you can delete this section. Anything that is not part of the baseline 1/3/5 day content should be here.

Engagement Schedule<<REQUIRED FOR 10/15 DAY CUSTOM ENGAGEMENTS>>



Note to xDPS consultant: Here you will provide a breakdown of the work performed each day and what task was being worked on. Please note that customer feedback forms will refer to this schedule and ask if these events represent the effort of the engagement. Make sure your customer is aware of what tasks you are working on each day.

The following is the summary of the project schedule and tasks that took place during the engagement:

Engagement Day Tasks

Day 1 Describe task/deliverable worked on and work performed this day





Day X… …

Next Steps

<<REQUIRED FOR ALL ENGAGEMENTS>>

Note to xDPS consultant: Here you will provide a summary of the next steps. These items should help summarize the scope of a follow-on engagement. An example is provided below:

The following next steps are recommended:

1. Additional Data collection required for input into the full design:

a. User messaging profile – the user profile information is necessary to properly size the Exchange servers

b. Public folder size / counts – public folder information is necessary to properly size the Exchange servers

c. Etc…

2. Address the following high priority outstanding questions from the Envisioning Workshops:

a. What storage will be used – SAN vs. DAS?

b. What is the target mailbox quota (analysis required)?

c. Is site resiliency in scope of the design?



d. What are the RPO / RTO requirements?

3. Create full design covering the following topics

a. AD integration

b. Languages

c. Address lists

d. Email address policies

e. Distribution Groups

f. Role based access control

g. Calendaring and resources

h. Server roles and placement

i. Storage

j. High availability / site resiliency

k. Edge connectivity

l. Transport / routing

m. Unified messaging / UC integration

n. Compliance, Archiving, and eDiscovery

o. Data loss prevention

p. Sizing

q. WAN impacts

r. Client configuration

s. Client access

t. Application dependencies

u. Throttling policies

v. Site mailboxes / public folders

w. Federation

x. Backup, Restore, Disaster Recovery

y. Malware planning

z. Monitoring

4. Create a full upgrade / co-existence / migration strategy

5. Create a test lab specification

6. Write test plans

7. Write build documents

8. Etc….



Tools and Best Practices ReferenceThis section provides links to some of the tools and best practices.

There are many resources available on the Internet to assist in the planning and deployment for Exchange server. The list below is by no means a complete list. However, most of the guidance in this document was acquired from the locations named below, and you can find the latest up-to-the-minute guidance available from Microsoft in these locations.

Microsoft Exchange Server 2013

http://technet.microsoft.com/en-us/library/bb124558(v=exchg.150).aspx

Microsoft Exchange 2013 - Planning and Deployment

http://technet.microsoft.com/en-us/library/aa998636(v=exchg.150).aspx

The Microsoft Exchange Team Bloghttp://blogs.technet.com/b/exchange/

TechNet Forums - Exchange Serverhttp://social.technet.microsoft.com/Forums/en-US/category/exchangeserver/

Microsoft Remote Connectivity Analyzer

https://www.testexchangeconnectivity.com/

MSF Process Modelhttp://www.microsoft.com/downloads/details.aspx?FamilyID=e481cb0b-ac05-42a6-bab8-fc886956790e&DisplayLang=en

Microsoft Operations Framework (MOF)http://www.microsoft.com/mof


http://www.microsoft.com/mof

http://www.microsoft.com/downloads/details.aspx?FamilyID=e481cb0b-ac05-42a6-bab8-fc886956790e&DisplayLang=en

http://www.microsoft.com/downloads/details.aspx?FamilyID=e481cb0b-ac05-42a6-bab8-fc886956790e&DisplayLang=en

https://www.testexchangeconnectivity.com/

http://social.technet.microsoft.com/Forums/en-US/category/exchangeserver/

http://blogs.technet.com/b/exchange/

http://technet.microsoft.com/en-us/library/aa998636(v=exchg.150).aspx

http://technet.microsoft.com/en-us/library/bb124558(v=exchg.150).aspx

Documents

Engagement Findings and Recommendations - Exchange 2013