Module 1 Introduction to Designing a Microsoft® Exchange Server 2010 Deployment.
Post on 18-Jan-2016
219 Views
Preview:
Transcript
Module 1
Introduction to Designing a Microsoft® Exchange Server 2010
Deployment
Module Overview
• Gathering Business Requirements
• Identifying Additional Requirements
• Introduction to Service Level Management
• Analyzing the Current Messaging Environment
Lesson 1: Gathering Business Requirements
• What Are Business Requirements?
• What Are Functional Requirements?
• Defining Service Level Agreements
• Discussion: Identifying Regulatory and Organizational Compliance Requirements
• Identifying Project Constraints
What Are Business Requirements?
• Improving efficiency
• Meeting external requirements
• Avoiding disruptions to business processes
• Exploring new business areas or solutions
Business requirements may include:
A technology deployment is more likely to address an organization’s needs if business requirements are clearly and concisely defined at the project’s inception
A technology deployment is more likely to address an organization’s needs if business requirements are clearly and concisely defined at the project’s inception
What Are Functional Requirements?
• All e-mail sent to and from a partner organization must be secure
• Exchange Servers must be configured to require encryption of all e-mail messages
Business RequirementBusiness Requirement Functional RequirementFunctional Requirement
Functional requirements are derived from business requirementsFunctional requirements are derived from business requirements
Defining Service Level Agreements
An SLA is an understanding that is reached between an organization and its information technology department, which defines expected infrastructure performance and availability levels
An SLA is an understanding that is reached between an organization and its information technology department, which defines expected infrastructure performance and availability levels
Availability Availability PerformancePerformance RecoveryRecovery
SLAs typically define different categories for expected performance, including:
Discussion: Identifying Regulatory and Organizational Compliance Requirements
Regulatory and organizational compliance requirements
15 min15 min
Notes Page Over-flow Slide. Do Not Print Slide. See Notes pane.
Identifying Project Constraints
Project constraints can include:
ResourcesResources FeaturesFeaturesSchedulesSchedules
Lesson 2: Identifying Additional Requirements
• Typical Stakeholders
• Defining Technology Requirements
• Identifying IT Requirements
• Identifying Security Requirements
• Identifying User Requirements
• Discussion: Dealing with Conflicting Requirements
Typical Stakeholders
• A project stakeholder is anyone who sponsors a project, or has interest in the project’s completion
• The business sponsor is one of the most important stakeholders
• Additional project stakeholders for an Exchange Server 2010 deployment include:
IT personnel
Security and compliance officers
Messaging users
Defining Technology Requirements
• Server room equipment
• Storage technologies
• Backup and recovery solutions
• Network infrastructure
• Active Directory infrastructure
• Datacenter configuration and location
• User distribution
Components in the existing infrastructure that you must consider include:
Identifying IT Requirements
• IT department needs
• Concerns about the project
• Current IT pain points that the project may address
• IT requirements for accepting the new technology
• IT policies and processes
To identify IT requirements, you must determine:
Identifying Security Requirements
• Security risks for messaging within the organization
• How security requirements are currently addressed
• The gaps between security requirements and current solutions
• General security guidelines or mandates that the messaging project must follow
To identify security requirements, you must determine:
Identifying User Requirements
• How users currently use e-mail
• Types of messaging clients that the organization uses
• Problems with the current messaging system
• Training requirements
• Security requirements for mailboxes
• Level of use of the messaging system
• Special security needs, performance requirements, or functionality concerns
To identify user requirements, you must determine:
Discussion: Dealing with Conflicting Requirements
Resolving conflicting requirements
15 min15 min
Notes Page Over-flow Slide. Do Not Print Slide. See Notes pane.
Lesson 3: Introduction to Service Level Management
• What Are Service Level Agreements?
• What Is Service Level Management?
• What Is Availability?
• Business Requirements and Service Level Management
• Disaster Recovery and Service Level Management
• Creating Service Level Agreements
What Are Service Level Agreements?
An SLA documents service expectations and requirements delivered from an IT service provider to an organization
An SLA documents service expectations and requirements delivered from an IT service provider to an organization
SLA Type Description
Internal A formal agreement between two departments within the same organization
External A formal, legally binding contract
Informal A verbal agreement between the IT service provider and the organization
ITIL refers to an internal SLA as an Operational Level AgreementITIL refers to an internal SLA as an Operational Level Agreement
What Is Service Level Management?
Service level management defines and manages required and expected service levels
Service level management defines and manages required and expected service levels
• Creating a service catalog
• Negotiating SLAs
• Monitoring service levels
• Reporting service levels
• Reviewing service level agreements
Service level management tasks:
What Is Availability?
• Availability is a level of service that applications, services, or systems provide, expressed as a percentage of time
• Highly available services or systems are available more than 99% of the time
• Availability requirements differ based on how availability is measured
• Planned outages typically are not included when calculating availability
Business Requirements and Service Level Management
• Number of impacted users and severity of impact
• Number of impacted customers and severity of impact
• Number of affected services and severity of impact
Business requirements help IT providers understand business processes
Business requirements help IT providers understand business processes IT providerIT provider
Stakeholders must understand that providing high availability levels costs moreStakeholders must understand that providing high availability levels costs more
Some measures used to define service priority include:
Disaster Recovery and Service Level Management
Disaster recovery is a critical part of service level management
Disaster recovery is a critical part of service level management
• Implementing redundant hardware in servers
• Storing backups offsite
• Maintaining local copies of recent backups
• Maintaining spare hardware
• Synchronizing data between two or more servers
• Synchronizing data between two data centers
Disaster recovery planning can include:
Failure to quickly recover from a disaster can impact businessFailure to quickly recover from a disaster can impact business
Creating Service Level Agreements
• Availability definitions
• Security requirements
• A process for problem resolution escalation
• Actions to take if the SLA is not met
• Support business objectives
• Be specific and measurable
• Be attainable
• Bring value to the organization
SLA objectives must:
At a minimum, an SLA must include:
Lesson 4: Analyzing the Current Messaging Environment
• Analyzing the Physical Network Infrastructure
• Analyzing the Name Resolution Services Infrastructure
• Analyzing the Active Directory Infrastructure
• Analyzing the Messaging Infrastructure
• Identifying Messaging System Usage
• Identifying Additional Infrastructure Components
• Analyzing Administrative Models and Processes
• Analyzing the Change Control Process
Analyzing the Physical Network Infrastructure
• The number, geographic locations, and link speed of all sites where network services are currently offered
• A routing topology map that illustrates the physical sites and the IP subnets in use at those sites
• Bandwidth, latency, and current usage
• Use of virtual local area networks
• Firewall configuration requirements
• Non-technical constraints
Consider the following elements of the physical network infrastructure:
Analyzing the Name Resolution Services Infrastructure
• DNS software
• DNS maintenance and administration
• DNS namespace planning
• Location of DNS servers
• Number of DNS zones, and Active Directory integration
• Resource records
Consider the following elements of the name resolution services infrastructure:
Analyzing the Active Directory Infrastructure
• Active Directory site configuration
• Active Directory forest and domain topology
• Domain controller and global catalog server configuration
• Group Policy configuration
• Schema master configuration
• Existing directory service (if migrating to AD DS)
Consider the following elements of the Active Directory infrastructure:
Analyzing the Messaging Infrastructure
• Use the Microsoft Exchange Server Profile Analyzer and Exchange Server Best Practices Analyzer tools to capture current information about the messaging environment
• Document information that you can use to roll back if necessary to a previous state or compare the existing environment to the intended Exchange Server 2010 environment
It is critical that you assess and document specific functionality and configuration parameters before proceeding with an Exchange Server 2010 deployment
It is critical that you assess and document specific functionality and configuration parameters before proceeding with an Exchange Server 2010 deployment
Identifying Messaging System Usage
Usage information Considerations
Client environment
• Current operating system and e-mail client
• Number of client computers and their locations
• Current plans to redeploy, update, or replace clients
• Client protocols used to access e-mail
Messaging statistics
• Total size of user mailboxes
• Size of all messages in specific folders
• Average number of messages received per day
• Average number of messages sent per day
• Average number of recipients for each sent message
• Attachment size statistics across all attachments
• Number of contacts in a mailbox
• Number of appointments in a mailbox calendar
• Average number of meeting requests received per day
Identifying Additional Infrastructure Components
• What is the current storage method for the messaging databases?
• Have you integrated Windows Clustering Services?
• What additional software has been integrated within the current messaging system?
• Have you implemented a specific backup and disaster recovery infrastructure?
• How is your current messaging environment integrated with other systems?
Analyzing Administrative Models and Processes
Current organizational administrative model?
User account administrative model?
Business unit structure
• Do separate business units or divisions require security boundaries between them?
• What are the requirements for communication between business units?
• How is cross-unit communication controlled?
• How is the messaging system funded?
Analyzing the Change Control Process
• How does the organization implement IT changes?
• IT infrastructure change approvals
• Change notification
• Emergency escalation notification processes
• What are the time frames for making changes that may impact availability?
• What are the risk management processes related to change management?
Lab: Introduction to Designing an Exchange Server 2010 Deployment
• Exercise 1: Evaluating an Existing Messaging Infrastructure
• Exercise 2: Creating a Requirements Document
• Exercise 3: Discussion: Real-World Best Practices for Setting Budget Expectations
• Exercise 4: Discussion: Refining the Scope of SLA Requirements
Estimated time: 120 minutes
Lab Review
• In Exercise 1, what additional information may be required to complete a design for the A. Datum messaging infrastructure? How would you get that information?
• In Exercise 2, which requirements discussed in Task 1 have the potential to cause conflicts? What solutions would you propose to resolve these conflicts?
Lab Scenario
You are a messaging engineer for A. Datum Corporation, an enterprise-level organization with multiple locations. A. Datum is an international corporation involved in technology research and investment, and is planning to upgrade from Exchange 2003 Server to Exchange Server 2010. A. Datum currently has three remote sites and their headquarters. The company is pursuing an aggressive expansion plan, and will be adding two new office locations during the upgrade project.
Module Review and Takeaways
• Review Questions
• Best Practices
top related