L&EDPS Engagement Findings and Recommendations Documentation

Document Sample
L&EDPS Engagement Findings and Recommendations Documentation Powered By Docstoc
					EDPS Engagement Summary and Recommendations
            Exchange Deployment Planning Services


                                               Prepared for
                                        <Customer Name>
                                                   <Date>
                                               Version 3.3



                                              Prepared by
                                       <Consultant Name>




                                               Contributors
                                     EDPS Delivery Partner
                                                                                                    Microsoft and Microsoft Confidential Confidential




Revision and Signoff Sheet

Change Record
 Date       Author                     Version             Change reference




Reviewers
 Name       Version approved                    Position                                                                       Date




                                                                                                                                             Page ii
              EDPS Engagement Findings and Documentation, Exchange Deployment Planning Services, Version 2.0 Final
              "EDPS Engagement Findings and Documentation” last modified on 13 Sep. 12, Rev 10
                                                                                                                      Microsoft and Microsoft Confidential Confidential




    Table of Contents


1    Document Purpose ........................................................................................................................ 1

2    Session Participant Record .......................................................................................................... 2

3    Business Drivers............................................................................................................................ 3

4    Organization Requirements .......................................................................................................... 4
    4.1    Business Requirements ............................................................................................................ 4
    4.2    Operational Requirements ........................................................................................................ 5
    4.3    Technical Requirements ........................................................................................................... 6

5    Customer Infrastructure ................................................................................................................ 7
    5.1    Network Topology ..................................................................................................................... 7
    5.2    Active Directory Environment ................................................................................................... 7
    5.3    Current Messaging Architecture ............................................................................................... 8
    5.4    Message Hygiene ..................................................................................................................... 8
    5.5    Backup and Data Recovery ...................................................................................................... 8
    5.6    Disaster Recovery .................................................................................................................... 9
    5.7    Administration Model ................................................................................................................ 9
    5.8    Compliance ............................................................................................................................... 9

6    EDPS Technical Presentation Findings .................................................................................... 10
    6.1    Network and Messaging Discovery ........................................................................................ 10
     6.1.1      Network and Messaging Module ....................................................................................... 10
     6.1.2      Network and Messaging Findings ..................................................................................... 10
    6.2    High Level Conceptual Design ............................................................................................... 10
     6.2.1      Conceptual Design Findings ............................................................................................. 11
    6.3    Exchange 2010 Transport, Routing, IPC ................................................................................ 12
     6.3.1      Transport, Routing, and IPC Module................................................................................. 12
     6.3.2      Transport and Routing Findings ........................................................................................ 12
    6.4    Exchange 2010 Deployment .................................................................................................. 12
     6.4.1      Setup and Deployment Module ......................................................................................... 12
     6.4.2      Setup and Deployment Findings ....................................................................................... 12
    6.5    Exchange 2010 Upgrade and Coexistence: Exchange 2003 ................................................. 13
     6.5.1      Upgrade and Coexistence Module .................................................................................... 13
     6.5.2      Upgrade and Coexistence Findings .................................................................................. 13
    6.6    Exchange 2010 Management ................................................................................................. 13
     6.6.1      Management and RBAC Module ...................................................................................... 13
     6.6.2      Management and RBAC Findings..................................................................................... 14


                                                                                                                                                               Page iii
                                EDPS Engagement Findings and Documentation, Exchange Deployment Planning Services, Version 2.0 Final
                                "EDPS Engagement Findings and Documentation” last modified on 13 Sep. 12, Rev 10
                                                                                                                          Microsoft and Microsoft Confidential Confidential



     6.7      Exchange 2010 Compliance, Archiving, and Retention ......................................................... 14
      6.7.1        Compliance, Archiving, and Retention Module ................................................................. 14
      6.7.2        Management and RBAC Findings..................................................................................... 14
     6.8      Exchange Unified Messaging ................................................................................................. 14
      6.8.1        Unified Messaging Module ................................................................................................ 14
      6.8.2        Unified Messaging Findings .............................................................................................. 15
     6.9      Exchange Complementary Products ...................................................................................... 15
      6.9.1        Complementary Products Module ..................................................................................... 15
      6.9.2        Complementary Products Findings ................................................................................... 15
     6.10          Exchange Developer Platform .......................................................................................... 15
      6.10.1           Exchange 2010 Developer Platform Module ................................................................ 15
      6.10.2           Exchange 2010 Developer Platform Findings ............................................................... 16

