Exchange Migration Best Practices
Process, Planning, and Success Using Priasoft’s
Migration Suite for Exchange
09/19/2014
Eriq Vanbibber – CTO, Priasoft Inc.
Introduction
 Presenter - Eriq VanBibber
–
–
–
–
Expert in automation
Expert in .NET
Expert in MAPI and COM
Long history of Enterprise consulting and IT management/architecture
 Developer of Exchange Migration Software and Solutions since
1999
– Focused 100% on Microsoft exchange migration space – Enterprise,
Government, SMB
– Over 5 million mailboxes / public folders and thousands of customers
migrated to date
 Product suite capable of migrating to / from all versions of
Exchange 5.5, 2003, 2007, 2010, 2013 and Office 365 (in Beta)
Assumptions
–
Attendees have varying levels of MS Exchange experience
•
–
Some attendees have prior migration experience
•
–
–
Experience could be
– Designed
– Managed
– Executed
– Lived thru a migration as an end user
Attendees are attending this conference in order to learn how to achieve the BEST success for an
upcoming migration
Some attendees have technical experience across these areas:
•
•
•
•
•
–
Experience types:
– Architect
– Manager/Admin
– End user – Outlook / OWA
Exchange
Windows Networking
File system
Windows Security
Active Directory
Some attendees have non-technical experience across these areas:
•
•
•
Project Management
Process Development
Help Desk Management
Architecting Success – Current State
 Current migration plan/process
– Success criteria
• Does this exist? If not, should it?
• Technical success vs. Business success vs Project success
– Simple outline of desired/expected migration process today
• What is the starting point of the current plan?
• What event(s) have the most affect on success?
• When is it complete?
– Highlights of important or challenging aspects
•
•
•
•
•
Compressed timeline
Highly distributed environment
Large amounts of data - size/items
Unique accounts or objects – e.g. help desk applications
Source/Target owner interaction
Architecting Success – Influencers
 Corporate Communication
– Word-smithing
– Consistent messaging
– Avoid “scary” words
• Big Bang, Cutover
• Try: Single-Event migration, Switch-over
– Simple information when delivered to everyone
– Detailed information sent only to department leaders
 Help Desk
– Will receive most first calls
– Must use same messaging a Corp. Communication
– Should attempt to have ready responses to questions or issues
• “I don’t know” or “We’ll get back to you” increases anxiety of users
– Response to unresolved issues
– Multiple Help Desks (common with acquisitions)
Architecting Success – Process


Current migration plan/design
Priasoft’s typical process vs. current ideas
–
–
–
–
–


AD migration – Do or do not? Now or Later?
Coexistence vs. ‘big bang’
Pre-load vs. backfill
Pre-stage vs. sync
Complex vs. simple
Process is Not tech heavy
Identify gaps and possible concerns
–
–
–
–
–
MAC (Move/Add/Change) process(es) before, during, and after migration
Compliance – direct and indirect
Help Desk
High security influence
Minimum requirements for use
• End user clients
• Business rules
• SLAs
Architecting Success – Scheduling

Requirements
– Contractual
– Agency
– Migration team




Cascaded dependency – e.g. network cutoffs, scheduled outages
Blackout dates
Approved time windows and impact if exceeded
Control and influence
–
–
–
–
–



Who really owns the schedule? (The migration team, not the department/business unit)
Users can impact schedule
Departments and dependencies can impact
Expectations
Repercussions of missed dates
Approval and CYA
Exception handling
Metrics, metrics, metrics!
Architecting Success – DryRun



What is it?
– A migration of objects using the exact same process and tools that would be used
during the production migration
– Does not interrupt or interfere with operations
– Does not make changes to the source environment
What is the purpose?
– Identification of problems that would have otherwise been seen during production.
– Identification of gaps in the current migration process
– Validation of environmental changes
– Metrics – how long, how fast
What does it deliver?
– A guarantee – when you get 100% success of the DryRun, you know that the
production migration will succeed.
– No-slip scheduling – you know how long the migration will take and can schedule
appropriately
– Confidence – for the migration team, end users, and stakeholders
Architecting Success – DryRun
 How to approach?
– Have to know purpose first. Each purpose has different caveats
– Balance between critical value and effort needed
 Order?
–
–
–
–
Functional Tests: Can I migrate?
Performance Tests: How much can I migrate?
Fidelity Tests: What issues will I find?
Metric Tests: How long does it take to migrate?
 Important variables
–
–
–
–
External influencers still exist and can skew results
Time windows and environment load still apply
Time between dry-run and production run
Difference between dry-run of all mailboxes versus a portion
Migration Components
 Accounts/Users
– Categorization – VIP, Simple, Power-user, Webmail user, application accounts,
shared mailboxes, resource mailboxes, multiple-mailbox accounts, dependent
accounts
– Ambiguity and misinterpretation
– Expectations and Perceptions
– Interface types – Outlook, OWA, etc..
– Communication
 Contacts
– Categorization – Simple Forward, Local Org representation of remote user,
utility/application, other
– Ambiguity – within the topic of contacts and between contacts and users/DLs
– Expectations and Perceptions
– Header rewrites
– Edge/gateway dependency
Migration Components
 Distribution Lists
