There’s no denying it. The Cloud is here, and email should logically be the first thing to migrate. Email requires the most storage and—despite what Microsoft says—it consumes more IOPS (Input/output operations per second) on your storage area network (SAN) than it should. So far, so good. But how do you ensure a successful email migration for your organization? Well, the prudent move would be to engage Anexinet! But if poorer judgment prevails, and you don’t, here’s a quick primer to explain the first few steps in the process:
If you’re an Active Directory house (and you probably are), you’re most likely going to use something called Azure AD Connect (AADC). This allows folks to login with the same credentials they use for applications that aren’t moving to the cloud.
But first, you need to ensure your Active Directory is healthy enough to synchronize with Azure. This means bringing a couple of tools into play.
First, review your Organizational Unit (OU) structure and decide if you want all that extraneous data pushed into the cloud. Many objects aren’t necessary in the cloud, so why push them there? Perhaps all you need migrated are user accounts and some distribution & security groups. Better to adjust the structure so that when you select the OUs to synchronize in Azure AD Connect (AADC), you don’t have to jump through more hoops to select what you want (and deselect what you don’t).
Next, run the IdFix tool from Microsoft. This will provide a report of all the fields (names, addresses, etc.) that are incompatible with Azure Active Directory. IdFix also finds duplicate address and invalid characters. Since you’ve already tidied-up the OU structure, you can tackle the objects you know are in scope first, then return to clean up the rest of the directory when time permits.
The AADC application has specific requirements, so review this link and carefully follow them. The web sites that only discuss AADC will tell you that the AD Forest Functional Level (FFL) need merely be 2003 or higher. However, you’ve probably got Exchange in the mix and you’re probably going to deploy an Exchange “hybrid” server, so you can manage users from an on-premises resource, which means you’ll need the FFL to be at least 2008 R2. So although the one document is technically correct, it’s likely not contextually correct for you. The AADC is relatively easy to install and configure, but this isn’t the article to help you with that. Perhaps in the next installment.
Let’s assume you’re running Exchange (if you were running Notes you’d have greyer hair). First you’ll want to review your Exchange environment to make sure it meets the minimum requirements. The bare minimum is Exchange 2010 SP3. That may seem old, but I’ve encountered Exchange 2010 SP2 a handful of times over the past year so it’s by no means a statistical outlier.
Spend some time cleaning up old distribution lists and mailboxes that are no longer required or in use. You don’t want to waste the time, and perhaps licenses, on old data and users who are no longer within the company. Work with HR to cleanse the Exchange databases and purge any mailboxes that are no longer required. Management, legal and perhaps HR will also have a handle on how much email ought to be retained. Sometimes, policies to purge old data are not universally applied. Don’t forget to ask users to purge data they know they shouldn’t keep but are reluctant to delete. The more unnecessary data you have, the longer it will take to move the good data to Exchange online.
Additionally, review your send and receive connectors. Sometimes SMTP connectors persist that are no longer needed. Perhaps you switched from Mimecast to ProofPoint, or vice-versa. You don’t want to keep confusing information in the environment.
Ideally, you’ll want an Exchange 2016 server in the environment, because it shares a similar look and feel with Office 365 Email Management. This Microsoft guide will help you migrate a legacy Exchange 2010 server environment to Exchange 2016. Once you introduce that server into the environment, you should run the Hybrid Configuration Wizard, information on which is here. This tool will create the necessary federation connections to the Office 365 tenant, letting you make changes to user mailboxes using the on-premises server and then sync those changes to the cloud. You can also use this system to initiate the migration of on-premises mailboxes to Office 365.
Prevalent these days are message hygiene solutions, both on-premises and cloud-based. These include Mimecast, ProofPoint, and Barracuda, to name just three, and all of them offer documentation on integrating with Office 365. Mainly these services simply scan and pass SMTP traffic so there’s little else that need be done. Download the relevant documentation from the vendor and review the Office 365 sections. These will help you configure the service to send email into Office 365 rather than to the on-premises server as well as configuring the outbound connector to send messages from Office 365 into the cloud-based solution.
If you have an existing on-premises hygiene solution, you’ll be getting rid of it because you don’t want your email travelling out of Office 365 to your data center and then out again to the Internet. That’s pretty inefficient. Instead, implement a cloud-based hygiene solution from either your current on-premises vendor or have Microsoft do all the hygiene and data loss prevention (DLP in the parlance) for you.
For many organizations this is going to be the thing that is most visible and takes the most time. You’ll want to gather all the information from your phone service vendor about voicemail-to-email integration (e.g. are you using Cisco, Mitel, Avaya, etc.).
You want to know the locations of all the fax servers because they will need to be reconfigured to send faxes to an Office 365 mailbox rather than to the local Exchange server—not least because the server they currently communicate will be decommissioned as part of this migration exercise (and is almost certainly out of support, anyway).
Gather information about all applications deployed on-premises that need to send email. Your IT help desk system, timesheet system, and expense notifications will all need to start delivering email to Office 365. Document everything and discuss reconfiguring the applications with the service owners at the earliest opportunity. It’s best to get these things ironed out before moving users.
When planning your move to Office 365, one of your decisions will be whether to continue with the distribution groups as-is, or to move to shared mailboxes, or Office 365 groups. Some applications don’t like to communicate with shared mailboxes but instead need a “conventional” mailbox. Don’t just assume you can make an Office 365 shared mailbox for all the applications delivering email because some incompatibility is possible. Research the vendor documentation. Luckily, you can convert from shared to normal and back. Remember that if you convert from a shared mailbox, you will have to assign a license. So it’s in your best interest to maintain a shared mailbox because it’s cheaper for the business.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
|cookielawinfo-checbox-analytics||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".|
|cookielawinfo-checbox-functional||11 months||The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".|
|cookielawinfo-checbox-others||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.|
|cookielawinfo-checkbox-necessary||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".|
|cookielawinfo-checkbox-performance||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".|
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.