Transition to the services in the cloud can be either easy if you handle smaller number of users and migrating just users’ mailboxes from some hosting provider. But, when talking about larger number of users and services used in on-prem systems, things can get complicated. Algebra have been using on-prem systems from Exchange 2003 and OCS 2007. This summer we’ve done migration to Office 365 Exchange and Lync Online as well as AD synchronization from on-prem AD to Azure AD. In this session you will hear about our migration process, why we’ve chosen that migration path and not some other.
3. Before migration
• Exchange 2010 organization
• 1 – CAS/HUB/MBX server
• 1 – EDGE with Forefront
• Lync 2010
• 1 – standard edition
• 1 – EDGE
• Reverse Proxy – MS TMG
• Only algebra.hr domain was migrated, subdomains *.algebra.hr
and racunarstvo.hr were in Office 365 in separate tenants
4. Before migration
• 60ish users (average mailbox is 4GB)
• around 120 distribution groups
• 60 dynamic distribution groups
• 50ish Public Folders and majority are mail enabled
• Lync was used primarily for IM and presence, seldom for Web
Conferencing
• SharePoint wasn’t used
5. Requirement
• Migrate all the services to Office 365
• Show-stoppers:
• Password syncronization
• ADFS isn’t an option
6. What we did?
• Tenant was registrated in Office 365 (April, 2013)
• 1st step was creating custom domain (you get
*.onmicrosoft.com by default)
• We got stuck in this step – domain algebra.hr was reserved and locked
in Live system ?!?
• Office 365 support received ticked in April, and it was resolved in June
7. What we did?
• 2nd step was choosing Exchange migration option
• Boundaries
•
•
•
•
Number of mailboxes
User management in cloud or on-prem (DirSync)
Exchange version
But there were some additional requirements (what about Public Folders?)
8. What we did?
Existing Exchange
organization
Exchange 2013, Exchange
2010, Exchange 2007 or
Exchange 2003
Exchange 2007 or Exchange
2003
Number of mailboxes
Management of users on-prem
Migration type
Less than 1000 mailboxes
No
Cutover Exchange migration
Less than 1000 mailboxes
No
Staged Exchange migration
Exchange 2007 or Exchange
2003
Supported more than 1000
mailboxes
Yes
Staged Exchange migration or
remote move migration in
Exchange hybrid deployment
Exchange 2013 or Exchange
2010
Supported more than 1000
mailboxes
Yes
Remote move migration in
Exchange hybrid deployment
Exchange 2000 Server or
previous version
No restrictions
No
IMAP migration
Non-Exchange systems
No restrictions
No
IMAP migration
9. What we did?
Office 365 Small
Business
Office 365 Small
Business
Premium
Office 365 Midsize
Business
Office 365
Enterprise E1
Office 365
Education A2
Office 365
Government G1
No
No
Yes
Yes
Yes
Yes
Yes
IMAP migration
supported
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Cutover migration
supported
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Staged migration
supported
No
No
Yes
Yes
Yes
Yes
Yes
Functionalities
Hybrid deployment
supported
Office 365
Enterprise E3
Office 365
Education A3
Office 365
Government G3
Office 365
Enterprise E4
Office 365
Education A4
Office 365
Government G4
Office 365
Enterprise K1
Office 365
Government K1
10. Migrations in short
• IMAP migration
•
•
•
•
•
•
Creating EXO users before migration
Creating CSV file (EXO-mail, username, password)
Starting migration batch (all or part of users)
Inbox and subfolder migration
Maximum 50.000 items from whole mailbox
Maximum item size is 35MB
11. Migrations in short
• Cutover migration
•
•
•
•
•
Simple migration – move everything to the cloud
Less than 1000 mailboxes
Migration creates EXO users
It will migrate distribution lists and contacts
Requirement is Outlook Anywhere – publicly trusted CA certificate
12. Migrations in short
• Staged migration
• User migration in phases (based on CSV file)
• Less than 1000 mailboxes
• Requirement is DirSync and Outlook Anywhere – publicly trusted CA
certificate
• Exchange 2010 and Exchange 2013 are not supported
• Final goal is to migrate all the users to the Office 365
13. Migrations in short
• Hybrid
• More than 1000 users or keeping on-prem server
• Online archive, mailbox on-prem
• Requirement is DirSync and Outlook Anywhere – publicly trusted CA
certificate
• On-prem Exchange versioned 2010 or 2013
• One organization – sharing free/busy, OOF, mail tips…
• Mailboxes are movable in all directions
14. What we did?
• 2nd step was choosing Exchange migration option
• We wanted to use DirSync (user management and user credentials onprem) – so choose Staged Migration
• Staged Migration – doesn’t support Exchange 2010!
• Conclusion – we need to use hybrid migration
15. What we did?
• 2.a. Lync migration
•
•
•
•
•
•
•
Enabled DirSync
Assigned Lync licences in Office 365
Changed DNS records for Lync
Users use Lync Online
Users needed to recreate their contacts in Lync clients
Turning off on-prem servers
Migration time was 1 day
16. What we did?
• 3. start of Hybrid deployment
• Preparation of existing Exchange environment
• Autodiscover – up and running – pointing to on-prem Exchange
• Outlook Anywhere – up and running on on-prem Exchange
• Starting of Hybrid Deployment Wizard
• ! – in Office 365 domain settings, domain has to be marked for Hybrid
deployment
• Validaton by using Remote Connectivity Analyzer (RCA)
18. What we did?
• 4. start of Hybrid deployment
• Choosing of mail routing
• Inbound – EXO on-prem or on-prem EXO
• Outbound – EXO on-prem or on-prem EXO or each by itself
• Establishing federation with Microsoft Federation Gateway – domain
validation by adding TXT DNS record
• FAILED - domain is locked on MFG (?!?) – support ticket
19. What we did?
• 4. start of Hybrid deployment
• August 2013 – problem was solved
• Finalized Hybrid Deployment Wizard
• Mail routing was set-up
• Inbound – to on-prem system
• Outbound – every system by using DNS MX routing
• Autodiscover – pointed to the on-prem system
20. What we did?
• 5. preparation for data move
• Dynamic distribution groups – based on LDAP querys, by using OU
parameters – it’s not supported in Office 365 as there are no Ous
• Conversion from dynamic DGs to „static” DGs isn’t supported
• What about Public Folders?
• There is supported hybrid scenario (PFs stay on on-prem system)
• Migration is supported – but only in Cutover and Staged migrations
• PST migration - ?!?
21. What we did?
• 5. preparation for data move
• Dynamic distribution groups were converted to static – by manually
creating them
• Problem was client auto-complete option and NDR generation – high
support ticketing volume
22. What we did?
• 6. migration of user mailboxes in batches
• It took 72 hours to complete
• Some of the mailboxes failed durring migration
• BadItems – user data that is corrupted in mailboxes
• LargeItems – big messages with up to 1023 attachments
• Default migration settings set that values to 0 – that kind of items are not allowed
23. What we did?
• 7. Public Folder migration
• It took 48 hours to complete
• Even dough we are in Hybrid we choose „unsupported” option to
migrate Public Folders instead
• PF can be on-prem or in EXO
• Migration is done by using scripts
24. What we did?
• 7. Public Folder migration
•
•
•
•
1. script – creates mapping PF size
2. script – creates PF mailboxes
3. script – creates CSV file with mail-enabled PF parameters
Migration is contiguous, but there are some downtimes at the end of
migration – when PFs are finally moved to EXO
25. Where are we now?
• November 2013
• We are still in Hybrid model – we are waiting for the DEV team to
change application configuration for using Office 365 SMTP transport
• Moving Exchange on-prem to virtual machine and hoping for better
time…
27. Conclusion
• Migration wasn’t done in planned time frame
• User education is crucial during migration
•
•
•
•
Distribution groups
Loosing Address Book segmentation and hierarchy
Changing of SPAM policy
Not all mobile phones reconfigured as expected