EDPS Engagement Summary and Recommendations

Reviews
Shared by: Shanna Mo
Stats
views:
29
rating:
not rated
reviews:
0
posted:
6/7/2009
language:
English
pages:
0
EDPS Engagement Summary and Recommendations Exchange Deployment Planning Services Prepared for Customer Name Sunday, 7 June 2009 Version 1.0 Prepared by Consultant Name Contributors EDPS Delivery Partner Microsoft and Microsoft Confidential Confidential Revision and Signoff Sheet Change Record Date 2 Aug 2008 8 Sep 2008 October 2008 4 Feb 2009 18 Feb 2009 24 Feb 2009 Author K. Miller Pavel Haspra Elik Diaz Elik Diaz Elik Diaz Elik Diaz Version 0.1 1.0 1.5 2.0 1.0 1.1 Change reference Initial outline History deleted, Version 1 prepared Document name changed from EDPS-Deployment Planning Recommendations Template. Feedback updates. Complete redo of document template to support EDPS 2.0 content Complete restructure and title change to become deliverable for entire EDPS line of offerings. Reset to version 1.0. Minor updates and modifications Reviewers Name Version approved Position Date Page ii EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 1.0 Final Prepared by Elik Diaz "EDPS Engagement Summary and Recommendations” last modified on 7 Jun. 09, Rev 98 Microsoft and Microsoft Confidential Confidential Table of Contents 1 2 3 4 Document Purpose ........................................................................................................................ 1 Session Participant Record .......................................................................................................... 2 Business Drivers............................................................................................................................ 3 Organization Requirements .......................................................................................................... 4 4.1 4.2 4.3 Business Requirements ............................................................................................................ 4 Operational Requirements ........................................................................................................ 5 Technical Requirements ........................................................................................................... 6 5 Customer Infrastructure ................................................................................................................ 7 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 Network Topology ..................................................................................................................... 7 Active Directory Environment ................................................................................................... 7 Current Messaging Architecture ............................................................................................... 8 Message Hygiene ..................................................................................................................... 8 Backup and Data Recovery ...................................................................................................... 8 Disaster Recovery .................................................................................................................... 9 Administration Model ................................................................................................................ 9 Compliance ............................................................................................................................... 9 6 EDPS Technical Presentation Findings .................................................................................... 10 6.1 Environmental Dependencies ................................................................................................. 10 Environmental Dependencies Module .............................................................................. 10 Environmental Dependencies Findings ............................................................................ 10 6.1.1 6.1.2 6.2 High Level Conceptual Design ............................................................................................... 10 Conceptual Design Findings ............................................................................................. 11 6.2.1 6.3 Exchange 2007 Transport and Routing .................................................................................. 12 Transport and Routing Module .......................................................................................... 12 Transport and Routing Findings ........................................................................................ 12 6.3.1 6.3.2 6.4 Exchange 2007 Deployment .................................................................................................. 12 Deployment Module .......................................................................................................... 12 Deployment Findings ........................................................................................................ 12 6.4.1 6.4.2 6.5 Exchange 2007 Upgrade and Coexistence: Exchange 2003 ................................................. 13 Upgrade and Coexistence Module .................................................................................... 13 Upgrade and Coexistence Findings .................................................................................. 13 6.5.1 6.5.2 6.6 Exchange 2007 Upgrade and Coexistence: Lotus Notes....................................................... 13 Upgrade and Coexistence Module .................................................................................... 13 Upgrade and Coexistence Findings .................................................................................. 14 Page iii EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 1.0 Final Prepared by Elik Diaz "EDPS Engagement Summary and Recommendations” last modified on 7 Jun. 09, Rev 98 6.6.1 6.6.2 Microsoft and Microsoft Confidential Confidential 6.7 Exchange 2007 Operations and Management ....................................................................... 14 Operations and Management Module ............................................................................... 14 Operations and Management Findings ............................................................................. 14 6.7.1 6.7.2 6.8 Exchange 2007 Security and protection ................................................................................. 14 Security and Protection Module ........................................................................................ 14 Security and Protection Findings ...................................................................................... 15 6.8.1 6.8.2 6.9 Exchange Complementary Products ...................................................................................... 15 Complementary Products Module ..................................................................................... 15 Complementary Products Findings ................................................................................... 15 6.9.1 6.9.2 7 8 9 10 11 12 Customer Deployment Challenges / Risks ............................................................................... 16 Customer High Level Deployment Plan .................................................................................... 17 EDPS Objectives And Documentation....................................................................................... 18 EDPS Engagement Results ..................................................................................................... 19 EDPS Engagement Schedule .................................................................................................. 20 APPENDIX ................................................................................................................................. 21 12.1 12.1.1 12.1.2 12.1.3 12.1.4 12.1.5 12.2 Deployment Planning Concepts ........................................................................................ 21 Envision ......................................................................................................................... 21 Plan ............................................................................................................................... 21 Developing/Build ........................................................................................................... 22 Stabilize ......................................................................................................................... 23 Deploy ........................................................................................................................... 23 Tools and Best Practices Reference ................................................................................. 25 Page iv EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 1.0 Final Prepared by Elik Diaz "EDPS Engagement Summary and Recommendations” last modified on 7 Jun. 09, Rev 98 Microsoft and Microsoft Confidential Confidential 1 DOCUMENT PURPOSE <> The following document is a summary of the X-day Exchange Deployment Planning Session (EDPS) held for <>. It documents the findings and tasks accomplished during this engagement. <>can use this document to engage internal IT teams, partners and vendors in deployment planning discussions and proposal or statement of work generation. Note to EDPS 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 “EDPS 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: <> 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. Note to EDPS 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. Page 1 EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0 Final Prepared by Elik Diaz "Document1" last modified on 7 Jun. 09, Rev 98 Microsoft and Microsoft Confidential Confidential 2 SESSION PARTICIPANT RECORD <> The following table lists the participants of the engagement. Name Role [Role] [Role] [Role] [Role] [Role] [Role] [Role] [Role] [Role] [Name1] [Name2] [Name4] [Name5] [Name6] [Name7] [Name8] [Name9] [Name10] Page 2 EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0 Final Prepared by Elik Diaz "Document1" last modified on 7 Jun. 09, Rev 98 Microsoft and Microsoft Confidential Confidential 3 BUSINESS DRIVERS <> Organizations are subject to external forces that shape what products or services are delivered in addition to how the organization will operate. The responses to these trends are the “business drivers” resulting in business strategies and the IT initiatives to support them. The EDPS consultant and <> have determined the following primary business drivers for deployment of Exchange 2007 Server:  Business Driver 1  Business Driver 2  Business Driver 3 EDPS Consultant: A business driver should be high level. Some common examples would be improve operational efficiency, reduce costs, improve business integration, reduce risk exposure, etc. Make sure to address how Exchange assists with these business drivers in the business requirements section of this document. Page 3 EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0 Final Prepared by Elik Diaz "Document1" last modified on 7 Jun. 09, Rev 98 Microsoft and Microsoft Confidential Confidential 4 ORGANIZATION REQUIREMENTS <> <> has the following organization requirements that were identified during the EDPS workshops and will therefore be addressed and reflected in the architecture and recommendations. Organization requirements will be divided into three types: Business, Operational and Technical. Each type and its accompanying requirements are detailed below: EDPS Consultant: 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 EDPS engagements. 4.1 Business Requirements <> Business requirements are the most important drivers for a project and the solution architecture. Following are the business requirements discussed during the engagement: Improve Operational Efficiency: <> desires to improve its operational efficiencies by reducing the cost of purchasing and managing messaging storage; reducing the time required for backup and restore operations; improving the efficiency of messaging administrators; and improved management, reporting, and administration functionality. Exchange 2007 will enable this with… Security: <> recognizes that information security is one of its chief priorities. Exchange Server 2007 will enable <> to improve its security by deploying server-to-server transport encryption and improved security and policy controls for mobile devices, as well as message hygiene and the security improvements resulting from Microsoft’s Trustworthy Computing initiative. Compliance and governance: <> has a number of compliance and governance requirements, including a requirement to archive e-mail messages and to support discovery requests. Exchange Server 2007 will help meet these requirements by implementing features such as journaling, message retention Service Level Agreements: <> has the requirement to meet the following SLA agreements: 1. SLA 1 2. SLA 2 Exchange Server 2007 will help meet these requirements by implementing features such as… Mobility: by providing improved mobile and wireless access to data, <> will increase its business agility and flexibility. In particular, <> expects to benefit from the ability to provide secure remote access to messaging, calendar, and file share data through Exchange Server 2007. EDPS Consultant: Verify that your business requirements address the business drivers from earlier in this document. Page 4 EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0 Final Prepared by Elik Diaz "Document1" last modified on 7 Jun. 09, Rev 98 Microsoft and Microsoft Confidential Confidential 4.2 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: Disaster recovery and business continuity: <> expects to realize a major improvement in disaster recovery and business continuity capability, with a targeted recovery time objective (RTO) of X hours for following services and data. Service/Data Mailbox service OWA service Message transfer within organization Single item recovery (30 days) Single item recovery (>30 days) … Recovery time 30 min 5 min 5 min 30 min 8 hours … Measure CCR NLB for ISA, Server farm for CAS Deploying multiple HT in each AD site containing MBX servers Deleted items configuration Restore … New Exchange 2007 clustering technologies will enable <> to … Centralized Management: <> requires a deployment that is centrally managed but allows granular delegation. Exchange Server 2007 will help meet these requirements by implementing features such as… Full Outlook email without VPN: <> has a large remote workforce that needs full client access without the requirement of establishing a VPN session. Exchange Server 2007 will help meet these requirements by implementing features such as… Page 5 EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0 Final Prepared by Elik Diaz "Document1" last modified on 7 Jun. 09, Rev 98 Microsoft and Microsoft Confidential Confidential 4.3 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: <> requires a deployment that can.. Journaling of all email from Management: <> requires a deployment that can … Page 6 EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0 Final Prepared by Elik Diaz "Document1" last modified on 7 Jun. 09, Rev 98 Microsoft and Microsoft Confidential Confidential 5 CUSTOMER INFRASTRUCTURE <> EDPS 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. 5.1 Network Topology EDPS Consultant: Shortly describe the network topology. Insert a copy of the network diagram, if available. 5.2 Active Directory Environment EDPS Consultant: Briefly describe the Active Directory environment. The table below lists the Active Directory forests of the environment: Forest name contoso.com adatum.com Forest Functional Level Windows 2000 Windows Server 2003 Exchange installed in forest? Yes No User accounts are located in the following Active Directory Domains: Domain name europe.contoso.com Number of Users 8500 Comments Page 7 EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0 Final Prepared by Elik Diaz "Document1" last modified on 7 Jun. 09, Rev 98 Microsoft and Microsoft Confidential Confidential 5.3 Current Messaging Architecture The current messaging environment consists of… EDPS Consultant: Insert here 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 SOW generation. Include information such messaging product, as number of servers, users per server, server role, physical location, clusters, SAN, etc… 5.4 Message Hygiene 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)? 5.5 Backup and Data Recovery EDPS Consultant: Briefly describe topics such as: 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? Does the client implement Operations Level Agreements (OLAs) for messaging? If so, what are they? Has recovery been tested and practiced? Is the process documented? Are backups verified? Page 8 EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0 Final Prepared by Elik Diaz "Document1" last modified on 7 Jun. 09, Rev 98 Microsoft and Microsoft Confidential Confidential 5.6 Disaster Recovery EDPS Consultant: 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? Datacenter failure - what does the client do? Has DR scenario ever been tested and verified? 5.7 Administration Model EDPS Consultant: 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? Are administrative groups use? How are administrative groups assigned? Do administrators control a single server or an entire AG? 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. 5.8 Compliance EDPS Consultant: Briefly describe topics such as: Are there existing archiving solutions? Is it compatible with Exchange 2007? Is there an existing e-Discovery solution, and if so, what is it used for? Is it compatible with Exchange 2007? 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 2007? Are messages inspected for content prior to leaving the organization? If so, how, and is the solution compatible with Exchange 2007? 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? Page 9 EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0 Final Prepared by Elik Diaz "Document1" last modified on 7 Jun. 09, Rev 98 Microsoft and Microsoft Confidential Confidential 6 EDPS TECHNICAL PRESENTATION FINDINGS << SECTION 6.X OPTIONAL FOR CUSTOM ENGAGEMENTS >> 6.1 6.1.1 Environmental Dependencies Environmental Dependencies Module The environmental dependencies module discusses the pre-requisites that must be in place before deploying any Exchange 2007 Servers into your environment. Topics that are discussed include:     Name resolution requirements Active Directory requirements Certificate requirements Cleanup tasks The following is a summary of the findings during this module. 6.1.2 Environmental Dependencies Findings The following items were identified during the EDPS engagement: Item Item A Item B Comment Describe Describe EDPS Consultant: Place any specific items discussed in the High Availability module that would be of benefit to document and would aid in defining the scope or complexity of this deployment effort. For example, the client needs to upgrade DC’s to the latest service pack, the client will evaluate their AD sites and services layout, the client needs to purchase a SAN certificate, etc. 6.2 High Level Conceptual Design  Exchange 2007 Architecture  Exchange 2007 High Availability  Exchange 2007 Planning This section encompasses the findings from the following three modules: The findings are combined because the results of the three modules were high level architectural decisions leading to a high level conceptual design. All recommendations here are “as-of-today” which means they have been decided only with information available to the team at the time of writing this document. Decisions made during EDPS must be validated in a formal Exchange Server 2007 engagement with a full envisioning and scoping phase. This following conceptual design is NOT a full design and cannot be used to build against or to purchase/budget with. The purpose is to illustrate the topology discussed during EDPS sessions, and serve as a starting point for further discussions and considerations. A full design would be part of a formal Exchange Server 2007 deployment project. Page 10 EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0 Final Prepared by Elik Diaz "Document1" last modified on 7 Jun. 09, Rev 98 Microsoft and Microsoft Confidential Confidential EDPS Consultant: Insert a HIGH LEVEL simple Visio diagram here showing the discussed messaging topology. 6.2.1 Item Item A Item B Conceptual Design Findings Comment Describe Describe The following items were identified during the EDPS engagement: EDPS Consultant: Place any specific items in regards to the design findings that would be of benefit to document and would aid in defining the scope or complexity of this deployment effort. For example: The customer would like to deploy x number of mailbox servers, the mailbox servers will be combined or dedicated, CCR cluster, X number of HT servers in X location, X number of CAS servers in X location, ET server in perimeter network, etc... Keep it at a HIGH LEVEL, with the goal of explaining the provided diagram. Page 11 EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0 Final Prepared by Elik Diaz "Document1" last modified on 7 Jun. 09, Rev 98 Microsoft and Microsoft Confidential Confidential 6.3 6.3.1 Exchange 2007 Transport and Routing Transport and Routing Module The Exchange 2007 Transport and Routing module discusses the routing technology used by Exchange 2007. Topics that are discussed include:     Hub and Edge Transport Servers SMTP Connectors Active Directory sites and Routing Least cost Routing examples The following is a summary of the findings during this module. 6.3.2 Item Item A Item B Transport and Routing Findings Comment Describe Describe The following items were identified during the EDPS engagement: EDPS Consultant: Place any specific items discussed in the Transport and Routing module that would be of benefit to document and would aid in defining the scope or complexity of this deployment effort. For example: The customer has a complex routing topology, the customer AD sites and services has a lot of manual configuration, etc. 6.4 6.4.1 Exchange 2007 Deployment Deployment Module The Exchange 2007 Deployment module discusses Exchange 2007 setup and deployment topologies. Topics that are discussed include:  Exchange 2007 Setup  Deployment Topologies  Deployment order The following is a summary of the findings during this module. 6.4.2 Item Item A Item B Deployment Findings Comment Describe Describe The following items were identified during the EDPS engagement: EDPS Consultant: Place any specific items discussed in the Deployment module that would be of benefit to document and would aid in defining the scope or complexity of this deployment effort. For example: The customer has multiple AD Forests and is a complex environment, requires GAL Page 12 EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0 Final Prepared by Elik Diaz "Document1" last modified on 7 Jun. 09, Rev 98 Microsoft and Microsoft Confidential Confidential synchronization with another entity, all roles will be combined on one server in a simple topology, what order servers will be deployed, etc… 6.5 6.5.1 Exchange 2007 Upgrade and Coexistence: Exchange 2003 Upgrade and Coexistence Module The Exchange 2007 Upgrade and Coexistence module discusses Exchange 2007 transition and coexistence strategies with Exchange 2003. Topics that are discussed include:       Recipient Management Recipient Update Service Administrative Groups Link State Routing Groups Upgrading The following is a summary of the findings during this module. 6.5.2 Item Item A Item B Upgrade and Coexistence Findings Comment Describe Describe The following items were identified during the EDPS engagement: EDPS Consultant: Place any specific items discussed in the Upgrade and Coexistence module that would be of benefit to document and would aid in defining the scope or complexity of this deployment effort. For example: The customer has a complex Routing Group design, the Exchange 2003 organization is complex, Exchange 2003 will need to be retained for the Lotus Notes connector, etc… 6.6 6.6.1 Exchange 2007 Upgrade and Coexistence: Lotus Notes Upgrade and Coexistence Module The Exchange 2007 Upgrade and Coexistence: Lotus Notes module discusses Exchange 2007 transition and coexistence strategies with Lotus Notes. Topics that are discussed include:      Overview of the Transporter Suite Directory Synchronization SMTP Mail routing Free Busy Connectivity User and Mailbox Migration The following is a summary of the findings during this module. Page 13 EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0 Final Prepared by Elik Diaz "Document1" last modified on 7 Jun. 09, Rev 98 Microsoft and Microsoft Confidential Confidential 6.6.2 Item Item A Item B Upgrade and Coexistence Findings Comment Describe Describe The following items were identified during the EDPS engagement: EDPS Consultant: Place any specific items discussed in the Upgrade and Coexistence module that would be of benefit to document and would aid in defining the scope or complexity of this deployment effort. For example: XYZ, etc… 6.7 6.7.1 Exchange 2007 Operations and Management Operations and Management Module The Exchange 2007 Operations and Management module discusses Exchange 2007 management, monitoring, and tools. Topics that are discussed include:       Exchange 2007 Management Console Exchange 2007 Management Shell Exchange 2007 Recipient Management Exchange 2007 Monitoring Exchange 2007 Tools Exchange 2007 Backup and Recovery The following is a summary of the findings during this module. 6.7.2 Item Item A Item B Operations and Management Findings Comment Describe Describe The following items were identified during the EDPS engagement: EDPS Consultant: Place any specific items discussed in the Operations and Management module that would be of benefit to document and would aid in defining the scope or complexity of this deployment effort. For example: The customer does not have a compatible backup solution, The customer has a third party monitoring solution they would like to use, etc.. 6.8 6.8.1 Exchange 2007 Security and protection Security and Protection Module The Exchange 2007 Security and Protection module discusses Exchange 2007 security architecture. Topics that are discussed include:  Exchange 2007 Permissions Page 14 EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0 Final Prepared by Elik Diaz "Document1" last modified on 7 Jun. 09, Rev 98 Microsoft and Microsoft Confidential Confidential      Exchange 2007 Compliance Exchange 2007 Journaling Exchange 2007 Records Management Exchange 2007 Communications Exchange 2007 Anti SPAM and Anti Virus The following is a summary of the findings during this module. 6.8.2 Item Item A Item B Security and Protection Findings Comment Describe Describe The following items were identified during the EDPS engagement: EDPS Consultant: Place any specific items discussed in the Security and Protection module that would be of benefit to document and would aid in defining the scope or complexity of this deployment effort. For example: The customer will employ journaling, has or does not have an AV solution for 2007, has the following compliance requirements, etc… 6.9 6.9.1 Exchange Complementary Products Complementary Products Module The Exchange 2007 Complementary products module discusses Microsoft products designed to work with Exchange 2007. Topics that are discussed include:     Forefront AV System Center Data Protection Manager Office Communication Server System Center Operations Manager The following is a summary of the findings during this module. 6.9.2 Item Item A Item B Complementary Products Findings Comment Describe Describe The following items were identified during the EDPS engagement: EDPS Consultant: Place any specific items discussed in the Complementary Products module that would be of benefit to document and would aid in defining the scope or complexity of this deployment effort. For example: The client is interested in finding out more about and possibly deploying X Product for Exchange 2007, the client would like x product as part of the deployment engagement, etc… Page 15 EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0 Final Prepared by Elik Diaz "Document1" last modified on 7 Jun. 09, Rev 98 Microsoft and Microsoft Confidential Confidential 7 CUSTOMER DEPLOYMENT CHALLENGES / RISKS <> This section lists the deployment challenges that are specific to the environment. These may include operational constraints, SLAs, network or bandwidth issues, mobility or security requirements, or any other issue that may slow down or block deployment or use of Exchange 2007. The following key deployment challenges and risks were identified during the session:  XYZ  XYZ  XYZ EDPS Consultant: create a list of issues that may be significant for the customer. Add any additional items that may be required and delete those that do not apply. Obviously, there are many other potential challenges; these are simply some of the more common issues and questions that arise. If this is a customized engagement you may not have a deployment plan as part of your deliverable, in that case you should delete this section. Page 16 EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0 Final Prepared by Elik Diaz "Document1" last modified on 7 Jun. 09, Rev 98 Microsoft and Microsoft Confidential Confidential 8 CUSTOMER HIGH LEVEL DEPLOYMENT PLAN <> The following is a preliminary high level Exchange 2007 Server deployment plan: EDPS Consultant: make sure you provide some value in the description of the deployment sequence. Specify which locations will probably go first, which servers in the locations, etc. The idea is for the customer to understand at a high level what the flow of the deployment may look like in their organization. If this is a customized engagement you may not have a deployment plan as part of your deliverable, in that case you should delete this section. Page 17 EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0 Final Prepared by Elik Diaz "Document1" last modified on 7 Jun. 09, Rev 98 Microsoft and Microsoft Confidential Confidential 9 EDPS OBJECTIVES AND DOCUMENTATION <> The Exchange deployment team has determined the following objectives to be part of the EDPS offering:    XYZ XYZ XYZ These objectives will be met by completion of the following tasks/documents:   Task/Document name and description Task/Document name and description Note to EDPS consultant: Here you will define any CUSTOM objectives and additional documentation that is part of this engagement. If this is 10/15 day or a customized engagement this section is required. If it is a 3/5 day engagement and you are using the standard offering, you can delete this section. Anything not part of the baseline 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 “EDPS Engagement 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. Page 18 EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0 Final Prepared by Elik Diaz "Document1" last modified on 7 Jun. 09, Rev 98 Microsoft and Microsoft Confidential Confidential 10 EDPS ENGAGEMENT RESULTS <> Note to EDPS consultant: Here you will provide any recommendations, results, diagrams, or additional documentation that supports the custom scope and documentation for this engagement. For example, if you decided to build a lab environment the description of the lab and diagram should be here. If the documentation does not fit well into this deliverable (such as a full Vision/Scope) it can be a separate document but must be referenced in the section entitled “EDPS Objectives And ”. If this is 10/15 day or a customized engagement this section is required. If it is a 3/5 day engagement and you are using the standard offering, you can delete this section. Anything that is not part of the baseline 3/5 day content should be here. Page 19 EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0 Final Prepared by Elik Diaz "Document1" last modified on 7 Jun. 09, Rev 98 Microsoft and Microsoft Confidential Confidential 11 EDPS ENGAGEMENT SCHEDULE <> The following is the summary of the project schedule and tasks that took place during the EDPS engagement: Engagement Day Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10 Day X…. Tasks Describe task/deliverable worked on and work performed this day Describe task/deliverable worked on and work performed this day Describe task/deliverable worked on and work performed this day Describe task/deliverable worked on and work performed this day Describe task/deliverable worked on and work performed this day Describe task/deliverable worked on and work performed this day Describe task/deliverable worked on and work performed this day Describe task/deliverable worked on and work performed this day Describe task/deliverable worked on and work performed this day Describe task/deliverable worked on and work performed this day Describe task/deliverable worked on and work performed this day Note to EDPS 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. Page 20 EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0 Final Prepared by Elik Diaz "Document1" last modified on 7 Jun. 09, Rev 98 Microsoft and Microsoft Confidential Confidential 12 APPENDIX <> 12.1 Deployment Planning Concepts Consistently delivering high-quality technology solutions on time and on budget is challenging for any business. The Microsoft Solutions Framework (MSF) provides people and process guidance— the proven practices of Microsoft—to help teams and organizations become more successful in delivering business-driven technology solutions to their customers. MSF is a deliberate and disciplined approach to technology projects based on a defined set of principles, models, disciplines, concepts, guidelines, and proven practices from Microsoft. Through the Exchange Deployment Planning Service engagement, you have begun the process of following the MSF for your Exchange transition, starting with the Envisioning process. The next step for your company is to take this document, prepare a detailed plan, and then begin the Build phase. Let’s discuss the main steps of MSF and how they apply to an Exchange migration. 12.1.1 Envision The envisioning phase addresses one of the most fundamental requirements for project success— unification of the project team behind a common vision. The team must have a clear vision of what it wants to accomplish for the customer and be able to state it in terms that will motivate the entire team and the customer. Envisioning, by creating a high-level view of the project’s goals and constraints, can serve as an early form of planning; it sets the stage for the more formal planning process that will take place during the project’s planning phase. The primary activities accomplished during envisioning are the formation of the core team (described below) and the preparation and delivery of a vision/scope document. The delineation of the project vision and the identification of the project scope are distinct activities; both are required for a successful project. Vision is an unbounded view of what a solution may be. Scope identifies the part(s) of the vision can be accomplished within the project constraints. Risk management is a recurring process that continues throughout the project. During the envisioning phase, the team prepares a risk document and presents the top risks along with the vision/scope document. During the envisioning phase, business requirements must be identified and analyzed. These are refined more rigorously during the planning phase. 12.1.2 Plan The planning phase is when the bulk of the planning for the project is completed. During this phase the team prepares the functional specification, works through the design process, and prepares work plans, cost estimates, and schedules for the various deliverables. Early in the planning phase, the team analyzes and documents requirements in a list or tool. Requirements fall into four broad categories: business requirements, user requirements, operational requirements, and system requirements (those of the solution itself). As the team moves on to design the solution and create the functional specifications, it is important to maintain traceability between requirements and features. Traceability does not have to be on a one to one basis. Maintaining traceability serves as one way to check the correctness of design and to verify that the design meets the goals and requirements of the solution. Page 21 EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0 Final Prepared by Elik Diaz "Document1" last modified on 7 Jun. 09, Rev 98 Microsoft and Microsoft Confidential Confidential The design process gives the team a systematic way to work from abstract concepts down to specific technical detail. This begins with a systematic analysis of user profiles (also called “personas”) which describe various types of users and their job functions (operations staff are users too). Much of this is often done during the envisioning phase. These are broken into a series of usage scenarios, where a particular type of user is attempting to complete a type of activity, such as front desk registration in a hotel or administering user passwords for a system administrator. Finally, each usage scenario is broken into a specific sequence of tasks, known as use cases, which the user performs to complete that activity. This is called “story-boarding.” There are three levels in the design process: conceptual design, logical design, and physical design. Each level is completed and baselined in a staggered sequence. The results of the design process are documented in the functional specification(s). The functional specification describes in detail how each feature is to look and behave. It also describes the architecture and the design for all the features. Specifically for Exchange, the final output of the planning process will identify servers, their locations, their uses, the feature matrix that will be used by Exchange, the operational and management infrastructure that will be used or that will need to be built (in the case of provisioning systems), as well as client and management expectations. Part of that document will include the answers to all of the questions raised in chapter 8, “Deployment Planning”. 12.1.3 Developing/Build During the Build phase, the team accomplishes most of the building of solution components (including documentation and infrastructure, as well as code). However, some development work may continue into the Stabilization phase in response to testing. The developing phase involves more than code development and software developers. The infrastructure is also developed during this phase and all roles are active in building and testing deliverables. The Build phase culminates in the scope complete milestone. At this milestone, all features are complete and the solution is ready for external testing and stabilization. This milestone is the opportunity for customers and users, operations and support personnel, and key project stakeholders to evaluate the solution and identify any remaining issues that must be addressed before the solution is released. Typically the Build phase includes a proof-of-concept non-production implementation of the project result and the POC platform is used for testing intermediate results and for developing deployment scripts and operational guidance. After the proof-of-concept implementation is complete, it is time to deploy the infrastructure to support a pilot group roll-out. Specifically for Exchange, the developing phase is used to identify, develop, and test any custom programs, scripts, etc. that are required for the Exchange implementation. At the same time, the Build phase is used to acquire knowledge and usage experience of the solution within the support and operational groups of your enterprise and to determine how to meet the requirements that came out of the planning phase. Page 22 EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0 Final Prepared by Elik Diaz "Document1" last modified on 7 Jun. 09, Rev 98 Microsoft and Microsoft Confidential Confidential 12.1.4 Stabilize The stabilizing phase conducts testing on a solution whose features are complete. Testing during this phase emphasizes usage and operation under realistic environmental conditions. The team focuses on resolving and triaging (prioritizing) bugs and preparing the solution for release. Early during this phase it is common for testing to report bugs at a rate faster than developers can fix them. There is no way to tell how many bugs there will be or how long it will take to fix them. There are, however, a couple of statistical signposts known as bug convergence and zero-bug bounce that helps the team project when the solution will reach stability. These signposts are described below. MSF avoids the terms “alpha” and “beta” to describe the state of IT projects. These terms are widely used, but are interpreted in too many ways to be meaningful in industry. Teams can use these terms if desired, as long as they are defined clearly and the definitions understood among the team, customer, and stakeholders. Once a build has been deemed stable enough to be a release candidate, the solution is deployed to a pilot group for production use. Specifically for Exchange Server 2007, this will typically mean that a few generic steps will be executed to prepare the corporate environment:  If a transition from Exchange 2000/2003, then PrepareLegacyExchangePermissions (to add the security interop required for legacy Exchange versions to work with Exchange 2007)  PrepareSchema (to apply all Exchange schema updates to Active Directory)  PrepareAD (to create AD objects in the Configuration container and universal groups and to assign security to Exchange related objects and property sets)  PrepareDomain or PrepareAllDomains (to create AD objects in the various domain containers and populate the groups for the domains that will contain Exchange objects) Once those four steps have been executed, the Exchange tools and the Exchange server setup process can be executed. A minimum Exchange pilot requires a Client Access Server, a Hub Transport Server, and a Mailbox Server; and they are typically installed in that order (and for a very minimal pilot or for a very small organization, they may all be installed on one properly sized server). From a co-existence perspective, a CAS may act as a front-end server for an Exchange 2000/2003 organization. The stabilizing phase culminates in the release readiness milestone. Once reviewed and approved, the solution is ready for full deployment to the live production environment. The release readiness milestone occurs at the point when the team has addressed all outstanding issues and has released the solution or placed it in service. At the release milestone, responsibility for ongoing management and support of the solution officially transfers from the project team to the operations and support teams. 12.1.5 Deploy During this phase, the team deploys the core technology and site components, stabilizes the deployment, transitions the project to operations and support, and obtains final customer approval of the project. After the deployment, the team conducts a project review and a customer satisfaction survey. Page 23 EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0 Final Prepared by Elik Diaz "Document1" last modified on 7 Jun. 09, Rev 98 Microsoft and Microsoft Confidential Confidential Stabilizing activities may continue during this period as the project components are transferred from a test environment to a production environment. The deployment complete milestone culminates the deploying phase. By this time, the deployed solution should be providing the expected business value to the customer and the team should have effectively terminated the processes and activities it employed to reach this goal. The customer must agree that the team has met its objectives before it can declare the solution to be in production and close out the project. This requires a stable solution, as well as clearly stated success criteria. In order for the solution to be considered stable, appropriate operations and support systems must be in place. The final deliverables from the Deploy phase include:  Operation and support information systems  Procedures and processes  Knowledge base, reports, logbooks  Documentation repository for all versions of documents, load sets, and code developed during the project  Project close-out report  Final versions of all project documents  Customer/user satisfaction data  Definition of next steps In an Exchange environment, the deployment phase for small to medium operations typically only involves move-mailbox operations for one-to-a-few servers and then decommissioning of the legacy environment. For large organizations with many sites and many servers, the deployment phase may consume an extended period of time, as each individual site must go through a deployment and approval phase. Large organizations can incur significant hardware and software upgrade costs and time, as well as significant man-hours of implementation team expense. However, we believe that with the implementation of Exchange Server 2007 in your organization, you will experience significantly improved messaging capabilities and, especially if server consolidation is part of your project plan, quick return on investment. Page 24 EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0 Final Prepared by Elik Diaz "Document1" last modified on 7 Jun. 09, Rev 98 Microsoft and Microsoft Confidential Confidential 12.2 Tools and Best Practices Reference This section provides links to some of the tools and best practices, and the latest information can be found at <>. 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-theminute guidance available from Microsoft in these locations. Exchange Best Practices Analyzer http://www.exbpa.com Mailbox Server Role Storage Requirements Calculator http://msexchangeteam.com/archive/2007/01/15/432207.aspx Microsoft Solutions Framework (MSF) http://www.microsoft.com/technet/solutionaccelerators/msf/default.mspx MSF Process Model http://www.microsoft.com/downloads/details.aspx?FamilyID=e481cb0b-ac05-42a6-bab8fc886956790e&DisplayLang=en Microsoft Operations Framework (MOF) http://www.microsoft.com/mof Microsoft Exchange Server 2007 - Planning and Architecture http://technet.microsoft.com/en-us/library/aa998636(EXCHG.80).aspx Microsoft Exchange Server 2007 - Deployment http://technet.microsoft.com/en-us/library/bb123895(EXCHG.80).aspx Microsoft Exchange Server 2007 - Operations http://technet.microsoft.com/en-us/library/aa998842(EXCHG.80).aspx Common Mistakes When Upgrading Exchange 2000/2003 to Exchange 2007 http://support.microsoft.com/kb/555854/en-us The Microsoft Exchange Team Blog http://www.msexchangeteam.com The Exchange 2007 Wiki http://www.exchangeninjas.com TechNet Forums - Exchange Server http://forums.microsoft.com/TechNet/default.aspx?ForumGroupID=235&SiteID=17 Page 25 EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0 Final Prepared by Elik Diaz "Document1" last modified on 7 Jun. 09, Rev 98

Related docs
premium docs
Other docs by Shanna Mo