7     Customer Deployment Challenges / Risks ............................................................................... 17

8     Customer High Level Deployment Plan .................................................................................... 18

9     EDPS Objectives And Documentation....................................................................................... 19

10         EDPS Engagement Results ..................................................................................................... 20

11         EDPS Engagement Schedule .................................................................................................. 21

12         APPENDIX ................................................................................................................................. 22
     12.1          Deployment Planning Concepts ........................................................................................ 22
      12.1.1           Envision ......................................................................................................................... 22
      12.1.2           Plan ............................................................................................................................... 22
      12.1.3           Developing/Build ........................................................................................................... 23
      12.1.4           Stabilize ......................................................................................................................... 24
      12.1.5           Deploy ........................................................................................................................... 24
     12.2          Tools and Best Practices Reference ................................................................................. 26




                                                                                                                                                                   Page iv
                                    EDPS Engagement Findings and Documentation, Exchange Deployment Planning Services, Version 2.0 Final
                                    "EDPS Engagement Findings and Documentation” last modified on 13 Sep. 12, Rev 10
                                                                                                             Microsoft and Microsoft Confidential Confidential




1         DOCUMENT PURPOSE
    <<REQUIRED SECTION>>
    The following document is a summary of the X-day Exchange Deployment Planning Session
    (EDPS) 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.
    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:

                                         <<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.
    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
                         L&EDPS Engagement Findings and Recommendations Documentation - Exchange, Exchange Deployment Planning Services, Version 2.0 Final
                         "Document1" last modified on 13 Sep. 12, Rev 10
                                                                                                             Microsoft and Microsoft Confidential Confidential




2         SESSION PARTICIPANT RECORD
    <<REQUIRED SECTION>>
    The following table lists the participants of the engagement.



        Name                                                      Role

        [Name1]                                                   [Role]

        [Name2]                                                   [Role]

        [Name4]                                                   [Role]

        [Name5]                                                   [Role]

        [Name6]                                                   [Role]

        [Name7]                                                   [Role]

        [Name8]                                                   [Role]

        [Name9]                                                   [Role]

        [Name10]                                                  [Role]




                                                                                                                                                             Page 2
                         L&EDPS Engagement Findings and Recommendations Documentation - Exchange, Exchange Deployment Planning Services, Version 2.0 Final
                         "Document1" last modified on 13 Sep. 12, Rev 10
                                                                                                            Microsoft and Microsoft Confidential Confidential




3         BUSINESS DRIVERS
    <<REQUIRED SECTION>>
    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 <<Customer>> have determined the following primary business drivers
    for deployment of Exchange 2010 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
                        L&EDPS Engagement Findings and Recommendations Documentation - Exchange, Exchange Deployment Planning Services, Version 2.0 Final
                        "Document1" last modified on 13 Sep. 12, Rev 10
                                                                                                             Microsoft and Microsoft Confidential Confidential




4         ORGANIZATION REQUIREMENTS
    <<REQUIRED SECTION>>
    <<Customer>> 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
    <<REQUIRED SECTION>>
    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: <<Customer>> 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 2010 will enable this with…
    Security: <<Customer>> recognizes that information security is one of its chief priorities. Exchange
    Server 2010 will enable <<Customer>> 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: <<Customer>> has a number of compliance and governance
    requirements, including a requirement to archive e-mail messages and to support discovery
    requests. Exchange Server 2010 will help meet these requirements by implementing features such
    as journaling, message retention
    Service Level Agreements: <<Customer>> has the requirement to meet the following SLA
    agreements:
         1. SLA 1
         2. SLA 2
    Exchange Server 2010 will help meet these requirements by implementing features such as…
    Mobility: by providing improved mobile and wireless access to data, <<Customer>> will increase
    its business agility and flexibility. In particular, <<Customer>> expects to benefit from the ability to
    provide secure remote access to messaging, calendar, and file share data through Exchange
    Server 2010.
    EDPS Consultant: Verify that your business requirements address the business drivers from
    earlier in this document.




                                                                                                                                                             Page 4
                         L&EDPS Engagement Findings and Recommendations Documentation - Exchange, Exchange Deployment Planning Services, Version 2.0 Final
                         "Document1" last modified on 13 Sep. 12, Rev 10
                                                                                                                 Microsoft and Microsoft Confidential Confidential




