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!