– UDG vs. USG
– DLs are actually AD Groups
• Contains many types: Contacts, Users, Groups, PFs
• Objects must exist in order to re-add
– USGs can be use to secure Exchange Objects like PFs
– Should migrate holistically
– Changes during and after migrated
 Public Folders
–
–
–
–
–
–
Often controlled access by DLs
PFs attributes: items, rules, email addresses, permissions
Each mail-enabled PF has corresponding AD object
Changes during and after migrated
Access to PF data is determined by Exchange Database setting
Folder structure is replicated by default; content can be on specific server(s)
Migration Components
 Outlook Profiles
–
–
–
–
–
–
–
Cross Forest versus same Forest
Multiple profiles
Secondary Mailboxes
Group Policies
AutoDiscover Issues
Deployment
Help Desk responses
Migration – Technical Influencers
 Mail flow
–
–
–
–
–
Edge/gateway routing
Namespace mangling
Expectations/perceptions pre and post migration
Control and ownership
External impact (partners, suppliers, customers, etc.) of namespace changes
 Network Analysis
–
–
–
–
–
–
–
–
Line speeds and types – mpls, vpn, burst vs sustained, etc.
Latency – impact, mitigation, and planning
Auto-Auto
Jumbo Frames
Firewalls
Load Balancers / High Availability Designs
IPv6 – Enable or disable?
Certificates
Migration – Technical Influencers
 Storage Architecture
– Impact based on type
• SAN – implementation design and impact
• Local – SaS, SCSI, SATA, etc.
– Utilization
• Dedicated
• Shared – Isolated
• Shared – fully shared
– Read/write queue metrics
 Directory Replication, Synchronization
–
–
–
–
–
–
Existing DirSync solutions, if any
Priasoft’s Collaboration Suite
Scope, overlap, and conflicts
Post migration necessity
Changes and considerations during migration “period”
Coexistence support – ADFS, Availability Service, etc.
Migration – Performance Influencers

Virus Scanners
–
–
–

Backups
–
–


Circular logging
Network, VPNs, and Firewalls
Throttling Policies
Users
–
–
–

Exchange backups
Backups of other systems that use same disk system as Exchange
Archiving
DAGs and Clusters
–



On access vs. gateway
Item age impact
Benefit of dry-run
User initiated (not requested) ‘clean up’ – creates trans logs
Mass changes to source items affects backfill cutoff date (modified date)
Very large mailboxes (item count) – migration duration for batch is at least as long as the largest mailbox
Migration workstation/server
–
–
–
–
–
Physical placement considerations
Concurrency and read/write queue exhaustion
CPU and RAM considerations
NIC configurations, including virtual to physical mapping
Virtual Machines vs Physical Machines
Technologies and Requirements
 Requirements
– Local computer – OS, specs, etc.
– Environmental – No Firewalls, no wireless, etc.
– Permissions – AD/LDAP, local machine, and exchange data
 Technologies used
–
LDAP
–
–
–
–
MAPI
HTTP
PowerShell
Name resolution
• DNS, WINS, hosts, lmhosts, etc
• User PCs and Migration Workstation
– MS-RPC
 Domains, Forests, GCs vs DCs, etc.
– AD Sites and Replication
 Trusts vs. not
Topology
Exchange 2007 or earlier using Windows Trust
Topology
Exchange 2010 or Untrusted Source
Lab work, Reporting, and Troubleshooting
 Troubleshooting and support
–
–
–
–
–
–
–
Domain Policies – Workstation and User in relation to migration computer
IPV6
Permissions
Typical issues and identification
Distinguishing process vs technical issues
Where/what to analyze
Flags and overrides
 Reporting
– Requirements
• Contractual (typically for 3rd party consultants)
• Customer driven
• Smart/CYA
– Where to find
– How to get if not exactly available
– Identification of data that requires scripting or non-core tools.
Most Common Issues
 Permissions
– Rights to logon to mailboxes change
• …because of Domain Policy change
• …because ‘MAPI’ account added to additional group(s)
• …because account disabled/locked out
 Name resolution
– Changes to DNS
– Changes to WINS
– Changes to IP configuration – perhaps by Domain Policy
 Mailbox Limits
 Throttling Policies
 Source or Target mailbox moved to different server before migration
completed
 AD user account deleted or moved after migration started
 Outlook Profile Update did not run
Review and Migration Plan

Review and Q&A
–
–
–

Listing of new tasks identified thus far
Clarification of ideas
Ordering of above by time/priority
Outline of revised migration plan
①
②
Discovery
Outlook Client Updater – deployment
–
–
–
③
User account staging
–
–
–
④
⑤
ADMT
Priasoft Pre-staging Tools
Scripted
Distribution List Migration – if not handled by Pre-Staging efforts
Dry-Run
①
②
③
④
⑤
⑥
Performance Tuning
Fidelity Checks
Duration and Metrics
Issue resolution
Dry-run of resolved items or new dry-run if major environment change
Public Folder Migration
①
②
⑦
⑧
⑨
⑩
⑪
⑫
User acceptance and confidence of ‘new change’
Assurance that automation process is working
Optional collection of mailbox size info
Performance and duration calculations
Production migration
Production Scheduling
Pre-migration tasks – gateway suspension, MAC suspension
Mailbox Migration
Public Folder migration of any updated/new items
Post-migration tasks – MX record switch, gateway resumption, new MAC process
Outlook Client Updater – execution
Questions / QA?
Thank You!