4.2      Operational Requirements
 <<REQUIRED SECTION>>
 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: <<Customer>> 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                                      Recovery time                   Measure

 Mailbox service                                   30 min                          HA implementation

 OWA service                                       5 min                           Load balance for ISA, Server farm for CAS

 Message transfer within organization              5 min                           Deploying multiple HT in each AD site containing MBX servers

 Single item recovery (30 days)                    30 min                          Deleted items recovery configuration

 Single item recovery (>30 days)                   8 hours                         Mail item recovery, mail retention, etc.

 …                                                 …                               …



 New Exchange 2010 clustering technologies will enable <<Customer>> to …


 Centralized Management: <<Customer>> requires a deployment that is centrally managed but
 allows granular delegation.   Exchange Server 2010 will help meet these requirements by
 implementing features such as…
 Full Outlook email without VPN: <<Customer>> has a large remote workforce that needs full
 client access without the requirement of establishing a VPN session. Exchange Server 2010 will
 help meet these requirements by implementing features such as…




                                                                                                                                                                 Page 5
                             L&EDPS Engagement Findings and Recommendations Documentation - Exchange, Exchange Deployment Planning Services, Version 2.0 Final
                             "Document1" last modified on 13 Sep. 12, Rev 10
                                                                                                          Microsoft and Microsoft Confidential Confidential




4.3    Technical Requirements
 <<REQUIRED SECTION>>
 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>> requires
 a deployment that can..
 Journaling of all email from Management: <<Customer>> requires a deployment that can …




                                                                                                                                                          Page 6
                      L&EDPS Engagement Findings and Recommendations Documentation - Exchange, Exchange Deployment Planning Services, Version 2.0 Final
                      "Document1" last modified on 13 Sep. 12, Rev 10
                                                                                                               Microsoft and Microsoft Confidential Confidential




5         CUSTOMER INFRASTRUCTURE
    <<REQUIRED ALL SECTION 5.X>>
    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                              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




                                                                                                                                                               Page 7
                           L&EDPS Engagement Findings and Recommendations Documentation - Exchange, Exchange Deployment Planning Services, Version 2.0 Final
                           "Document1" last modified on 13 Sep. 12, Rev 10
                                                                                                         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
                     L&EDPS Engagement Findings and Recommendations Documentation - Exchange, Exchange Deployment Planning Services, Version 2.0 Final
                     "Document1" last modified on 13 Sep. 12, Rev 10
                                                                                                          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? Data-
 center 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 2010? Is there an existing e-Discovery solution, and if so, what is it used
 for? Is it compatible with Exchange 2010? 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 2010? Are
 messages inspected for content prior to leaving the organization? If so, how, and is the solution
 compatible with Exchange 2010? 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
                      L&EDPS Engagement Findings and Recommendations Documentation - Exchange, Exchange Deployment Planning Services, Version 2.0 Final
                      "Document1" last modified on 13 Sep. 12, Rev 10
                                                                                                             Microsoft and Microsoft Confidential Confidential




6            EDPS TECHNICAL PRESENTATION FINDINGS
    << SECTION 6.X OPTIONAL FOR CUSTOM ENGAGEMENTS >>

6.1          Network and Messaging Discovery
6.1.1          Network and Messaging Module
    The environmental dependencies module discusses the pre-requisites that must be in place before
    deploying any Exchange 2010 Servers into your environment. Topics that are discussed include:
            Name resolution requirements
            Active Directory requirements
            Certificate requirements
            Current messaging environment
            Cleanup tasks
    The following is a summary of the findings during this module.

6.1.2          Network and Messaging Findings

    The following items were identified during the EDPS engagement:

      Item                                           Comment

      Item A                                         Describe
      Item B                                         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
    This section encompasses the findings from the following three modules:
        Exchange 2010 High Availability
        Exchange 2010 Storage
        Exchange 2010 Planning and Sizing
    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 2010 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 2010 deployment project.


                                                                                                                                                             Page 10
                         L&EDPS Engagement Findings and Recommendations Documentation - Exchange, Exchange Deployment Planning Services, Version 2.0 Final
                         "Document1" last modified on 13 Sep. 12, Rev 10
                                                                                                           Microsoft and Microsoft Confidential Confidential



  EDPS Consultant: Insert a HIGH LEVEL simple Visio diagram here showing the discussed
  messaging topology.



