EDPS Engagement Summary and Recommendations
Document Sample
EDPS Engagement Summary and Recommendations
Exchange Deployment Planning Services
Prepared for
Customer Name
Friday, 28 October 2011
Version 2.0
Prepared by
Consultant Name
Contributors
EDPS Delivery Partner
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 Instant 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 Environmental Dependencies ................................................................................................. 10
6.1.1 Environmental Dependencies Module .............................................................................. 10
6.1.2 Environmental Dependencies Findings ............................................................................ 10
6.2 High Level Conceptual Design ............................................................................................... 10
6.2.1 Conceptual Design Findings ............................................................................................. 11
6.3 Lync Server 2010 Deployment ............................................................................................... 12
6.3.1 Deployment Module .......................................................................................................... 12
6.3.2 Deployment Findings ........................................................................................................ 12
6.4 Lync Server 2010 Migration and Coexistence: OCS 2007 or OCS 2007 R2 ......................... 12
6.4.1 Migration and Coexistence Module ................................................................................... 12
6.4.2 Upgrade and Coexistence Findings .................................................................................. 12
6.5 Lync Server Management and Admin Experience ................................................................. 13
6.5.1 Management and Admin Experience Module ................................................................... 13
6.5.2 Operations and Management Findings ............................................................................. 13
6.6 Lync Server Remote Access ................................................................................................. 13
6.6.1 Remote Access Module .................................................................................................... 13
6.6.2 Remote Access Findings .................................................................................................. 14
Page ii
EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 1.0
6.7 Lync Server 2010 Bandwidth Management ........................................................................... 14
6.7.1 Bandwidth Management and Call Admission Control Module .......................................... 14
6.7.2 Bandwidth Management Findings ..................................................................................... 14
7 Customer Deployment Challenges / Risks ............................................................................... 15
8 Customer High Level Deployment Plan .................................................................................... 16
9 EDPS Objectives And Documentation....................................................................................... 17
10 EDPS Engagement Results ..................................................................................................... 18
11 EDPS Engagement Schedule .................................................................................................. 19
12 APPENDIX ................................................................................................................................. 20
12.1 Deployment Planning Concepts ........................................................................................ 20
12.1.1 Envision ......................................................................................................................... 20
12.1.2 Plan ............................................................................................................................... 20
12.1.3 Developing/Build ........................................................................................................... 21
12.1.4 Stabilize ......................................................................................................................... 21
12.1.5 Deploy ........................................................................................................................... 22
12.2 Tools and Best Practices Reference ................................................................................. 24
Page iii
EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 1.0
1 DOCUMENT PURPOSE
<<REQUIRED SECTION>>
The following document is a summary of the X-day UC 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
EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0l
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
EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0l
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 Lync Server 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 communications, reduce costs, improve business integration, etc. Make sure to address
how Lync 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.0l
4 ORGANIZATION REQUIREMENTS
<<REQUIRED SECTION>>
<<Customer>> has the following organization requirements that were identified during the UC
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:
Maintain regulatory compliance <<Customers>> compliance and governance requirements are
met by built-in security, encryption, archiving, and call detail records. By using your own servers and
network, you maintain control over sensitive data that would otherwise be transmitted over public
telephone networks and third-party conferencing platforms.
Control costs Voice over IP (VoIP) enables communications among geographically dispersed
company locations without long distance charges. Integrated audio, video, and Web conferencing
helps reduce travel costs as well as the cost of third-party conferencing solutions.
Gain operational efficiencies <<Customer>> improves operational efficiencies by integrating
Unified Communications and rich presence into business workflows, latency and delays can be
reduced or eliminated. For geographically dispersed teams, group chat can enable efficient, topic-
specific, multi-party discussions that persist over time.
Improve productivity Rich presence information helps <<Customer>> employees find each other
and choose the most effective way to communicate at a given time. Instead of e-mailing
documents back and forth for approval, workers can rely on real-time collaboration through
enhanced conferencing with desktop, application, and virtual whiteboard sharing—or contact a
collaborator from within Microsoft Office or other applications. The unified Microsoft Lync 2010
client provides access to enterprise voice, enterprise messaging, and conferencing from one
simplified interface.
Support the mobile workforce <<Customers>> mobile workers get access to rich Unified
Communications tools from practically anywhere with an Internet connection, no VPN needed. An
updated Lync Mobile client makes joining and managing conferences, searching the Global Address
List, and viewing presence information easy. Rich presence in Lync Server 2010 has been updated
with mobile location information, making on-the-go workers easier to find and contact.
Note: An updated mobile client is not available as of now, it is expected to be coming this summer.
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.0l
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:
Lync Server 2010 technologies will enable <<Customer>> to …
Centralized Management: <<Customer>> requires a deployment that is centrally managed but
allows granular delegation. Lync Server 2010 will help meet these requirements by implementing
features such as…
Full Lync access without VPN: <<Customer>> has a large remote workforce that needs full client
access without the requirement of establishing a VPN session. Lync Server 2010 will help meet
these requirements by implementing features such as…
Data Center Resiliency: Split pool approach, The front and back end of Lync Server 2010 may be
split across two data centers, or primary and backup data centers may be used..
Branch Resiliency options: Branch resiliency options enabled by survivable branch appliances or
survivable branch servers.
Page 5
EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0l
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:
Public IM Connectivity: <<Customer>> requires a deployment that can …
Federation: <<Customer>> requires a deployment that can
Platform Extensibility: <<Customer>> requires a deployment that can
Page 6
EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0l
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 OCS/ Lync Server installed in
forest?
contoso.com Windows Server 2003 Native Yes
adatum.com Windows Server 2003 Native No
User accounts are located in the following Active Directory Domains:
Domain name Number of Users Comments
europe.contoso.com 8500
Page 7
EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0l
5.3 Current Instant Messaging Architecture
The current instant messaging environment consists of…
EDPS Consultant: Insert here a diagram of the current messaging topology if the client has one
available. Describe the customer instant 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 Instant Messaging 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 instant messaging servers? Is protocol
inspection done on incoming and exiting instant 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? What are the SLA’s regarding data recovery (from single server
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? Does the client implement
Operations Level Agreements (OLAs) for instant 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.0l
5.6 Disaster Recovery
EDPS Consultant: Briefly describe topics such as: Account 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 instant messaging administration
centralized or decentralized? Do instant messaging administrators require domain admin
privileges? Is there a separation between AD and Instant Messaging administration? Are there
read-only administrators? Is a resource forest in use? What political or delegation of privilege
requirements led to that decision? Who manages the instant messaging servers? Is it the same
people that manage the main organization directory (Active Directory)? Are the instant 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 there 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 Lync Server 2010? Is there an existing e-Discovery solution, and if so, what is it
used for? Is it compatible with Lync Server 2010? Are there 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 Lync Server 2010?
Are messages inspected for content prior to leaving the organization? If so, how, and is the solution
compatible with Lync Server 2010? Are there rules in place about how long instant messages
can/must be retained? How are these rules enforced? 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.0l
6 EDPS TECHNICAL PRESENTATION FINDINGS
<< SECTION 6.X OPTIONAL FOR CUSTOM ENGAGEMENTS >>
6.1 Environmental Dependencies
6.1.1 Environmental Dependencies Module
The environmental dependencies module discusses the pre-requisites that must be in place before
deploying any Lync 2010 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 Comment
Item A Describe
Item B Describe
EDPS Consultant: Place any specific items discussed that would aid in defining the scope or
complexity of this deployment effort. For example, the client needs to raise the forest and domain
functional level, 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 four modules:
Microsoft Lync Server 2010 - What is New
Microsoft Lync 2010 - What is New
Microsoft Lync Server 2010 - Edge Server Remote Access
Microsoft Lync Server 2010 - High Availability and Resiliency
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 Microsoft Lync 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.
Page 10
EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0l
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 Microsoft
Lync Server 2010 deployment project.
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 aid in
defining the scope or complexity of this deployment effort. For example: The customer would like to
deploy x number of backend servers, the edge servers will be combined or dedicated, SQL cluster,
X number of Frontend and backend 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
EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0l
6.3 Lync Server 2010 Deployment
6.3.1 Deployment Module
The Microsoft Lync Server 2010 - Setup and Deployment module discusses Lync Server 2010
setup and deployment topologies. Topics that are discussed include:
Changes in Setup and Deployment in Lync Server 2010
Overview of End-to-End Setup and Deployment process
Central Management Server and Store
Planning Tool and Topology Builder Demo
The following is a summary of the findings during this module.
6.3.2 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 directory
synchronization with another entity, all roles will be combined on one server in a simple topology,
what order servers will be deployed, etc…
6.4 Lync Server 2010 Migration and Coexistence: OCS 2007 or OCS
2007 R2
6.4.1 Migration and Coexistence Module
The Microsoft Lync Server 2010 - Migration and Coexistence module discusses Lync Server 2010
transition and coexistence strategies with OCS 2007 or OCS 2007 R2. Topics that are discussed
include:
Approach for migration and support boundaries
What do we migrate?
Demo: How do we migrate?
Migration and Coexistence Topologies
Demo: Client Interoperability
Interoperability during Coexistence
TAP Migration Lessons Learned
A typical Migration Guidance
The following is a summary of the findings during this module.
6.4.2 Upgrade and Coexistence Findings
The following items were identified during the EDPS engagement:
Item Comment
Page 12
EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0l
Item A Describe
Item B Describe
EDPS Consultant: Place any specific items discussed in the Migration and Coexistence module
that would aid in defining the scope or complexity of this deployment effort. For example: The
customer has an existing Edge design, the OCS 2007/2007 R2 environment is complex, LCS 2005
environment exists etc…
6.5 Lync Server Management and Admin Experience
6.5.1 Management and Admin Experience Module
The Lync Server Management and Admin Experience module discusses Lync Server 2010
management using Lync Server control. Topics that are discussed include:
Lync Server Control Panel
Lync Server PowerShell
Management Experience
RBAC
The following is a summary of the findings during this module.
6.5.2 Operations and Management 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 Operations and Management module
that would aid in defining the scope or complexity of this deployment effort. For example: The
customer does not have a dedicated operations team to manage Lync infrastructure, The customer
would like to integrate Lync user provisioning with existing provisioning system, etc..
6.6 Lync Server Remote Access
6.6.1 Remote Access Module
The Microsoft Lync Server 2010 - Edge Server Remote Access module discusses Lync Server
2010 Edge Server Architecture and deployment scenarios. Topics that are discussed include:
Edge Scenarios
Interoperability Federation
Plan for Edge
Manage Edge
Architecture
Page 13
EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0l
The following is a summary of the findings during this module.
6.6.2 Remote Access 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 Remote Access module that would
aid in defining the scope or complexity of this deployment effort. For example: The customer will
deploy multiple Edge Servers, etc…
6.7 Lync Server 2010 Bandwidth Management
6.7.1 Bandwidth Management and Call Admission Control Module
The Lync Server 2010 Management and Call Admission Control module discusses the problems of
over-subscribing network bandwidth and how CAC helps protect the network against unexpected
spikes.
Solution overview
Differentiators
Planning and Provisioning
6.7.2 Bandwidth Management 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 Bandwidth Management and Call
Admission Control Module that would aid in defining the scope or complexity of this deployment
effort. For example: etc…
Page 14
EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0l
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, hardware availability, mobility
or security requirements, or any other issue that may slow down or block deployment or use of
Lync Server 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 15
EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0l
8 CUSTOMER HIGH LEVEL DEPLOYMENT PLAN
<<OPTIONAL FOR CUSTOM ENGAGEMENTS>>
The following is a preliminary high level Lync Server 2010 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 16
EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0l
9 EDPS OBJECTIVES AND DOCUMENTATION
<<REQUIRED FOR CUSTOM ENGAGEMENTS>>
The Lync 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 17
EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0l
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 18
EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0l
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 19
EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0l
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 UC Exchange Deployment Planning Service engagement, you have begun the
process of following the MSF for your Lync 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 a Lync 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 20
EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0l
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 Lync, the final output of the planning process will identify servers, their locations,
their uses, the feature matrix that will be used by Lync, 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 7,
“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 Lync, the Developing phase is used to identify, develop, and test any custom
programs, scripts, etc. that are required for the Lync 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.
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.
Page 21
EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0l
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 Lync Server 2010, this will typically mean that a few generic steps will be executed
to prepare the corporate environment:
If a transition from OCS 2007, then migration of global settings from system container to
configuration partition
Prepare Schema (to apply all Lync schema updates to Active Directory)
Prepare Forest (to create AD objects in the Configuration container and universal groups
and to assign security to Lync related objects and property sets)
Prepare Domain (to create AD objects in the various domain containers and populate the
groups for the domains that will contain Lync objects)
Once those four steps have been executed, the Topology Builder and Lync server setup process
can be executed. A minimum Lync Server pilot requires a Front-End Server, a Back-End server
and an Edge Server.
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.
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.
Page 22
EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0l
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 a Lync environment, the deployment phase for small to medium operations typically only
involves moving account 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.
Page 23
EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0l
12.2 Tools and Best Practices Reference
This section provides links to some of the tools and best practice.
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.
Lync Best Practices Analyzer
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=030548df-0dc7-4f86-b8a9-
2f5ec8de8ba5
Microsoft Lync Server 2010, Planning Tool
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=bcd64040-40c4-4714-9e68-
c649785cc43a&displaylang=enMicrosoft Solutions Framework (MSF)
http://www.microsoft.com/technet/solutionaccelerators/msf/default.mspxMSF 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 Lync Server 2010 - Planning
http://technet.microsoft.com/en-us/library/gg398447.aspx
Microsoft Lync Server 2010 - Deployment
http://technet.microsoft.com/en-us/library/gg398664.aspx
Microsoft Lync Server 2010 - Operations
http://technet.microsoft.com/en-us/library/gg398344.aspx
Lync Blogs
http://technet.microsoft.com/en-us/lync/gg213847.aspx
Page 24
EDPS Engagement Summary and Recommendations, Exchange Deployment Planning Services, Version 2.0l
Shared by: xiaohuicaicai
Related docs
Other docs by xiaohuicaicai
brochure1 second generation third generation first generation Associates Inc
Views: 4 | Downloads: 0