6.2.1        Conceptual Design Findings
The following items were identified during the EDPS engagement:

    Item                                           Comment

    Item A                                         Describe
    Item B                                         Describe

  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, dedicated, or virtual, DAG configuration, X number of HT servers in X location, X
  number of CAS servers in X location, Edge server in perimeter network, etc... Keep it at a HIGH
  LEVEL, with the goal of explaining the provided diagram.




                                                                                                                                                           Page 11
                       L&EDPS Engagement Findings and Recommendations Documentation - Exchange, Exchange Deployment Planning Services, Version 2.0 Final
                       "Document1" last modified on 13 Sep. 12, Rev 10
                                                                                                              Microsoft and Microsoft Confidential Confidential




6.3          Exchange 2010 Transport, Routing, IPC
6.3.1          Transport, Routing, and IPC Module
 The Exchange 2010 Transport and Routing module discusses the routing technology used by
 Exchange 2010. Topics that are discussed include:
            Hub and Edge Transport Servers
            SMTP Connectors
            Active Directory sites and Routing
            Least cost Routing examples
            Information leakage Control


 The following is a summary of the findings during this module.

6.3.2          Transport and Routing Findings
 The following items were identified during the EDPS engagement:

      Item                                            Comment

      Item A                                          Describe
      Item B                                          Describe

 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          Exchange 2010 Deployment
6.4.1          Setup and Deployment Module
 The Exchange 2010 Deployment module discusses Exchange 2010 setup and deployment
 topologies. Topics that are discussed include:
        Exchange 2010 Setup
        Deployment Topologies
        Deployment order


 The following is a summary of the findings during this module.

6.4.2          Setup and Deployment Findings
 The following items were identified during the EDPS engagement:

      Item                                            Comment

      Item A                                          Describe
      Item B                                          Describe

 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
                          L&EDPS Engagement Findings and Recommendations Documentation - Exchange, Exchange Deployment Planning Services, Version 2.0 Final
                          "Document1" last modified on 13 Sep. 12, Rev 10
                                                                                                             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          Exchange 2010 Upgrade and Coexistence: Exchange 2003
6.5.1          Upgrade and Coexistence Module
 The Exchange 2010 Upgrade and Coexistence module discusses Exchange 2010 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          Upgrade and Coexistence Findings
 The following items were identified during the EDPS engagement:

      Item                                           Comment

      Item A                                         Describe
      Item B                                         Describe

 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 2007 will need to be retained for the Lotus Notes
 connector, etc…




6.6          Exchange 2010 Management
6.6.1          Management and RBAC Module
 The Exchange 2010 Management and RBAC module discusses Exchange 2010 management,
 monitoring, and tools. Topics that are discussed include:
            Exchange 2010 Management Console
            Exchange 2010 Management Shell
            Exchange 2010 RBAC
            Exchange 2010 Monitoring
            Exchange 2010 Tools
            Exchange 2010 Backup and Recovery


 The following is a summary of the findings during this module.



                                                                                                                                                             Page 13
                         L&EDPS Engagement Findings and Recommendations Documentation - Exchange, Exchange Deployment Planning Services, Version 2.0 Final
                         "Document1" last modified on 13 Sep. 12, Rev 10
                                                                                                             Microsoft and Microsoft Confidential Confidential




6.6.2          Management and RBAC Findings
 The following items were identified during the EDPS engagement:

      Item                                           Comment

      Item A                                         Describe
      Item B                                         Describe

 EDPS Consultant: Place any specific items discussed in the Management and RBAC 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 or
 looking to go backupless, The customer has a third party monitoring solution they would like to use,
 etc..



6.7          Exchange 2010 Compliance, Archiving, and Retention
6.7.1          Compliance, Archiving, and Retention Module
 The Exchange 2010 Compliance, Archiving, and Retention module discusses Exchange 2010
 compliance capability, expected experiences, and ways to achieve them. Topics that are discussed
 include:
            World Today
            Exchange 2010 Archive – both IW and IT Pro perspective
            Exchange 2010 Policy management
            Exchange 2010 Discovery


 The following is a summary of the findings during this module.

6.7.2          Management and RBAC Findings
 The following items were identified during the EDPS engagement:

      Item                                           Comment

      Item A                                         Describe
      Item B                                         Describe

 EDPS Consultant: Place any specific items discussed in the Compliance, Archiving, and Retention
 module that would be of benefit to document and would aid in defining the scope or complexity of
 this deployment effort.



6.8          Exchange Unified Messaging
6.8.1          Unified Messaging Module
 The Exchange 2010 Unified Messaging module discusses Exchange UM overview as relates to
 Exchange. This section is optional if customer is not planning to deploy UM. Topics that are
 discussed include:
        Exchange 2010 Unified Messaging Fundamentals
        Unified Messaging Migration
        Unified Messaging administration


                                                                                                                                                             Page 14
                         L&EDPS Engagement Findings and Recommendations Documentation - Exchange, Exchange Deployment Planning Services, Version 2.0 Final
                         "Document1" last modified on 13 Sep. 12, Rev 10
                                                                                                             Microsoft and Microsoft Confidential Confidential




 The following is a summary of the findings during this module.

6.8.2          Unified Messaging Findings
 The following items were identified during the EDPS engagement:

      Item                                           Comment

      Item A                                         Describe
      Item B                                         Describe

 EDPS Consultant: Place any specific items discussed in the Unified Messaging 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 2010 or integration with OCS Voice, etc…

6.9          Exchange Complementary Products
6.9.1          Complementary Products Module
 The Exchange 2010 Complementary products module discusses Microsoft products designed to
 work with Exchange 2010. 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          Complementary Products Findings
 The following items were identified during the EDPS engagement:

      Item                                           Comment

      Item A                                         Describe
      Item B                                         Describe

 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 2010, the client would like x product as part of the deployment
 engagement, etc…




6.10 Exchange Developer Platform
6.10.1         Exchange 2010 Developer Platform Module
 The Exchange 2010 Developer Platform module discusses the basic understanding of Exchange
 2010 APIs and Platform capabilities. This section is optional. Topics that are discussed include:
        Exchange as a platform

                                                                                                                                                             Page 15
                         L&EDPS Engagement Findings and Recommendations Documentation - Exchange, Exchange Deployment Planning Services, Version 2.0 Final
                         "Document1" last modified on 13 Sep. 12, Rev 10
                                                                                                          Microsoft and Microsoft Confidential Confidential



         Exchange Web Services
         Exchange PowerShell
         Exchange Transport APIs
         API changes in Exchange 2010


 The following is a summary of the findings during this module.

6.10.2      Exchange 2010 Developer Platform Findings
 The following items were identified during the EDPS engagement:

   Item                                           Comment

   Item A                                         Describe
   Item B                                         Describe

 EDPS Consultant: Place any specific items discussed in the Exchange Developer Platform
 module that would be of benefit to document and would aid in defining the scope or complexity of
 this deployment effort.




                                                                                                                                                          Page 16
                      L&EDPS Engagement Findings and Recommendations Documentation - Exchange, Exchange Deployment Planning Services, Version 2.0 Final
                      "Document1" last modified on 13 Sep. 12, Rev 10
                                                                                                            Microsoft and Microsoft Confidential Confidential




7         CUSTOMER DEPLOYMENT CHALLENGES / RISKS
    <<OPTIONAL FOR CUSTOM ENGAGEMENTS>>
    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
    2010.
    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 17
                        L&EDPS Engagement Findings and Recommendations Documentation - Exchange, Exchange Deployment Planning Services, Version 2.0 Final
                        "Document1" last modified on 13 Sep. 12, Rev 10
                                                                                                             Microsoft and Microsoft Confidential Confidential




8         CUSTOMER HIGH LEVEL DEPLOYMENT PLAN
    <<OPTIONAL FOR CUSTOM ENGAGEMENTS>>
    The following is a preliminary high level Exchange 2010 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 18
                         L&EDPS Engagement Findings and Recommendations Documentation - Exchange, Exchange Deployment Planning Services, Version 2.0 Final
                         "Document1" last modified on 13 Sep. 12, Rev 10
                                                                                                             Microsoft and Microsoft Confidential Confidential




9         EDPS OBJECTIVES AND DOCUMENTATION
    <<REQUIRED FOR CUSTOM ENGAGEMENTS>>
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 19
                         L&EDPS Engagement Findings and Recommendations Documentation - Exchange, Exchange Deployment Planning Services, Version 2.0 Final
                         "Document1" last modified on 13 Sep. 12, Rev 10
                                                                                                         Microsoft and Microsoft Confidential Confidential




10     EDPS ENGAGEMENT RESULTS
 <<REQUIRED FOR CUSTOM ENGAGEMENTS>>
 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 20
                     L&EDPS Engagement Findings and Recommendations Documentation - Exchange, Exchange Deployment Planning Services, Version 2.0 Final
                     "Document1" last modified on 13 Sep. 12, Rev 10
                                                                                                          Microsoft and Microsoft Confidential Confidential




11      EDPS ENGAGEMENT SCHEDULE
 <<REQUIRED FOR CUSTOM ENGAGEMENTS>>
 The following is the summary of the project schedule and tasks that took place during the EDPS
 engagement:


     Engagement Day                               Tasks

     Day 1                                        Describe task/deliverable worked on and work performed this day
     Day 2                                        Describe task/deliverable worked on and work performed this day
     Day 3                                        Describe task/deliverable worked on and work performed this day
     Day 4                                        Describe task/deliverable worked on and work performed this day
     Day 5                                        Describe task/deliverable worked on and work performed this day
     Day 6                                        Describe task/deliverable worked on and work performed this day
     Day 7                                        Describe task/deliverable worked on and work performed this day
     Day 8                                        Describe task/deliverable worked on and work performed this day
     Day 9                                        Describe task/deliverable worked on and work performed this day
     Day 10                                       Describe task/deliverable worked on and work performed this day
     Day X….                                      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 21
                      L&EDPS Engagement Findings and Recommendations Documentation - Exchange, Exchange Deployment Planning Services, Version 2.0 Final
                      "Document1" last modified on 13 Sep. 12, Rev 10
                                                                                                           Microsoft and Microsoft Confidential Confidential




12       APPENDIX
 <<OPTIONAL>>

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 22
                       L&EDPS Engagement Findings and Recommendations Documentation - Exchange, Exchange Deployment Planning Services, Version 2.0 Final
                       "Document1" last modified on 13 Sep. 12, Rev 10
                                                                                                          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 23
                      L&EDPS Engagement Findings and Recommendations Documentation - Exchange, Exchange Deployment Planning Services, Version 2.0 Final
                      "Document1" last modified on 13 Sep. 12, Rev 10
                                                                                                          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 2010, 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 2010)
     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 24
                      L&EDPS Engagement Findings and Recommendations Documentation - Exchange, Exchange Deployment Planning Services, Version 2.0 Final
                      "Document1" last modified on 13 Sep. 12, Rev 10
                                                                                                         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 2010 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 25
                     L&EDPS Engagement Findings and Recommendations Documentation - Exchange, Exchange Deployment Planning Services, Version 2.0 Final
                     "Document1" last modified on 13 Sep. 12, Rev 10
                                                                                                          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 <<URL>>.
 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.
 Exchange Best Practices Analyzer
 http://www.microsoft.com/downloads/details.aspx?familyid=dbab201f-4bee-4943-ac22-
 e2ddbd258df3&displaylang=en
 Mailbox Server Role Storage Requirements Calculator
 http://msexchangeteam.com/archive/2009/11/09/453117.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-bab8-
 fc886956790e&DisplayLang=en
 Microsoft Operations Framework (MOF)
 http://www.microsoft.com/mof
 Microsoft Exchange Server 2010 - Planning and Architecture
 http://technet.microsoft.com/en-us/library/aa995902(EXCHG.140).aspx
 Microsoft Exchange Server 2010 - Deployment
 http://technet.microsoft.com/en-us/library/dd351084(EXCHG.140).aspx
 The Microsoft Exchange Team Blog
 http://www.msexchangeteam.com
 TechNet Forums - Exchange Server
 http://forums.microsoft.com/TechNet/default.aspx?ForumGroupID=235&SiteID=17




                                                                                                                                                          Page 26
                      L&EDPS Engagement Findings and Recommendations Documentation - Exchange, Exchange Deployment Planning Services, Version 2.0 Final
                      "Document1" last modified on 13 Sep. 12, Rev 10

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:8
posted:9/13/2012
language:English
pages:30